Aimless
October 31st, 2012, 06:41
Quote:
[Originally Posted by anthrazius;93540]
Now I wrote a starter programm that injects an emulation code into the programm that does exactly the same thing as the Olly-script and it doesn't work anymore. Somehow the program detects the injected code and changes the input to the dongle. I tried to figure out the detection mechanism but can't find anything.
|
Two questions please:
1. What does your emulation program do specifically in terms of registers and memory locations?
2. What does ollydbg do specifically in terms of registers and memory locations?
While you still have a long way to go, I have a couple of road-signs you might want to try taking:
1. There must an EIP address, up to which, the code is executing correctly when you are in ollydbg and then a set of code instructions (as yet unknown) that must be checking whether you are modifying the code in memory (hundreds upon thousands of ways to check that, actually, don't bother trying to find out which one). Since it runs well in Ollydbg, there must be a certain CODEPATH that the program takes when running under ollydbg and certain memory locations and registers at certain points in time must need certain values to be present. What you therefore need, is a dump (yes, an ENTIRE disassembly) of the program path including modification of memory locs and registers. Easy to do, because Olly provides that support.
2. Since you are now running a LOADER program next, that INJECTS code into the existing memory, something is getting modified somewhere. And the program knows it. The point here is: Even though the program knows it, there will an EIP address up to which the code will execute correctly. AFTER a certain IP, of course the program will go on a DIFFERENT CODEPATH to the one you've just recorded above. So what do you do? Well, for starters, you could run YOUR starter program in Ollydbg and get the entire assembly listing to see what it's doing. ALTERNATIVELY, you could run it in IDA PRO and debug it. Either way, you'll get a COMPLETE DISASSEMBLY LISTING of the erroneous program, with register and memory values.
3. Now since, you have the CORRECT PATH listing and the ERROR PATH listing, it all remains to compare using a DIFF utility (of your choice) or MANUALLY comparing where the CODEPATHS diverge.
4. What you have now, is the location of the routine that CHECKS to ensure that the inmemory contents of the dongle are not tampered with.
5. THEN, once you've LOCATED the offending code, it's a simply matter of bypassing it.
As someone used to say. Cracking is not difficult. Knowing WHERE to crack, is.
Have Phun,
