unipacker v1.0.6 releases: Unpacking PE files using Unicorn Engine

by do son · Published June 17, 2019 · Updated April 10, 2021

Un{i}packer

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 malware sample, it is often required to unpack the binary. Usually, this means, that the analyst will have to manually unpack the binary by using dynamic analysis techniques (Tools: OllyDbg, x64Dbg). There are also some approaches for automatic unpacking, but they are all only available for Windows. Therefore when targeting a packed Windows malware the analyst will require a Windows machine. The goal of our project is to enable platform-independent automatic unpacking by using emulation.

Supported packers

UPX: Cross-platform, open source packer
ASPack: Advanced commercial packer with a high compression ratio
PEtite: Freeware packer, similar to ASPack
FSG: Freeware, fast to unpack

Any other packers should work as well, as long as the needed API functions are implemented in Unipacker. For packers that aren’t specifically known you will be asked whether you would like to manually specify the start and end addresses for emulation. If you would like to start at the entry point declared in the PE header and just emulate until section hopping is detected, press Enter

At this point, Unipacker will have identified the packer that was used to obfuscate this binary, if it is one of the supported ones (UPX, ASPack, PEtite and FSG). The aaa command will show you general information over four categories:

File analysis: What are the YARA matches found by our rules collection (located in malwrsig.yar) and which unpacker has been chosen. If the packer is known, this chosen unpacker provides a set of config presets that might help unpacking. Those presets are also shown in this info section (e.g. allowed sections for section hopping detection).
PE stats: How big is the declared amount of memory the loaded PE file will occupy (and how much is actually used, so discrepancies can be spotted easily). Additionally, the image base address is displayed (usually 0x400000 or 0x10000000) and the address spaces we reserved for stack and API-call hook memory.
Imports: Here we list the imports declared in the PE header, including the respective DLL and the address in of the call stub. You might notice a “Dynamic imports” section that is still empty. In here we will list used library functions that aren’t declared in the PE header but rather loaded dynamically during runtime. So when running aaa after the emulation has finished, this section might list many more library functions, depending on the used packer.
Register status: The values of the emulator registers. At this point those are still presets from the loading process.

After looking at those general infos about the current sample, we can go to the next step. By the way, there is an alternative command, aaaa, which displays all of the infos mentioned above but also starts emulation automatically.