REFERENCE GUIDE

Packed binaries and identifying original-code transitions

Packing compresses or transforms executable code and supplies a loader stub that reconstructs it at runtime.

Also known as: unpacking · OEP

packing-and-unpackingreversing

Mechanism

Packing compresses or transforms executable code and supplies a loader stub that reconstructs it at runtime. Indicators include sparse imports, unusual sections, high entropy, and code that writes then executes memory. These clues are not unique to packing; encrypted resources and legitimate runtimes can exhibit similar patterns.

Practical method

Inspect sections and imports, then trace memory allocation, writes, protection changes, and control transfers. Stop when execution enters reconstructed application code. Capture the relevant memory and reconstruct imports or section boundaries only as needed for analysis. Retain the original file and the dump as separate artifacts.

loader stub -> decode/write region -> set executable protection -> jump
                                                 candidate original entry

Interpreting evidence

A useful unpacked artifact exposes meaningful application control flow and validation strings. Compare its behavior with the original instead of judging success from an entropy decrease alone.

Pitfalls and limits

Self-modifying code may unpack incrementally. Dumps can omit relocations or imported-function metadata. Executing an unknown binary outside the dedicated challenge environment creates an unnecessary analysis risk.

Sources & further reading

  1. VirtualProtect ↗microsoft
  2. mprotect ↗linux-man

Content license: CC-BY-4.0. Source-derived sections retain their cited licenses and redistribution notices. How this reference is compiled →