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.