让 AI 看懂没源码的软件:REA 把逆向分析接进智能体

QUOTE

AI 能否看懂软件，不只看模型，还要看它能否调用合适工具、展示可复核的证据。

—— AI先知奇点

很多 AI 编程助手擅长读源码、改代码。可一旦目标只剩安装包、桌面应用或二进制文件，智能体就缺少“眼睛”和“手”：它需要知道从哪里找入口、怎样看调用关系、如何把运行现象对应到程序行为。

REA 想补上的正是这一层。它把逆向分析工具整理成 AI 智能体能调用的 MCP 服务和命令行工作流。理解它的关键，是把它看作“分析能力的接线台”，而不是自动吐出完整源代码的反编译器。官方 README

本文看点

REA（Reverse Engineer Anything）面向原生二进制、JavaScript/Electron、.NET、网站和运行时行为等目标。它让智能体针对一个具体问题调用合适的分析能力，再把结果和证据返回给模型。

这改变的是工作入口。过去，使用者通常要先熟悉多套工具和各自的操作方式；现在，可以先用自然语言说清楚要查什么，再让智能体围绕目标组织分析。例如，不是笼统地问“这个程序怎么工作”，而是问“这个桌面应用点击导出后，数据经过哪些模块，最终调用了什么系统接口”。

但自然语言不会自动变成真相。智能体提出的结论仍要回到函数、调用者、指令、配置或运行结果核对。REA 提供的是调查工具和证据，不替人完成判断。

还有个容易忽略的隐私边界：分析可以在本地执行，但工具结果会交给当前智能体。结果是否会被模型服务保存或用于改进，取决于所用服务的数据政策。处理公司软件或敏感文件前，应先确认本机分析环境和模型服务规则。REA 官方说明

Notion：追踪剪贴板写入过程

REA 官方展示的 Notion Desktop 案例，从界面侧的 clipboard.write 出发，经过 preload 封装和 IPC 调用，再到达主进程中的 Electron clipboard API。

这个案例说明，分析价值不只是“搜到一个函数”。真正有用的是沿着调用关系补足上下文，再检查相关源码和证据，弄清楚数据怎样从界面传到系统能力。REA 的结果帮助定位线索；追踪、解释和验证仍是整个过程的一部分。Notion 案例

DX-Ball：线索、重建和验证各有分工

另一个案例更接近传统逆向：项目用 REA 检查 1996 年 Windows 游戏 DX-Ball 的可执行文件，追踪一个声音左右声像的计算过程。REA 给出函数指令、调用者和常量等线索；随后，项目开发者自己编写了可维护的 C 版本，并用 3,205 组原版 x86 行为用例及编译字节比对做验证。

这里最值得注意的不是数字有多大，而是分工清楚：REA 帮忙调查，开发者负责重建，独立测试负责验证。案例没有证明“REA 单独把游戏源码还原出来”，也不能说明每个二进制都能照此复刻。DX-Ball 案例

官方推荐用 npx rea-agents setup 配置智能体。安装流程会列出计划修改的路径和内容，等待使用者审阅、批准；完成后按提示重启智能体。REA 支持多种客户端，具体选择和可用工具会受当前环境影响。官方安装文档

使用前先把问题缩小到一个行为或一段调用链，再确认目标类型需要哪些分析引擎。JavaScript 代码、原生二进制、Android 安装包和网站的分析条件并不相同；是否需要 Ghidra、IDA、Hopper、JADX 或浏览器环境，要以官方当前文档和本机诊断结果为准。不要因为 MCP 已接入，就假定所有引擎都已安装、所有目标都能分析。

REA 对需要让编程智能体调查陌生软件的开发者、工具作者和安全研究者更有吸引力。它能减少“先把工具和智能体接起来”的重复配置，也让问题、分析步骤和证据更容易形成一条工作流。

如果你已经熟练使用 Ghidra 或 IDA，并有固定的脚本和分析流程，REA 的价值可能主要是把已有能力暴露给智能体；它不一定替代你的主力工具。若任务只是读开源项目源码，也未必需要引入逆向分析链路。

工具也不替你决定分析是否合规。只对自己拥有、获准测试或依法可以分析的目标开展工作。REA 降低的是操作门槛，不会自动赋予软件授权，也不会让不完整的证据变完整。

REA 值得关注的地方，是它尝试把逆向工程从“专家手动操作一堆工具”，推进到“智能体能按问题调用工具，并展示证据”。这让更多开发者有机会调查没有源码的软件行为。

但准确的期待应该是：它帮智能体更系统地找线索、读证据、解释行为；最终结论、重建代码和验证责任，仍在人手里。把它当作调查助手，能看到价值；把它当作源码复原按钮，就会高估它。