New FUU plugin – deExeFog!

Hello!,

those who know me know that i’m always trying to do something, writing a tutorial, programming a tool, etc; today, i want to do a thing: for every new FUU plugin i will program, i’ll write a post here to talk about packer tricks and those importants pieces of code to indentify in an easy way witch are the
“hot” zones in the packer.

In this first post, i will talk about a simple packer, exeFog, to be more accurate, exeFog v1.x, i really don’t if there is another version available to download but if you have one different from this, please, send it to me and i will update the plugin to support newer version.

Btw, the idea of this and the future post is not to write a detailed analysis (as you probably know i always do that in avery of my tutorials) but the idea is to look just the important parts like IAT rebuild and OEP’s Jmp.

i will take this unpackme as sample: http://www.tuts4you.com/request.php?1093

well, if we load the unpackme in Olly and hit F9 (Run), we’ll see Olly died in an exception, more specifically, DIVISION_BY_ZERO:

This is due an old anti-dbg trick known as IsDebuggerPresent but in this case, the packer is not calling directly to the API IsDebuggerPresent, it has an inline
code to perform IsDebuggerPresent.

If we trace, we’ll see that we reach a loop that performs the decryption of some part of the code:

As you can see, first, it puts a pointer in EBX, then in ECX an offset (0x3c8) and in AL the xor key (0x8c), after that, it indexs EBX+ECX and xors every byte in AL.

After this, we reach the IsDebuggerPresent inline code:

As you probably guessed, it is just reading the “BeingDebugged” heap’s flag in the PEB of the process:

typedef struct _PEB {
BYTE                          Reserved1[2];
BYTE                          BeingDebugged;
BYTE                          Reserved2[1];
PVOID                         Reserved3[2];
PPEB_LDR_DATA                 Ldr;
PRTL_USER_PROCESS_PARAMETERS  ProcessParameters;
BYTE                          Reserved4[104];
PVOID                         Reserved5[52];
PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;
BYTE                          Reserved6[128];
PVOID                         Reserved7[1];
ULONG                         SessionId;
} PEB, *PPEB;

The flag is in PEB[2] (movzx eax, byte ptr ds:[eax+2]).

It tooks the flag, then it does a NOT followed bye an AND with 1, so, if the flag is 1 (process being debugged), the result would be 0, and if the flag is 0 (process is not being debugged), it would be 1.

so, where is the trick? this value is used as divisor and dividend in a division a little bit later:

As we seen, the result for the operation is moved to EBX but also in EAX, so, when you do the NOT and AND with 1 then you have 0 / 0 = ERROR!!!.

To solve this, you simply need to set the flag to 0 so the result will be 1. We can do it in a lot of ways, but the fastest way is when we are in the EP of the packer and the hit CTRL+G and put EBX, then we change the value in the second byte to 0. Why is this? well, simple answer, EBX is always pointing to the PEB’s process when we are debugging a process an we are in the EP:

The, we have two more important parts:

1) where the imports are resolved.
2) where the OEP jmp is performed.

both zones are easy to find, just look at the code and we will see that here is where the packer resolve the imported dlls:

if we look at the registers in this moment, we can see that EBX holds a pointer to the imported dll’s name:

After that, we’ll see how it resolves the imported functions for every dll:

and if we llok at the registers, we’ll see that EAX holds a pointer to the name of the imported funciont and EDI holds a pointer to the place in the IAT where the function pointer should be placed:

before to continue, i want to tell you taht exeFog does some tests in the first bytes of every API it will use (to see if there is a breakppiont there):

There, we can see an example of what i mention before about breakpoint test.

well, finally, this is the place where the packer goes to the OEP:

when you are in the ADD instruction, ESP holds an offset to the EP and EBP holds the ImageBase of the program, so, when you ADD the EP to the ImageBase and hit the RET, you get the OEP address:

To do this plugin you need a couple of steps:

1) search for the xor pattern first.
2) trace over the xor pattern and search for the piece of code that resolves the dlls names, functions names, OEP jmp and the inline code for IsDebuggerPresent. i do this by setting callbacks for every event.
3) when the IsdebuggerPresent callback is reached, the only thing i do is to put 1 in EAX.
4) when the LoadLibraryA callback is reached, i take the value in EAX and add it to the IAT.
5) when the GetProcAddress callback is reached i take the values from EAX and EDI and i add it to the IAT.

you can get the plugin here:http://tinyurl.com/2arrnct

sources for the plugin here: http://tinyurl.com/2wz5bty

See you in the next post!.

ps. sorry for my ugly english, if you find a mistake, please, report it.