x64dbg mcp server

Technical Briefing – x64dbg‑MCP Server Prepared as a consultant‑grade note for a technical client.

The Problem

Reverse‑engineering workflows that require programmatic debugger control today either depend on heavyweight frameworks (.NET, Python) or require custom‑built plugins with manual wire‑up of RPC layers. Teams that want an AI‑assisted, scriptable debugging experience must either accept limited tooling or maintain a separate bridge between an AI assistant and x64dbg. This repo attempts to close that gap by exposing the full x64dbg API over the Model Context Protocol (MCP), but the engineering maturity of that bridge has not been verified through testing or automated gates.

What This Does

The repository delivers a native x64dbg plugin written in Zig (12 source files under src/) that implements 71 MCP tools and 22 event callbacks. Core responsibilities are split across a few files:

The build system is defined in build.zig and its metadata in build.zig.zon; the final binary is a single‑file plugin that can be dropped into the x64dbg plugins folder. Default bind ports are 9094 (x64) and 9095 (x32), configurable via the Plugins‑menu dialog.

Transport options are Streamable HTTP (recommended) and Server‑Sent Events (legacy). The server auto‑starts when x64dbg launches, and the config dialog can change the bind address to 0.0.0.0 for remote connections (e.g., from WSL).

How It Is Wired

1. x64dbg loads the plugin → main.zig registers the plugin entry point and spawns an async MCP listener thread.
2. MCP client sends a JSON‑RPC 2.0 request (e.g., {"method":"SetBreakpoint","params":{"address":0x…}}).
3. The request passes through json.zig (parsing) → bridge.zig (conversion to x64dbg API calls) → the underlying x64dbg debugging engine updates its internal database (break‑point table, register state, memory map).
4. Event callbacks (breakpoint hit, exception, thread change) are fired by x64dbg; mcp_server.zig encodes the event data into an MCP response and pushes it over the active transport (HTTP or SSE).
5. Configuration (config.zig) stores the bind IP/port; on save the server restarts with the new values, no x64dbg restart required.

The call graph is shallow: client → HTTP/SSE → mcp_server.zig → json.zig → bridge.zig → x64dbg API. The bridge is the single point that touches the debugger’s native API; any change there ripples to all 71 tools. No other module intercepts or transforms the request, so the blast radius of a bug in bridge.zig is the entire toolset.

How To Use It

Build / Install (from the repo root):

# Clone the repo (exact URL as provided)
git clone https://github.com/moses-y/x64dbg-mcp-server

# Build the Zig plugin (requires Zig >=0.11)
cd x64dbg-mcp-server
zig build                # produces dist/ directory with x32/x64 binaries

Deploy: copy the contents of dist/ into your x64dbg root folder. The plugin appears under Plugins → x64dbg‑MCP Server.

Configure: open the Plugins menu, click the x64dbg‑MCP Server entry to adjust IP/port. Save → server restarts automatically.

Connect an MCP‑compatible AI assistant (example .mcp.json):

{
  "mcpServers": {
    "x64dbg": {
      "type": "http",
      "url": "http://localhost:9094/"
    }
  }
}

Or use SSE (http://localhost:9094/sse) for legacy clients.

Typical workflow (AI‑assisted RE session):

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

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

All 71 tools are accessible; the AI can sequence them to explore code, scan for patterns, dump PE sections, or inspect the PEB/SEH chain.

Real‑World Use

A red‑team analyst can embed the plugin in a x64dbg instance used during a engagement, then feed break‑point and memory‑read events into a local LLM (e.g., via Ollama). The LLM can suggest next‑step offsets, auto‑generate IDC/Python scripts, or produce a YARA rule based on observed PE characteristics—all without leaving the debugger. Because the plugin is a single native binary, there is no interpreter overhead and the attack surface stays within the x64dbg process.

Code Health & Issues

• No test files detected – untested code paths across the 71 tools and 22 callbacks.
• No CI/CD pipeline – no automated build, static‑analysis, or test gate (.github/ absent).
• Zig version & dependencies – the project claims “zero dependencies”; verify the build.zig.zon lock file matches the installed Zig release to avoid subtle ABI drift.

These findings stem from a static‑scan of the repository structure; no dynamic execution or fuzzing was performed.

The Bottom Line

The x64dbg‑MCP Server provides a clean, zero‑dependency bridge between an MCP‑compatible AI assistant and the x64dbg debugger, delivered as a single Zig binary that builds for both x32 and x64. The feature set is extensive (71 tools, 22 events) and the transport options are modern (Streamable HTTP + SSE). However, the absence of tests, CI, and any form of automated quality gate means the plugin is functionally capable but unproven in production pipelines. Teams comfortable with manual verification and willing to add their own test harness can adopt it quickly; organizations requiring out‑of‑the‑box reliability should budget time for testing and CI integration.