Using DLL Injection to Automatically Unpack Malware

In this post, I will present DLL injection by means of automatically unpacking malware. But first, the most important question:

What is DLL Injection and Reasons for Injecting a DLL

DLL injection is one way of executing code in the context of another process. There are other techniques to execute code in another process, but essentially this is the easiest way to do it. As a DLL brings nifty features like automatic relocation of code good testability, you don't have to reinvent the wheel and do everything on your own.

But why should you want to injecting a DLL into a foreign process? There are lots of reasons to inject a DLL. As you are within the process address space, you have full control over the process. You can read and write arbitrary memory locations, set hooks etc. with unsurpassed performance. You could basically do the same with a debugger, but it is way more convenient to do it in an injected DLL.

 Some showcases are:

• creation of cheats, trainers
• extracting passwords and encryption keys
• unpacking packed/encrypted executables

To me, especially the opportunity of unpacking and decrypting malware is very interesting. Basically, most malware samples are packed by the same packer or family of packers. In the following, I will shortly summarize how it works.

 

The Malware Packer

 In order to evade anti-virus detection, the authors of the packer have devised an interesting unpacking procedure. Roughly, it can be summarized in the following stages:

1. First, the unpacker stub does some inconspicuously looking stuff in order to thwart AV detection. The code is slightly obfuscated, but not as strong as to raise suspicion. Actually, the code that is being executed decrypts parts of the executable and jumps to it by self-modifying code. In the snippet below, you see how exactly the code is modified. The first instruction of the function that is supposedly called is changed to a jump to the newly decrypted code.
   
   mov [ebp+var_1], 0F6h
   mov al, [ebp+var_1]
   mov ecx, ptr_to_function
   xor al, 0A1h
   sub al, 6Eh
   mov [ecx], al ; =0xE9
   mov ecx, ptr_to_function
   ...
   mov [ecx+1], eax ; delta to decrypted code
   ...
   call eax
   
   As you can see (after doing some math), an unconditional near jmp is inserted right at the beginning of the function to be called. Hence, by calling a supposedly normal function, the decrypted code is executed.
    
2. The decrypted stub allocates some memory and copies the whole executable to that memory. Them it does some relocation (as the base address has changed) and executes the entry point of executable. In the following code excerpt, you can see the generic calculation of the entry point:
   
   mov edx, [ebp+newImageBase]
   mov ecx, [edx+3Ch] ; e_lfanew
   add ecx, edx ; get PE header
   ...
   mov ebx, [ecx+28h] ; get AddressOfEntryPoint
   add ebx, edx ; add imageBase
   ...
   mov [ebp+vaOfEntryPoint], ebx
   ...
   mov ebx, [ebp+vaOfEntryPoint]
   ...
   call ebx
   
   
   
   
3. Here, the next stage begins. At first glance it seems the same code is executed twice, but naturally, there's a deviation in control flow.
   
   For example, the the packer authors had to make sure that the encrypted code doesn't get decrypted twice. For that, they declared a global variable which in this sample initially holds the value 0x6E6C82B7. So upon first execution, the variable alreadyDecrypted is set to zero.
   
   mov eax, alreadyDecrypted
   cmp eax, 6E6C82B7h
   jnz dontInitialize
   ...
   mov alreadyDecrypted, 0
   dontInitialize:
   ...
   
   In the decryption function, that variable is checked for zero, as you can see/calculate in the following snippet:
   
   mov [ebp+const_0DF2EF03], 0DF2EF03h
   mov edi, 75683572h
   mov esi, 789ADA71h
   mov eax, [ebp+const_0DF2EF03]
   mov ecx, alreadyDecrypted
   xor eax, edi
   sub eax, esi
   cmp eax, ecx ; eax = 0
   jnz dontDecrypt
   
   Once more, you see the obfuscation employed by the packer.
   
   Then, a lengthy function is executed that takes care of the actual unpacking process. It comprises the following steps:
   
   • gather chunks of the packed program from the executable memory space
   • BASE64-decode it
   • decompress it
   • write it section by section to the original executable's memory space, effectively overwriting all of the original code
   • fix imports etc. 
   
   After that, the OEP (original entry point) is called.
   
   The image below depicts a typical OEP of an unspecified malware. Note that after a call to some initialization function, the first API function it calls is SetErrorMode.
   
   

   

   Code at the OEP

   
   

   
   

Weaknesses

What are possible points to attack the unpacking process? Basically, you can grab the unpacked binary at two points:

• first, when it is completely unpacked on the heap, but not yet written to the original executable's image space, and 
• second, once the malware has reached its OEP.

The second option is the most common and generic one when unpacking binaries, so I will explain that one. Naturally, you can write a static unpacker and perhaps one of my future posts will deal with that.

One of the largest weaknesses are the memory allocations and setting the appropriate access rights. As a matter of fact, in order to write to the original executable's memory, the unpacker grants RWE access to the whole image space. Hence, it has no problems accessing and executing all data and code contained in it.

If you set a breakpoint on VirtualProtect, you will see what I mean. There are very distinct calls to this function and the one setting the appropriate rights to the whole image space really sticks out.

After a little research, I found two articles dealing with the unpacking process of  the packer (here and here), but both seem not aware that the technique presented in the following is really easily implemented.

Once you have reached the VirtualProtect call that changes the access rights to RWE, you can change the flags to RW-only, hence execution of the unpacked binary will not be possible. So, once the unpacker tries to jump to the OEP, an exception will be raised due to missing execution rights.

So, now that we know the correct location where to break the packer, how to unpack malware automatically?

Here DLL injection enters the scene. The basic idea is very simple:

• start the binary in suspended state
• inject a DLL
• this DLL sets a hook on VirtualProtect, changing RWE  to RW at the correct place
• as backup, a hook on SetErrorMode is set. Hence, when encountering unknown packers, the binary won't be executed for too long.
• resume the process

Some other things have to be taken care of, like correctly dumping the process and rebuilding imports, but these are out of the scope of this article. If you encounter them yourself and don't know how to handle them, just ask me ;-)

It seems not too easy to find a decent DLL injector. Especially, one that injects a DLL before the program starts (if there is one around, please tell me). As I could not find an injector that is capable of injecting right at program start, I coded my own. You can find it at my GitHub page. It uses code from Jan Newger, so kudos to him. I'm particularly fond of using test-driven development employing the googletest framework ;-)

Conclusion

The presented technique works very well against the unpacker. So far, I've encountered about 50 samples and almost all can be unpacked using this technique. Furthermore, all unpackers that overwrite the original executable's image space can be unpacked by this technique. In future posts, I will evaluate this technique against other packers.