ghidra-reverse

Ghidra 逆向分析技能（GhydraMCP）

来源与验证状态（必读）

来源：GhydraMCP 官方文档/README（https://github.com/starsong-consulting/GhydraMCP）， 本仓库尚未实战验证，遇到新坑请补充到此文件。

本文档基于 2026-07-11 对 GhydraMCP 仓库（starsong-consulting/GhydraMCP，276 star，Apache 2.0，未 归档）README 和源码（bridge_mcp_hydra.py）的核实整理。本仓库目前没有一次真实逆向任务跑过这套工具 链。不像 ida-reverse 的"已知问题与反思"来自真机踩坑，这里列的都是文档/源码推断出的"可能坑"， 请在第一次真实使用后回填本文件、补充真实踩坑记录。

这是什么

GhydraMCP（starsong-consulting/GhydraMCP）把 Ghidra 通过一个 HATEOAS REST API 插件 + Python MCP 桥接脚本（bridge_mcp_hydra.py）+ 独立 CLI（ghydra）暴露给 AI 助手。它 fork 自 LaurieWired/GhidraMCP，新增了多实例支持、数据操作能力和 HATEOAS REST API。支持 Ghidra 11.x 和 12.x（两个版本分开打包 release，插件 ghidraVersion 必须和实际 Ghidra 版本精确匹配）。

官方 README 把 MCP 桥接层标注为"deprecating in favor of CLI"—— 独立 CLI ghydra 是更新、更推荐 的用法（同等能力 + 更好的输出格式化 + --json 模式），但桥接脚本仍可用，是否切换不是本文档要决 定的事，先如实记录两条路径都存在。

端口配置存疑（请在首次真机验证时确认）

.kiro/settings/mcp.json 里已有这一条注册（此前完全没有文档说明，属于"已经接入但未被记录"的状态）：

"ghidra": {
  "url": "http://localhost:8765/mcp"
}

kali/mcp-kali-example.json 也有对应条目（见该文件 ghidra 键）。但根据 GhydraMCP 官方 README 和 bridge_mcp_hydra.py 源码核实（2026-07-11 用 gh api 拉取 README 全文 + 用 GitHub code search 搜 8765/streamable 均零命中 + 直接 grep 源码得到下面两行）：

bridge_mcp_hydra.py:31:  DEFAULT_GHIDRA_PORT = 8192
bridge_mcp_hydra.py:4261: mcp.run(transport="stdio")

也就是说：

• 官方桥接脚本固定走 stdio 传输，不是 HTTP/url 形式的 MCP 端点
• Ghidra 插件本身监听的默认端口是 8192（第一个打开的 CodeBrowser 用 8192，后续每开一个递增， 多实例范围 8192-8447），不是 8765
• 官方文档/源码全文搜不到任何 "8765" 的引用

http://localhost:8765/mcp 这个配置，既不匹配 GhydraMCP 文档化的 Ghidra 实例端口范围（8192 起）， 也不匹配它的 MCP 传输方式（stdio，不是 HTTP url）。可能的解释（未核实，按可能性排列）：

1. 有人在这台机器上手动跑了一个自定义 HTTP wrapper，把 stdio 桥接转成 HTTP，监听在 8765
2. 这条配置指向的其实是另一个同类 Ghidra-MCP 项目（不是 starsong-consulting/GhydraMCP）
3. 这条配置是占位/未验证，从未真正连通过

首次真机验证此技能时，请先确认 .kiro/settings/mcp.json 里这条 ghidra 到底连的是什么进程；连 不通就改用下面的官方 stdio 配置。

标准配置（官方 README，stdio 方式）

{
  "mcpServers": {
    "ghydra": {
      "command": "uv",
      "args": ["run", "/ABSOLUTE_PATH_TO/bridge_mcp_hydra.py"],
      "env": { "GHIDRA_HYDRA_HOST": "localhost" }
    }
  }
}