unpacking-protected-binaries

Unpacking Protected Binaries

Static unpacking is a trap for anything beyond UPX. The reliable method is to let the program unpack itself, then take the result out of memory. Almost every protector, however sophisticated, must eventually produce executable code in a readable page — that moment is what you are waiting for.

Run protected samples only in a contained environment; see analyzing-malware.

When to Use

• binwalk -E shows uniformly high entropy across most of the file
• The import table has a handful of entries (LoadLibrary, GetProcAddress)
• Section names are absent, random, or UPX0/.themida/.vmp0
• Disassembly shows a small stub and one large data blob
• A tool reports the file is packed, or analysis finds essentially no code

When NOT to Use

• The wider malware workflow — use analyzing-malware for containment, triage, and IOC output; come back here for the unpacking step
• .NET assemblies — use analyzing-dotnet-assemblies, which covers .NET packers and managed memory dumping specifically
• Obfuscation without packing (readable imports, normal entropy, confusing control flow) — use analyzing-binaries
• Firmware images — binwalk -Me extraction is a different job; see analyzing-binaries

Identify the Protector First

The response differs enormously between a commodity packer and a commercial protector, so spend a minute here.

diec target.exe                     # Detect It Easy — the best single identifier
rg -a -o 'UPX|MPRESS|Themida|VMProtect|ASPack|Enigma|Obsidium|PECompact' target.exe
binwalk -E target.exe               # entropy profile

# Structural tells
readpe target.exe                   # or: rabin2 -S target.exe
#   raw size ≈ 0 with large virtual size   → section unpacked at runtime
#   section marked writable AND executable → self-modifying
#   entry point outside the first section  → stub in a later section
#   TLS callbacks present                  → code runs BEFORE the entry point