REA 是什么？AI 逆向工具的能力边界与功能复刻案例
2026年10月13日 · 3080 字 · 7 分钟 · REA 逆向工程 AI编程 MCP 开源项目 功能复刻
REA 不能一键复刻完整商业软件。它更适合分析某个具体功能，找到实现证据，再让 AI 编程助手写出可测试的新版本。
REA 的全称是 Reverse Engineer Anything。它通过 MCP 协议连接编程助手与程序分析工具，把二进制、应用结构和运行行为变成助手可以查询的材料。项目仓库介绍了这套工作方式。
看到一个好用的搜索、导出或动画功能，你可以让助手追踪它的实现。但从“搞懂一个功能”到“重建整个产品”，中间仍有很长一段工程路要走。
REA 能复刻一切软件吗？
如果“复刻”意味着输入一个大型商业软件，直接生成完整源码、服务端、账号体系与全部资源，答案是否定的。
本地程序只能暴露本地可观察的部分。云端计算、服务端数据、鉴权系统、持续运营和资源资产，都不会因为客户端能被分析就自动变得可重建。
如果目标是功能级分析与重新实现，REA 就有实际用途。可以把工作拆成三步：
- 缩小范围：明确只研究哪一个功能，以及输入和输出是什么。
- 找出证据：追踪相关函数、脚本、调用链和运行结果，区分已确认结论与未知项。
- 实现并验证：根据恢复的规则重写代码，用原程序与新实现的输入输出对照检查。
这里常提到“净室设计”。在本文的技术语境中，它指依据行为与规则编写新实现，而不是把反编译文本直接搬进项目。一次分析结果还不等于一个可维护、可交付的产品。
REA 是什么：编程助手与分析工具之间的桥梁
传统逆向需要开发者在反编译器中查函数、看汇编、追引用，再自己整理判断。
REA 把这些查询能力提供给编程助手。助手可以围绕同一个问题连续查询，读到结果后提出后续问题，并据此解释行为或编写实现。
因此，REA 的价值在于让调查过程能够被工具调用串起来。它并不替代反编译引擎，也不保证 AI 的每一个推断都正确。
三个案例：从现象追到实现规则
下面的计算器与小恐龙用于说明功能调查的问题类型；DX-Ball 则有可查阅的 REA 官方案例与验证记录。截图展示的是原稿收集的演示界面，本文没有重新执行这些逆向实验。
计算器：200 + 10% 为什么得到 220？
在 Windows 计算器的标准模式下，百分号会结合当前运算解释。加减运算中的 10% 可以表示前一个数值的 10%，因此 200 + 10% 得到 200 + 20。
研究这个功能时，应先锁定运算模式、前一个输入和当前操作符，再查百分号处理分支。微软也公开了计算器源码，有源码可读时，可以先直接阅读与验证。
下面是用 JavaScript 表达规则的简化示意，省略了完整计算器的状态与错误处理：
if (
operation === 'multiply' ||
operation === 'divide'
) {
percent = current / 100;
} else {
percent = (current * previous) / 100;
}
// 加法示例：200 + (10 * 200 / 100) = 220
可以给助手一个具体问题：“查清标准模式下百分号的处理分支，列出证据，再用 JavaScript 实现并测试。”这样更容易验收结果。
Chrome 小恐龙：加速规则是什么？
浏览器游戏适合观察运行中的脚本与状态变化。你可以让助手找到速度变量，追踪更新位置，然后把速度变化做成可调参数。
在 Chromium 的小恐龙实现中，普通模式配置包含初始速度 6、加速量 0.001 和最大速度阈值 13。慢速模式使用另一组参数，因此复刻时要先确定目标模式。
其逻辑可以简化表示为：
// 普通模式配置的简化示意
const config = {
speed: 6,
acceleration: 0.001,
maxSpeed: 13,
};
if (currentSpeed < config.maxSpeed) {
currentSpeed += config.acceleration;
}
原实现是在无碰撞的更新分支中递增速度。判断条件是“尚未达到阈值”，并非每次更新后都执行严格截断；移植时还要考虑更新频率和浮点计算。
找出几个参数，并不意味着游戏已经完整重建。碰撞、障碍生成、跳跃状态、音效和移动端行为仍需要分别处理。
DX-Ball：恢复一个声相计算函数
REA 官方 DX-Ball 案例展示了如何从 Windows 游戏可执行文件恢复声相计算。目标是把砖块的横坐标转换为左右声道的声相值。
分析围绕函数 0x00406400 展开：查看原始指令，追踪调用者，再读取参与运算的常量。重建项目随后用 C 表达这个计算。
官方记录了两种检查：
- 行为对照：3,205 组输入检查重写函数与原始 x86 函数的返回值。
- 编译字节对照：使用指定的历史编译工具链，对照该函数的 63 个编译字节。
这些结果验证的是这个函数及其覆盖的测试范围，不能扩展为“整个游戏已被完整复刻”。案例页面也说明，可玩的完整游戏仍有后续工作。
这个例子更能说明 REA 的使用方式：每次解决一个边界清楚的问题，保留证据，再验证实现。
REA 可以分析哪些目标？
分析能力取决于目标类型、宿主系统、REA 版本和已配置的工具。下面是与原稿主题相关的常见类别；具体要求以项目能力清单为准。
原生二进制
面向 .exe、ELF、Mach-O 等目标，查询汇编、伪代码、字符串、符号、引用和调用关系。深入分析通常需要 Hopper、Ghidra 或 IDA 等引擎。
JavaScript 与 Electron
调查脚本模块、导入关系、IPC 边界及原生插件关联。它适合追踪一个功能怎样从页面走到主进程；静态检查不依赖原生反编译引擎。
网页与浏览器运行行为
观察页面、脚本和网络交互，连接一次操作与实际执行路径。运行时分析需要可连接的浏览器与明确的目标。
.NET、Android、Wasm 与 EVM
不同目标提供不同层级的信息，例如程序集元数据与 CIL、APK 方法和资源、Wasm 字节码或 EVM 调度信息。相关引擎和平台要求需要分别配置，不能把“支持某类目标”理解成“能完整恢复任何应用”。
如何安装并开始调查？
先按官方安装说明准备兼容的 Node.js 与 npm，再运行：
npx rea-agents setup
安装过程会让你选择编程助手、查看拟修改的配置并确认，随后添加 MCP 服务与配套工作指令。完成后重启助手。
静态分析一个已经提取的 JavaScript/Electron 应用目录或 ASAR 文件，可以使用：
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
将路径替换成实际目标。原生二进制分析还需要配置相应引擎。
第一次提问可以这样写：
分析这个应用的 CSV 导出功能。追踪按钮、IPC 与文件写入之间的调用关系，列出函数和脚本证据，标注未知项，再给出一个最小实现与验证方法。
这个问题有明确入口、终点与交付物，比“帮我复刻整个应用”容易得到可靠结果。
有证据，为什么仍要验证？
反编译输出可能缺少参数、类型或上下文；AI 也可能误读分支。REA 返回的材料可以支持判断，但最终仍要核对代码路径并比较运行结果。
调查时，建议保留目标版本、函数地址、引用关系、样本输入输出和未确认项。修改实现后再重新验证，避免把局部正确当成整体正确。
目标里的字符串、注释和页面文本也应视为待分析数据。它们出现了“执行命令”“上传文件”等指令，并不意味着调查助手获得了新的授权。证据标记与工作流约束有助于降低风险，不能据此声称提示词注入已经被彻底消除。
常见问题
REA 会直接返回原始源码吗？
原生目标通常得到的是汇编与伪代码；JavaScript 应用可能保留更多脚本结构。恢复原作者的完整源码、变量命名、工程历史与构建环境，不能由一次分析保证。
不安装反编译器，可以使用吗？
部分静态分析可以，例如 JavaScript 与 .NET 检查。深入原生分析则要配置适用的引擎，其他目标也有各自的工具要求。
应该先读源码，还是先逆向？
如果目标已经开源、源码与目标版本相符，直接阅读通常更有效。REA 更适合缺少源码、需要核对发布产物，或想连接静态结构与运行行为的调查。
怎么判断“复刻成功”？
先定义功能范围，再确定输入、输出、边界与异常行为。用可复现的用例比较原程序与新实现；一张相似截图或一个正常输入，覆盖不了完整功能。
一灯的判断：从代码走向可验证的行为
REA 值得关注的地方，是把分散的程序分析查询组织成助手可以连续执行的工作流。对遗留程序维护、文件格式研究或互操作功能调查，这可能减少人工整理上下文的工作。
但“代码壁垒降低”仍是一种趋势判断。品牌、用户信任、服务端数据和持续维护能力，也不会随着一个功能被重写而自动被复制。
更有价值的起点，是选一个你确实想理解的小功能，把输入输出说清楚，找齐证据，并用测试确认新实现。能解释、能验证、能维护，才是功能复刻真正有用的结果。