old game crack request..

[The-S-Owl]

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

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

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]

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