What is Packing?
A packer compresses, encrypts, or otherwise transforms the original executable so that its code and data are unreadable on disk. When the packed file runs, a small unpacking stub executes first, restores the original payload in memory, and transfers control to it.
Packing defeats:
- Signature-based AV: the on-disk bytes change completely, producing a different hash for every packed variant
- Static analysis: strings, imports, and code are hidden until runtime
- Pattern matching: the original code pattern never appears on disk
The analyst must recognise packed binaries and unpack them before meaningful analysis can begin.
How a Packer Works
Original PE:
.text (code) ← readable, analysable
.data (globals)
.rdata (constants)
IAT (imports)
After packing:
UPX0 (empty on disk, reserved in memory for unpacked code)
UPX1 (compressed original PE — near-maximum entropy)
UPX2 (unpacking stub — runs first)
At runtime:
1. CPU executes UPX2 stub
2. Stub decompresses UPX1 into UPX0 memory region
3. Stub reconstructs the IAT (calls LoadLibraryA + GetProcAddress)
4. Stub jumps to the Original Entry Point (OEP) in UPX0
5. Original code runs normally
The analyst''s goal is to reach step 4 (the OEP) and dump the restored executable from memory.
Four Indicators of Packing
1. High Entropy in the Code Section
Shannon entropy above 7.0 in the .text section means the code is packed or encrypted. Normal compiled code sits between 5.0 and 6.5.
Normal: .text entropy = 5.82
UPX packed: UPX1 entropy = 7.84 ← near-maximum
Themida protected: packed section = 7.91
Check with PEStudio (Sections tab) or Detect-It-Easy (entropy graph).
2. Truncated Import Table
A normal Windows program imports dozens of API functions. A packed binary''s IAT contains only:
kernel32.dll:
LoadLibraryA
GetProcAddress
These two functions are sufficient to resolve all other imports at runtime. Their presence alone (and nothing else) is the signature of a packed binary.
3. Non-Standard Section Names
| Normal Compiler Output | Packer-Inserted Sections |
|---|---|
.text, .data, .rdata, .rsrc | UPX0, UPX1 (UPX) |
.aspack (ASPack) | |
.themida (Themida) | |
.petite (Petite) | |
Random strings like .xq9k (custom packers) |
4. VirtualSize >> SizeOfRawData
The first section is almost empty on disk but large in memory:
Section header:
VirtualSize = 0x00050000 (320 KB reserved in memory)
SizeOfRawData = 0x00000200 (512 bytes on disk)
The stub decompresses the packed code into this reserved space during execution.
Detecting the Packer with Detect-It-Easy
Detect-It-Easy (DIE) matches packer signatures against an internal database:
die suspicious.exe
Example outputs:
UPX(3.96)[NRV,brute]
ASPack(2.42)[-]
Themida/WinLicense(2.x)[protection]
VMProtect(3.x)[virtualization]
When DIE identifies the packer, research its known anti-debug techniques before opening the debugger. Different packers require different unpacking approaches.
Packer Families and Analyst Approach
| Packer | Protection Level | Approach |
|---|---|---|
| UPX | None | upx -d command-line unpack OR ESP breakpoint technique |
| ASPack | Light anti-debug | ScyllaHide + ESP breakpoint |
| PECompact | Light anti-debug | ESP breakpoint |
| Themida | Nanomites, stolen bytes, anti-VM | ScyllaHide VMProtect profile + VirtualAlloc breakpoint |
| VMProtect | Code virtualisation | Dynamic analysis only: no recoverable native OEP |
| Custom packers | Unknown | Entropy analysis + VirtualAlloc/VirtualProtect breakpoint |
UPX: The Simplest Case
UPX is open-source and reversible with a single command:
upx -d packed_sample.exe -o unpacked_sample.exe
However, malware authors often corrupt the UPX header to prevent command-line unpacking while keeping the unpacking stub functional:
UPX header check: FAIL (header corrupted)
upx -d fails with: "p_info corrupted"
In this case, use the manual ESP breakpoint technique (covered in Topic 2) regardless of the upx -d failure. The stub still works: only the header is corrupted to prevent easy recovery.
Non-Packing Explanations for High Entropy
Not all high-entropy binaries are malicious. Always combine entropy analysis with other indicators:
| High Entropy + | Verdict |
|---|---|
| Stripped IAT + non-standard sections | Almost certainly packed malware |
| Normal IAT + standard sections | May be a legitimate installer or encrypted resource |
| Resource section only | Likely compressed images: low suspicion |
| Signed binary (valid signature) | Commercial protector on legitimate software |
Refer to REMA eBook 2026, Figure 5.1 for the packed vs normal PE structure diagram.