FileForums

FileForums (https://fileforums.com/index.php)
-   PC Games (https://fileforums.com/forumdisplay.php?f=6)
-   -   old game crack request.. (https://fileforums.com/showthread.php?t=77018)

pokopo 03-06-2006 10:53

old game crack request..
 
could someone remove the cd-check from this exe (should be only a simple cd check,according to protection-id)? its an old game and it was released only on certain european markets so no crack exists..

it would make my life a bit easier..thanks.

zipped exe

phil8900 03-06-2006 10:58

Hi,
should work:
http://rapidshare.de/files/22119255/phi-owar.rar.html

DABhand 03-06-2006 13:03

Im guessing you changed this


Code:

:00457C6D E8B6E6FAFF  CALL 00406328
:00456C72 83F805      CMP EAX,00000005
:00457C75 753D        JNE 00457CB4  --- CHANGED TO JMP 00457CB4


BarryB 03-06-2006 16:11

Nope!

He changed CMP EAX,00000005 to CMP EAX,00000003, which may or not work depending on the rest of the CD checking routine.

DABhand 03-06-2006 17:56

ack either way, his or my way would have got to the same place :P

phil8900 04-06-2006 03:06

Hi,
yeah, BarryB is right - i couldn't test it, so i just "guessed" ;)

pokopo 04-06-2006 10:55

nope,didnt work,still asks for cd..

phil8900 04-06-2006 11:52

Hi,
is there a file named "data6.owp" on the disc?
Try copying it to the installdir & and try this exe:
http://rapidshare.de/files/22207441/Owar.rar.html

We'll get this game to work without a cd :)

pokopo 06-06-2006 05:19

I'll see if I can find it..thanks.

cdkiller 06-06-2006 07:06

CODE:00459335 loc_459335: ; CODE XREF: sub_4592F8+1Cj
CODE:00459335 ; sub_4592F8+36j
CODE:00459335 call sub_457C2C ---> calls GetDriveTypeA
CODE:0045933A test al, al ---> test al = 0 (if 0 = no cd inserted)
CODE:0045933C jz short loc_459316 ---> patch to jmp, elso bad guy
CODE:0045933E mov eax, esi
CODE:00459340 call sub_458F2C
CODE:00459345 lea eax, [ebp+var_4]
CODE:00459348 call @System@@LStrClr$qqrr17System@AnsiString ; System::__linkproc__ LStrClr(System::AnsiString &)
CODE:0045934D cmp byte ptr [esi+319h], 0
CODE:00459354 jz short loc_459399
CODE:00459356 lea eax, [ebp+var_4]
CODE:00459359 mov edx, offset unk_459508

patching the jz should work so u can play without cd.
if the "pls insert cd blablabla" doesn´t appear ingame u can upload the dlls + exe so it can be debugged.

pokopo 06-06-2006 21:32

nope,the last patched exe from rapidshare doesnt work either..pretty sure the protection is only in the exe file-its possible to use the exe from the demo and the game runs,but its buggy,especially after updating..

The-S-Owl 07-06-2006 01:04

Get a hex editor and change the bytes 8D 45 at raw offset 5704A to EB 47

DABhand 08-06-2006 07:16

You cant change a 3 byte instruction to a 2 byte only, that will screw up the rest of the coding, you have to nop the last byte also.

Besides I dont see why a jump there would help with anything.


You could just nop out


457C6D to 457C76

That would take out the call,cmp and conditional jmp.

The-S-Owl 08-06-2006 12:30

Quote:

Originally Posted by DABhand
You cant change a 3 byte instruction to a 2 byte only, that will screw up the rest of the coding, you have to nop the last byte also.

Congratulations, you have just given the proof that you do not have a clue how a program works.


Quote:

Originally Posted by DABhand
Besides I dont see why a jump there would help with anything.


You could just nop out


457C6D to 457C76

That would take out the call,cmp and conditional jmp.

That will not work.

Time for a REAL lesson in assembly maybe ?

1. If you do not kill the instruction at 457C6C too, the stack pointer will be screwed and the program will crash when it tries to leave the function.
2. In the beginning of the function, the variable [ebp-1] is set to 1. If your patch is applied, the call at 457C8A will always fail (al = 0) since data6.owp will not be found. After doing this check from drive C to Z, [ebp-1] is set to 0 and this value will be given back. Moreover, since the check always fails, the code between 457C93 and 457CB2 is never executed. I have not analyzed what these functions do, but they are executed if the cd-check succeeds, but not when it fails. And that is exactly what my patch does: the cd-check is skipped and these functions are executed without even checking any drive.

DABhand 08-06-2006 23:45

Quote:

Originally Posted by The-S-Owl
Congratulations, you have just given the proof that you do not have a clue how a program works.




That will not work.

Time for a REAL lesson in assembly maybe ?

1. If you do not kill the instruction at 457C6C too, the stack pointer will be screwed and the program will crash when it tries to leave the function.
2. In the beginning of the function, the variable [ebp-1] is set to 1. If your patch is applied, the call at 457C8A will always fail (al = 0) since data6.owp will not be found. After doing this check from drive C to Z, [ebp-1] is set to 0 and this value will be given back. Moreover, since the check always fails, the code between 457C93 and 457CB2 is never executed. I have not analyzed what these functions do, but they are executed if the cd-check succeeds, but not when it fails. And that is exactly what my patch does: the cd-check is skipped and these functions are executed without even checking any drive.



Now let me give you a lesson.



1. You replaced a 3 byte instruction with a 2 byte short jump, there is a byte left over, the coding will then continue making instructions from the 3rd byte you left behind unchecked and screw the rest of the program.

It is basic Assembly and everyone knows this as fact. Besides if I didnt know ASM why have I made code-injected trainers in the past?

2. The previous set of instructions are only shifting values about ready for the CALL op, which is where the GetDriveTypeA API is being used, and if you knew this you will know it returns a value while checking a file if its on a local drive or CD-Rom device, each their own unique number (even the floppy or network devices), then the compare instruction will check this value and if it not the same value, the Zero Flag is set and the Conditional Jump comes into effect.

My first post was wrong I will admit that as I only looked over it for a few seconds.


When GetDriveTypeA is executed it will return a value of 3 for Hard Disk and 5 for CD-Rom, since the compare is checking this value with 5, I therefore figured out that the JMP will goto the Bad Boy and show the InsertCD message. Therefor nop'ing out the CALL - JNE ops it will miss the whole checking sequence and carry on and hopefully start the game, but the GetDriveTypeA could be called elsewhere in the coding and has to be changed also.


EBP is a Base Pointer and not the actual Stack itself which is ESP. If you check the GetDriveTypeA API you will see the stack itself is not changed in any way. So therefor the Stack is perfectly fine as it is.

DABhand 09-06-2006 01:52

For the poster try this http://www.vwaskar.pwp.blueyonder.co.uk/fun/Owar.rar


Overwrite the file in the game folder, and also copy the file data6.owp into the same folder along with the crack.

I dont have the game to test it, but it seems to be the root folder of the game this data file goes to.

Or do a quick search of the games' sub folders for other .owp files, and place it there also.

pokopo 12-06-2006 11:25

nope,still no go.the last exe says something stupid about the game not being installed (it is,of course),and quits with "please insert install cd" message..all owp files are in the "disk2" folder (in the main game folder),the game is not accesing any data from cd,its just doing a cd check when it starts,thats all..

2 all with the hexedit advices: sorry guys,but I'm obviously too lame to crack it myself,thats why I'm asking for your help ;)

The-S-Owl 12-06-2006 12:12

Give this a try:

http://rapidshare.de/files/22606113/...s-owl.rar.html

DABhand 13-06-2006 03:38

I changed mine a bit also, this time with registry checking etc. (seems its looking for a full.dll file also - if not in game folder/sub-folder you may need to get it from cd and copy into game folder)

www.vwaskar.pwp.blueyonder.co.uk/fun/Owarv2.rar

TippeX 13-06-2006 04:45

hmm all the pissing contests, you're doing it the wrong way...

Patch the proc, NOT the conditional...

.00457C2C is the proc i think (couldnt download exe, link expired, so i had to look at phils exe, nice tagging -> do the tags AFTER the crack works...)

looks like a simple true / false proc...

so a 33 C0 40 C3 should do the job... cant test, aint got all the files...

will do later, if someone wants to put the link up with the files needed to run
the exe until the msgbox appears or whatever...

-----

1. You replaced a 3 byte instruction with a 2 byte short jump, there is a byte left over, the coding will then continue making instructions from the 3rd byte you left behind unchecked and screw the rest of the program.

may/may not matter, depending on the code execution path, if the short jump is a forced jump, EB xx, then the extra byte should never be executed, unless theres a conditional above the part you patch that can branch past it..

-------

EBP is a Base Pointer and not the actual Stack itself which is ESP. If you check the GetDriveTypeA API you will see the stack itself is not changed in any way. So therefor the Stack is perfectly fine as it is.

-------

ebp is a FRAME and holds the stack pointer on entry of the proc...

typically looks like

push ebp
mov ebp,esp
blah blah blah

then can end with a...

mov ebp,esp
pop ebp
ret xx

or leave
ret xx

EBP is important especially within framed procs like this one, calling an api within the ebp frame doesnt matter, the cleanup at the end of the proc RELIES on the stack not being fucked, as it has to pop ebp, and set esp from ebp...

lessons... blind leading the blind more like...

DABhand 13-06-2006 04:54

Like I said, EBP is a Base Pointer for ESP yes, and like I said the GetDriveTypeA is not harming the stack. EDIT: Not everything uses stack frames, they can use local data too as in callbacks.



Thats correct on the 3 > 2byte, but on most occassions the byte left if it were a 74 then the coding will then take the next few bytes of the next op to make a je instruction which would then feck up the rest of the coding :) But as you know most nop the estranged byte/s to make sure.

DABhand 13-06-2006 04:55

Quote:

Originally Posted by TippeX
hmm all the pissing contests, you're doing it the wrong way...

Patch the proc, NOT the conditional...

.00457C2C is the proc i think (couldnt download exe, link expired, so i had to look at phils exe, nice tagging -> do the tags AFTER the crack works...)

looks like a simple true / false proc...

so a 33 C0 40 C3 should do the job... cant test, aint got all the files...

will do later, if someone wants to put the link up with the files needed to run
the exe until the msgbox appears or whatever...


Relies, it seems on 2 files and registry entry. data6.owp and full.dll and as I said the Software/Owar branch.

phil8900 13-06-2006 05:41

Hi,
@TippeX: If i had the game i would have testet it ;)

TippeX 13-06-2006 06:50

my comment was that you probably spent more time puting in your tags :), as for testing, thats the job of the guy who wanted the crack


All times are GMT -7. The time now is 08:07.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
FileForums @ https://fileforums.com