fanweibin.cn

主题

⏱ 10 分钟阅读✍️ 2,817 字👁 ...AI技术开源工具# REA# 逆向工程# AI Agent# MCP# Electron

让 AI 帮忙分析一个没有源码的桌面应用，最危险的结果不是“看不懂”，而是它根据几个字符串和函数名讲出一套听起来完整、实际上没有证据的故事。

REA（Reverse Engineer Anything）试图解决的正是这个问题。它不是一个新的大模型，也不替代 Ghidra、Hopper 或 IDA；它把这些逆向工具，以及 JavaScript、Electron、.NET、Android、固件和网页分析能力，整理成一套 CLI 与 MCP 接口，让编码 Agent 能提出问题、调用分析工具，再把结论指回具体文件、字节摘要和源码位置。

这个项目最近快速升温。第三方的 2026 年 10 月 9 日 GitHub Trending 快照把 REA 列在总榜第一，并记录当天新增约 1.49 万 Star；截至 2026 年 10 月 11 日观察 GitHub 仓库时，Star 数约为 6.9 万。这个数字只能说明开发者关注度，不能证明工具已经被大规模采用，更不能证明分析结论一定正确。

现在值得看的技术变化是版本本身：项目在 2026 年 10 月 9 日（UTC）发布了 REA 6.3.0，随后将同版本发布到 npm。这个版本包含多项破坏性契约调整，要求更多分析结果显式携带元数据，拒绝缺少当前生产者信息或事务身份的旧捕获，并进一步保留证据上下文、未知值和失败原因。换句话说，REA 的重点不是让 Agent “说得像逆向工程师”，而是限制它能凭什么下结论。

它不是反编译器，而是一层调查协议 ​

传统逆向流程常被拆散在多个窗口里：反编译器给出伪代码，抓包工具给出网络请求，浏览器调试器给出运行时对象，分析者再手工把它们串起来。如果把其中几段复制给大模型，模型看到的只是片段，通常不知道：

  • 这段结果来自哪个版本的文件；
  • 某条关系是直接观察，还是静态推断；
  • 分析有没有因为大小、格式或权限被截断；
  • “没找到”究竟表示不存在，还是工具没有覆盖到。

REA 在中间增加了一层结构化调查协议。可以把它想成给侦探配发统一的物证袋：每条发现不只写“发现了什么”，还要写物证编号、采集位置、采集工具、覆盖范围，以及哪些地方仍不能确定。

一份典型结果会同时包含几类信息：

层次回答的问题常见字段
Artifact分析的是哪一份输入路径、SHA-256、字节数、容器类型
Observation原始材料中直接看到了什么state: observed、源码范围、精确置信度
Inference依据静态关系推断了什么state: inferred、推断机制、限制
Coverage工具看完了吗complete、partial、截断和遗漏数量
Unknown为什么不能继续确定动态调用、表达式不可解析、输入缺失

这套区分很重要。比如在 Electron 应用中看到 ipcRenderer.invoke("copy-note")，只能直接观察到 renderer 发出了一个字面量通道调用；如果主进程中恰好只有一个 ipcMain.handle("copy-note")，工具可以把两者配对，但这仍是静态推断。相同的字符串并不能证明 handler 在运行时已经注册，也不能证明这条路径真的会执行。

三条分析路线各自负责什么 ​

REA 把多种后端放在同一接口后面，但它们的证据强度并不相同。

1. 静态 JavaScript 与 Electron 重建 ​

对解包后的应用目录或 ASAR，REA 可以不运行应用代码，读取 package.json、JavaScript、TypeScript、HTML、source map 和 Electron 配置，恢复入口、模块、preload、contextBridge、IPC、路由、网络端点与存储关系。

这条路线不需要 Ghidra 或 Hopper，适合回答“renderer 通过哪个 preload 暴露能力”“哪个 IPC 通道连接了前后端”一类问题。它的安全边界也比较清晰：官方文档明确说明不会调用 eval、Function、应用启动代码或打包器的 push handler。

2. 原生二进制深度分析 ​

对 ELF、Mach-O、PE 等原生目标，REA 仍然需要实际分析引擎。它可以连接 Ghidra、Hopper 或 IDA，向 Agent 暴露函数、伪代码、汇编、字符串、调用关系和引用。

REA 的价值是把查询和证据整理成可组合结果，不是发明了一套比这些成熟反编译器更强的底层分析算法。没有合适的引擎、架构支持或调试符号时，Agent 也不会凭空得到可靠答案。

3. 运行时捕获与静态结果对齐 ​

静态分析告诉你“代码里可能有什么”，运行时捕获告诉你“一次具体执行中观察到了什么”。REA 可以采集浏览器、Electron、进程和网络行为，再用文件摘要、source map 和位置关系与静态图对齐。

两层证据不会被强行合并成一个确定结论：一次运行中没出现某个分支，只能说明这次授权的捕获没有观察到它，不能证明代码永远不会执行。

用四个文件验证 Electron 边界 ​

我在 Node.js 24.19.0 环境中固定 rea-agents@6.3.0，准备了一个最小 Electron 目录。它没有安装或启动 Electron，只提供静态源文件：

text
rea-demo/
├── package.json
├── main.js
├── preload.js
└── index.html

主进程注册一个 copy-note handler，并从 preload.js 向 renderer 暴露 notes.copy：

js
// main.js
const { app, BrowserWindow, ipcMain, clipboard } = require("electron");

ipcMain.handle("copy-note", (_event, text) => {
  clipboard.writeText(text);
  return { copied: text.length };
});

app.whenReady().then(() => {
  const window = new BrowserWindow({
    webPreferences: {
      preload: require("path").join(__dirname, "preload.js"),
    },
  });
  window.loadFile("index.html");
});
js
// preload.js
const { contextBridge, ipcRenderer } = require("electron");

contextBridge.exposeInMainWorld("notes", {
  copy(text) {
    return ipcRenderer.invoke("copy-note", text);
  },
});

固定版本运行命令如下。目标必须使用绝对路径；换成自己的目录即可复现：

bash
npx -y rea-agents@6.3.0 \
  analyze-javascript-application /absolute/path/to/rea-demo \
  --json

本次命令退出码为 0。结果读取了 4 个相关文件和 952 字节文本，构建出 20 个应用图节点、91 个语义节点与 50 条语义关系。Electron 摘要识别出：

  • 一个主进程入口 main.js；
  • 一个 preload 入口 preload.js；
  • 一个 renderer 文件 index.html；
  • 一个名为 notes 的 contextBridge API，其中包含 copy；
  • 两次 IPC 操作，共用字面量通道 copy-note；
  • renderer 的 invoke 与主进程的 handle 得到唯一静态配对。

更有价值的是，结果没有把所有事情都说成“已验证”。入口文件和 IPC 语法的位置属于直接观察；preload.js 会被窗口加载、两个通道会在运行时连接，则标为高置信度静态推断，并附上“静态语法不能证明运行时执行”的限制。

语义图还保留了 38 个 unknown，例如外部 electron 模块中的对象身份、成员调用和动态值无法仅凭这四个文件完全解析。这个数量不是质量分数，也不表示示例有 38 个错误；它说明工具没有把分析边界之外的内容悄悄补成确定事实。

Agent 真正能从中得到什么 ​

有了结构化图，Agent 可以从一个业务问题逐步缩小范围，而不是直接阅读全部反编译输出。例如要查“复制按钮最终如何写入系统剪贴板”，调查路径可以是：

  1. 从 renderer 暴露的 notes.copy 开始；
  2. 跟到 preload 中的 ipcRenderer.invoke；
  3. 用字面量通道 copy-note 找唯一 handler；
  4. 查看 handler 所在源码范围及其调用的 clipboard.writeText；
  5. 对每一步分别报告观察、推断和未知项。

真实应用的结果可能达到数百 MB。此时不应把整份 JSON 塞进模型上下文，而要保存 Evidence，再请求摘要、指定模块页或功能 trace。这样既减少 token，也避免因为截断而让 Agent 误以为自己已经读完全部结果。

MCP 只解决工具调用和结果结构，不解决模型可信度。Agent 仍可能错误概括证据，因此最终结论最好保留关键位置、摘要和限制，重要安全判断还要由人工在原始工具中复核。

哪些场景适合，哪些不适合 ​

REA 比较适合：

  • 分析 Electron 或 JavaScript 桌面应用的模块和 IPC 边界；
  • 在获得授权的安全研究、兼容性开发和 CTF 中调查二进制；
  • 将一次逆向过程整理成可复查的证据，而不只是聊天记录；
  • 比较不同版本应用的结构变化，寻找新增或删除的路径。

它不适合拿来做“一键克隆应用”。逆向结果通常只能说明实现线索，不能自动处理产品设计、数据迁移、测试、许可和知识产权问题。对已有源码或公开 API 的项目，直接阅读源码和文档往往更简单。

上手前必须知道的边界 ​

  • 先确认授权。 项目本身也要求只用于合法的逆向研究。软件许可、当地法律和合同限制不会因为使用 AI 而消失。
  • 本地分析不等于所有数据都留在本地。 REA 在本机读取目标，但 Agent 是否把工具结果发送给模型提供商，取决于你使用的客户端和数据政策。
  • 静态关系不是运行时事实。 对启动顺序、动态加载、反射、混淆和环境分支，必须结合实际捕获或手工验证。
  • 原生能力依赖外部工具。 Ghidra、Hopper、IDA、JADX、Binwalk 等各有平台、版本和许可条件；REA 不能消除这些依赖。
  • 版本变化很快。 6.3.0 含多项破坏性契约变更。自动化脚本应固定包版本和证据格式，升级前先跑回归样例。
  • 热度不是成熟度。 数万 Star 和榜单增长只证明很多人正在看；生产使用仍要评估稳定性、更新节奏、目标格式覆盖和误判成本。

REA 最值得借鉴的并不是“让 Agent 会逆向”这句口号，而是把不确定性也设计成输出的一部分。对于任何高风险 Agent 工具，这都是更普遍的原则：结论必须能追到证据，推断必须标明边界，没看见的东西不能自动写成不存在。

原始资料 ​

📚 相关文章

💬 评论

已运行 … · 总访问 … 次

© 2018-2026 范伟彬 · 写作空间