10.12
After one week detour to reversing tool coding field we return to what TitanEngine does best which making unpackers of course. This week we take a peek into what hides in the fog, exeFog.
Being a relatively simple shell modifier it must be classified as a protector. I know that most of you wold disagree because this shell modifier is a simple one but it has all the characteristics of an protector so we have no choice but to call it one. What does it have? It compresses the PE file with aplib algorithm, encrypts the file, processes the import table and makes use of simple anti debugging features. Maybe advanced crypter or just a packer?
Can't wait to have some fun? Me neither. Lets load up some samples and make them sing our tune.
Entry point looks like there is a loader decryption going on but its all an optical illusion. Take a closer look at:
PUSH ECX L001: MOVZX ECX,CL ROR ESP,80 LEA ECX,DWORD PTR DS:[ECX] NOP PUSH EBX JB L009 JNS L009 ADD EBX,0 L009: POP EBX CMP SI,6C CLC DEC ECX INC ECX STC CLD CMC LOOPD L001
It doesn't do anything except execute 0xFF times trying to confuse us. Or possibly break an emulator or two? Never the less we trace some more until we find first and the only stub decryption code.
MOV EBX,00406E57 MOV ECX,3C8 MOV AL,0A0 L003: XOR BYTE PTR DS:[EBX+ECX],AL MOV AL,BYTE PTR DS:[EBX+ECX] LOOPD L003
We simply place a hardware breakpoint on execution for the next "call" instruction and hit run. After this has been executed we see that our "call" was indeed a CALL but after it has been decrypted it lead to a more plausible location. What comes next is an interesting approach to an old anti debugging trick. Here we have to pay close attention to what is going on:
XOR ECX,ECX ADD ECX,10 MOV EBX,77FFFFFF MOV EAX,DWORD PTR FS:[EBX+88000019] ;TEB MOV EAX,DWORD PTR DS:[EAX+ECX*2+10] ;PEB MOVZX EAX,BYTE PTR DS:[EAX+2] ;BeingDebugged NOT EAX AND EAX,1 MOV EBX,EAX PUSH 0C3FBF6 CALL L011 L011: SUB DWORD PTR SS:[ESP],33 MOV ESI,ESP ADD ESI,4 JMP NEAR ESI ;Crash the debugger (safely)
This is a simple PEB.BeingDebugged trick but if you trace the code and your debugger isn't hidden from this you will end up executing JMP ESI which leads to IDIV BL instruction. Why is this bad? Because if the program is being debugged processor will need to divide AL with BL which would be fine if they weren't set to NULL. In math we can handle such cases but processor doen't know how to do this and generates an exception which can't be passed making the target terminates itself. To skip this we can either hide our debugger with OllyDBG plugins or manually set EAX to NULL after the BeingDebugged line.
PUSH EAX LEA EDX,DWORD PTR SS:[EBP+1000] PUSH EAX PUSH EDX CALL 00407173 ; decompress aplib data ADD ESP,8 MOV EAX,DWORD PTR SS:[ESP] MOV ECX,EDI DEC ECX MOV EDX,EAX PUSH ESI LEA ESI,DWORD PTR SS:[EBP+1000] L012: MOV AL,BYTE PTR DS:[EDX+ECX] ; write decompressed data MOV BYTE PTR DS:[ESI+ECX],AL LOOPD L012
Further tracing leads us to this point where exeFog decompresses the main section and writes it to its original location. Following this is a code which frees up temporary memory and creates a unique mutex which ensure that only one copy of the protected file is running at the same time. This is an option set in exeFog before the file was protected, but that doesn't have an impact on what we are doing. However next code does:
MOV EBX,0040445C MOV ECX,3C MOV AL,1B L003: XOR BYTE PTR DS:[EBX+ECX],AL LOOPD L003
What is interesting about this code is that it only decrypts a small piece of memory, and that piece of memory is the exact size of three IIDs. After the code is decrypted we take a look at the decrypted memory and find out that imports are at their original location and that only the IIDs were encrypted meaning that we can just skip the import processing in our unpacker and read the data from the decryptor above in order to set the import table address and size. But for exercise purposes we decided to use our importer module and make this a full dynamic unpacker with the full use of importer module. Code that exeFog uses to process the import table is located just below this decryptor and you can easily analyze it to figure out where to set the breakpoints.
Which only leaves the last piece of the puzzle, and that is always... How does it jump to entry point (and is it protected)?
PUSH 12C0 ;Entry point relative virtual address TEST EAX,EAX PUSH EBX PUSH EDI PUSH EAX ADD SI,0 POP EAX POP EDI POP EBX NOP SUB DL,0 ADD DWORD PTR SS:[ESP],EBP RET ; Jump to OEP
Just after the code for import filling exeFog store the code above which is in-charge of jumping to the entry point. As you can see the PUSH instruction hold the relative virtual address of the entry point, and once the last RET instruction is executed exeFog passes control to the original entry point and continues the execution of protected file.
Writing an unpacker for exeFog should be an easy task since there are just a few things to look out for. As always unpacker, source code and the samples are included with the blog. Until next week...
TitanEngine ReversingLabs Corporation |
RL!deExeFog |
