old game crack request..

[The-S-Owl]

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.

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]

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]

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]

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]

Give this a try:

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

[DABhand]

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]

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...