Identifying Packed Malware

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.