debugging-malware-with-x64dbg

name	debugging-malware-with-x64dbg
description	Uses x64dbg to dynamically debug Windows malware: setting strategic breakpoints on APIs, stepping through unpacking and decryption, dumping memory at the right moment, and manipulating execution to reach hidden code. Activates for requests to debug malware with x64dbg, set API breakpoints, or step through unpacking in a debugger.
domain	cybersecurity
subdomain	reverse-engineering
tags	["reverse-engineering","x64dbg","debugging","unpacking","breakpoints","windows"]
version	1.0.0
author	analyst-ai-pack
license	Apache-2.0
mitre_attack	["T1027","T1140","T1497","T1055"]
d3fend	["D3-PSA","D3-FCR"]
references	["x64dbg documentation — https://help.x64dbg.com/","Windows API reference — https://learn.microsoft.com/windows/win32/api/"]

Debugging Malware with x64dbg

When to Use

• You need to observe a sample's runtime behavior at the instruction level on Windows.
• You are manually unpacking, decrypting strings, or reaching code guarded by anti-analysis.
• You want to dump a payload from memory after it is decoded but before it is hidden.

Do not use a debugger on a host you care about — debug only inside the isolated victim VM, and revert the snapshot after.

Prerequisites

• x64dbg (and the matching x32/x64 build for the sample's bitness) inside the victim VM.
• A clean snapshot; the lab's simulated internet.
• Familiarity with Windows APIs commonly used by malware.

Safety & Handling

• The sample executes under the debugger; this is detonation. Stay in the isolated VM.
• Revert the snapshot after the session; treat memory dumps as live samples.

Workflow

Step 1: Set strategic API breakpoints

Rather than stepping from the entry point, break on APIs that mark interesting moments:

VirtualAlloc / VirtualProtect  -> unpacking buffer about to be written/executed
CreateProcessInternalW         -> process hollowing target
WriteProcessMemory             -> injection payload in a register/buffer
CryptDecrypt / lstrcpy         -> decoded data available
ResumeThread                   -> hollowed process about to run

Use bp VirtualAlloc then inspect the return value (allocated base) on return.

Step 2: Step through unpacking

Run to the allocation, set a memory breakpoint on the new region, and continue until the unpacker writes and jumps to it. The tail jump to OEP marks the unpacked entry.

Step 3: Dump at the right moment

When the payload is decoded in memory (e.g. after VirtualProtect makes it executable), dump the region with Scylla/the dump plugin and fix the import table for the unpacked PE.

Step 4: Defeat simple anti-debugging

Patch or skip checks like IsDebuggerPresent, PEB BeingDebugged, and timing checks (see the anti-debugging skill). Set the return value to evade detection rather than removing the call.

Step 5: Record breakpoints and notes

Save a breakpoint plan and observations. The bundled script generates an x64dbg command script of API breakpoints to bootstrap a session.

python scripts/analyst.py breakpoints --preset unpacking > bp.txt

Validation

• The dumped region is a valid PE (MZ/PE headers) and disassembles to real code.
• API breakpoints fire in an order consistent with unpacking/injection.
• Patched anti-debug checks no longer alter the execution path.

Pitfalls

• Stepping blindly from the entry point instead of using API breakpoints — slow and easy to get lost.
• Dumping too early (still encrypted) or too late (already executed/freed).
• Removing anti-debug calls entirely, which can break control flow; prefer faking the result.

References

• See references/api-reference.md for the breakpoint-script generator.
• x64dbg and Windows API documentation (linked in frontmatter).