ARTICLE · 1209169
REA:把逆向工具交给 AI,软件还能藏住多少秘密?
看到一款软件里有个好用的功能，想知道它怎么实现，手里却只有安装包。AI 能不能研究这个成品，再为自己的项目写出类似功能？REA 有一个公开案例。
在打砖块游戏 DX-Ball 中，砖块的位置决定声音偏向左边还是右边。项目借助 REA 找出这段计算，并写成 C 函数。根据公开记录，这个函数通过了 3,205 组原始 x86 代码对照，重新编译后的 63 个字节全部匹配。
第一次反编译并没有直接给出答案。最初的伪代码几乎只显示了一次数值转换。继续读汇编、追查调用者、读取常量，才查清输入和运算过程。匹配范围仅限于这个函数，整个游戏的可玩重建仍在继续。DX-Ball 案例[1]
这个案例展示了 REA 的工作方式：找到实现依据，再写代码、做对照。
REA 把哪些工作交给了 AI
REA 全称 Reverse Engineer Anything，通过 MCP 和命令行接口，让编程智能体调用软件分析工具。MCP 是让 AI 调用外部工具的一套接口规范。
智能体提出问题，REA 返回分析结果和证据，智能体再据此追问、解释或编写实现。深入分析原生程序时，可以调用 Ghidra、Hopper、IDA 等已有工具；分析 JavaScript、Electron 等目标，则采用不同的流程。官方仓库[2]
AI 由此能获得截图之外的线索。界面能告诉它按钮长什么样，程序里的调用关系和指令则可能解释：按钮触发了什么，输入经过哪些处理，结果为什么变化。
不过，工具返回的伪代码和调用关系仍需核对。原作者的注释、设计意图和完整工程，也不会因此自动恢复。
先确认分析对象，再准备环境
先确认手里的文件属于哪类软件，再准备工具。不同类型的软件，所需工具差别很大。
Hopper 分析界面，可见汇编指令、程序信息与分析日志。图片来自 REA 官方仓库，非本次实测截图。
具体能分析什么，还取决于操作系统、文件格式和分析后端，不能只看文件扩展名。目标类型与要求[3]
REA 需要 Node.js 和 npm。官方支持 Node.js 22.x（至少22.19）、24.x（至少24.11）或26及以上版本。Linux 上的部分流程还需要兼容 procps 的 ps 命令，具体按安装文档准备。
装好 REA 后，还需要检查分析所需的后端是否就绪。Hopper、IDA 等商业工具有独立许可，REA 不提供它们的授权。环境与后端配置[4]
安装后，还要把助手接通
在终端运行：
npx rea-agents@latest setup按引导选择要接入的智能体，例如 Claude Code、Codex 或 Cursor，再检查程序展示的配置路径和变更。确认后，setup 会注册 MCP 服务，添加配套工作流指令。完成后，按提示重启对应助手。
技能文件和 MCP 服务各有作用：前者告诉助手怎样组织调查，后者让它实际调用分析工具。只装技能，工具并不会自动接通。
如果助手重启后仍然看不到 REA，可以先检查配置和前置条件：
npx rea-agents@latest doctor --jsondoctor 只做诊断，不会替你完成全部修复。如果某个可选后端未配置，整体检查结果也可能显示失败，因此要看具体是哪一项。配置检查通过，也不代表当前聊天已经连上工具，仍可能需要重新连接助手。安装与诊断说明[4]
第一轮提问，交代清楚四件事
只说“把这个应用复刻出来”，很难判断任务到底完成了多少。目标越大，越容易把界面相似、行为接近和实现正确混在一起。
提问时，把四件事说清楚：目标在哪里、研究哪项功能、需要哪些证据、最终交付什么。
准备好自己有权分析的应用目录后，可以这样问助手：
用 REA 分析
/绝对路径/应用目录中的搜索功能。第一轮先定位入口、关键模块和调用链，列出对应代码位置，并把已确认结论、推断和未知项分开。输出一份功能说明，列出还需要验证的问题。
示例路径要换成真实位置。这份模板先限定调查范围，让助手把功能查清楚。
拿到功能说明后，再追问：
根据已确认的规则，为我的项目编写独立实现。列出输入输出、异常情况和测试方法；对尚未确认的行为，说明采用了什么假设，以及怎样补充验证。
分两轮提问，可以先检查 AI 是否理解了原功能，再检查它写出的代码。否则，误读可能直接带入实现，最后得到的只是一个看起来能运行的演示。
也可以先用命令行检查应用
暂时不接入智能体，也可以用官方提供的命令，直接分析 JavaScript、Electron 应用：
npx -y rea-agents@latest analyze-javascript-application "/absolute/path/to/app" --json把示例路径换成提取后的应用目录或 ASAR 文件；路径有空格时，保留引号。命令会输出应用关系和证据记录，重建代码仍需另行编写和验证。
真实应用的完整分析结果可能很大。官方 CLI 文档建议先保存证据，再读取摘要、分页查看模块或查看单个模块。让助手先找出相关部分，比一次把全部结果放进对话更方便核对。命令行与证据指南[5]
拿到报告，重点看哪些内容
看报告时，重点检查三件事。
结论从哪里来。 是读到了某个方法、追到了实际调用，还是根据名称和上下文推断？报告里写着“没有找到”，也要看分析覆盖了哪些部分，不能直接认定功能不存在。
实现到了哪一层。 恢复计算公式、追通调用链、写出可运行模块，分别代表不同的进展。DX-Ball 的函数对照有价值，但它验证的是对应计算，不能据此认定整款游戏都已正确。
测试检查了什么。 正常输入、空输入、边界值和异常情况分别怎样处理？涉及多个模块时，还要检查它们一起运行的行为。证据记录应保留观察到的事实、推断和未解决的问题。证据说明[6]
功能可以重写，产品仍需要整合
软件内部的实现更容易被理解后，单靠“别人不知道这段功能怎么写”形成的优势，可能会减弱。但还原局部功能之后，还要处理功能之间的关联、异常情况、版本兼容和维护，才能交付长期可用的产品。
如果应用依赖服务器，仅凭本地客户端，也无法了解服务端实现、运营数据和用户关系的全貌。
还要留意分析数据的去向。REA 在本地分析目标，但返回智能体的结果仍受其模型服务商的数据政策约束。静态检查读取文件，运行时捕获则会执行目标程序或与之交互，选择时需要了解具体操作。官方问答与目标说明[7]
REA 将软件调查与代码生成连在一起，让开发者有机会从软件成品中找出规则，再据此编写新实现。理解已有功能的门槛有望降低；这些代码能否成为可靠的产品，仍取决于后续的整合、验证和维护。
引用链接
[1] DX-Ball 案例: https://rea.tools/showcase/dx-ball/[2] 官方仓库: https://github.com/morluto/rea[3] 目标类型与要求: https://github.com/morluto/rea#what-you-can-analyze[4] 环境与后端配置: https://github.com/morluto/rea/blob/main/docs/installation.md[5] 命令行与证据指南: https://github.com/morluto/rea/blob/main/docs/cli.md[6] 证据说明: https://github.com/morluto/rea/blob/main/docs/cli.md#import-export-and-compare-evidence[7] 官方问答与目标说明: https://github.com/morluto/rea#faq
