PDA

View Full Version : code injection detection


anthrazius
October 27th, 2012, 05:49
Hi,

I am running a certain dongle-protected program without dongle by emulating the dongle within a Ollydbg script. It works everytime because the program uses the same input-output buffers for the dongle protection.

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.

Maybe you guys can give me hints about detection techniques for code detection.

Best regards
Anthrazius

FoxB
October 27th, 2012, 10:02
tell us type of the dongle

anthrazius
October 27th, 2012, 13:10
Its a HASP dongle, not sure about the version right now.
No envelope, just API.

Regards

anthrazius
October 31st, 2012, 05:49
No help from the experts?

FoxB
October 31st, 2012, 06:22
check sum of the executable, crc some block inside executable file, size of file, number of sections, etc.
if the developer is not lazzy =)

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,

Indy
October 31st, 2012, 07:34
..

anthrazius
October 31st, 2012, 10:24
Thanks for your answers.

I'm not changing the protected program at all in memory, so CRC, ... cannot be the reason.

Its the usual VirtualAllocEx, WriteMemory,...CreateRemoteThread...
The injected code hooks some DLL functions and then just sits there and waits.

Surely the program flow of the protected program with and without injected code is different, that's kind of obvious.

But the only 'intrusion' into the address space of the target is the allocated memory for the injected code and the DLL-hooks.
Can you give me some hints how the program could detect that? The protected program does not check for hooked DLL-functions, I verified that with Olly.

I will try the procedure proposed by Aimless, but only as a last last resort, it seems to be kind of an overkill, at least for me.

Best regards

anthrazius
November 1st, 2012, 10:44
Sorry Indy, didn't understand a word you were writing...

In case it was something useful, maybe you could put it in a way that laypeople can understand

regards