Unpack Hands by Hands

One day, I found that peid showed me the wrong packer information. Here, I decided to unpack the exe by my own hands.

When do I find that I need to unpack by myself

As usual, I open my ida for static analysis after I got a executable file. However,

What a fuck is this? Apparently the executable file might be obfuscated or packed. Therefore, I open the PEiD for check

ez! But when I tried to unpack it with tool

Just like the screenshot above showed, file is modified/hacked/protected. In other words, although peid has high accuracy to identify the signature of packer, this condition still happened. The file might be a scrambled upx or not upx, I need to unpack it by my own hands.
Before starting on work, the concept of packer is important. Packer can be categorized to compression-packer or encrypted-packer, and just like their names, the purpose they focus on are different.
What is OEP? OEP is the Original Entry Point, the start point of program. Packer always hides the OEP for obfuscation, so it is also our first mission to find the true-OEP!
How exe file works with packer? Packer doesn’t have any impact on the execution on file. Here I would compare the packer to a cloth. When we execute the file, the naked-file would decrypt itself and load into memory. Therefore, we cannot see the decrypted data even though it can execute normally.
In other words, if we can catch the true-OEP, we have the opportunity to dump the naked-file and fix it.

Find the true OEP

In fact, there are many ways to find the true OEP. Here I only introduce one way: find command POPAD. Some packers will use PUSHAD to push all the registers onto the stack before decrypting themselves, and use POPAD to pop out all the registers after decrypt finished. Here, it is the best time for us to catch the true OEP!

I found the command PUSHAD at the very beginning of the file, which means the exe start to decrypt itself. Then I search for the command POPAD and set breakpoint directly. After the file continued from PUSHAD and stopped at the POPAD, I found a big JUMP after the command. (Just like the screenshot above, POPAD is at the address 0x406B9D, big jump is at the address 0x406BAB). Ok, we found the true-OEP which was the address exe jumped to: 0x40133C. We can trace into to make sure how the entry point looks like

There is a call at the start line of the entry point, let’s trace into the call

Nice! That is the function prologue which we are familiar with, it also means we found a right entry point.

Dumpling exe

After we found the true-OEP, we can dump our file with the tool LordPE. Here, please remember to open with administrator! You can find the running process in the list, and right click to make a full dump.

This is the dump of process which started from the true OEP. If we try to execute the file, the error message will pop out with application address error. The reason is that we still not correct the IAT.

Correct IAT and fix dump

What is IAT? It is Import Address Table, which memory the address of imported API calls(e.g. Kernel32.dll). Therefore, it’s also our mission to fix the address of imported functions.
Open the tool ImportREC, again find the active process. In the bottom side, fill in the true-OEP you found(Fill out with the entrypoint RVA, that’s the reason for 0x133C in the picture). Next, click IAT AutoSearch, it would automatically correct the information of RVA and Size of IAT(If your OEP is right, it would pop out a window of found something! just like following picture). Here comes the last step, click the button GetImports, and it should show all imported functions valid in the window.

Verify the all imported functions are valid, then click the Fix Dump. There should be a new fixed file in the same directory as dumped exe.

Happy ending

Open the peid again

“You just said that the file is packed with upx….”
Open the ida again

This is the assembly file what I want.
I consider it is the most simplest process to unpack a file, and expect to learn another way to unpack at the next time:)