人生贵相知，何用金与钱。——李白

REA：让 AI Agent 从应用表象一路追到二进制深处

项目地址：https://github.com/morluto/rea

当你在某个应用里看到一个令人印象深刻的功能时，最自然的念头往往是：

它到底是怎么做到的？

也许是一个离线搜索功能，也许是一套看似流畅的更新机制，也许是某个桌面应用中隐藏得很深的存储逻辑、网络流程、界面行为或数据格式。

过去，这类问题通常意味着漫长而专业的逆向工程工作。需要打开反汇编器，在符号、字符串、函数、调用关系和汇编代码之间一点点寻找线索。即使找到了入口，仍要不断追踪控制流，判断哪些证据可靠，哪些只是猜测。

REA 想改变的，不是逆向工程本身的严谨性，而是它的使用方式。

它将逆向工程能力封装为 CLI 与 MCP 工具，让 AI Agent 可以参与对二进制、原生应用、JavaScript、Electron 应用、.NET 程序、网站与运行时行为的调查。用户可以让 Agent 研究一个应用中的具体功能，查看它找到的证据，理解实现路径，再把得到的结论适配为自己项目中的功能。

REA 的目标并不是恢复原始源代码，也不是自动复制一个应用。

它更像是一位带着工具箱的调查员。

它打开目标。

寻找线索。

建立关系。

追踪实现。

呈现证据、限制与未知项。

最后，再由 Agent 将所理解的行为转化为适合当前项目的代码、测试、迁移说明或兼容实现。

从“我喜欢这个功能”开始

REA 最直观的使用方式并不需要先学习反汇编命令。

完成设置后，可以直接向 Agent 描述想了解的内容：

1
2
Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.

这句话里包含了 REA 的完整工作方向。

不是简单问“这个应用用了什么技术”。

而是要求理解一个具体功能如何工作。

不是只要结论。

而是要求展示证据。

不是停留在分析。

而是进一步将所学内容适配到自己的项目中。

REA 允许把一个模糊的观察，逐步变成有边界的工程调查。

例如：

1
2
Reverse engineer the Notes app. Find how offline search works, explain it,
and build a version for my project using TypeScript and SQLite.

对于这样的请求，REA 会帮助 Agent 从打开目标开始，识别可能与离线搜索相关的字符串、名称与过程，再将这些线索连接到可执行代码，重建调用关系与控制流，最后取得伪代码、汇编与函数信息。

而功能的最终实现，则由 Agent 使用正常的文件编辑与测试工具完成。

REA 负责理解目标。

Agent 负责将理解转化为适合当前项目的结果。

三步调查模型：反编译、理解、重建

REA 的工作模型可以概括为三个阶段。

反编译

第一步是打开应用，并恢复尽可能多的可读信息。

其中包括：

  • 代码结构
  • 字符串
  • 名称
  • 函数
  • 符号
  • 调用关系
  • 汇编指令
  • 元数据
  • 文件与资源信息

逆向工程不总能获得完整、清晰的原始信息。REA 并不假装可以凭空还原应用最初的源代码，而是从目标中提取能够支持调查的线索。

一个字符串可能指向功能入口。

一个函数名称可能揭示模块职责。

一次交叉引用可能将界面行为连接到内部实现。

一段伪代码可能展示关键状态流转。

这些线索组合起来，才逐渐形成对功能的理解。

理解

第二步不是立刻复制功能，而是顺着代码与证据继续追踪。

Agent 可以从应用的一个部分走向另一个部分，直到能够解释某项功能真实的运行方式。

例如，离线搜索可能涉及本地存储、索引构建、查询调用、结果排序与界面渲染。

认证流程可能涉及令牌读取、状态检查、网络请求与错误分支。

更新机制可能涉及版本比较、资源下载、校验、缓存与重启逻辑。

REA 的重点是帮助 Agent 从碎片化信息中建立联系，而不是只给出一段孤立的反编译结果。

重建

第三步是将调查结果转化为自己的产品能力。

这里的“重建”不是机械复制目标应用。

而是根据当前项目的技术栈、接口、用户体验与需求，构建一个适合自己的版本。

同样是离线搜索，目标应用可能使用某种存储和索引方式，而你的项目可以使用 TypeScript 和 SQLite。

同样是数据同步，目标应用的实现路径可以成为理解对象，但最终落地时仍要符合自己的架构与约束。

REA 提供的是从观察到理解的桥梁。

真正的产品代码，仍然应该服务于自己的项目。

Agent 不再只能猜测应用行为

没有源代码时，Agent 往往只能根据表面行为猜测。

它可以看到一个功能存在，却很难知道背后的真实结构。

REA 让 Agent 可以使用多类工具进行调查。

在原生二进制分析中，它可以处理函数、伪代码、汇编、字符串、符号、调用、引用、注释、字节读取与文件偏移。

在调查流程中，它可以生成应用概览、函数档案、调用图、功能追踪、批量反编译结果，以及与 Swift、Objective-C 相关的发现结果。

在 JavaScript 和 Electron 场景中，它可以静态分析模块、导入关系、Source Map、路由、IPC 通道、存储与原生附加组件。

在 .NET 场景中，它可以查看程序集标识、元数据、CIL 指令、原生依赖、重建导入与构建差异。

在网站场景中，它可以检查页面结构、网络元数据、脚本证据、Source Map、截图与 WebMCP 发现结果。

在浏览器与进程行为场景中，它还可以记录受控行为捕获结果，并对不同证据记录进行比较。

这让“没有源码”不再等于“没有调查路径”。

原生二进制调查：从字符串走进函数与调用图

REA 在原生应用分析中，可以与 Hopper 或 Ghidra 协作。

它支持打开 Mach-O、ELF、PE 以及 macOS 的 .app 目标，并检查函数、字符串、汇编、反编译结果、调用关系和引用关系。

一个典型的调查流程如下。

首先打开并识别二进制：

1
2
open_binary
binary_overview

随后寻找与目标功能相关的线索：

1
2
3
search_strings
search_procedures
list_names

接着，寻找名称和函数之间的关联：

1
2
3
find_xrefs_to_name
xrefs
procedure_callers

然后重建关键调用链与控制流：

1
2
3
get_call_graph
procedure_callees
procedure_info

最后读取关键过程的伪代码、汇编或批量反编译结果：

1
2
3
procedure_pseudo_code
procedure_assembly
batch_decompile

这种路径很适合处理从一个关键词出发的调查。

比如从“offline”开始。

从一个错误提示开始。

从某个设置项名称开始。

从一个协议字段、文件后缀、菜单文案或界面标签开始。

一个字符串不是结论。

但它可以成为进入实现层的门把手。

Hopper 与 Ghidra：两条原生分析路径

REA 并不自己实现完整反编译器，而是通过 Provider Adapter 接入已有分析工具。

对于 Hopper，REA 可以在需要时启动它。

Hopper 可以处理分析请求，并提供函数、汇编、伪代码与相关观察结果。REA 会在会话结束时关闭自身桥接并清理临时 socket 目录，同时保留用户自己可能正在使用的 Hopper 应用。

Hopper 的 Demo 模式也可用于分析。首次启动时如果出现提示，可以选择 Demo 或输入已有许可证。

对于已经使用 Ghidra 的用户，REA 可以连接现有 Ghidra 安装。

Ghidra Provider 需要 Ghidra 12.1.4 与 64 位 JDK 21。REA 不会自行下载或修改 Ghidra 与 Java，而是在用户提供路径后进行检查和连接。

配置示例如下：

1
2
3
4
5
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
export JAVA_HOME=/absolute/path/to/jdk-21
rea doctor --json
rea setup
rea providers --json

Ghidra Provider 支持清单、函数、内存与加载映像检查，也支持 Linux 与 macOS 上原子化的函数注释编辑。

它可以编辑函数名称与入口注释，让人工分析与 Agent 分析留下的结果逐渐累积在同一个分析环境中。

REA 分析 Ghidra 目标时使用临时副本，并在会话关闭后移除临时项目。结果会标明 Ghidra 实际观察到了什么，以及哪些内容仍未解析。

不只分析二进制，也能静态检查 JavaScript 与 Electron 应用

许多桌面应用并不是纯原生程序。

Electron、ASAR、JavaScript 模块、Source Map、IPC 通道、本地存储与原生插件，都是现代应用中常见的组成部分。

REA 支持对 JavaScript 与 Electron 应用进行静态分析，而且可以不执行目标应用。

对于应用目录或 ASAR 文件，可以直接运行：

1
rea analyze /absolute/path/to/releases/app.asar --json

也可以使用更明确的命令：

1
rea analyze-javascript-application /absolute/path/to/releases/app.asar --json

如果没有指定 Provider，也没有指定快照路径，针对目录或 .asar 的通用 rea analyze 会自动选择静态 JavaScript 应用 Provider。

这类分析能够返回 Evidence、恢复出的图结构、限制项与未知项。

它不依赖 MCP 设置。

不依赖 Hopper。

不依赖 Ghidra。

也不需要执行应用。

对于需要快速理解一个 Electron 程序结构、寻找模块关系、检查 IPC 通道或查看路由和存储行为的场景，这提供了一条更轻量的入口。

.NET、Android、固件与应用资源

REA 的调查范围并不只停留在原生桌面程序与 JavaScript 应用。

它还支持多个不同层次的目标。

.NET 程序集

REA 可以检查 .NET 程序集的元数据与 CIL 指令，并比较构建版本、检查声明的原生依赖。

如果导入外部反编译结果，这些输出会被明确标记为导入内容，而不是 REA 直接观察到的原始结果。

Android APK

REA 支持静态 APK 分析。

该路径需要单独提供 headless JADX JAR 与 Java，不需要模拟器，不执行 APK，也不需要安装 Android SDK。

它可以用于查看包与 Manifest 声明、搜索类、列出成员、反编译方法，并追踪静态引用。

固件

对于 Linux 环境中的固件区域检查与明确提取，REA 可以接入调用者提供的 Binwalk 与 Unblob。

REA 不会在分析过程中下载或安装固件提取引擎。它通过 Adapter 解释这些工具的命令与报告，并保留对工具来源、版本与实际摘要的关注。

包与资源

REA 可以检查目录、ZIP、APK、IPA、ASAR、plist、编译后的 Interface Builder 文件以及 Apple Asset Catalog。

应用中的资源并不总是附属信息。

有时，界面布局、图像资产、配置文件、归档结构和安装包内容，本身就是理解功能的重要线索。

Evidence：不是“我觉得”，而是“我看到了什么”

REA 的一个核心概念是 Evidence。

分析结果不仅应当给出结论，还应当记录：

  • 目标工件身份
  • 使用的 Provider
  • 观察位置
  • 置信信息
  • 限制条件
  • 未解决的问题
  • 比较结果
  • 调查上下文

这让逆向工程结果不只是模型说出的一段解释。

它可以被导出、导入、标准化、比较和复用。

例如，可以导入 Evidence Bundle：

1
rea evidence-import /absolute/path/to/evidence/bundle.json

导出标准化结果：

1
rea evidence-export /absolute/path/to/evidence/bundle.json /absolute/path/to/evidence/canonical.json

比较两份 Evidence：

1
rea compare /absolute/path/to/evidence/left.json /absolute/path/to/evidence/right.json

这种机制适合进行构建版本比较、目标行为差异分析、函数观察比较，以及将调查结果保存为可再次审阅的工件。

逆向工程中，证据尤其重要。

因为反编译结果可能不完整。

符号可能被移除。

行为可能只能在部分条件下观察到。

REA 不把缺失信息伪装成确定结论，而是让未知项继续保留为未知项。

快照：避免反复启动分析流程

深度分析通常不便宜。

打开大型应用、导入二进制、运行自动分析，都可能需要时间。

REA 支持将成功的分析结果保存为 Snapshot，并在后续精确匹配的查询中复用。

1
rea analyze /absolute/path/to/app --snapshot /absolute/path/to/analysis/app.json

下一次执行相同查询时：

1
rea analyze /absolute/path/to/app --snapshot /absolute/path/to/analysis/app.json

REA 只有在目标字节、操作、参数、分析工具与设置完全匹配时，才会复用快照结果。

它不会因为文件路径相同，就假设目标仍然是同一份内容。

这种谨慎很符合逆向工程工作流。

缓存能节省时间。

但缓存不能用来掩盖目标已经变化的事实。

浏览器观察：先看，不急着动

REA 也可以通过 Chrome DevTools Protocol 检查一个已经运行的 Chrome 系浏览器。

使用时，需要明确提供 loopback CDP Endpoint 与目标页面。

1
rea list-browser-targets http://127.0.0.1:9222 --json
1
rea inspect-web-page http://127.0.0.1:9222 TARGET_ID --json

这组被动浏览器工具可以检查页面结构、网络元数据、脚本证据与截图。

它们不会导航页面。

不会点击页面。

不会执行页面 JavaScript。

也不会将 Cookie、凭据与授权头作为普通观察结果暴露出来。

这种被动观察模式适合先建立对页面的理解。

例如：

  • 当前页面有哪些主要结构
  • 加载了哪些脚本
  • 网络中出现了哪些可观察到的元数据
  • 页面有哪些可见组件
  • 当前目标是否存在 Source Map
  • 某个页面状态是否可以被截图记录

在需要进行交互时，REA 还提供受控浏览器场景捕获。

受控浏览器场景：把行为变成可比较的记录

capture_browser_scenario 用于执行调用方声明的一组浏览器操作。

不同于被动观察，它可以与页面交互。

每一步都可以记录截图、页面结构、导航与网络活动等证据。

1
rea capture-browser-scenario ./scenario.json --json

场景 JSON 中保存的是 Secret Reference 与环境变量名称，而不是 Secret 的实际值。

这让场景描述可以表达需要哪些敏感输入，却不要求将敏感信息直接写进记录中。

REA 支持两种方式。

一种是 Launch Mode。

它拥有临时浏览器配置文件，并在终止启动的浏览器后移除这个临时配置。

另一种是 Connect Mode。

它连接一个明确指定的 loopback CDP 目标，在结束后只断开连接，而不会关闭外部浏览器。

场景捕获的价值不只是“自动点一下页面”。

它可以为两个实现建立可比较的行为记录。

如果观测缺失或被截断，REA 不会据此宣称两次运行行为相同。

Node 与 Electron 运行时观察：记录，不执行

REA 可以连接已有的 Node 或 Electron V8 Inspector Target。

1
rea list-javascript-runtime-targets http://127.0.0.1:9229 --json
1
2
rea observe-javascript-runtime http://127.0.0.1:9229 TARGET_ID \
  --runtime-kind node --json

这一能力记录脚本位置与执行上下文事件。

它不会在目标上执行代码。

不会设置断点。

也不会由这些有限观察自动推导出导入关系、事件活动、IPC、进程身份或 Electron 角色。

这份边界说明非常重要。

观察到什么，就报告什么。

没有观察到什么，就不将其伪装为结论。

进程捕获：让行为比较拥有可复现基础

REA 还提供 Process Capture。

它会按照请求中声明的可执行文件、场景、工作目录和环境运行目标。

调用者可以选择需要快照的文件系统观察路径。

需要注意的是，Process Capture 记录行为，但并不是安全沙箱。目标进程仍以当前用户权限运行。

捕获与比较的流程如下：

1
2
3
rea capture-process ./scenario.json > authority.json
rea capture-process ./reconstruction.json > reconstruction.json
rea compare-process-captures authority.json reconstruction.json

比较结果会分别报告观察到的维度，并识别最先发生差异的位置。

这可能是终止状态差异。

可能是交互差异。

可能是退出码差异。

可能是文件系统差异。

也可能是进程行为差异。

这种能力很适合在重建功能后验证行为是否接近参考目标。

它不会承诺两个程序“完全一样”，但可以将可观察到的差异明确标记出来。

CLI 与 MCP：同一套调查能力，两种入口

REA 同时提供命令行与 MCP Server。

这两条路径共享应用工作流与 Evidence Contract。

如果只是希望在终端中快速查看一个目标，可以直接使用 CLI。

1
npx -y rea-agents@latest analyze /Applications/Notes.app
1
npx -y rea-agents@latest inspect /Applications/Notes.app
1
npx -y rea-agents@latest search /Applications/Notes.app "offline"
1
npx -y rea-agents@latest function /Applications/Notes.app 0x1000
1
npx -y rea-agents@latest xrefs /Applications/Notes.app 0x1000
1
npx -y rea-agents@latest trace /Applications/Notes.app "offline"
1
npx -y rea-agents@latest capabilities
1
npx -y rea-agents@latest providers

如果希望长期使用，也可以全局安装：

1
npm install --global rea-agents

随后运行：

1
2
3
rea --help
rea update
rea mcp

CLI 适合一段明确的单次调查。

MCP 则适合将同一套能力交给 Agent，使调查与编码、测试、文档编写处于同一个工作会话中。

设置 REA，让 Agent 获得调查能力

推荐的设置方式是：

1
npx rea-agents setup

设置过程会让用户选择哪些受支持的 Agent 应使用 REA，并在应用更改前展示具体路径和变更内容。

已有 REA 注册项会默认被选中。

新检测到的 Agent 则可以按需选择。

设置过程中会备份已有配置。

它还可以连接已有的分析工具，或者在获得批准后安装 Hopper。

REA 支持的 Agent 包括：

  • Claude Code
  • Claude Desktop
  • Codex
  • Cursor
  • Gemini CLI
  • Windsurf
  • Devin
  • OpenCode
  • Antigravity
  • GitHub Copilot CLI
  • Command Code
  • VS Code

如果只希望安装 Agent 指令，而不注册 MCP Server 或配置分析引擎，也可以单独安装 Reverse Engineer Anything Skill：

1
npx skills add morluto/rea --skill reverse-engineer-anything

这种方式只安装指令内容，不完成 MCP 注册和分析引擎设置。

诊断优先：doctor 用来判断环境是否准备好

逆向工程的环境通常涉及多个组件。

Node 与 npm。

目标操作系统。

分析工具。

Java。

Hopper 或 Ghidra。

Agent 配置。

浏览器调试端口。

外部工具路径。

因此，REA 提供了 doctor 命令用于检查当前环境。

1
npx -y rea-agents@latest doctor

需要结构化输出时：

1
npx -y rea-agents@latest doctor --json

doctor 会检查主机、依赖、分析工具和 Agent 配置，但不会修改任何内容。

如果某个外部 Provider 的可选前提条件缺失，它会作为信息性诊断保留，而不会阻止与该 Provider 无关的设置或操作。

这避免了一个常见问题：某一条可选分析路径不可用，就让整个工具链都无法继续工作。

本地分析，并不等于忽略安全边界

REA 的分析默认在受支持的本地主机上运行。

它没有托管分析服务，也不会将应用上传到远程分析平台。

REA 与 Hopper、Ghidra 之间通过认证的私有本地 Socket 通信。

不过，REA 也明确指出，Agent 或模型提供方本身可能有自己的数据策略，因此相关策略仍需要单独审查。

运行时请求会作用于声明的目标和生命周期。

分析工具与启动的目标使用当前用户权限运行。

原生 UI 捕获还依赖 macOS 的辅助功能与屏幕录制权限。

对于 Windows x64 Ghidra P0，REA 使用 Job Object、私有运行时 DACL 与基于句柄的准入控制，其实验性范围限定在本地 NTFS 上的原生 x86-64 PE 应用。

这些边界说明提醒用户：

REA 可以帮助调查。

但调查能力本身也需要明确的目标、权限和运行范围。

不承诺恢复原始源码，只承诺呈现可用证据

REA 对逆向工程能力有一个明确而克制的表述。

它不会声称恢复原始源代码。

任何反编译器都无法保证还原开发者最初写下的代码。

REA 提供的是伪代码、汇编、符号、字符串、元数据与关系信息。Agent 可以基于这些材料解释观察到的行为，并构建兼容或适配后的实现。

这一区分非常重要。

原始源代码与反编译结果不是同一件事。

目标行为的理解与原样克隆也不是同一件事。

REA 的调查结果应被视为带有证据、范围与限制的工程观察，而不是无条件正确的源代码复原。

复杂目标，也需要明确 Provider 选择

当 Hopper 与 Ghidra 都可用时，REA 不会在没有明确指示的情况下随意选择其中一个。

可以通过 CLI 查看 Provider 状态：

1
rea providers --json

指定 Hopper：

1
rea analyze /absolute/path/to/program --provider hopper

也可以通过环境变量选择：

1
REA_ANALYSIS_PROVIDER=hopper rea decompile /absolute/path/to/program 0x1000

在 MCP 中，则可以在打开二进制时传入 provider_id：

1
2
3
4
{
  "path": "/absolute/path/to/program",
  "provider_id": "hopper"
}

指定 Provider 的选择会优先于环境变量。

会话会保持该选择，直到用户明确切换。

这种方式避免在复杂分析中出现“同一个目标、不同工具、不同结果却没有记录来源”的问题。

调查结论不仅要知道是什么，也要知道来自哪个工具和哪种分析路径。

从一个目标到完整调查：REA 的价值不只是工具数量

REA 的工具目录覆盖多个领域。

它包含原生检查、调查工作流、macOS 原生工具、工件图、托管 PE 与 CLI、固件、Android APK、浏览器观察、Electron 分析、JavaScript 运行时、应用流程、工作区与观察记录等工具家族。

但 REA 的真正价值，并不只是工具数量多。

它更强调一条完整调查路径。

先确定目标。

再建立会话。

然后选择合适 Provider。

接着按能力边界进行观察。

保存证据。

记录限制。

保留开放问题。

必要时比较不同版本、不同运行记录或不同重建结果。

最后，将理解交给 Agent，用于实现、测试、文档和迁移工作。

它让逆向工程不再只是一个人盯着反汇编界面，也可以成为 Agent 驱动的软件理解流程。

REA 不是自动复制器，而是理解工具

REA 的核心理念可以浓缩为一句话：

看到一个功能，理解它如何工作，再为自己的产品构建适合的版本。

它不会自动复制应用。

不会承诺恢复原始源代码。

不会把缺失证据包装成确定结论。

不会将本地分析伪装成无边界的安全沙箱。

但它可以帮助 Agent 调查原生二进制、应用资源、JavaScript、Electron、.NET、Android APK、固件、浏览器页面与运行时行为。

它可以将字符串、符号、函数、调用图、伪代码、汇编、资源结构、页面观察和过程捕获组织为可追踪的 Evidence。

它可以让“我想知道它是怎么做的”不再只能停留在猜测。

对于希望从既有软件中学习功能设计、理解行为逻辑、记录协议结构、研究未公开接口，或将观察结果转化为自己项目功能的开发者而言，REA 提供的是一条从表象走向证据、从证据走向理解、再从理解走向重建的路径。