im trying to crack an app so that it will accept any registration key i enter and iv been able to isolate the bytes i need to change and when i test it in my debugger it works fine and excepts any reg code i enter.

the weird thing is, when i open it with my Hex editor then and change the bytes and then re-launch the app it just quits before even displaying a window.

I have an IsDebugPresent plugin to hide my debugger (OllyDbg) and im not sure why it works when i test it in my debugger but not when i hex it... so any ideas of stuff i should look for?

thnx for any help
_Ecks

This usually happens when the app has another registration check at
the initialization phase. You need to trace into the app and see what
it does after it accepts fake registration code. Or you can look for similar
code pattern as the registration code check routine. It's highly likely
that the reg code check routine is called multiple times, so you can also
look for "CALL 00423b7D" (for example) in your disassembler.

Another posiblility is that the application checks for the integrity of the file you modifyied early during the start process:

When you do the changes with the debugger, the check has already occurred and passed , so it is OK, but when you modif the exe file with your hex editor the app catches the change and quits on you.
Search for crc checks in this board and in google, also look for program exit APIs like PostQuitMessage and the like. . .

iv looked around and understand more about the crc checks now but cant locate one in my target file....

iv searched for CreateFile apis and ExitProcess and so fourth but i have no idea were the routine is, so is there any tips or ideas for things i should look for?

(this is only my second app i'v ever cracked on my own so bare with me ;P)

When doing an integrity check on the file, there's two options (not excluding ones):
- you can check the file on disk
- you can check the loaded file

Per the first, you should look for functions that open and read the file. There's quite a few, so you'll have to do some searching. However, if the file you're working on is not packed or encrypted (it would seem not, since you can patch it), disassemble with Ida or w32dasm and look for suspects.

Per the second, try and put a memory breakpoint on the place for the patch. If the file is doing an integrity check on itself in mem, it should trigger a memory breakpoint.

If both of these fail, I'd recommend taking Homersux' advice and go looking for another place of serialcheck.

Fake