REA 可以让 AI 调用逆向分析工具帮助开发者在没有原始源码的情况下检查软件并追踪某个功能的实现。它的价值在于把“这段解释听起来合理”推进到“这段解释对应哪些代码和观察”。假设你正在研究一个桌面笔记应用。输入关键词点击搜索界面马上显示结果。你想知道它在哪里执行搜索页面自己处理还是交给应用的其他部分相关代码究竟在哪个文件这几个问题比“把整个软件还原出来”更具体也更容易检查答案。下面就沿着搜索这个例子讲清 REA 能做什么、为什么能做到以及第一次应该怎样使用。REA 如何帮助 AI 查软件而不只是猜实现REA全称 Reverse Engineer Anything是连接 AI 助手与逆向分析工具的一层软件。逆向分析就是从已有程序、文件或运行行为中反过来理解它怎样工作。通常写程序时我们从源码出发得到能运行的软件。逆向时手里可能只有安装包、应用文件或可执行程序需要沿着留下的线索找回实现逻辑。这类调查以前经常需要手动串联找文件、搜字符串、查看函数、追调用关系再把材料复制给模型解释。困难既在于读代码也在于连续追问之后是否还记得每条判断来自哪里。REA 把一部分操作变成 AI 可调用的工具。AI 可以检查目标、读取结果再针对具体线索继续追问。这里的 AI 助手指能够调用工具、运行命令的 Claude Code、Codex 等编程助手它与只接受文字问答的聊天界面有不同的操作能力。双方通过 MCP 连接。可以把 MCP 理解为一套“助手怎样发现并调用外部工具”的通用通信规则助手发出请求REA 执行相应分析再把结果交回来。模型负责提出问题和解释分析工具负责提供材料。工具返回了什么才决定解释能说到哪一步。这也是阅读 REA 结果时最应该记住的分工。REA 官方项目[1]同时提供终端命令方便直接保存和处理分析结果。先看懂搜索请求经过哪里在本文的验证样例里搜索请求从页面出发经过桥接脚本交给主进程处理。理解这三个角色就能读懂后面的分析。样例使用 Electron。它是一种用 JavaScript、HTML 等网页技术构建桌面应用的框架。应用虽然看起来像网页却可以拥有桌面软件的窗口、文件访问等能力。Electron 中显示页面的部分通常称为渲染进程负责输入框、按钮和结果展示。管理应用生命周期、窗口以及处理本例搜索请求的部分是主进程。两者运行在不同进程里需要通过消息交换信息这种方式叫 IPC也就是进程间通信。页面与应用能力之间还常有一个preload 脚本。preload 可以理解为“页面加载之前准备好的桥接脚本”它向页面提供受控的方法例如search避免页面直接获得全部系统能力。这个机制能建立访问边界但具体暴露什么方法、怎样验证请求仍由开发者决定。于是本例的预期调用关系是图根据样例代码简化绘制说明预期调用关系不代表已经记录了一次真实点击。桥接脚本中有这样一句发送请求的代码// 把关键词交给 notes:search 通道的处理端ipcRenderer.invoke(notes:search, query);其中query是关键词notes:search是消息通道的名称。这里的“通道”可以理解成请求要交给哪个处理端的标识。主进程中对应的代码是// 收到搜索请求后筛选笔记并返回结果ipcMain.handle(notes:search, (_event, query) { const notes [MCP evidence, Electron IPC, Static analysis]; return notes.filter(note note.toLowerCase().includes(String(query).toLowerCase()) );});这段代码声明了处理端把关键词和笔记都转成小写再筛选包含该关键词的笔记。读到这里调查就从“它大概有搜索功能”缩小到了“这段函数声明了怎样筛选笔记”。对于实际发布的 Electron 应用这些文件可能装在app.asar里。ASAR 是文件归档格式可以把它理解为装着应用代码和资源的文件容器。它通常不压缩Electron 可以直接访问其中的文件。打包并不等于加密里面也不一定保留开发者最初的文件组织和可读名称。因此REA 分析 Electron 应用时可以从本地应用目录或 ASAR 文件入手寻找入口、脚本和消息关系。以上进程分工与归档方式可在 Electron 官方文档[2]及 ASAR 说明[3]中核对。第一性原理为什么能沿着这些线索找到实现这条方法有效是因为程序要完成一个功能相关部分必须以某种方式连接起来。代码、消息名称、引用关系和运行记录会暴露其中一些连接。要理解这个原理需要先明确调查的输入和输出。输入是某个版本的应用文件以及“搜索请求由谁处理”这个问题输出应当是相关代码位置、它们之间的关系、支持该判断的依据以及尚未确认的部分。从文字匹配走到程序结构最直接的方法是全文搜索notes:search。它能找出包含这段文字的文件但其中可能有实际调用也可能只是注释、日志或测试数据。更进一步的分析会检查代码结构这里调用的是发送消息的方法那里调用的是注册处理函数的方法两边使用同一个固定通道名称处理端在所分析的范围内能否唯一确定这些条件比“两个文件出现了同一个词”更有约束力。REA 的静态 JavaScript 分析会解析文件并组织入口、调用和通道等关系。静态分析就是不运行程序先检查它的代码与文件结构。它适合用来定位下一步应该检查哪里。官方分析文档[4]说明了这条路径及其限制。软件的这些实体与关系可以组成一张图。这里的“图”不是界面截图而是一种记录连接的结构某个脚本加载了另一个文件某个发送端关联到一个处理端。沿着已记录的连接继续追踪就能把散落在多个文件里的线索放到同一个问题下理解。找到代码关系为什么还不能证明真实执行代码里存在一条路径不代表每次操作都会走它。运行状态、输入、注册时机和分支条件都可能改变结果。例如本例代码声明了搜索处理函数。要证明某次点击确实调用它还要在指定输入下运行应用观察请求与返回值。这叫运行时观察也就是检查程序实际运行时发生了什么。可以把这两种证据分别记住• 静态分析回答“代码中有哪些线索哪些部分可能相连”• 运行时观察回答“在这次输入和状态下实际发生了什么”它们不能相互替代。静态分析能够检查尚未触发的路径但遇到动态表达式可能无法确定结果一次运行观察能确认一个场景却不能穷尽所有输入。这是分析方法本身的取舍不会因为加入 AI 就消失。为什么每条结论都要带来源当调查跨越多个文件或多个版本时容易发生的错误是把不同条件下的材料拼到一起新版本的函数配上旧版本的调用记录或者把一个推测当成已经观察到的事实。REA 用 Evidence也就是证据记录组织分析结果。记录保留目标身份、操作结果、位置及限制等信息让后续追问可以回到同一批材料。目标的内容摘要也参与身份核对可以把内容摘要理解为根据文件内容计算的指纹帮助区分不同文件内容。这种组织方式有助于检查来源但并不自动保证解释正确。模型仍可能误读结果分析工具也可能存在盲区。对搜索案例最有用的检查仍然很具体发送请求的代码在哪里处理函数在哪里为什么认为两者对应还有什么条件没验证从这些基本约束推导REA 的优势是减少工具调用和证据整理之间的断层。它能降低调查成本却无法补回目标里已经丢失的信息也无法把推测变成事实。调查越接近一个有限、可核对的问题结论就越容易接受检验。验证样例固定名称能配对动态名称留下未知项目中保存的一次验证实验确认了 REA 可以在这个小样例里配对发送端与搜索处理端改变通道表达式后这种配对就失效了。实验使用 macOS、Node.js 22.22.3 和 REA 6.4.0。目标是一个自建的五文件样例包含页面、页面脚本、桥接脚本、主进程代码和应用配置。它用于检查静态分析能力没有启动 Electron。固定通道版本的分析结果是三个 JavaScript 文件被解析没有报告解析失败找到了一个桥接 API并配对了一个发送请求与一个主进程处理端。与已知样例代码对照这回答了“工具能否识别这对 IPC 调用”。随后只把发送语句改成// 通道名称取决于 query 的实际值ipcRenderer.invoke(notes: String(query), query);主进程仍注册notes:search。重新分析后工具识别到一个动态通道操作但不再给出已配对的发送端。要检查的结果固定名称动态名称识别到的动态通道操作01已配对的发送请求10原因很直观固定名称直接写在代码中动态名称要等query有具体值才能确定。如果它的值是search就会构造出notes:search如果是其他值就会产生另一个名称。这个改动是故意构造的边界实验不与原版在所有输入下保持同样行为。它说明没有配对成功可能是当前静态证据不足不能据此认定处理端不存在。遇到这种情况下一步应当查明变量如何获得值、有哪些可能取值再选择受控输入观察实际消息。补充一次运行实验可以回答那个场景的问题要扩大结论仍需覆盖其他相关输入。对原版样例静态关系已提供足够的定位线索继续安装原生分析工具不会帮助回答同一个 IPC 配对问题。更有价值的下一步是验证搜索函数的输入与输出。这一判断只适用于这份样例真正的应用可能包含更多文件和不同的通信方式。第一次使用先让 AI 回答一个有限问题如果你已经使用 Claude Code 或 Codex可以先把 REA 接入助手再给它一个明确的应用目录和调查问题。运行时需要符合 REA 的 Node.js 要求。本例使用 22.22.3当前安装文档要求 Node.js 22.x 不低于 22.19、24.x 不低于 24.11或 26。第一次配置可以运行# 展示安装与配置计划审阅后再确认npx rea-agentslatest setup按计划选择使用的助手确认配置后重启或重连。这里的setup是把工具注册给助手要确认真正可用还应检查当前会话是否能发现 REA 工具并成功完成一项简单分析。安装文档[5]提供了更详细的诊断方法。接着可以这样描述任务分析我提供的桌面应用目录查找搜索请求在哪里处理。本轮先检查文件和代码不启动应用。找出页面入口、桥接方法、消息名称和处理函数。每个结论说明文件位置与依据区分已找到的事实和推测。如果无法继续说明缺少什么信息不要补写未知实现。这份任务的完成标准是找到可核查的相关代码或者明确报告卡在哪条关系上。它没有要求助手立即还原整个应用也没有把“写出一段类似代码”当成分析成功。如果只想从终端检查目录不接入助手也可以使用本例验证过的固定版本命令# 把路径换成你有权分析的应用目录npx -y rea-agents6.4.0 analyze-javascript-application \ /absolute/path/to/app --json app-evidence.json--json表示把结果按便于程序读取的格式输出将结果保存到文件。执行后检查命令是否成功退出再看结果中的相关文件、搜索线索和限制。成功退出说明这次操作完成不能单凭它认定搜索功能已完全查清。如果出现路径错误先确认提供的是确实存在的绝对路径如果结果显示没有找到预期关系应检查目标是否包含相关文件再根据限制判断是否需要运行观察。反复要求模型“再想一想”不能补出缺失的文件。从分析到重建选择工具也选择证明范围JavaScript 文件可以直接按代码结构分析编译后的原生程序则需要另一类工具。先识别目标能减少不必要的环境配置。原生程序通常指已编译成机器指令的部分。分析时可使用 Ghidra、Hopper 或 IDA 这类工具把指令、引用和近似的高级语言表达呈现出来再继续调查。编译过程中可能丢失原始名称、注释和部分结构工具给出的伪代码因此不等于开发者原来写下的源码。图来自 REA 官方仓库展示其与 Hopper 配合检查原生程序的界面非本文验证样例。搜索链路如果完全位于 JavaScript 文件中可以先沿本例的方法调查如果进入原生扩展再按目标配置相应引擎。“连接了工具”和“当前目标可分析”是两个验收条件。缺少引擎、目标格式不受支持、文件不完整都可能阻断下一步。应该处理报告的具体原因而不是把安装成功当成所有能力已经就绪。当准备重建搜索功能时先定义想保留的行为。例如大小写是否影响匹配空关键词返回什么结果的排列顺序是否一致。用这些条件比较原程序与自己的实现才知道复现了哪些行为。只测试一个关键词结论就只能覆盖那个场景。要宣称更大的等价范围需要更多依据。对研究旧项目、分析桌面应用功能或定位问题的开发者这种有限验收通常比追求“还原一切”更实用。还应注意两条使用条件分析目标应当是你有权检查的文件工具在本地运行时交给 AI 助手的结果仍可能进入其模型服务。敏感代码和数据是否适合传入应根据具体客户端与服务方式判断。第一次尝试 REA可以选择一个自己熟悉的小应用提出一个明确问题。能回到具体文件核对的答案才是值得继续往下追的起点。参考资料• REA 官方项目[1]工具定位、终端使用和原生分析入口。• REA 官方文档JavaScript 应用分析[4]、功能追踪与比较[6]、安装与配置[5]。• Electron 官方文档进程模型[2]、ASAR 归档[3]。2026.10.13 22:22沪 · 赵巷你在研究一个软件功能时最想查清的是哪个环节欢迎在评论区分享具体问题以及已经找到的线索。这样的讨论也能帮助其他国内开发者选择调查方法。如果文章对你有用欢迎点一下“在看”或分享给正在研究类似问题的朋友。关注沐风不定期更新全是干货。引用链接[1]REA 官方项目: https://github.com/morluto/rea*[2]Electron 官方文档:https://www.electronjs.org/docs/latest/tutorial/process-model[3]ASAR 说明:https://www.electronjs.org/docs/latest/tutorial/asar-archives[4]官方分析文档:https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md[5]安装文档:https://github.com/morluto/rea/blob/main/docs/installation.md[6]功能追踪与比较:https://github.com/morluto/rea/blob/main/docs/javascript-application-workflows.md