Obfuscation & Packing

Why Malware Packs

Packing compresses/encrypts a binary so its real code is hidden from static analysis. The visible file is a small stub that unpacks the real payload at runtime.

Detecting a Packed Binary

Signal	What it means
High entropy sections	compressed/encrypted data looks random
Few strings / imports	the real code is hidden
Entry point in RWX section	the stub writes then executes
Small import table (LoadLibrary + GetProcAddress)	resolves APIs dynamically
Known packer signatures	UPX!, section names UPX0/UPX1

Common Packers

• UPX — legitimate compressor, trivial to unpack (upx -d), often used by malware too.
• Themida / VMProtect — commercial protectors, heavily obfuscated (virtualized).
• Custom stubs — a short decryptor loop, unique per campaign.

The Unpacking Stub

The stub typically:

1. Locates the packed payload.
2. Decrypts/decompresses it into a new region.
3. Flips that region to executable.
4. Jumps to it (the OEP — original entry point).

Recovering the Real Code

Two strategies:

1. Static unpack — run the stub, dump the unpacked memory, fix imports (dump + Scylla/PE tools).
2. Dynamic — let it run in a sandbox/VM, dump memory after it unpacks, analyze the dump.

Obfuscation Beyond Packing

• Encrypted strings — no strings output; decrypted in place at runtime.
• Junk/dead code — noise to bury the real logic.
• Control-flow flattening — an opaque dispatcher instead of normal branches.

None of these change what the code does — only how hard it is to read.

Interactive: Packer Detection

The hex below shows a UPX-stubbed binary. Note the UPX! signature and the high-entropy section.

Takeaway

Packing hides the payload, not the behavior. Run it, dump it, and analyze the dump.

Lab 16: Packer Identification → Packer Identification