AI都开始逆向软件了,程序员还需要自己看代码吗?

没有源代码，AI能看懂一款软件吗？

以前提到AI逆向，很多人首先想到的是把反编译出来的代码扔给大模型，让它解释这段程序在做什么。

但真正分析一款应用，远不止读懂几段代码：一个功能涉及哪些模块？实际运行时发生了什么？某个结论是工具查到的，还是AI根据线索推测的？当分析结果大到几百MB，又该从哪里查起？

10月11日，GitHub累计获得超过11万星标的开源项目REA（Reverse Engineer Anything）发布6.4.0版本。

这次更新扩展了Android设备检查、JEB反编译工具接入，也改进了大型分析结果的保存和读取方式。其中一个很直观的例子是：项目文档中的一份Obsidian应用分析结果约334MB，而对应的摘要视图只有约10KB。 Agent可以先读摘要，再按需要查具体模块，而不是一次吞下整份材料。

这不是“AI一键还原任意软件”的突破，却提供了一种更值得关注的思路：让AI不只是给答案，还能沿着证据一步步往下查。

01｜AI逆向软件，不能只靠猜

先说清楚REA是什么。

它不是一款新的反编译器，也不是一个能凭空看穿软件的模型。更准确地说，REA是一套把AI Agent与现有分析工具连接起来的工作流程。

开发者提出问题，Agent通过MCP接口调用相应工具；工具返回代码结构、函数信息或运行时观察；REA再将这些结果组织成可追溯的证据，供Agent继续分析。

分析原生程序时，可以接入Ghidra、IDA或Hopper；面对JavaScript、Electron应用以及Android安装包，又有各自对应的分析入口。

举个例子。

假设开发者获准分析一款没有完整源码的Android应用，想查清楚某个功能为什么运行异常。

他需要的不是AI直接回答“可能是网络请求出了问题”，而是进一步确认：应用声明了哪些组件？相关方法做了什么？设备日志里出现过什么异常？代码中的调用关系，是否真能解释运行时的现象？

REA能让Agent围绕这些问题逐步调用不同工具，并把取得的结果保留下来。

但查到调用关系，不等于证明这段代码已经执行；看到权限声明，也不等于证明应用实际使用了该权限。 代码、配置和设备日志是不同层次的证据，仍然需要分别判断。

02｜Android这次多了什么？

REA此前已经能够借助相关工具开展Android APK静态分析。6.4.0的变化，是把设备状态、安装包获取和更多资源分析能力接入同一套工作流。

首先是ADB，也就是Android调试桥。

新版本允许Agent通过明确的接口查询已连接设备、应用信息、进程和日志，获取截图，也可以从设备上提取已安装的APK。

这里有一个容易被忽视的细节：一些Android应用并不是只有一个安装包，而是由基础APK和多个分包组成。REA会记录提取到的整组文件，并为文件生成摘要。如果部分文件没能成功取得，结果也会注明缺失，而不是把不完整的材料当成完整应用。

代码和资源分析则由不同工具承担。例如，JADX侧重类、方法和引用；Apktool可以解码Manifest、字符串及多语言资源。

换句话说，一个入口帮助查看应用写了什么，一个入口帮助观察设备上发生了什么。 两者结合，才有机会进一步解释某项功能。

另一个更新是JEB接入。

JEB是一款已有的专业逆向分析工具。REA现在可以通过使用者自行启动的本地JEB MCP服务，读取项目单元，并请求反编译选定的类型或方法。

需要强调，REA不会自动安装或启动JEB，相关能力也取决于JEB版本、运行模式和许可环境。这是工具协作能力的扩展，不是免费获得一套完整的JEB功能。

此外，6.4.0还扩展了部分Ghidra分析配置能力，并加强了JavaScript应用中对部分tRPC调用、HTTP链接和GraphQL操作的识别。它们没有Android更新直观，但也指向同一件事：让Agent能提出更具体的问题，而不是只得到一大段模糊解释。

03｜334MB结果，为什么只需要先看10KB？

逆向分析还有一个现实困难：工具未必查不出来，而是查出来的东西太多。

一个复杂应用可能包含大量模块、依赖关系、函数和分析记录。即使全部输出都能生成，把几百MB内容直接塞给模型，也不是合理的工作方式。

REA的CLI文档给出了一个例子：针对Obsidian应用，完整的Evidence（证据）结果文件约334MB，而一份摘要视图约10KB。

注意，这不是把334MB的信息无损压缩成10KB，更不是模型已经通过10KB理解了整个应用。

完整结果仍然保留，10KB只是帮助定位信息的“目录”。 Agent可以先查看概况，再读取某一页模块列表、某个模块，或原生分析中的特定函数、伪代码和引用信息。

就像查询一本很厚的工具书，不需要每问一个问题就从第一页读到最后一页。

这种设计还有另一层价值：分析中的事实能够留下来。

REA的Evidence记录会包含分析对象的文件摘要、使用的工具及版本、查询操作、结果和来源位置，也能注明限制和关联证据。

它还会区分三类信息：

• observed（观察所得）：工具直接取得的观察结果；
• derived（计算或处理所得）：在已有材料上进一步处理得到的结果；
• inferred（推断所得）：根据证据作出的判断。

这几个标签并不保证判断绝对正确，但至少能提醒读者：“工具观察到了什么”和“AI认为这意味着什么”，不是同一回事。

例如，静态分析发现两个函数之间存在可能的调用关系，不等于已经观察到该关系在真实运行中发生。无法解析的动态调用，也不能直接解释为“没有这项行为”。

另外，6.4.0为JavaScript源码分析加入独立进程及内存、超时限制。分析因资源不足而中断时，已完成的静态事实有机会被保留，未完成的部分则明确标注。

这意味着任务不必总是从零开始，也减少了Agent把“没查完”误写成“已经确认”的风险。当然，独立进程不等于完整安全沙箱，仍应根据实际调用方式判断风险。

04｜AI真的能看懂任意软件了吗？

REA项目方确实提供了真实工具链的验证记录。例如，JEB相关测试覆盖了特定版本的Java样本、Signal APK和Flutter Gallery APK；ADB功能也在Android 14模拟器环境中进行过验证。

这些测试至少说明，部分能力不只停留在接口设计或演示文字上，而是曾经通过真实工具和样本检验。

但验证某些方法可以反编译，不等于整款应用都能被完整理解；特定样本能够顺利分析，也不能推导出所有Android软件的逆向成功率。

有些目标会受到混淆、加固、动态加载或分析工具支持范围的影响。静态结果与真实运行行为之间，也可能存在很大的信息缺口。

还有实际使用成本。

REA本身采用MIT开源许可，但不同任务仍可能依赖ADB、JADX、Ghidra、IDA、JEB等工具和运行环境。某些工具需要单独安装或授权，Agent调用模型也可能产生额外费用。

因此，REA现阶段更合适的定位，是服务于获授权的软件维护、兼容性排查、应用研究与分析复核，而不是“输入一个App，就能自动复制它的一切”。

不过，6.4.0值得关注的地方，可能恰恰不在于它又接上了几款工具。

过去，我们常用“AI能不能写出答案”来衡量一个Agent。可当工作对象变成庞大的软件系统，一个更重要的问题出现了：它能不能说清答案来自哪里，哪些地方真的查过，哪些地方还不知道？

REA这次更新的方向，是把这些问题落实到工具调用、证据留存和按需读取上。

AI未必因此立刻变成更准确的逆向专家，但如果它能把“观察、推断、未知”分开，再把分析过程留给人复查，那它提供的就不只是一段看起来合理的解释。