old game crack request..

[pokopo]

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

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

[DABhand]

Im guessing you changed this

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

[BarryB]

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]

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

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

[pokopo]

nope,didnt work,still asks for cd..

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]

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

[cdkiller]

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]

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]

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.