bethington/ghidra-mcp

解决什么问题

在 Ghidra 里逆向一个二进制，日常是大量琐碎重复操作：反编译某个函数、看调用者、跟 xref、重命名、写 plate comment，然后重复几百次。写脚本当然可以，但 Ghidra 的 API 风格独特，多数分析员要么反复复制同一批脚本，要么干脆手点。这个项目把 Ghidra 的分析与编辑能力包装成 MCP server，让大模型客户端来驱动这些步骤——关键在于它同时提供写操作（重命名、改类型、加注释、建结构体），而不只是只读查询。

有什么不同

现在市面上已有若干 Ghidra MCP 桥接项目，大多只是几十个只读工具的薄封装。这个项目的覆盖面大得多：README 声称有 209 个工具，涉及 P-code 模拟、实时调试器控制和 PCode 图数据流传播，还支持 headless 模式用于批处理和 CI。更有意思的设计是把命名与类型约定做进工具层——auto-fix / warn / reject 三档校验，外加 analyze_function_completeness 评分，等于给 AI 或人一个明确目标。这和"让模型自由发挥命名风格"的常见做法很不一样，也是最可能在实战中见效的部分，因为把命名交给模型后，最先崩的就是一致性。此外它支持按函数哈希在不同二进制版本之间迁移注释，这属于工作流级别的能力，而不只是 API。

适合谁

已经在 Ghidra 里长期工作的恶意样本分析、漏洞研究和固件/嵌入式逆向人员，适合把 LLM 当作快速阅读反编译和批量补注释的助手。跨固件版本做版本化分析的团队，能从注释迁移和 Ghidra Server 集成里获益最多。不适合还没掌握 Ghidra 的人——安装扩展、严格匹配 Ghidra 版本、排查 bridge 问题都是必修课；也不能代替对汇编的理解，模型输出仍然需要人工核验。

上手成本

偏高。Ghidra 必须锁定 12.1.4（扩展只在与构建时相同的版本加载），还需要 Java 21、Python 3.10–3.13、uv，以及支持 MCP 的客户端。安装走 release 里的扩展 zip 和 wheel，README 的 quickstart 给出了 uv tool install 命令。README 明确提醒两个坑：从 GUI 启动的客户端继承不到 shell 的 PATH；release candidate、main 和 dev 分支的稳定性各不相同。Apache-2.0 许可友好，但版本迭代频繁，Ghidra 一升级就要预留迁移时间。

点评

这不是一个刚冒出来的试验品：约 14 个月内积累了 5800 多 star、带测试的发布流水线，还有一条 298 分的 Show HN 帖。真正值得看的信号是它在 Java 月榜上单月 +1,948 star——热度在上升而不是消退，这也符合当下 MCP 的普遍热潮，意味着 API 还会继续变。209 个工具的覆盖面很强，但同样是维护负担；真正有态度的赌注是约定校验那一层。如果你已熟悉 Ghidra、想要一个 LLM 在旁边协助标注，它是目前最完整的选择；如果你想找个稳定的底座在上面二次开发，建议等 tagged release 再稳定一阵。