没有源码,AI 怎么看懂一个软件?拆解 REA 的实现逻辑与能力边界

本文看点

我们已经习惯让 AI 读源码、写代码，但如果手上只有一个安装包、一款桌面应用或者一个编译后的可执行程序，怎么处理？REA 给出了一条路径。REA 的全称是 Reverse Engineer Anything，可以意译为“万物皆可逆向”，它是一个开源工具，同时提供 MCP 和命令行两种接口，让 AI Agent 调用专业逆向工具，去调查软件如何工作。所谓逆向工程，就是从已发布的软件成品出发，反向分析它的结构、实现与行为，落到使用层面，你可以直接向 Agent 提出这样的问题：“这个应用的某项功能是怎么实现的？请找到相关代码，解释其逻辑，并给出证据。”

Agent 可以借助 REA 搜索线索、追踪调用链、检查具体函数，再基于这些发现解释软件的行为，进一步为你的项目编写实现相应功能的代码，这里需要先明确它的定位：REA 把专业分析工具接入 Agent 的调查流程，由 Agent 根据返回结果继续推理和操作，它本身不提供新的基础模型，也不承诺能还原出原始源码。

源码完整、文档清楚的时候，AI 可以直接搜索文件，找到功能入口，再顺着代码分析实现，但现实中，我们拿到的可能只有软件成品：源码没有公开，旧项目的代码已经丢失，或者文档与实际运行的版本对不上。这时，通常情况下，分析人员需要从程序中寻找其他线索，例如界面提示、文件名、网络地址、函数符号和调用关系，再结合汇编、伪代码或运行记录判断它们的含义。

这些工作过去通常需要专业人员持续操作工具，即使引入 AI，也往往是人先取得分析结果，整理后交给模型，再根据模型的建议回去继续检查，问题越复杂，需要衔接的工具和上下文就越多。

REA 尝试减少的正是这部分反复操作、整理信息和传递上下文的工作，它让 Agent 可以直接取得工具结果，并根据新发现决定下一步调查什么，一次调用没有解释清楚的问题，可以继续追踪；前后结果出现矛盾，也可以回到指令、数据或运行记录中寻找原因。

整个流程里有三个主要角色：Agent 负责理解问题、提出假设和安排调查步骤；REA 负责提供接口、管理分析会话，并组织分析结果；Ghidra、Hopper、IDA 等工具则承担反汇编、反编译和函数关系分析等工作。用户最后看到的解释是 Agent 基于这些结果形成的判断。

以“弄清一款应用的搜索功能如何实现”为例，Agent 通常不会从头到尾通读整个程序，而是先找与搜索相关的字符串、符号或候选函数，再查看哪些代码引用了它们；找到可能的位置后，继续追踪输入如何处理、数据从哪里读取、结果经过哪些转换；遇到信息缺口，就进一步检查函数、指令或常量；在支持的环境和场景下，还可以观察程序运行，核对实际行为。

这个路径并不是一条固定执行的流水线：过程中新的发现可能推翻最初的猜测，也可能暴露出信息缺口，Agent 会依据证据不断调整方向；条件允许时还可以实际运行目标程序、观察行为，与静态分析的结论互相印证。

接口层面，REA 提供 MCP 支持，让兼容该协议的 Agent 能够调用 REA 的能力、传递参数并接收结果，同时 REA 也保留命令行接口，人和脚本可以直接调用。

这里重点介绍两类：

第一类是编译后的原生程序，例如用 C、C++、Rust、Go 等语言编译生成的应用，这类程序发布时，源码已经转换为机器码，变量名、注释和部分结构信息可能丢失。分析时，REA 可以连接 Ghidra、Hopper 或 IDA 等专业工具，由这些工具将机器码转换为汇编指令，并尝试生成更便于阅读的伪代码，再把分析结果返回给 Agent。

不过，伪代码是分析工具重建出的表达，可能存在类型识别、参数恢复或控制流分析错误，因此，Agent 还需要结合原始指令、调用该函数的代码和相关数据，判断它实际做了什么。程序中保留的提示语、文件名、网络地址和符号，也可能成为有效的切入点：先找到这些线索，再追查哪些代码引用了它们，这种方式比从头逐行阅读更容易定位到目标功能。

第二类是 JavaScript 与 Electron 应用，发布包中通常包含可以解析的脚本，即使代码经过压缩或混淆，也可能保留可供分析的语法结构。REA 可以据此检查模块关系，以及 Electron 主进程、预加载脚本和页面之间的通信，如果存在可用的 Source Map，还能辅助追溯构建后代码与原始文件的对应关系。

此外，还有与静态分析形成互补的运行时观察分析方法：静态分析检查程序中存在的结构和可能路径，运行时观察记录特定条件下实际发生的行为。

官方展示了一个分析经典打砖块游戏 DX-Ball 的案例：让 Agent 弄清楚，游戏如何根据砖块的位置，计算声音从左边还是右边传来。

调查一开始，反编译结果并没有完整显示这段计算逻辑，然后 Agent 继续查看汇编指令，发现函数接收了一个输入参数，再追踪调用它的代码，确认了这个参数与砖块的水平位置有关；最后读取程序中的常量，逐步还原出位置与声音左右分布之间的计算关系。

REA 提供了指令、调用关系和常量等线索，Agent 据此编写了对应函数，并与原程序进行验证：在 3,205 组测试条件下，两者的返回值一致；使用指定工具链编译，按案例说明处理重定位后，重建函数的全部 63 字节机器码也与原程序一致。（说明：这些检查为该函数的重建提供了具体依据，但验证范围仍然是这个函数，不能据此认为整个游戏已经被完整、自动地复制。）

案例中的每一步，其实都涉及一个问题：哪些已经确认，哪些还需要验证？例如，指令中读取了一个参数，可以直接检查；这个参数代表砖块的水平位置，则需要结合调用者判断；新实现是否与原函数一致，还要通过进一步比较来检验，整个过程中，不同结论依赖的证据并不相同。

REA 把分析过程中的每一次工具调用都记录成结构化证据：目标程序信息、使用的分析工具、操作参数、返回结果，以及结果对应的文件位置或内存地址，同时给每条证据标注性质，区分直接观察到的结果、由已有结果推导出的结论、仍依赖假设的推断，这种设计逻辑让复核者有机会检查结论从哪里来、依赖哪些假设、目前能支持到哪一步。不过证据记录完整，并不保证解释正确，工具可能分析有误，Agent 也可能误读结果，必要时仍需回到原程序验证。

为什么广泛受到关注？

首先，它把一个专业门槛较高的过程，转化成了容易理解的任务：给 Agent 一份软件，问它某项功能如何实现，普通开发者可以从自己关心的问题出发，由 Agent 借助工具逐步追查，这让更多人看到了参与软件分析的可能。

其次，它将“理解已有软件”与“编写新的实现”连接起来。调查过程中得到的发现被进一步用于补充文档、研究兼容方案，或重建某项功能，这条从分析到实现的路径，让逆向工程的价值变得更加具体。

第一，反编译结果不等于原始源码。 编译会丢失信息，优化也会改变结构；理解机器行为，并不意味着找回作者当初的写法。

第二，理解一项功能与重建整个软件之间仍有大量工作。 重建局部功能也不等于复制完整软件，有限测试中的一致，不代表整个应用的异常处理、并发、时序和环境依赖都已还原。REA 的验证规则也明确区分成功、未知、不支持和不完整结果。

第三，拿到客户端不等于看见服务端内部。 Agent 可以分析客户端代码、观察请求，但仅凭这些材料无法恢复服务器上的私有数据、完整业务逻辑或内部算法，实际分析深度也取决于目标类型、工具、平台和 Agent。

第四，本地分析不意味着数据全程留在本机。 REA 的分析工具可以在本地运行，但 Agent 可能把返回结果发送给模型服务，实际的数据流向仍需结合所用模型的数据政策判断。

REA 引发关注，是因为它让人看到：即使没有源码，Agent 也可能借助专业工具，逐步理解软件的部分实现，背后的逻辑是模型提出问题、工具取得线索，再通过证据和验证推进调查，它展示了 AI 参与软件理解与重建的潜力，但不能因此就说“任意软件都能一键复制”，更不能由此推出“软件已死”或企业级软件的护城河已经消失。