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
Nice! That is the function prologue which we are familiar with, it also means we found a right entry point.
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
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.
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:)