Describe how you unpack a packed sample to reach the original code.
Short answer
Unpacking recovers the original code the packer hid. For known packers you use the matching unpacker or an emulator. For custom packers you unpack manually: run the sample in a debugger, let the stub decompress the payload into memory, find the moment it jumps to the original entry point (often by breaking on memory that becomes executable, or on the tail jump), then dump the process image from memory and rebuild the import address table with a tool like Scylla or PE-sieve. The result is a runnable or analyzable PE containing the real payload.
Unpacking is the gate you must pass before deep static analysis of most malware: the disassembler only sees the stub until you recover the real payload. Interviewers use this to test whether you understand what a packer does to memory at runtime, not just that packing exists.
Known packers — take the shortcut
If a detector like Detect It Easy names a common packer (UPX, ASPack, older Themida builds), reach for the matching tool first: upx -d for UPX, dedicated unpackers, or an emulation-based unpacker that runs the stub in a sandboxed CPU and dumps the result. This is fast and worth trying before any manual work.
Custom packers — manual unpacking
When there is no off-the-shelf unpacker, you unpack by hand:
- Run the stub under a debugger (x64dbg). The stub will allocate memory and decompress or decrypt the payload into it.
- Find the original entry point (OEP). Common techniques: set a hardware breakpoint on execute on the freshly allocated/written memory so you catch the first instruction of the real code; watch for the tail jump (a
jmp/retinto a different section); or break on a telltale API the payload calls early. Tools like PE-sieve can also detect the unpacked region automatically. - Dump the process image from memory once execution reaches the OEP.
Rebuilding the imports
A raw memory dump usually has a broken import address table, because the packer resolved APIs at runtime and the on-disk IAT is empty or stale. Use Scylla (often integrated with x64dbg) or PE-sieve/pe_unmapper to reconstruct the IAT and fix the entry point, producing a clean, analyzable PE.
A senior answer names the OEP-finding strategy, the memory dump, and the IAT rebuild as the three real obstacles — and notes that for triage you may simply read the unpacked payload from a sandbox memory dump instead of fully repairing it.
Likely follow-ups
- How do you find the original entry point (OEP) for a custom packer?
- Why does a memory dump usually have a broken import table, and how do you fix it?
- When would PE-sieve or a dynamic unpacker beat manual unpacking?