没有源码,AI也能看懂软件?我拆解了爆火的 REA,发现最厉害的不是反编译

一款 1996 年的老游戏，只剩 EXE ，没有原始源码。你想弄清：砖块在屏幕左边或右边被击中时，声音为什么会跟着偏向不同声道？

反编译器给出了一段伪代码，却没显示关键计算。接下来， AI 应该相信它，还是继续追查？

REA 的官方 DX-Ball 案例，恰好展示了这次调查。它吸引我的地方，是从一个不完整的结果出发，怎样找到依据，再让恢复的实现接受检验。DX-Ball 官方案例^[1]

REA ，全称 Reverse Engineer Anything 。

图 1 ｜ REA 项目主页截图，展示项目定位与入口。画面信息以截图时点为准。

截至 2026 年 10 月 14 日核对时， GitHub 页面已显示超过 20 万 Star 。热度足够高，但要判断价值，还得回答：它究竟给现有逆向工具增加了什么？项目页面^[2]

图 2 ｜ morluto/rea 的 Star History 趋势图。 Star 反映关注度，不等同于实际采用或技术效果。

本文基于项目源码、文档与官方案例展开分析；文中的第三方软件案例未由我独立复现。

01 ｜先看分工： REA 接上了哪一环？

研究一个没有原始工程源码的软件，仍然需要从产物里寻找信息。原生程序有指令、字符串和调用关系； Electron 应用还可能保留打包后的 JavaScript 。不同目标，能取得的材料不同。

REA 将这些分析能力通过 CLI 和 MCP 接口交给 Agent 使用。原生分析可以调用 Hopper 、 Ghidra 、 IDA 等引擎， JavaScript 、 Electron 、.NET 等目标则有相应路径，具体覆盖依赖格式与环境。官方概览^[3]

这里有三种职责：

开发者仍要判断调查是否答对问题、验证是否充分。把工具交给模型，并不会自动完成这些判断。

传统逆向工程本来就会围绕具体问题寻找证据。 REA 值得关注的变化，是把这套工作中的操作和结果组织成 Agent 可以连续调用的流程。工具设计^[4]

图 3 ｜ REA 调查流程示意：提问、检查与追踪、读取证据，再由 Agent 解释、实现和测试，并根据结果继续追问。

它让 AI 有机会从“解释给定材料”，走向“围绕问题主动取得材料”。 两个案例，可以看清这一步的实际含义。

02 ｜两个案例：一个追路径，一个查缺口

Notion ：复制按钮背后的进程边界

Notion 怎样把文字和 HTML 写入系统剪贴板？只找到页面上的 clipboard.write()，还不足以回答。

官方调查先通过 REA 定位预加载脚本中的 API 和 IPC 调用位置。 Agent 再阅读包装函数，找到 notion:clipboard:write 通道，继续寻找主进程中的接收方。

由此连接起一条路径：页面 API → preload 包装层 → IPC 消息 → 主进程处理器 → 系统剪贴板。 主进程检查请求来源后，再调用 Electron 的剪贴板接口。Notion 官方案例^[5]

这份材料的价值，是把“界面上发生了什么”和“哪个进程实际处理”连起来。对于开发者，找到进程边界，才能继续分析数据怎样传递、权限在哪里检查。

也要看清分工： REA 定位线索， Agent 还要读取包装实现，才能连接发送端和接收端。案例的桌面调用链来自 Notion Desktop 7.6.1 ，定位结果由 REA 4.1.0 记录，不能直接推成其他版本的完整运行事实。

图 4 ｜依据官方特定版本案例整理的调用路径，非本次运行记录。

DX-Ball ：伪代码缺了逻辑，怎么办？

老游戏里的声像函数，第一次返回的伪代码几乎只剩 __ftol() 转换调用。它看起来像一个完整函数，却解释不了位置怎样变成声道偏移。

继续查看指令、调用者和常量后，线索才完整起来：输入是横坐标，计算使用了 1.5625、500.0 和一个缩放系数。

核心算术可简写为：(x × 1.5625 − 500.0) × pan_scale，最后转换为整数。缩放系数为 1 时，x 取 0 、 320 、 640 ，分别对应 −500 、 0 、 500 。

重建项目随后做了两类检查：3,205 组输入输出与原始 x86 函数对照；使用固定 VC4.0 工具链，并处理审查过的重定位后，核验完整 63 字节函数匹配。计算与验证记录^[6]

REA 提供分析材料，重建项目另行实现并验证。这些结果适用于 DX-Ball 1.07 中的特定函数，不代表整款游戏已恢复。

图 5 ｜ REA 提供线索，重建项目另行实现与验证；数字仅适用于案例中的单个函数。

两个案例放在一起，说明了同一件事：调查需要能连接线索，也需要能发现材料的缺口。拿到一段伪代码，只完成了取得材料这一步。

在阅读这类演示时，我会把成果分成三层：定位，找到相关位置；解释，说清数据、分支与调用怎样构成功能；验证，检查恢复的实现是否符合目标行为。

Notion 案例重点连接功能路径， DX-Ball 案例则对一个函数继续做了行为和编译结果对照。分清这三层，才不会把“找到相关代码”直接理解成“已经完整还原功能”。

03 ｜已有 Ghidra MCP ， REA 的增量在哪里？

这个问题，比“AI 能不能逆向一切”更值得讨论。

GhidraMCP 、 IDA Pro MCP 已经能把专业引擎连接到模型。对已有成熟单一引擎工作流的用户，换成 REA 未必带来决定性收益。GhidraMCP^[7]、IDA Pro MCP^[8]

我更愿意从两个方面评价 REA 。

一是调查能否跨过工具与材料的边界。 一个功能可能同时涉及脚本、 IPC 和原生模块。共同的操作方式，能让 Agent 在不同材料之间延续问题；但统一接口不等于不同平台、引擎拥有同样能力。

这里也有一个设计上的取舍：共同接口越强调统一，就越需要保留底层差异。某个引擎没覆盖的操作、某次静态分析无法确认的关系，都应在结果里显露出来。否则，接口看起来更容易用，调查者却更难判断回答的有效范围。

二是结果能否留下可继续检查的依据。 REA 的 Evidence 记录包含目标摘要、分析提供者、操作参数、结果位置及限制。这使“分析了哪份文件、用了什么操作、结论指向哪里”有机会被追溯，而不只留下最后一段解释。Evidence 实现^[9]

这种设计直接回应了 Agent 调查的一个难点：模型擅长组织语言，却可能把局部线索写成完整故事。保留依据，至少能让后续检查有地方落脚。

不过，可追溯并不等于正确。 底层工具可能分析有误，模型也可能误解含义。 JavaScript 关系图因此保留观察、推断和未知等区别：静态代码里的关联，不能直接写成已经发生的运行行为。关系图说明^[10]

图 6 ｜三类阅读判断示意，不代表 REA 全部字段或状态；静态关联不能直接当作运行事实。

所以， REA 的项目价值应在具体调查里检验：是否更容易取得相关材料？能否追问缺口？结果是否方便复核？这些问题，比接口数量更接近实际使用收益。本文没有做同类工具的横向效率或准确率测试。结果契约^[11]

这也解释了为什么“再包装一层”未必没有价值，但价值必须具体。对需要跨层追踪和保留依据的任务，组织方式可能有用；对已经熟悉单一引擎、目标又很明确的工程师，新增流程是否划算，需要结合配置、阅读和核验成本判断。

04 ｜“没有源码”，仍然有信息边界

项目名里的 Anything ，是一个很大的覆盖目标。实际分析首先取决于产物中还剩多少信息：编译优化可能改变结构，混淆和运行时解密会增加调查难度；客户端没有包含的服务端实现，也无法靠读取客户端直接取回。

“理解实现”与“拿回作者原来的源码”也应分开。就算一个重建函数通过对照，原始命名、注释和工程组织仍可能没有恢复。 DX-Ball 的字节核验很有说服力，但它证明的是该函数在注明条件下的匹配，不能替其他函数或整个产品作保证。

环境和版本同样影响结果。当前固定提交的文档中， Windows Ghidra 路径仍是实验性只读 P0 ；仓库 main 、 npm 发布包和运行中的 MCP 服务，也可能对应不同代码。看见官网演示，需要再核对自己的目标和配置。Windows 支持说明^[12]、版本说明^[13]

数据流和使用权限则要分别判断。 REA 在本地分析，工具结果会交给 Agent ，其模型服务有自己的数据政策；获得分析输出，也不自动获得第三方代码和资源的使用权。隐私说明^[14]、使用声明^[15]

这些边界决定了，一次成功演示能支持多大范围的结论。

05 ｜我更看重的，是调查怎样变得可核查

REA 没有证明 AI 已能理解任何软件。它展示了一种值得观察的组合：专业工具提供材料， Agent 组织追问，开发者用证据和测试检查解释。

这对软件开发的启发很具体。面对一个现有功能，我们除了提出“帮我做一个类似的”，还可以继续问：关键路径在哪里？这个判断依据哪段实现？哪些条件没有确认？

如果这些问题更容易进入开发流程，部分技术学习和行为对照就可能更容易开展。收益有多大，仍取决于调查目标、材料质量和验证成本。

我也会关心调查何时停下来。 Agent 能不断发起查询，不代表每一次查询都有价值。先明确要回答哪一个问题、什么证据足以支持它，才能判断后续调用是在补齐关键缺口，还是只让报告变得更长。这部分工作仍需要人的判断。

因此，我会用一个小而明确的任务评价 REA ：查清一条导出路径，解释一个异常分支，或核对一个版本变化。能把一处行为说清，并让别人沿着依据检查，才有理由扩大使用范围。

AI 给出解释的能力已经很常见。 REA 更值得讨论的，是让解释之前的调查、解释之后的检验，也进入工具流程。

对于开发者，值得保留的习惯也很直接：让 AI 继续找线索，同时追问它的结论来自哪里。

资料核对： 2026 年 10 月 14 日。技术解读参考 main 提交 bbf0638e 与官方案例；案例适用其注明的版本和验证范围。 Star 表示关注度，不代表使用人数或能力证明。文中价值判断为分析意见，未进行第三方软件独立复现或同类工具对照实测。

参考链接

[1] DX-Ball 官方案例: https://rea.tools/showcase/dx-ball/

[2] 项目页面: https://github.com/morluto/rea

[3] 官方概览: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/README.md

[4] 工具设计: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/docs/tool-design.md

[5] Notion 官方案例: https://rea.tools/showcase/notion/

[6] 计算与验证记录: https://rea.tools/showcase/dx-ball/#checking-the-recovered-function

[7] GhidraMCP: https://github.com/LaurieWired/GhidraMCP

[8] IDA Pro MCP: https://github.com/mrexodia/ida-pro-mcp

[9] Evidence 实现: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/src/domain/evidence.ts

[10] 关系图说明: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/docs/javascript-application-graph.md

[11] 结果契约: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/docs/mcp-contracts.md

[12] Windows 支持说明: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/docs/windows-ghidra-p0.md

[13] 版本说明: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/docs/installation.md#released-package-and-main

[14] 隐私说明: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/README.md#faq

[15] 使用声明: 

https://github.com/morluto/rea/blob/bbf0638e884d29cac21cb1f51fa0d41dce36d3a1/DISCLAIMER.md

强瑞技术博士工作站致力于工业大模型研发和工程应用，欢迎进群交流！