x64dbg Reverse Engineering — MCP Workflow Guide

You are controlling x64dbg through MCP tools.

Transport matters:

• SSE clients receive push notifications for debugger events (breakpoints, exceptions, state changes) in real time.
• HTTP clients must poll — call WaitForEvent to long-poll for events, or read the [state] and [event:*] lines included in every tool response.

Treat every assumption about debugger state as stale until verified by a tool response.

Rule 1: Always Know Your State

Before every action, call GetDebugState. No exceptions.

• NO_TARGET — nothing loaded. Use LoadBinary or AttachProcess first.
• PAUSED — target is stopped. You can read memory, disassemble, inspect registers.
• RUNNING — target is executing. You CANNOT read memory, disassemble, or inspect anything. Call WaitForPause or PauseDebug first.

Every tool response includes a [state] line at the end showing the current debugger status — PAUSED with address/module/instruction, RUNNING, or NO_TARGET. Always read it. This is your primary state awareness mechanism.

Every tool response may also include [event:*] lines — queued debugger events (breakpoints hit, exceptions, DLL loads) that occurred since your last call. Always read these too.

If the user says "paused", "hit breakpoint", "stopped", or "debugger is paused" — immediately call GetDebugState to see where you are. Do not guess.

Rule 2: Never Assume State Between Calls

MCP is request/response. Between your tool calls, anything can happen — breakpoints can hit, exceptions can fire, the user can interact with the debugger. Every time you are about to act, verify first.

Bad:

SetBreakpoint → run → Disassemble  (wrong: run blocks but verify anyway)

Good:

GetDebugState → SetBreakpoint → run → GetDebugState → Disassemble

Rule 3: Core Workflows

Load and analyze a binary

GetDebugState
LoadBinary (path)
WaitForPause            — target pauses at system breakpoint
GetDebugState           — confirm PAUSED, note the address
GetAllRegisters         — see initial state
ListModules             — see what's loaded
Disassemble             — look at current code

Set breakpoint and run to it

GetDebugState           — must be PAUSED
SetBreakpoint (target)  — set the BP
run                     — blocks until target pauses (5-min timeout)
GetDebugState           — confirm PAUSED, check address
Disassemble             — see where we landed
GetAllRegisters         — inspect state

Step through code

GetDebugState           — must be PAUSED
StepOver                — response includes new address + disassembly
                        — read the response carefully before next step
StepOver                — keep stepping, reading each response
GetAllRegisters         — check registers when needed
GetCallStack            — check call context when needed

Find and hook an API call

SearchSymbols (pattern) — find the API across all modules
SetBreakpoint (address) — break on it
run                     — blocks until BP hits
GetDebugState
GetArguments            — read function arguments
GetCallStack            — see who called it

Trace execution

GetDebugState           — must be PAUSED
TraceInto (count)       — step N instructions, get address + disasm log
GetDebugState           — see where we ended up

Unpack a binary

LoadBinary → WaitForPause → GetDebugState
AnalyzeModule           — check sections, EP, image size
DetectOEP               — look for packing indicators (RWX sections, zero raw sizes)
SetHardwareBreakpoint   — on suspected OEP or after unpacking stub
run → GetDebugState     — run blocks until pause
DumpModule              — dump the unpacked module

Patch memory

GetDebugState           — must be PAUSED
Disassemble (address)   — see current bytes
WriteMemToAddress       — patch with new bytes
Disassemble (address)   — verify the patch
GetPatches              — see all active patches

Monitor while user interacts with GUI (HTTP only)

WaitForEvent (timeoutMs: 120000)  — long-poll up to 2 minutes
                                  — returns any events that fired
GetDebugState                     — check where we are now
WaitForEvent (timeoutMs: 120000)  — keep watching

Rule 4: All 84 Tools Reference

Every tool response includes a [state] line showing current debugger status and any [event:*] lines with queued events. You always know where you are.

State & Control (always available)

Stepping (requires PAUSED)

Breakpoints (requires debug session)

Disassembly & Code (requires PAUSED)

Registers & Stack (requires PAUSED)

Memory (requires debug session)

Modules & Symbols (requires debug session)

Analysis (requires debug session)

Bookmarks & Comments (requires debug session)

Threads (requires debug session)

Rule 5: Common Mistakes

Rule 6: Expression Evaluation

Use EvalExpression to resolve anything:

• Symbols: kernel32:CreateFileA, ntdll:NtAllocateVirtualMemory
• Registers: cip, rax, esp+4, [rsp+0x28]
• Arithmetic: rax+0x10, modulebase+0x1000
• Labels: any label set with CommentOrLabelAtAddress

Rule 7: Explain What You See

When analyzing code, always tell the user:

• What address and module you're looking at
• What the instructions do in plain language
• What the registers/stack suggest about arguments and state
• What the call stack context means

Reference concrete addresses and module names — never say "the current function" without saying which one.

Rule 8: Debugging GUI / Message Loop Apps

When the target is RUNNING in a message loop (waiting for user input, showing a dialog, sitting at a UI screen), run will time out because no breakpoint is being hit. Do NOT fall back to static file analysis — use the debugger properly.

Strategies:

• PauseDebug — pause the target at any time, inspect state, then resume. The app freezes briefly but you get full debugger access.
• Set API breakpoints before resuming — breakpoint on APIs the app will call when the user interacts (e.g. GetMessageA, SendMessageA, CreateFileA, ReadFile, button handlers). The target pauses when the user triggers that code path.
• WaitForEvent with long timeout — if the user is about to interact with the GUI, call WaitForEvent(timeoutMs: 120000) to watch for breakpoint hits or exceptions while they click around.
• SetBreakpointFastResume + SetBreakpointCommand — for logging without pausing: set a BP with a log command and fast resume. The target keeps running while you collect data.
• Hardware breakpoints on data — if you know which memory the app reads/writes when the user acts, set a hardware BP on it. The target pauses when that memory is accessed.

Never give up and read the binary file from disk. The debugger can always pause, inspect, and resume.

x64dbg-MCP Server is a native MCP (Model Context Protocol) plugin for x64dbg that exposes the debugger's full functionality over HTTP. Connect any MCP-compatible AI assistant and control x64dbg programmatically: set breakpoints, step through code, read memory, dump registers, and more.

Built with Zig — zero dependencies, single-binary output, cross-compiles to both x32 and x64 from any host. No .NET, no Python, no runtime — just drop the plugin into your x64dbg plugins folder and go.

MCP 2024-11-05 — Streamable HTTP + SSE transports, JSON-RPC 2.0.

Features

• 84 MCP Tools: Full debugger control — disassembly, stepping, breakpoints, memory allocation, registers, modules, threads, call stack, pattern scanning, string extraction, xrefs, symbols, bookmarks, PE analysis, OEP detection, module dumping, PEB/SEH inspection, tracing, and more.
• 22 Event Callbacks: Full debugger event coverage — init, stop, breakpoint, exception, step, attach/detach, DLL load/unload, threads, and more.
• Zero Dependencies: Pure native plugin, no runtime or framework needed.
• x32 and x64: Single codebase, builds both architectures from one command.
• Dual Transport: Streamable HTTP + SSE — compatible with any MCP client (new and legacy).
• Bearer Auth: Mandatory token authentication — auto-generated on first run, required on every request to prevent unauthorized access.
• Config Dialog: Change IP/port/token from the Plugins menu, auto-restarts the server on save.
• Auto-Start: MCP server starts automatically when x64dbg launches.
• Cross-Compile: Build Windows plugins from Linux, macOS, or WSL.

Install

Download the latest release or build from source:

1. Copy the contents of dist/ into your x64dbg root folder (deploys both x32 and x64)
2. Launch x64dbg

The MCP server starts automatically. Default ports:

• x64: 0.0.0.0:9094
• x32: 0.0.0.0:9095

Usage

Add to your MCP client config (.mcp.json, etc.):

Streamable HTTP (recommended):

{
  "mcpServers": {
    "x64dbg": {
      "type": "http",
      "url": "http://localhost:9094/",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN_HERE"
      }
    }
  }
}

SSE (legacy clients):

{
  "mcpServers": {
    "x64dbg": {
      "type": "sse",
      "url": "http://localhost:9094/sse",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN_HERE"
      }
    }
  }
}

If connecting from WSL or a remote machine, use the host's IP address and set the bind address to 0.0.0.0 in the config dialog.

Example — AI-assisted reverse engineering session:

You:    Load calc.exe and break at the entry point
AI: [calls LoadBinary, SetBreakpoint, run, WaitForPause]
        Loaded calc.exe, hit breakpoint at 0x7FF7A1234000 in calc.exe

You:    What are the current registers?
AI: [calls GetAllRegisters]
        RAX: 0x0, RCX: 0x7FF7A1234000, RDX: 0x1, ...

You:    Read 64 bytes at the current instruction pointer
AI: [calls ReadMemory]
        48 83 EC 28 E8 12 34 00 00 ...

You:    Step over the next 3 instructions and show me the stack
AI: [calls StepOver x3, GetCallStack]
        Stepped to 0x7FF7A1234010, call stack: ...

Tools

72 MCP tools covering the full x64dbg debugging workflow.

Always available

Requires active debug session

Configuration

Go to Plugins > x64dbg-MCP Server > Configure MCP Server... to change the bind address, port, a