REA 实测：让 AI Agent 用自然语言驱动 Ghidra 逆向软件

逆向工程长期以来给人高门槛的印象：需要啃汇编、学习 Ghidra 或 IDA 这类重型工具，再花大量时间手动跟踪代码。开源项目 REA（Reverse Engineer Anything）尝试改变这一局面——它把 AI Agent 与真实的逆向工具连接起来，让你用自然语言提问，拿回带证据支撑的分析结论。

Learning How AI Can Reverse Engineer Software

这篇文章会拆解 REA 是什么、MCP 如何让它调用 Ghidra、它能分析哪些目标、如何安装配置，以及入门者在使用前必须了解的法律与安全边界。

REA 到底能分析什么

REA 是一个 MIT 许可证的开源项目，核心定位是充当 AI Agent（Claude Code、Codex、Cursor、Gemini CLI 等）与底层逆向工具之间的桥梁。你不必背下 Ghidra 的每一个菜单，只需要用日常语言描述问题，Agent 会调用 REA，REA 再在本地机器上运行重型分析工具，最终返回结论以及每一条结论背后的证据和局限。

覆盖面比多数人预期的更广：

分析目标	REA 返回内容	额外依赖
原生二进制	伪代码、汇编、字符串、符号、调用与引用	Ghidra（免费）、Hopper 或 IDA
JavaScript 与 Electron 应用	模块、导入、路由、进程间 IPC	仅需 Node.js 和 npm
.NET 程序集	元数据与 CIL 指令	无需额外工具，仅静态分析
Android APK	Manifest、类、反编译方法	JADX 与完整 JDK
数据包摘要	端点、DNS、TLS SNI、协议拆解	tshark 与 capinfos

最后一行对网络方向的学习者尤其有价值——同一个 Agent 既能读二进制，也能总结抓包文件。这种「一个入口覆盖多个分析域」的设计，是把 AI 辅助逆向真正落地到日常工作中的关键。

区分这几类分析目标的关键在于它们各自的「中间表示」不同。原生二进制没有源代码，只能从机器码反推汇编，再由 Ghidra 的 decompiler 生成伪 C 代码，分析难度最高。.NET 程序集则完全不同：它编译成 CIL（Common Intermediate Language）字节码，保留了完整的元数据（类型、方法名、签名），本质上是「带类型信息的中间语言」，因此无需反编译引擎即可读出结构，但代码被混淆器处理后会丧失可读性。Android APK 是 DEX 字节码加资源文件的压缩包，JADX 负责把 DEX 转回 Java 近似代码，同时解析 AndroidManifest.xml 暴露权限与组件。JavaScript/Electron 应用通常以压缩或打包后的形式分发，分析重点是还原模块边界与主进程/渲染进程之间的 IPC 通道。抓包文件（pcap）则是另一维度——它不是代码而是流量记录，tshark 按协议层次逐层解码，REA 把端点、DNS 查询、TLS SNI 等提炼成可读摘要。

MCP：让 AI 真正「使用」Ghidra 的机制

最反直觉的部分是：一个只懂读写的语言模型，凭什么能操作 Ghidra？答案是 MCP（Model Context Protocol），一种让 AI Agent 调用外部工具的标准协议。

单独的语言模型只能处理文本，把它丢进一段汇编里，本质上是在猜。REA 以本地 MCP 服务器的方式运行，向 Agent 暴露「反编译这个函数」「列出文件中的字符串」等工具集。整个流程形成闭环：

你向 Agent 提出关于某个程序的问题；
Agent 选择某个 REA 工具并通过 MCP 调用；
REA 在本地对文件运行 Ghidra 或其他引擎；
REA 返回伪代码、汇编、引用，以及无法确认的部分；
Agent 读取证据、追问后续问题，最后用人类能理解的方式解释。

关键在于：AI 并没有凭空编造程序行为，它读取的是人类逆向工程师会读取的同一批证据，只是速度快得多。REA 会明确报告「它无法确认什么」，这一点比想象中重要——模型很容易自信地给出错误答案，而把未知显式暴露出来，既约束了 Agent，也提醒了分析师。

MCP 由 Anthropic 于 2024 年底提出并开源，目标是解决 AI 应用与外部系统之间的「N×M 集成」难题：过去每接入一个新工具（数据库、文件系统、GitHub、Ghidra）都要为每个模型单独写适配层，而 MCP 把这件事抽象成统一协议。它借鉴了 LSP（Language Server Protocol）的思路——编辑器只需实现一次 LSP 客户端，就能对接任意语言的服务器；同理，Agent 只需实现一次 MCP 客户端，就能调用任意符合规范的 MCP 服务器。

MCP 服务器通常暴露三类能力：Tools（可被模型调用的函数，如「反编译函数」）、Resources（可读取的数据，如文件内容）、Prompts（预设的提示模板）。通信基于 JSON-RPC，支持本地 stdio 与远程 HTTP/SSE 两种传输方式。REA 采用本地 stdio 服务器形式，意味着所有分析都在你自己机器上执行，Agent 只负责决定「调用哪个工具、传什么参数」，这也是 REA 强调「证据来自本地」的技术前提。

安装与配置要点

REA 需要 Node.js 与 npm。支持的版本包括 Node 22（22.19 及以上）、Node 24（24.11 及以上）或 Node 26 及更高。分析原生二进制还需要 Ghidra、Hopper 或 IDA 之一，初学者建议从免费的 Ghidra 起步。

安装只需一条命令：

npx rea-agents setup

它会询问你使用哪些 Agent，展示将要修改的配置，并在写入 REA MCP 服务器前备份原有配置。重启 Agent 后即可使用新工具。如果希望终端里常驻 rea 命令，可全局安装：

npm install --global rea-agents
rea --help
rea update

几个容易被忽视的坑：在 Linux 上，Ghidra 和 JavaScript 分析都需要 PATH 中存在 procps 兼容的 ps 命令，精简版 VM 上失败往往就是这个问题。其次，项目 README 特别警告存在同名仿冒仓库，只应从官方 GitHub 仓库、rea.tools 或 rea-agents npm 包安装——这本身就是一堂藏在安装指南里的软件供应链安全课。

npx 是 npm 自带的包执行器，让你无需全局安装就能运行某个包的一次性命令——npx rea-agents setup 会临时下载 rea-agents 并执行其 setup 子命令，跑完后不在系统留下全局可执行文件。这对偶尔使用、又不想污染环境的用户很友好，但缺点是每次执行都要检查更新，首次运行会慢一些。若你打算频繁使用并希望固定版本，npm install --global rea-agents 会把它装到全局 node_modules 并把 rea 命令写入 PATH，之后可用 rea update 主动升级。

关于版本要求：Node.js 的偶数大版本号是 LTS（长期支持）线，奇数版本是短期实验版。文中提到的 Node 22、24 属于 LTS 序列，Node 26 是更晚的 LTS。MCP 客户端与服务器之间的协议版本会随 Node 生态演进，因此 REA 对 Node 版本有下限要求而非精确锁定。若你机器上同时装了多个 Node 版本，用 nvm 或 fnm 切换比修改系统 PATH 更稳妥。

两种使用路径：Agent 与命令行

使用 REA 有两种方式。第一种是通过 AI Agent：配置完成后，用自然语言描述你想理解的内容，Agent 自行决定调用哪些 REA 工具。典型的 prompt 可能是：

Explain how the clipboard feature in this app works, show me the evidence,
and list anything you could not confirm.

第二种是直接使用命令行，不依赖 Agent 也能跑同样的工作流。例如下面这条命令用于检查已解包的 JavaScript 或 Electron 应用，完全不需要原生分析引擎：

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

根据文档，输出会列出应用的模块、导入关系与 Electron 边界，并附带每一项结论的证据。

逆向工程的核心技能：识别已知算法

无论分析者是人还是 AI，逆向中最实用的技巧之一就是通过「指纹」识别常见算法。编译会丢弃注释，strip 会抹掉函数名，但数学本身无法被隐藏。以经典字符串哈希 djb2 为例：

unsigned int djb2(const char *s) {
    unsigned int h = 5381;
    while (*s) {
        h = ((h << 5) + h) + *s++;
    }
    return h;
}

编译并 strip 之后，名字「djb2」消失了，但伪代码或汇编中仍会留下两条线索：初始值 5381，以及左移 5 位后相加——这等价于快速乘以 33。熟悉这些线索的人几秒内就能叫出函数名，而读取 REA 证据的 Agent 也能用同样的方式匹配。其他著名常量同理，比如 MD5 与 SHA-1 开头的 0x67452301，或 CRC32 中的 0xEDB88320。

识别算法只是完成了一半工作，另一半是证明它：用相同输入分别运行原程序与重写版本，确认输出完全一致。

常量指纹之所以可靠，是因为编译器优化很少改变算法的数学结构。h = ((h << 5) + h) + *s++ 中 (h << 5) + h 等价于 h * 33，许多编译器会直接把它优化成 lea（load effective address）指令——在 x86 上形如 lea eax, [eax + eax*4] 再左移，或者 imul eax, eax, 33。因此识别 djb2 的关键不是记住源码，而是认识这两类指令模式加上 5381 这个魔数。

其他高频指纹还包括：MD5/SHA-1 的初始向量 0x67452301、0xEFCDAB89 等四个常量；CRC32 的多项式 0xEDB88320（反向表示）；RC4 的 256 字节 S 盒初始化循环；AES 的 S-box 与 Rcon 表。工具如 findcrypt（IDA 插件）或 Ghidra 的脚本会扫描二进制中的这些常量来自动标注候选算法。但要注意，指纹只能给出假设，最终仍需用已知输入输出对做行为验证——这正是文章强调「识别只是完成一半」的原因。

使用边界：法律与数据安全

REA 项目明确声明其用途限于合法研究、教育、互操作性、软件保存，以及你拥有或获得授权分析的对象。软件许可协议与当地法律可能限制逆向工程行为，因此在自有程序或 CTF 挑战上练习是最稳妥的选择。

几个必须遵守的原则：

只分析你拥有或被授权检查的软件。REA 不含 IDA、Hopper、JEB 等付费工具的许可证，项目明确反对破解版本与盗用密钥。Ghidra 免费，是学生的理想起点。
注意数据流向。REA 的分析在本地运行，但结果仍会发送给 Agent，背后的 AI 提供商有自己的数据政策。来自工作或学校、不允许外传的内容，不应投喂给 Agent。

实战价值与后续方向

REA 的 showcase 页面提供了两个值得参考的案例：有人追踪老游戏 DX Ball 中的声音计算逻辑，用 C 重写后通过了 3,205 个测试用例，与原 x86 代码行为一致；另一个案例则梳理了 Notion 桌面应用如何在进程间传递剪贴板数据。这些案例展示了「验证」这一步在规模化后的效果。

对网络方向的学习者来说，REA 的数据包分析能力与课堂内容直接相关，可以结合 picoCTF 这类允许「合法破坏」的练习平台逐步上手。核心循环很简单：提出问题，让 Agent 用 REA 收集证据，然后自己验证答案。AI 不会替代理解，它只是加速理解——跳过验证步骤，你信任的不过是一段自信满满的文字而已。