最近 GitHub 上有个项目挺有意思，叫 REA。

全称 Reverse Engineer Anything，翻译过来就是“逆向一切”。

名字很狂。

它想做的事情也确实不简单：把一个没有源代码的软件交给 AI，让 AI 帮你分析它的内部结构、追踪关键逻辑，甚至尝试在自己的项目里重新实现类似功能。

以前看到一个软件功能做得不错，我们通常只有两个选择。

要么研究它的公开接口和文档。

要么打开 IDA、Ghidra 之类的逆向工具，一点一点分析。

现在 REA 想提供第三种方式：

直接告诉 AI，你想弄清楚什么，让它自己调用工具去找答案。

这件事如果真的做好了，影响可能不只是逆向工程师。

对于普通程序员、独立开发者，甚至安全研究人员来说，都值得关注。

但我觉得，比“AI 能逆向软件了”更重要的，是另一个变化：

AI 正在从帮我们写代码，走向帮我们理解那些根本没有源代码的程序。

01. 逆向工程最难的，从来不是反编译

如果你接触过逆向工程，应该知道一个很现实的问题。

反编译工具已经很成熟了。

一个 Windows EXE 文件，放进 IDA 或 Ghidra，很多时候都能得到汇编代码和类似 C 语言的伪代码。

问题是，得到伪代码以后呢？

你可能面对几千个函数。

函数名被剥离。

变量名变成 v1、v2、a3。

控制流程复杂得让人头疼。

一个看似简单的功能，可能横跨几十个模块。

你真正想知道的，也许只是：

这个软件为什么能够自动识别文件类型？

某个搜索功能是怎么实现的？

它为什么在特定条件下会崩溃？

一个本地数据文件到底采用什么格式？

可为了回答这些问题，你可能要花上几个小时，甚至几天。

所以，逆向工程最痛苦的地方，往往不是拿不到代码。

而是拿到一大堆难以阅读的代码以后，不知道该从哪里下手。

反编译解决的是“把机器指令变成可分析的内容”，逆向分析要解决的却是“这些内容到底意味着什么”。

REA 想解决的，就是后面这个问题。

02. REA 到底是什么？别把它理解成一个新反编译器

先说结论：

REA 不是要替代 IDA、Ghidra，而是让 AI Agent 能够使用这些专业工具。

这才是它最有意思的地方。

按照项目官方介绍，REA 提供 MCP 服务和命令行工具，可以连接 Claude Code、Codex、Cursor 等 AI 编程环境。

它能够调用不同的分析能力，检查原生二进制程序、JavaScript、Electron 应用、.NET 程序集等目标。

对于原生程序，REA 可以借助 Hopper、Ghidra 或 IDA 获取函数、汇编、伪代码、字符串和引用关系。

对于 JavaScript、Electron 这类应用，它也提供相应的静态分析能力。

换句话说，它并不是把一个 EXE 文件直接扔给大模型，让模型凭空猜里面有什么。

而是建立了一套工作流程：

用户提出问题。

AI Agent 决定需要哪些证据。

REA 调用对应的分析工具。

工具返回函数、调用关系、伪代码等结果。

AI 再根据这些信息继续分析。

如果证据不足，就继续查。

最终给出解释，并尽可能说明判断依据。

这里有一个细节，我觉得特别重要。

REA 强调分析结果要有证据，而不是让 AI 编一个听起来合理的故事。

毕竟，大模型最让人头疼的地方之一，就是有时候会一本正经地胡说八道。

普通编程场景里，代码错了还能运行测试。

但逆向分析面对的是未知程序。

如果 AI 从一开始就理解错了一个关键函数，后面的结论可能全部跑偏。

所以，能不能追溯证据，比回答得是否流畅重要得多。

03. 举个例子：我想知道一个软件的搜索功能怎么做的

假设我正在开发一款本地笔记软件。

看到另一款软件的搜索体验不错。

它不仅能搜索标题，还能搜索正文，而且响应很快。

我很好奇：

它是每次都扫描全部文件？

还是使用了本地索引？

有没有缓存？

搜索结果是怎么排序的？

传统做法是自己观察软件行为，再尝试分析安装包、相关文件和代码。

如果是 Electron 应用，还可以研究它的 JavaScript 结构。

现在借助 REA，我们可以尝试把这个任务交给 Agent。

例如：

“分析这个我有权研究的本地笔记应用，找出搜索功能相关模块。说明它可能采用了什么索引或缓存机制，并给出对应代码位置和证据。”

接下来，Agent 可以借助 REA 检查应用结构，定位搜索相关模块，沿着调用关系继续调查。

如果发现了数据库查询、索引构建或缓存逻辑，就进一步分析。

最后给出一份调查结果。

注意，我说的是“可以尝试”。

不是说 REA 一定能够还原每一个软件的完整实现。

软件可能经过混淆、加壳，部分逻辑也可能运行在远程服务器上。

客户端里根本不存在的服务端代码，再强的反编译器也无法凭空恢复。

但至少，这种工作方式已经和过去不太一样了。

以前我们主要是在工具里自己寻找线索。

现在可以让 AI 帮我们组织调查过程。

真正节省时间的，可能不是反编译速度，而是少走了多少无效的分析路径。

04. 怎么用？REA 已经能接入 Codex 和 Claude Code

REA 的上手方式并不复杂。

根据官方 README，先准备符合要求的 Node.js 环境，再运行：

npx rea-agents setup   

安装程序会引导你选择需要接入的 Agent，并展示计划修改的配置。

确认以后，它会注册对应的 MCP 服务和工作流说明。

完成后重启 Agent。

如果你平时使用 Codex 或 Claude Code，就可以在已有工作环境里尝试调用 REA。

比如先分析一个自己编写的 JavaScript 或 Electron 应用。

REA 也提供独立的命令行分析方式：

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json  

它可以返回应用模块、导入关系和相关分析证据。

如果需要长期使用，还可以全局安装：

npm install --global rea-agentsrea --help

这里有几个需要注意的地方。

首先，REA 本身不等于所有逆向工具的合集。

如果要分析原生二进制文件，可能仍然需要配置 Ghidra、IDA 或 Hopper 等分析引擎。

其次，不同目标的分析能力、平台支持和环境要求并不完全相同。

最后，第一次使用时，最好拿自己编译的测试程序做实验。

比如写一个包含字符串处理、文件读取和简单加密逻辑的小程序。

保留源代码，编译后再让 REA 分析。

这样就能把 AI 的判断与真实实现进行对照。

比直接拿一个复杂商业软件测试，更容易知道它到底有没有分析对。

官方项目地址：

https://github.com/morluto/rea

05. 我更关心的，是它对普通程序员有什么价值

很多人看到“逆向工程”四个字，第一反应可能是破解软件。

但逆向工程的应用远不止这些。

我觉得至少有三个场景值得普通开发者关注。

第一个，是维护没有源码的老系统。

做企业软件开发的人应该遇到过。

一个系统运行了很多年。

原来的开发人员离职了。

文档不完整。

某些组件甚至只有 DLL、JAR 或可执行文件。

业务又不能停。

这时候，你想搞清楚某个组件到底做了什么，往往非常麻烦。

如果能够借助 REA 分析程序结构、函数调用和数据处理逻辑，就有机会缩短理解老系统的时间。

当然，前提是企业拥有相应的软件分析权限。

第二个，是安全审计和故障排查。

有些问题只在特定环境下出现。

源代码不一定完整。

第三方组件也未必提供足够的调试信息。

逆向分析可以帮助研究人员检查程序的实际行为。

比如文件操作、网络调用、异常处理等。

AI 可以帮助筛选值得重点检查的函数，但安全结论仍然需要人工验证。

第三个，是学习优秀的软件设计。

这一点我觉得很有价值。

我们平时学习开源项目，最大的优势就是能看源代码。

但现实世界里，大量优秀软件并不开源。

如果能在合法授权的范围内，研究它们的本地实现方式，就能从另一个角度学习软件工程。

例如分析某个程序的模块划分、数据格式或性能优化思路。

不过要特别强调：

研究一个软件的实现机制，不代表可以直接复制受版权保护的代码、绕过授权机制，或者把别人的商业产品原样搬走。

学习设计思想，与侵犯知识产权，是两回事。

06. REA 真正值得关注的，是 AI Agent 的下一步

最近这一两年，我们已经习惯让 AI 帮忙写代码了。

从代码补全，到生成接口，再到自动修改项目、执行测试。

AI 编程工具越来越像一个能够参与开发流程的助手。

但有个问题一直存在。

AI 对自己能够读取的源代码很擅长。

如果代码根本拿不到呢？

它能不能理解一个现有软件？

能不能根据运行行为推断实现？

能不能把观察到的现象与底层函数关联起来？

REA 的方向，正好补上了这块能力。

它把专业逆向工具接进 Agent 的工作流。

于是，AI 不再只能处理我们主动提供的源代码。

它还可以借助外部工具，从已有程序中收集信息。

这让我想到另一个趋势。

未来的 Coding Agent，可能不只是一个代码生成器。

它会逐渐具备更完整的软件工程工作能力。

能阅读项目。

能运行测试。

能检查日志。

能分析二进制。

能定位问题。

能提出修改方案。

甚至在验证通过后，帮助完成修复。

这里的关键，不是模型突然变得无所不知。

而是它能够使用的工具越来越多，工作流程越来越完整。

大模型负责推理，专业工具负责提供证据，人负责判断结论。

我觉得这才是 REA 最值得关注的技术价值。

07. 但别急着宣布：逆向工程师要失业了

每次出现一个新的 AI 工具，总有人喜欢问：

这个职业是不是要被替代了？

REA 也不例外。

但真正做过逆向的人应该清楚，理解程序远没有看起来那么简单。

反编译结果可能不准确。

优化后的机器代码可能和原始源代码差别很大。

符号缺失会增加理解难度。

混淆、加壳、自修改代码都会干扰分析。

运行时行为还可能依赖特定的环境、输入和外部服务。

AI 能找到一个看起来像目标的函数，不代表它就找对了。

能生成一段解释，不代表解释符合实际行为。

能写出一个相似功能，也不代表在边界条件、性能、安全性上与原程序一致。

这些都需要验证。

更重要的是，逆向工程很多时候并没有标准答案。

你只能不断收集证据，提出假设，再想办法证伪。

这本身就是一种很强的工程能力。

AI 可以帮你减少重复劳动。

但它不能替你承担所有判断责任。

所以我不认为 REA 会让逆向工程师突然失去价值。

相反，真正懂系统、懂底层、懂验证方法的人，可能更容易发挥这种工具的价值。

08. 写在最后：软件的黑盒，正在变得没那么黑

REA 给我的感觉，有点像早期 AI 编程工具刚出现的时候。

一开始，大家觉得它只是个效率工具。

后来发现，它正在改变整个开发流程。

REA 目前还不能被理解成“什么软件都能一键逆向”。

但它提出的方向很值得关注。

过去，逆向工程是高度依赖专业工具和个人经验的工作。

现在，AI Agent 开始参与其中。

它可以帮助我们寻找线索、理解复杂代码、组织证据。

未来，随着分析工具和 Agent 能力继续完善，更多开发者可能有机会接触以前门槛很高的软件分析工作。

这并不意味着逆向工程会变得毫无难度。

而是一些原本需要大量机械操作的环节，可能会逐渐交给 AI。

我一直觉得，AI 编程最有意思的地方，从来不只是让我们少写几行代码。

而是让我们有机会做以前做不了、或者成本太高而不值得做的事情。

REA 也是如此。

以前，AI 帮我们把想法写成代码。

现在，它开始尝试帮我们从已有程序中找回设计思路。

从创造软件，到理解软件。

这条路，可能比单纯的代码生成更值得期待。

最后也想问问大家：

如果有一天，你只需要描述一个软件的功能，AI 就能帮你分析它的实现思路，你最想研究什么？

是某个复杂的桌面软件？

一个没有源码的老系统？

还是那些一直让你很好奇的底层技术？

欢迎在评论区聊聊。