Connect an AI Assistant to x64dbg with x64dbg-MCP Server

What Is x64dbg-MCP Server?

x64dbg-MCP Server is a native Model Context Protocol plugin for x64dbg. It exposes x64dbg functionality through JSON-RPC over HTTP, allowing an MCP-compatible AI assistant to control debugging sessions programmatically.

The assistant can load or attach to a process, set breakpoints, step through instructions, inspect registers, read and patch memory, examine modules and threads, extract strings, follow references, analyze PE structures, and perform many other reverse-engineering operations.

The plugin is written in Zig and runs directly inside x64dbg. It does not require Python, .NET, or a separate runtime. It supports the MCP 2024-11-05 specification with Streamable HTTP and legacy SSE transports.

Use this software only for legitimate reverse engineering, malware analysis, security research, education, or other work for which you have explicit authorization.

Key Features

• Broad debugger control: Tools cover disassembly, execution, breakpoints, registers, memory, modules, threads, call stacks, symbols, references, PE analysis, tracing, dumping, PEB inspection, and more.
• Debugger event coverage: The plugin records events including initialization, stops, breakpoints, exceptions, stepping, process attachment, DLL activity, and thread activity.
• Native deployment: The plugin has no external runtime or framework dependencies.
• x32 and x64 support: One codebase builds plugins for both x64dbg architectures.
• Two MCP transports: Streamable HTTP is recommended, while SSE supports legacy MCP clients.
• Mandatory authentication: Every request must carry a valid Bearer token.
• Automatic startup: The server starts when x64dbg launches.
• Built-in configuration: The x64dbg Plugins menu provides settings for the bind address, port, and token.
• Cross-compilation: Zig can build the Windows plugins from Windows, WSL, Linux, or macOS.

How the Integration Works

When x64dbg starts, the plugin resolves debugger API symbols from x64bridge.dll and x64dbg.dll. It then starts an HTTP server on a background thread. An MCP client sends authenticated JSON-RPC requests, and each MCP tool maps to x64dbg SDK calls such as setting a breakpoint, reading memory, or resuming execution.

Because the plugin runs within the x64dbg process, it communicates directly with the debugger API. No external helper process or polling service is required.

Install the Plugin

Option 1: Install a Release

1. Download the latest package from the project’s GitHub releases.
2. Extract the package.
3. Copy the contents of its dist/ directory into the root directory of your x64dbg installation.
4. Launch the x32 or x64 edition of x64dbg.

The distribution mirrors x64dbg’s directory structure, so copying it into the root installs both architecture-specific plugins:

dist/
├── x32/
│   └── plugins/
│       └── x64dbg-MCP-Server.dp32
└── x64/
    └── plugins/
        └── x64dbg-MCP-Server.dp64

The server starts automatically. Its default ports are:

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

Option 2: Build from Source

Building requires Zig 0.16-dev or later. From the repository root, run:

zig build -Doptimize=ReleaseSafe --prefix dist

The command creates both x32 and x64 plugin files beneath dist/. Copy that directory’s contents into the x64dbg root folder just as you would with a release package.

Configure the Server and Authentication

In x64dbg, open Plugins > x64dbg-MCP Server > Configure MCP Server.... The dialog lets you change the bind address, port, and authentication token.

• Use 127.0.0.1 when the MCP client runs on the same Windows system and remote access is unnecessary.
• Use 0.0.0.0 when connecting from WSL or another machine that must reach the host over the network.
• Select Copy to copy the current token.
• Select Generate to rotate the token.

A Bearer token is generated automatically on the first run. Requests without the correct token receive 401 Unauthorized. Saved changes take effect immediately because the server restarts automatically. Configuration is stored in mcp_config.json next to the x64dbg executable.

The server provides memory read and write access, process manipulation, and debugger command execution over unencrypted HTTP. Do not expose it to an untrusted network, even though Bearer authentication is mandatory.

Connect an MCP Client

Recommended Streamable HTTP Configuration

Add a server entry to your MCP client configuration, such as .mcp.json. For the default x64 port, use:

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

Replace YOUR_TOKEN_HERE with the token copied from the plugin configuration dialog. If you are using x32dbg, change the default port to 9095.

SSE Configuration for Legacy Clients

If your MCP client only supports SSE, select the sse transport and append /sse to the endpoint:

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

For WSL or remote access, replace localhost with the Windows host’s IP address and ensure the server is bound to 0.0.0.0.

Run a Basic AI-Assisted Debugging Session

After connecting the client, open x64dbg and ask the assistant to perform a small sequence of debugging tasks. A typical session can begin with:

Load calc.exe and break at the entry point.

The assistant can combine LoadBinary, SetBreakpoint, run, and WaitForPause to load the executable, resume execution, and wait until the breakpoint is reached.

Inspect Registers

Once the target is paused, ask:

Show me the current CPU registers.

The assistant can call GetAllRegisters. To change a value during an authorized debugging session, it can use SetRegister.

Read and Disassemble Memory

Ask the assistant to inspect code around the current instruction pointer:

Read 64 bytes at the current instruction pointer and disassemble the next 10 instructions.

This can use GetCurrentAddress, ReadMemory, and Disassemble. To inspect a complete analyzed function, request DisassembleFunction.

Step Through Code

Execution tools correspond to familiar x64dbg actions:

• StepInto steps into calls like F7.
• StepOver steps over calls like F8.
• StepOut runs until the current function returns.
• run resumes execution like F9.
• PauseDebug pauses the target.
• RunToAddress continues until a specified address is reached.

For example:

Step over the next three instructions, then show the current address and call stack.

The assistant can invoke StepOver three times, followed by GetCurrentAddress and GetCallStack.

Use Breakpoints Effectively

The plugin supports normal software breakpoints, hardware breakpoints, memory breakpoints, conditional breakpoints, and exception breakpoints.

Conditional Breakpoint Example

Set a breakpoint on the target function, but pause only when the specified x64dbg condition is true.

The assistant can use SetConditionalBreakpoint with an x64dbg condition expression and an optional log action. Related tools can enable, disable, toggle, delete, or reset the hit count of a breakpoint.

Hardware and Memory Breakpoints

Use SetHardwareBreakpoint for read, write, or execute monitoring through the available debug registers. Use SetMemoryBreakpoint when page-level read, write, or execute monitoring better fits the investigation.

Before creating more breakpoints, ask the assistant to call ListBreakpoints. This helps avoid duplicate or conflicting debugger state.

Analyze Modules, Symbols, and References

The server exposes several tools for moving from low-level debugging to broader program analysis:

• ListModules reports loaded modules, base addresses, and sizes.
• AnalyzeModule examines PE sections, the entry point, and image size.
• GetImports and GetExports inspect import and export tables.
• SearchSymbols finds symbols matching a pattern.
• GetFunctions lists analyzed functions and labels.
• GetReferences locates CALL and JMP references to a target address.
• FindPattern scans module memory and supports ?? wildcards.
• GetStrings extracts ASCII strings from a module’s memory.
• DetectOEP helps locate the original entry point of packed executables.

A practical analysis request might be:

List loaded modules, analyze the main executable, extract its ASCII strings, and show references to the selected function.

Advanced Tips

Use Event-Aware Workflows

Avoid assuming that the target has paused immediately after resuming execution. Use WaitForPause or WaitForEvent after run, breakpoint operations, or other asynchronous debugger actions. GetEventLog can review recent breakpoints, exceptions, DLL loads, and related events.

Trace Instead of Repeating Individual Steps

For a short instruction history, use TraceInto to record addresses and disassembly while stepping into calls. Use TraceOver when calls should be stepped over. This is more convenient than issuing many separate step requests.

Batch Expression Inspection

EvalExpression evaluates an x64dbg expression such as an address, register, or arithmetic expression. When several values must be monitored together, use WatchExpressions to evaluate multiple expressions in one request.

Preserve and Restore Analysis State

Use CommentOrLabelAtAddress and bookmark tools to annotate important locations. Call SaveDatabase to save the x64dbg database as a .dd64 or .dd32 file.

Patch Carefully

WriteMemToAddress patches bytes, while Assemble writes an assembled instruction at an address. Inspect the existing bytes and keep a record of changes before patching. Use GetPatches to review modifications and RestorePatches to restore original bytes.

Investigate Process Structures

Use GetPEB to inspect Process Environment Block fields, GetSEHChain for the x32 Structured Exception Handler chain, and GetArguments to inspect function arguments from registers or the stack. FollowPointer can dereference a pointer chain for a specified number of levels.

Keep Network Exposure Minimal

Prefer 127.0.0.1 unless remote connectivity is required. If you must bind to 0.0.0.0, restrict access using trusted network controls, protect the token, and rotate it if exposure is suspected. Remember that the transport is HTTP rather than encrypted HTTPS.

Useful Operational Tools

• GetDebugState checks whether a debugging session is active and reports the PID and instruction pointer.
• AttachProcess attaches x64dbg to a running process by PID.
• ExecuteDebuggerCommand runs an x64dbg command directly.
• ListCommandsByCategory helps an MCP client discover available tools.
• GetThreads, SwitchThread, SuspendThread, and ResumeThread manage thread context.
• GetMemoryMap and GetDumpableRegions identify memory regions before reading or dumping them.
• DumpMemory saves a selected memory range, while DumpModule saves an entire module.
• StopDebug terminates the current session, and RestartDebug restarts it.

Conclusion

x64dbg-MCP Server connects x64dbg’s native debugging capabilities to MCP-compatible AI assistants without requiring an external runtime. After installing the correct x32 and x64 plugins, copying the generated Bearer token, and configuring an HTTP or SSE endpoint, you can drive complete debugging workflows through natural-language requests.

Start with a local-only bind address and simple read-only inspection tasks. Then progress to event-aware stepping, conditional breakpoints, tracing, PE analysis, and carefully controlled memory modifications. Always use the server on authorized targets and avoid exposing its unencrypted HTTP interface to untrusted networks.