Our Project
My partner and I started this project as part of our Bachelor lab course "Honeynets & Malware Forensics". Un{i}packer is a tool for debugging and deobfuscating x86 Windows malware on any platform, including Linux, by using binary emulation. Typically, malware is obfuscated by using so-called packers: The actual code to be executed is compressed and encrypted and stored as a large data blob inside the binary. Only a stub is left that is then used to unpack the malicious code when the binary is executed. Un{i}packer can automatically unpack a variety of different packers and dump the program as a Windows binary, which can then be statically analyzed by the reverse engineer. Any API imports that were intended to be hidden and headers of the binary are fixed, so it could be executed normally on any Windows machine, if desired.
Demo Link
See Un{i}packer in action as part of the lecture "Malware Analysis and Cyber Threat Intelligence" by a German university:
Link to Code
unipacker
/
unipacker
Automatic and platform-independent unpacker for Windows binaries based on emulation
_ _ __ _ __ _
| | | | / / (_) \ \ | |
| | | |_ __ | | _ | | _ __ __ _ ___| | _____ _ __
| | | | '_ \/ / | | \ \ '_ \ / _` |/ __| |/ / _ \ '__|
| |_| | | | \ \ | | / / |_) | (_| | (__| < __/ |
\___/|_| |_|| | |_| | || .__/ \__,_|\___|_|\_\___|_|
\_\ /_/ | |
|_|
Un{i}packer 
| Master |  |
| Dev |  |
Unpacking PE files using Unicorn Engine
The usage of runtime packers by malware authors is very common, as it is a technique that helps to hinder analysis Furthermore, packers are a challenge for antivirus products, as they make it impossible to identify malware by signatures or hashes alone.
In order to be able to analyze a packed…
How We built it (what's the stack? did we run into issues or discover something new along the way?)
Our unpacking framework is written in Python and uses Unicorn Engine, a CPU emulator. We load the PE file (.exe) using the pefile Python library, perform additional memory patching in order to be able to hook into calls to the Windows API that of course is not available out of the box. Any API call needs to be intercepted by us, any necessary steps executed and then we need to give back control to the malware itself, pretending the call was executed as expected.
Execution can be controlled by the user as they wish. For this purpose we provide a debugger shell interface based on cmd2, where the user can set breakpoints, step through the code, inspect and manipulate registers or memory contents. If desired, the current state can be dumped back to an exe file for further analysis.
Automatic unpacking steps can be taken as well. Using Yara we identify known packers and adjust execution limits accordingly, so that only the unpacking stub is emulated and not the actual malware code.
Top comments (0)