Unpacking

Packing compresses or encrypts a program's real code and wraps it in a small stub. At runtime the stub unpacks the original code into memory and runs it.

Malware authors use packing to evade signatures and frustrate static analysis.

A packed binary shows few strings, few imports, and high entropy. The meaningful code is hidden until the stub runs.

Unpacking recovers the original code so you can analyze it statically and extract real IOCs.

Tools like Detect It Easy (DIE) and PEiD identify known packers by signature. High entropy and a tiny import table are also strong clues.

Common packers include UPX, ASPack, and Themida.

UPX is a common, non-malicious packer that can be reversed with its own tool. The -d flag decompresses the binary back to its original form.

Many real-world samples use UPX or a slightly modified UPX, so this is a frequent first attempt.

Custom packers cannot be undone with a tool. Instead you let the stub unpack itself in memory, then capture the result.

The plan: run the sample under a debugger, stop right after unpacking completes, and dump the now-revealed code.

The Original Entry Point (OEP) is where execution jumps once unpacking finishes. Reaching the OEP means the real code is now in memory.

Techniques to find it include watching for a far jump out of the stub, or setting a breakpoint on memory the stub writes then executes.

A common trick is a hardware breakpoint on the stack (the stub often restores registers right before jumping to the OEP), or a breakpoint on common API calls the unpacked code uses.

When the breakpoint hits at the OEP, the original code is fully decoded.

At the OEP, dump the process memory to a new file. Tools like Scylla (built into x64dbg) or PE-sieve capture the unpacked image.

The dump now contains the real instructions, but it may not run on its own yet.

After dumping, the Import Address Table is often broken because the packer resolved imports at runtime. Scylla can rebuild the IAT so the dumped file is analyzable.

Once imports are fixed, you can load the clean dump into Ghidra or IDA.

Beyond packing, malware uses other obfuscation: encrypted strings decoded at runtime, junk instructions, control-flow flattening, and anti-debugging checks.

These are defeated case by case, often by combining dynamic tracing with patient static reading.

After dumping and rebuilding imports, confirm success by re-running static analysis: you should now see many more strings and a populated import table.

If entropy is back to normal and APIs are visible, the unpack worked and the real code is ready to analyze.

Recall what the OEP signifies during manual unpacking.

You now understand unpacking:

• Packing hides the real code; detect it with DIE/PEiD, high entropy, and few imports.
• Known packers like UPX unpack with a tool (upx -d).
• For custom packers, run under a debugger, find the OEP, dump with Scylla, and rebuild imports.
• Other obfuscation (encrypted strings, anti-debug) is handled case by case.

You have completed the Reverse Engineering Malware course.