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:

```text
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.

```bash
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`](references/api-reference.md) for the breakpoint-script
  generator.
- x64dbg and Windows API documentation (linked in frontmatter).