没有源代码,AI 也能读懂一个 App 怎么实现的?

你有没有遇到过这样的时刻：

用一个桌面软件时，发现它的复制粘贴体验特别好，想知道背后怎么实现；维护一个老程序时，手里只有安装包，找不到完整源码；排查 Electron 应用时，知道某个按钮有问题，却不知道它最终调用了哪段代码。

这类问题，往往要靠分析文件、追踪调用、阅读反编译结果，再反复验证。

REA 想做的，就是让你的 AI 编程助手也能用上这套工具，参与调查。

它的全名是 Reverse Engineer Anything。项目提供 MCP 服务和命令行工具，把本地分析能力接到 Claude Code、Codex、Cursor 等支持相应接入方式的编程助手上。

你提出具体问题，AI 调用 REA 找线索，再根据返回的代码、位置和限制继续追查。整个过程的重点，是让结论有东西可以核对。

REA 到底能帮你做什么？

先把"逆向工程"换成一句容易理解的话：

从已经存在的软件或文件出发，弄清它是怎样工作的。

比如你想知道："这个桌面应用，为什么能把一段内容同时复制成纯文本和富文本？"

要回答它，可能需要找到页面上的调用入口，查看预加载脚本如何传递参数，再追到主进程写入系统剪贴板的地方。

REA 能帮助 AI 获取这些分析结果。遇到原生二进制文件时，它还能通过适配的分析引擎，返回伪代码、汇编、字符串、符号、调用和引用。

对程序员来说，这意味着三种很具体的用途：

• 研究功能实现。 从你有权分析的应用中，追查搜索、导出、剪贴板等功能的实现路径。
• 理解遗留软件。 在源码不完整的情况下，从文件、函数和运行观察中寻找依据，辅助维护或迁移。
• 辅助定位问题。 从某条字符串、某个模块或 IPC 通道出发，缩小调查范围，再用测试检查判断。

这里的 IPC，可以理解成应用内部不同进程之间传递消息的通道。

它覆盖的目标还包括 .NET 程序集、Android APK、网站、网络捕获、固件等。不过，支持哪类目标，不等于装完就能分析所有目标。 不同任务需要不同工具和主机环境，应该按自己的需求查看对应指南。

它怎么和 AI 打配合？

可以把这套配合理解成三个角色。

AI 编程助手负责调查思路。 它理解你的问题，决定下一步查看什么，并解释分析结果。

REA 负责连接工具、返回结果。 它通过 MCP 给助手提供调用入口，也允许你在终端直接使用同一类能力。

分析引擎负责具体分析。 深入分析原生程序时，需要 Hopper、Ghidra 或 IDA 等适配的引擎；静态 JavaScript 和 .NET 检查则不需要这些原生分析引擎。

一次有用的调查，通常会从一个很小的问题开始。

例如："导出 CSV 时，文件名是在哪里生成的？"

助手先定位相关模块，读取调用和参数；线索不足就继续查询。拿到证据后，再解释实现，或者为你的项目编写一个类似功能，并补上测试。

项目同时提供 Skill 工作流指引，帮助助手按合适的方法调查。只安装 Skill，得到的是调查指引；要让助手实际调用工具，还需要注册 REA 的 MCP 服务。官方推荐的 setup 会一起处理这些配置。

看个真实案例：追到 Notion 的剪贴板代码

官方公开的一个案例，是分析 Notion Desktop 7.6.1 的剪贴板桥接代码。

问题很直观：页面调用复制操作后，文本和 HTML 是怎样进入系统剪贴板的？

案例先用 REA 定位预加载脚本中暴露给页面的 API，以及发送 IPC 请求的调用位置。随后，助手读取相关包装函数，找到 notion:clipboard:write 通道，再追到主进程里的接收处理和 Electron 剪贴板写入操作。

这对 Electron 开发者很有参考价值：

你能看到一个页面方法，怎样跨过进程边界，最终完成系统级操作；也能看到通道名、调用位置和包装函数，怎样帮助调查继续向前。

代码里找到了一条关系，只是调查的一步。 这份案例也明确交代了分析使用的应用版本、文件和测试范围。读者可以据此判断，哪些结论有依据，哪些还需要在自己的环境里验证。

再看一个：一个函数，怎么证明还原对了？

DX-Ball 是一款老 Windows 游戏。官方案例展示了如何利用 REA 返回的指令、调用方和常量，重建其中一个"声音左右位置"的计算函数。

这里有个很值得程序员注意的细节：最初的伪代码并没有完整体现输入和浮点运算。助手继续检查汇编、追踪调用方、读取常量，才得到可以实现的计算过程。

重建之后，还做了两项验证：

• 3,205 个行为测试用例。 对比原始 x86 函数和重建 C 函数的返回值，覆盖 0 到 640 的整数位置，以及五个声像缩放系数。
• 63 字节完全匹配。 使用案例指定的 VC4.0 工具链，并按文档处理重定位、核对常量后，编译结果与该原始函数的全部字节一致。

这些数字证明的是这个函数在案例所述条件下的验证结果，不能外推成 REA 对任意软件的还原成功率。

这个案例真正值得学的，是调查习惯：伪代码出现缺口，就去查指令和调用；实现写出来之后，还要拿原始行为做比较。

第一次用，建议从 JavaScript／Electron 起步

如果你是前端或全栈开发者，可以先用自己开发的示例应用，熟悉它返回的结果。静态 JavaScript 分析不需要先配置 Hopper、Ghidra 或 IDA，准备工作相对少。

先检查 Node.js 版本

在终端运行：

node -vnpm -v

本文核对到的 npm 发布版为 6.7.0。其 Node.js 要求为：22.x 中不低于 22.19、24.x 中不低于 24.11，或 26 及以上版本。它不是简单的"Node 22 以上都能用"，安装前应按官方要求检查。

把 REA 接到编程助手

运行：

npx rea-agents@latest setup

在交互界面中选择要接入的助手，检查计划修改的配置和 Skill 目录，再确认安装计划。完成后，按提示重启相应助手。

如果你先做 JavaScript 静态分析，可以暂时跳过原生分析引擎的配置。官方安装流程会展示变更计划，并为已有配置建立备份。

只挑一个小问题

准备自己有权分析的 JavaScript／Electron 应用目录或 ASAR 文件，再给助手这样的任务：

请使用 REA 分析 D:/demo/my-electron-app。我只想弄清"导出 CSV"功能的实现。先定位相关模块，追踪页面入口、预加载脚本和 IPC 通道，直到实际生成文件的位置。每个结论请给出文件位置或工具证据，并区分静态推断、已经观察到的行为和仍不确定的部分。本轮先完成分析。

如果目标不是 Electron，就把问题里的"预加载脚本和 IPC"换成对应的路由、模块或 API。问题越具体，越容易判断分析有没有帮助。

也可以先在终端跑一次分析

官方提供了这个入口：

npx -y rea-agents@latest analyze-javascript-application "D:/demo/my-electron-app" --json

把路径替换成真实的应用目录，或对应的 ASAR 文件路径。结果包含模块、导入、Electron 边界及相关证据。

阅读结果时，先关注目标是否识别正确、相关模块在哪里、有哪些未知项。静态分析得到的关系，需要结合实际调用和运行测试判断。

理解之后，再让 AI 实现

确认实现路径后，可以继续提要求：

根据刚才已确认的实现思路，为我的项目设计一个独立的 CSV 导出功能。先列出接口、数据流和测试用例，再编写实现，并说明还有哪些行为需要验证。

这样，一次调查就和自己的开发任务接上了：先弄懂机制，再设计接口，最后通过测试验证实现。

用之前，记住三个边界

第一，反编译结果可能有缺口。

原生分析通常返回伪代码和汇编。原来的变量名、注释、工程结构，未必能恢复。优化、混淆和动态行为也会增加分析难度。DX-Ball 案例本身就展示了继续查证的必要性。

第二，本地分析仍要关注工具结果如何被使用。

REA 在本机分析目标，编程助手会接收工具结果。如果助手连接云端模型，应结合模型提供商的数据政策，判断哪些文件和结果适合交给它。

第三，运行观察和静态检查的影响不同。

静态 JavaScript 和 .NET 检查读取文件，不运行目标应用；运行时捕获则可能以你的用户权限运行目标或与之交互。第一次使用，先选择可控的示例项目，并查看相应指南。商业分析工具的许可证也需要单独准备。

最后聊两句

REA 对程序员最有价值的地方，是把"我想弄清这个功能"变成一项能够逐步查证的任务。

你依然要提出好问题，判断证据是否充分，并用测试检查结果。AI 和 REA 则能帮助你定位入口、追踪关系、读取分析结果，减少在工具之间来回查找的工作。

第一次尝试，选一个足够小、能验证的问题就很好：

"这个导出按钮按下去之后，到底发生了什么？"

今天的 AI 分享就到这里。

如果你也想把 AI 用得更顺手，欢迎关注「AI学习指北」。

这里没有玄学，只有能落地的方法、工具和案例。有想了解的 AI 话题，也欢迎在评论区告诉我，说不定下篇就安排。

点个关注，不错过下一次更新。👋👋👋👋👋