rendari

Anyways, I was playing around with a funny target today after school. Its got a bunch of features; I usually break one of them per week This week's "feature to break" was something I have dubbed advanced API redirection.

Pretty much, what the protection does is take a huge routine of the target program, and stores it in a new section. There it replaces a bunch of the FF 15 calls with its own sort of 'macro', which calls into the protector code, where the protector then does whatever protectors do, and forwards it to the correct api. Here is a good example similar to what I am talking about:

Original code:

Code:

...
PUSH 00401000  
CALL DWORD PTR[11223344] ; VirtualAlloc
...

After protection process:

Code:

...
PUSHFD
PUSH EAX
MOV DWORD PTR[ESP], 1EEDDF40
XOR DWORD PTR[ESP], 1EADCF40
POPFD
PUSH 50010007
MOV EAX, _protector_routine
CALL EAX
...

Note:
the push 50010007 was just a pointer to an identifier used by the protector to see which API to forward to...

Now this is pretty basic stuff, right? Just search for a byte pattern, execute it, let the code execute up to some hook you have in the code of the protector, where EAX will hold the correct API address, and then just NOP out the entire thing above and replace it with a FF 15 <correct addr>. If you want to be extra neat you could also resolve the XORing obfuscation above to the correct command before obfuscation, which was:
push 00401000

Well, the thing is, this protector added a bit o spice to the game. Instead of having just one type of routine that is used for API handling, they used five types. So the above routine could also be:

Code:

PUSH 00401000  
PUSH 50010007
PUSH EAX
MOV DWORD PTR[ESP], EDX
MOV DWORD PTR[ESP], xxxxxxxx
XOR DWORD PTR[ESP], xxxxxxxx
POP EAX
CALL EAX

and then you have 3 other types of routines that the protector can replace the original call with...

Now, the trick in the protection is that you have to find and record the byte patterns for all 5 of these routines, and then subsequently fix them back to call dword <correct addr>.

So, fixing this protection is a two step process:
1) Identify all of the protector calls
2) fixing them one by one.

It is easily automated and fixed, once you have spent an hour hunting down the random crashes in your dump caused because your code has missed one of the protector calls.

But this got me thinking. What if the protection devs were to add metamorphoses? It shouldn't be hard to write a metamorphic code generator to morph the above 5 routines into even more complex routines.

Consider: only a couple of the same commands are being used in each of the protector routines:
CALL EAX...
MOV DWORD PTR[ESP], xxxxxxx
XOR DWORD PTR[ESP], xxxxxxx
....

and so on.

Now, what if for each of those instructions your metamorphic code generator could morph into 4 different code chunks? For example, the CALL EAX could be morphed into:

Code:

PUSH EAX
CALL _geteip
_geteip:
POP EAX
ADD AL, 9
XCHG DWORD PTR SS:[ESP],EAX
JMP EAX
db 0FF

or

Code:

PUSH EAX
call _geteip
_geteip:
POP EAX
ADD EAX, 0F
MOV WORD PTR[EAX], 0D0FFh
MOV EAX, DWORD PTR[ESP]
ADD ESP, 4
NOP
NOP

and so on...

Now lets assume that the devs took a couple of hours and coded this simple metamorphic code generator. Now all they have to do is:
a) protect each call dword ptr with the old method (using one of the 5 possible protector routines)
b) mark the offsets of each protected CALL in a list for later use
c) after all the CALL DWORD's have been protected via the old method, take your metamorphic code generator and feed it the list of offsets of protected CALLS, and let it morph each protector routine to a new one.

After it is done morphing, every single protector routine should be unique. This will throw a wrench in the prospective hacker's plans, because he can no longer easily identify all the protected CALLs that he needs to fix.

Anyways, this was just an idea I had kicking around in my head for some time. Hope that someone could actually understand it.

I'll re read this blog post and fix any errors in it later today.