让 AI 助手读懂二进制与应用行为（REA）

看到一个应用里的功能，想在自己的产品里做一个，源码拿不到，剩下的路通常是反汇编、读伪代码、盯运行时行为。这条路过去靠人一点点啃，工具散在不同软件里，结论也没有统一的记录方式。

REA 是用 TypeScript 写的 MCP 服务器，把 AI 编程助手接到二进制、JavaScript 应用、网站、Android 设备这些目标的分析工具上，输入目标路径，输出带证据与限制说明的分析结论。

用法是让 agent 通过 MCP 调用 REA 去检查目标、追踪相关代码，REA 把发现和对应的证据一起返回，agent 再拿这些材料追问、解释行为，或者据此写一份实现。CLI 命令走的是同一套工作流。分析在本地跑，原生分析可以复用机器上已有的 Hopper、Ghidra 或 IDA，纯静态的 JavaScript 分析不需要原生引擎。

仓库地址在 https://github.com/morluto/rea，MIT 许可证，主要语言 TypeScript，占比 83.5%。当前 149472 star、34567 fork、467 watcher，开放 Issue 323 个。典型场景是安全研究、CTF、以及对竞品应用做行为复刻前的调研：你手上只有编译产物或安装包，需要先搞清楚某段逻辑怎么实现。

基础用法

安装与依赖

运行环境需要 Node.js 22.x（>=22.19）、24.x（>=24.11）或 26+，另加 npm。装完之后先跑 setup：

npx rea-agents setup

setup 会让你选择要接入的 agent，展示将要做的改动，等你批准后再写入。它会注册 REA 的 MCP server 和配套的工作流指令，并对已有的配置文件做备份。做完这一步要重启 agent 才生效。

目前 setup 支持 Claude Code、Codex、Cursor、Gemini CLI、Grok Build，以及另外一些 agent，完整名单在 docs/installation.md#supported-agents。用 Bun 的话把 npx rea-agents@latest 换成 bunx rea-agents@latest。

原生二进制分析需要你机器上已经装好 Hopper、Ghidra 或 IDA 之一；setup 可以选择帮你装 Hopper，前提是你批准。这部分依赖不装，就只能做 JavaScript 这类静态分析。

最短能跑通的示例

装好之后，直接在 agent 会话里提问即可：

Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.

把 Notes 换成你的目标应用，把 search 换成你想弄懂的功能。

不想通过 agent，也可以直接在终端里分析一个已经解包出来的 JavaScript/Electron 应用目录或 ASAR 文件：

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

Windows 上路径写成 "D:/apps/example" 这种形式。如果要经常用命令行，装成全局命令：

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

确认它跑起来了

analyze-javascript-application 的返回结果里会带上模块、导入、Electron 边界，以及支撑这些结论的证据。终端输出是 JSON，里面能看到这几类字段，就说明这一跑是通的。

原生二进制的命令要先配置好 provider 才能用，具体命令和 provider 选择写在 docs/cli.md。仓库里没有给出原生分析成功输出的字段清单，这一点只能照着那份文档自己确认。

主要功能

可分析的目标类型

• 原生二进制：返回伪代码、汇编、字符串、符号、调用与引用。前提是机器上装了 Hopper、Ghidra 或 IDA。
• JavaScript 与 Electron：返回模块、导入、source map、路由、IPC，以及原生插件之间的关系，不需要原生分析引擎。配合 --json 输出结构化结果。
• 网站：返回页面结构、脚本和网络层面的信息。README 中这一项的说明在可获取的素材里被截断，完整返回字段没有列出。
• Android 设备：rea-agents 6.4.0 新增。通过 ADB 做设备检查、split-APK 获取、日志、截图、文件传输和显式的 app 生命周期操作，另外还做 manifest 与本地化字符串的解码。
• Go 二进制：内置静态的 ELF/PE/thin Mach-O 检查，给出编译器版本、模块、replace 和构建设置，不需要本地安装 Go。
• SQLite 数据库：读取表、列、索引、视图、触发器和选定普通表的行。需要本地的数据库或 WAL 快照，并要求 Node.js 24.x >= 24.15 或 26+，受原生 SQLite 的限制。

同一份 README 还列了 WASM 制品、EVM 字节码、离线 ELF 布局和录制的 Linux 崩溃这几类目标。WASM 需要自备 WABT 1.0.42，EVM 与离线 ELF 依赖 Linux x64 上的本地载体或 pwntools，条件比前面几类更窄。

Agent 接入与命令行

• setup 注册：把 REA 的 MCP server 与配套工作流指令写进所选 agent 的配置，改动前对原文件做备份，批准后生效，重启 agent 后可用。
• 命令行接口：CLI 与 MCP 共用同一套工作流。已有全局命令时用 rea 加子命令；更新用 rea update，通过 npx 使用的则重跑 npx rea-agents@latest setup。Bun 全局更新要求 Bun 1.2.17 或更高，版本不够得先手动升级 Bun。

参数与配置

常用参数

• --json：加在 analyze-javascript-application 后面，输出结构化的 JSON 结果而不是可读文本。
• 绝对路径：从 6.0.0 起，MCP 的文件系统输入要求绝对主机路径，覆盖 target 与 snapshot 路径、evidence bundle 路径、managed 与 firmware 输入，以及 browser/Electron 的启动路径。相对路径会被拒绝。
• npx -y rea-agents@latest 适合一次性命令，日常使用建议 npm install --global rea-agents 后直接调 rea。
• 原生分析还有一个 provider 选择参数，用来指定走 Hopper、Ghidra 还是 IDA，具体写法见 docs/cli.md。

配置文件

仓库里没有说明配置文件的字段结构。setup 会改动所选 agent 的 MCP 注册并对原文件做备份，但写入了哪些键、值长什么样，README 和素材里都没有展开。

实际使用中的坑

• 在真实的 Windows 11 x64 机器上，rea doctor 的原生权限自检会失败，报错是 Delete owned object by handle failed（Win32 5），并且会在磁盘上留下探测目录。这条 Issue 仍是待解决状态。
• 6.3.0 的 analyze-javascript-application --json 在一份大 bundle 上会中止，而同一份输入在 6.2.0 上能跑完。这条同样是待解决。
• MCP 在受限资源下的可用性与性能是排在前面的 roadmap 条目，40 条评论，未解决。这说明当前的问题不只是零散的单点 bug。
• JavaScript 分析在同步计算期间会阻塞 MCP 的 ping 与取消，这条已经修复。

几个同类怎么选

下面三个项目都在做「让 AI agent 参与逆向工程」这件事，差别在覆盖面和绑定深度。

REA 的短板在专精程度。它把多种目标收进一套接口，代价是原生二进制分析要额外维护 Hopper、Ghidra 或 IDA 这类外部引擎，而且 6.x 版本改动频繁，升级前必须先读迁移文档。如果你的活儿几乎只围绕 Ghidra，并且更想要贴近 GUI 的工具集，两个 Ghidra 系项目路径更短。反过来，目标形态多、想用一个 MCP 覆盖多种制品时，REA 的覆盖面更合适。

合规限制

REA 面向的是二进制、应用与网站分析，这类能力只适用于你自有的资产，或者已获得明确授权的目标。对着第三方应用或网站跑分析，可能触碰软件许可协议、平台服务条款与当地法律的红线，跨区域使用时适用规则还会更复杂。仓库里带了 DISCLAIMER.md，动手前值得读一遍。CTF 环境、自己公司的测试资产、有书面授权的渗透测试项目，属于常见的使用边界。

适合谁

需要跨多种目标做分析的安全研究与逆向工程项目适合用它，尤其是团队里已经在用 Claude Code、Codex、Cursor、Gemini CLI 或 Grok Build 这些 setup 已支持的 agent。手上只有编译产物、没有源码，想先弄懂某个功能怎么实现再自己写一份的开发者，也是它的目标用户。

只做 Ghidra 单一工具链、不想额外维护 Hopper 或 IDA 依赖的人，用 Ghidra 系项目更省事。对版本稳定性要求高、不愿意跟着 6.x 的 breaking change 频繁升级的团队，也要先掂量迁移成本。