[F]aster [U]niversal [U]npacker

Crosspost from: http://pastafr0la.wordpress.com/2011/02/18/probando/

Thanks to “El Tio Pastafrola” for the contribution!.

Hello buddies!, today, i bring you a little review about the PFE packer v0.1 wich one i did my first steps with TitanEngine and FUU.

First of all, take a look at the packer’s GUI:

We’ll pack a calc.exe with all the options to the maximum just to do a little test with it.

As we can see in the picture bellow, this packer runs in two separate processes:

So, we loaded it into Olly and search for all the calls to CreateProcessA to land in packer’s hot zone

This is the hot zone, we can see how the child process is created in a suspended mode, then, it allocates memory and finally it writes some stuffs in the childs’ memory 🙂

Lets put a BPX in WriteProcessMemory that follows the VirtualAllocEx and look what it has in the buffer

The MZ signature you can see is the one that match our protected exe, in our case, calc.exe. This means that we wont to work with the second process because the first
process gives us the second process served on a silver platter.

The only thing we need to do is to align  and dump.

For the alignment, the only thing we need to do is to change the Raw Offset and Raw Size of each section for the corresponding VirtualOffset and VirtualSize.

Then, we can dump the whole memory with the IsDebuggerPresent plugin:

Finally, we have a fully functional and valid PE.

We can automate this task very easily with TitanEngine. We only need to follow these steps:

• Set a breakpoint on WriteProcessMemory with the SetAPIBreakPoint function.
• To define a callback function to set the breakpoint, align the PE image and dump the memory.

We don’t need to worry about to dump all the memory regions neither because TitanEngine gives us the DumpMemory function.

That’s all folks, is an easy packer as long as we attack the first process. In my first tests, i started to work with the second process and i have to admit that it was a very hard task to work with the two processes at the time because the SDK doesn’t provided us with good functions to deal with.

All this process was automated in the following plugin: bin src

ps. For those who are interested into create a plugin for FUU i give you the good news that the _DoUnpack function is no longer neccessary as our first callback.  Now, we can directly call the InitDebugEx becuse its last argument let us define a BPX that will run when it reach the debuggee’s callback.

Keep in mind this because if you try to set a BPX in an API without calling the DebugLoop function, it will not process  the LOAD_DLL (code exception: 6) event, therefor you will not be able to set the breakpoint because the DLLs are not yet loaded.

Hi!,

after a while without any post of any kind, we are back!. This time is to let you know about another plugin update for FUU. This new plugin is for PeX, currently, we support PeX 0.99 but if you want us to support another version just send us the sample 🙂

I will show you just a few things about this simple packer.

This is the EP of PeX 0.99. If you look at the address where we are, you’ll see that the addresses belongs to the SFX section of the packed executable:

This is just the first “layer” of the packer.

We have this other piece of code where the addresses change drastically:

If you look at the [ESP], you’ll see RETF address:

In this case, 0x330000 is the address where the second layer will be executed, where imports are redirected and the JMP to the OEP is taken.

Then, we have the place where the IAT is redirected, here LoadLibrary is called to load into memory all the DLLs imported by the packed executable file:

Then, we have the GetProcAddress code that get all the imported functions from the packed file:

After this code is executed (redirection table), when we reach the OEP, we will see that all the indirect jumps from the IAT are redirected:

To fix the IAT wen can write a script for ODBScript (or OllyScript) by getting the original values from registers and overwrite the bad pointers with the good ones or simply look for the “magic” jump (yes, PeX has a magic jump that avoid the IAT redirection like many other packers):

we can find this jump by tracing the code mentioned above (GetProcAddress and LoadLibrary procedures) and analyzing it 😛

The last thing is the code that reach the OEP:

if we trace that piece of code, we’ll see that that the PUSH-RET combination will take the OEP’s address at the top of ESP:

This is just the value in the PUSH above plus 1:

That’s all folks!.

If you have any doubt, just email me!.

As always, all comments are welcome 😛

Here, you have the unpacker for PeX (dePeX) (binary) and here the sources.

See you soon!.

Hi there!,

as i promised, here is another post about another plugin for FUU. This time i will talk about MEW.

MEW is a simple packer without any dirty trick , so, it is quite simple to unpack it and program an unpacker using TE.

Let’s see MEW11:

This is the EP of MEW11. Here, we can just follow the JMP using GetJumpDestination function from the TE SDK and looking at the end of the code we will see a RET instruction:

just setting a breakpoint at the RET and running the process we will break in the right moment when MEW11 will jump to the OEP of the program:

ESP register is pointing to the OEP address, so, we can read this value from ESP to get the OEP address.

The IAT is not a problem here. We can find the CALLs to LoadLibraryA and GetProcAddress just some bytes before the JMP to the OEP:

We can use the Find() function to search for the patterns but instead of that we can use ImporterAutoSearchIAT and ImporterAutoFixIAT to search and fix the IAT.

With other version of MEW it is the same thing, no big changes.

You can download the deMew plugin code in fuu SVN: http://code.google.com/p/fuu/source/browse/#svn/trunk/src/x86/Plugins/deMew

See you soon!.

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.