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