1466 star 的 x64dbg-MCP：让 AI 亲手操作调试器，逆向从此说人话

AI 已经会写代码、改 bug、做 Code Review 了。但有一件事它一直没干过：亲手操作调试器。

断点怎么下、单步怎么走、内存怎么读、寄存器长什么样——这些它只能"看"（看截图、看日志），不能"动"。你让 AI 帮你分析一个崩溃，它顶多给你念一段 disasm 文本，然后说"你在这下个断点试试"。

x64dbg-MCP，上线 5 天 1466 star。它把这个缺口补上了：AI 终于能亲手把玩你的调试器。

一句话看懂它在反什么

市面上不是没有"AI 调试"的 MCP 方案。但绝大多数走的是套壳路线：在调试器外部跑一个进程，用命令行调调试器，再拿正则去解析它吐出来的文本。GDB 的 MCP 基本都这么干。

x64dbg-MCP 把这条路反过来：它不是一个外部进程，而是一个原生插件。编译出来是个 .dp64/.dp32，扔进 x64dbg 的 plugins 目录就生效。启动时它在 x64dbg 的进程地址空间里跑，运行时直接解析 x64bridge.dll 和 x64dbg.dll 的 API 符号，然后开一个 HTTP 服务等你连接。

它不解析调试器的"话"，它直接握住调试器的"手"。 这就是质的不同——没有文本解析的损耗，没有中间层的误解，AI 拿到的是断点、寄存器、内存这些结构化的原生数据。

为什么敢说"零依赖"：Zig 的功劳

作者用 Zig 写了这个插件。不是 C、不是 Rust、不是 Python，是 Zig。好处很实在：

• 零依赖、单二进制：没有 .NET runtime，没有 Python 环境，一个 .dp64 文件就是全部。装进插件目录即用。
• 一套代码交叉编译 x32 + x64：zig build 一条命令，Windows 插件连 Linux、macOS、WSL 上都能编出来——这对平时用 Linux 做逆向分析的工程师是刚需。
• 干净利落：项目结构就 src/ 一个目录，main.zig（插件入口）+ core/（SDK 绑定、配置、HTTP server）+ mcp/（JSON-RPC 工具）。

不用 .NET 意味着什么？你在 WSL 里开着 x64dbg，AI 在宿主机上连着它，中间不需要任何运行时对齐。这对逆向/恶意样本分析的工作流太关键了。

71 个工具，把调试器整个交出去

这是我最想强调的部分。x64dbg-MCP 暴露了 71 个 MCP 工具 + 22 个事件回调，覆盖完整调试工作流：

• 断点全家桶：SetBreakpoint、SetHardwareBreakpoint（DR0-DR3）、SetConditionalBreakpoint（带条件表达式）、Enable/Disable/Toggle/Delete、ResetHitCount
• 执行控制：run（F9）、StepInto（F7）、StepOver（F8）、StepOut（Ctrl+F9）、PauseDebug（F12）、RunToAddress
• 内存与寄存器：ReadMemory、WriteMemToAddress（直接 patch 内存）、GetAllRegisters、SetRegister、GetMemoryMap、AllocateMemory
• 逆向专用：FindPattern（特征码扫描带 ?? 通配符）、GetStrings、GetReferences（找 CALL/JMP 交叉引用）、DetectOEP（脱壳找原始入口点）、DumpModule（整模块 dump）、GetPEB、GetSEHChain（x32）
• 分析辅助：GetCallStack、GetThreads、ListModules、ListSymbols、AnalyzeModule（PE 结构分析）、FollowPointer（解指针链）

外加 22 个事件回调——init、stop、断点命中、异常、单步、attach/detach、DLL 加载卸载、线程切换。AI 不仅能"下指令"，还能"听事件"，这才能做出真正的 agentic 调试循环，而不是一问一答的死流程。

上手（真实可跑）

装起来比你想的简单，四步：

1
2
3
4
5
6
7
8
9

# 1. 下载 release，把 dist/ 里的文件复制进 x64dbg 根目录
#    （会自动部署 x32 和 x64 两个插件）
# 2. 启动 x64dbg —— MCP server 自动起
#    x64 默认 0.0.0.0:9094，x32 默认 0.0.0.0:9095
# 3. 在 MCP 客户端（如 Claude Code 的 .mcp.json）里加：
#    "mcpServers": {
#      "x64dbg": { "type": "http", "url": "http://localhost:9094/" }
#    }
# 4. 跟 AI 说人话，比如"加载 calc.exe 并在入口断下来"

README 里给了一段真实的对话演示，AI 会自己串工具：

你：加载 calc.exe 并在入口处断下来 AI：调用了 LoadBinary → SetBreakpoint → run → WaitForPause，在 0x7FF7A1234000 命中断点 你：当前寄存器是什么？ AI：GetAllRegisters → RAX: 0x0, RCX: 0x7FF7A1234000, RDX: 0x1, … 你：读当前指令指针处的 64 字节 AI：ReadMemory → 48 83 EC 28 E8 12 34 00 00 …

看到没？AI 会自己决定调哪个工具、按什么顺序调。 这就是 agentic 调试——你把"怎么调"的权利交给了 AI，它照着结果继续下一步。

和主流方案横向对比

区别在哪？前三种都在"调试器的外面"看它干活，靠解析输出来猜；x64dbg-MCP 在"调试器的里面"握着它的 API。数据是原生的，不是文本的；动作是直接的，不是模拟键盘的。 而且 HTTP + SSE 双传输，新的 Streamable HTTP 和老的 SSE 客户端都能连，兼容面宽。

丑话说前头

这个项目很香，但有几个坑你必须知道，尤其干逆向的：

• 才 5 天，单人项目。1466 star 涨得凶，但 143 个 fork 背后只有一个作者在推。真要上生产分析、当日常工具用，先做好它会频繁变、甚至某天不维护的心理准备。
• 开 HTTP 端口 = 开门揖盗。默认绑定 0.0.0.0:9094，意味着你局域网里任何设备都能连上来操控你的调试器。你分析的是恶意样本，结果自己的调试器被"朋友"反向操控了，画面太美。作者给了配置项可以改成 127.0.0.1——干恶意样本分析，务必改成本地回环，最好再加一层 Bearer token 鉴权（README 提到支持）。
• 71 个工具 = 上下文炸弹。MCP 工具列表会整个塞进 AI 的上下文。71 个工具的描述占的 token 不少，配合 22 个事件回调，你的上下文预算会紧张。这是 MCP 生态的通病，x64dbg-MCP 用"工具数量换能力完整"换得很彻底，但代价得你自己扛。
• AI 读恶意样本，可能被反咬。恶意代码是专门用来骗人的。你把一个混淆样本的完整内存、寄存器、特征码喂给 AI，AI 的判断可能被精心构造的假象带偏。AI 是你的副驾，不是你的安全带——最终结论还得靠人。

值得关注的方向

x64dbg-MCP 最值得抄的不是它 71 个工具，而是**“把能力住进进程里”**这个思路。外面跑个脚本去解析文本，永远有信息损耗和时序问题；住进进程里，直接拿 API，才是 AI 操控真实软件的正解。这个范式会蔓延到所有"需要上手操作"的工具——调试器只是第一个被攻克的。

当你的调试器能被 AI 亲手操作，逆向的门槛和上限同时被改写。门槛降了（说人话就能调试），上限也高了（AI 可以自己跑几百次特征码扫描、自己解指针链）。这可能是"AI 从写代码到碰系统"最实在的一步。

搬砖程序员带你飞，专注 Golang / AI / 后端。每天一篇，讲清楚一个技术真相。