Agent之ReverseEngineer:REA的简介、安装和使用方法、案例应用之详细攻略
目录
REA的简介
1、特点
REA的安装和使用方法
1、安装
1.1 环境要求
1.2 使用引导式设置
1.3 全局安装CLI
1.4 仅安装智能体Skill
1.5 检查安装状态
1.6 更新REA
2、使用方法
2.1 通过智能体调查应用功能
2.2 分析JavaScript或Electron应用
2.4 分析原生程序
2.5 选择分析提供方
2.7 使用范围说明
REA的案例应用
案例一:DX-Ball——重建声音声像计算
案例二:Notion——追踪Electron剪贴板桥接链路
案例三:TH04——恢复DOS环形子弹计算
REA的简介
REA是一个面向智能体的逆向工程项目,目标是通过统一的MCP服务和CLI,让智能体检查二进制文件、应用程序及其运行时行为。即使目标应用没有源代码,智能体也可以借助REA分析功能实现路径、解释工作机制、展示相关证据,并基于调查结果编写和测试相似实现。
REA将智能体连接到不同类型的分析工具,可以处理原生二进制文件、JavaScript与Electron应用、.NET程序集、网站、Android APK、固件、网络捕获和进程行为等对象。分析主要在本机运行,返回结果不仅包含分析发现,还包含支持结论的证据和相关限制。静态JavaScript和.NET检查只读取用户提供的文件,不会运行目标应用;运行时捕获则会以当前用户权限运行目标或与其交互。
在智能体工作流中,智能体通过MCP调用REA检查目标、追踪相关代码,REA返回调查发现及对应证据,智能体再据此继续提问、解释行为或编写实现。用户也可以直接通过终端调用相同的分析工作流。对于深入的原生程序分析,REA可以连接Hopper、Ghidra或IDA;JavaScript、Electron和.NET静态分析则不要求安装这些原生分析引擎。
GitHub地址:GitHub - morluto/rea: Reverse engineer anything with agents, from app behavior down to native binaries. · GitHub
1、特点
特点 | 详细说明 |
MCP与CLI双入口 | 智能体可以通过MCP调用REA,用户也可以在终端中使用相同的分析工作流和Evidence结果契约。 |
本地分析 | REA在本机分析目标,不会由REA将应用发送到托管分析服务;智能体仍会接收分析工具返回的结果。 |
证据驱动 | 分析结果包含支持各项结论的证据和相关限制,使智能体能够区分观察结果、推断和仍未解决的问题。 |
多类型目标支持 | 支持原生二进制文件、ELF布局、EVM字节码、Linux崩溃记录、JavaScript/Electron、网站、HAR网络捕获、.NET程序集、Android APK、Android设备、JEB项目、Android资源、固件、软件包和进程行为等对象。 |
原生二进制分析 | 可以返回伪代码、汇编、字符串、符号、函数调用和交叉引用;深入分析可使用Hopper、Ghidra或IDA。 |
JavaScript与Electron分析 | 可以恢复模块、导入关系、source map、路由、IPC以及原生扩展之间的关系,并支持分析解包目录或ASAR文件。 |
Web与网络分析 | 网站分析可以返回页面结构、脚本、网络观察结果和按请求获取的截图;已保存的网络捕获可以提取请求、响应、可访问载荷和来源位置。 |
Android分析 | 可以检查APK清单、类、反编译方法和引用,也可以通过调用方提供的adb检查设备、软件包、进程、日志、转储和截图。 |
固件与资源检查 | 可以借助Binwalk或Unblob检查固件区域和提取结果,也能分析文件清单、摘要、plist、Apple Bundle结构和提取资源。 |
分析会话与上下文 | 原生分析提供方会与当前会话绑定;用户可以在同一会话中继续调查目标,直到显式切换或关闭目标。 |
快照复用 | CLI支持将成功的分析结果保存为本地快照。当目标字节、操作、参数、提供方及设置一致时,可以直接复用完全匹配的结果。 |
引导式调查流程 | MCP提供功能调查、应用版本比较、重建验证、崩溃追踪、残余未知项审计和受控进程捕获设计等六类引导流程。 |
智能体配置自动化 | 设置流程能够注册REA MCP服务、安装匹配的工作流指引、备份已有配置,并在写入前展示计划供用户检查和批准。 |
多智能体客户端支持 | 设置程序支持Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf、Devin、OpenCode、Qwen Code、VS Code、Grok Build、Pi和Hermes等客户端。 |
分析提供方选择 | 用户可以列出可用提供方及其能力,由REA自动选择唯一可用的提供方,也可以通过参数或环境变量显式指定Hopper、Ghidra或其他提供方。 |
安全的配置变更 | 配置写入会保留无关字段和注释、创建备份、采用原子替换并验证结果;取消操作或拒绝确认不会产生配置变更。 |
REA的安装和使用方法
1、安装
1.1 环境要求
REA需要以下运行环境:
- Node.js 22.x,最低版本为22.19;
- Node.js 24.x,最低版本为24.11;
- 或者Node.js 26及以上版本;
- 与Node.js运行时配套的npm。
Node.js 23、25以及预发布版本不受支持。不同的分析目标还可能需要Hopper、Ghidra、IDA、JDK、JADX、adb、Apktool、Binwalk、Unblob、pwntools或Chrome系浏览器等额外工具。
1.2 使用引导式设置
安装Node.js和npm后,运行:
npx rea-agents setup如果希望明确使用npm中的最新版本,可以运行:
npx rea-agents@latest setup进入设置流程后:
- 选择需要配置的智能体客户端;
- 检查REA展示的配置变更计划;
- 根据需要选择是否安装或连接Hopper;
- 批准计划后,由REA注册MCP服务并安装匹配的工作流指引;
- 设置完成后,重新启动提示中列出的智能体。
该流程会在修改之前列出智能体配置路径、工作流安装位置、已检测到的分析工具以及可能执行的软件安装命令。已有的无关配置会被保留,并会创建配置备份。
1.3 全局安装CLI
如果需要经常在终端中使用rea命令,可以全局安装:
npm install --global rea-agents rea --help如果只执行一次任务,可以不进行全局安装,直接使用:
npx -y rea-agents@latest <command>仅执行下面的命令:
npm install rea-agents会把可执行文件安装到当前项目的node_modules/.bin中,不会使rea命令自动出现在Shell的PATH里。
1.4 仅安装智能体Skill
如果只希望安装REA的智能体调查指引,可以执行:
npx skills add morluto/rea --skill reverse-engineer-anything
该命令只安装智能体指引及其配套参考资料,不会注册REA MCP服务,也不会安装分析引擎。完整的引导式设置默认会安装与当前REA软件包匹配的Skill。
1.5 检查安装状态
rea doctor --client codex --json检查全部已检测配置和分析工具:
rea doctor --json检查Codex客户端注册:
rea doctor --client codex --json检查Ghidra提供方:
rea doctor --provider ghidra --json检查已安装的工作流指引:
rea doctor --skill --jsonrea doctor只读取主机依赖和智能体配置,不会修改相关文件。
1.6 更新REA
全局安装后,可以执行:
rea update使用npx配置智能体时,可以运行:
npx rea-agents@latest setup检查新的设置变更并批准,然后重新启动受影响的智能体。
2、使用方法
2.1 通过智能体调查应用功能
完成MCP注册并重新启动智能体后,可以直接描述待调查的应用和功能。例如仓库提供的请求形式是:
弄清 Notes 应用的搜索功能如何工作,展示证据,
并为我的项目实现类似功能。
实际使用时,将Notes替换为目标应用,并描述需要了解的具体功能。智能体会通过MCP调用REA检查目标、追踪相关代码、获取证据,并根据结果解释行为或编写和测试实现。
2.2 分析JavaScript或Electron应用
检查已经解包的应用目录或ASAR文件:
npx -y rea-agents@latest \ analyze-javascript-application \ /absolute/path/to/app \ --json命令返回模块、导入关系、Electron边界及相关证据。在Windows中,可以将目标路径写成:
D:/apps/example全局安装后,也可以使用:
rea analyze-javascript-application /absolute/path/to/app --json对于目录和.asar文件,在没有指定--provider或--snapshot时,还可以使用通用命令:
rea analyze /absolute/path/to/app --json ``` :chatgpt-content-reference{index="11"### 2.3 保存并查看大型分析结果
真实应用的完整Evidence文件可能非常大。CLI文档建议先保存结果,再生成摘要视图:
```bash rea analyze-javascript-application \ /absolute/path/to/app \ --json > app-evidence.json生成摘要视图输入:
jq -c \ '{source: {kind: "inline", evidence: .}, view: {kind: "summary"}}' \ app-evidence.json > app-view.json查看摘要:
rea inspect-analysis-view app-view.json还可以将视图改为模块分页形式,并通过offset和limit选择需要检查的模块范围。
2.4 分析原生程序
原生分析前需要配置Hopper、Ghidra或IDA。以Ghidra为例:
# 获取原生目标概览
rea analyze /absolute/path/to/program \ --provider ghidra \ --json# 搜索文本
rea search /absolute/path/to/program \ "search" \ --provider ghidra \ --json# 查看函数资料
rea function /absolute/path/to/program \ main \ --provider ghidra \ --json# 反编译指定地址
rea decompile /absolute/path/to/program \ 0x1000 \ --provider ghidra \ --json# 查询交叉引用
rea xrefs /absolute/path/to/program \ 0x1000 \ --provider ghidra \ --json# 追踪相关实现路径
rea trace /absolute/path/to/program \ "search" \ --provider ghidra \ --json其中,function返回函数资料,decompile返回伪代码。如果只需要汇编指令,可以使用rea instructions。macOS的.app应用包也可以直接作为目标传入。
2.5 选择分析提供方
列出可用提供方和相关能力:
rea providers --json rea capabilities --json显式指定提供方:
rea analyze /absolute/path/to/program --provider hopper也可以设置长期偏好:
export REA_ANALYSIS_PROVIDER=hopper单次命令中的--provider优先级高于环境变量。通过MCP调用open_binary时,可以传入:
{ "path": "/absolute/path/to/program", "provider_id": "hopper" } ``` :chatgpt-content-reference{index="14"}### 2.6 保存并复用分析快照
保存分析结果:
```bash rea analyze /absolute/path/to/program \ --provider ghidra \ --snapshot /absolute/path/to/analysis/program.json再次执行完全相同的查询:
rea analyze /absolute/path/to/program \ --provider ghidra \ --snapshot /absolute/path/to/analysis/program.json当目标内容、操作、参数、提供方和设置全部匹配时,REA可以从快照中复用已保存的分析结果。快照保存在本地,并使用仅所有者可访问的文件权限。
2.7 使用范围说明
REA用于合法的逆向工程研究、分析和重建。使用者需要自行取得必要授权并遵守适用法律,项目不支持非法或未经授权的使用。
REA的案例应用
案例一:DX-Ball——重建声音声像计算
案例实现内容:
该案例从DX-Ball的声音调用路径开始追踪,定位到一个根据位置计算声音声像的辅助函数。调查过程进一步检查相关机器指令,并将不完整的伪代码转换为C语言实现。
重建结果通过了3,205个原始x86测试用例,同时复现了编译后函数的全部63个字节。该案例展示了REA从调用关系、指令和伪代码中提取证据,并据此重建底层算法实现的过程。
案例二:Notion——追踪Electron剪贴板桥接链路
案例实现内容:
该案例首先定位Notion渲染进程中的剪贴板API,然后沿着preload层和IPC通信路径继续追踪,最终到达Electron主进程。
在完整调用链路被识别后,案例进一步检查富格式剪贴板数据,用于说明渲染进程中的剪贴板操作如何经过preload与IPC桥接到主进程。
案例三:TH04——恢复DOS环形子弹计算
案例实现内容:
该案例检查原始PC-98游戏中的16位机器指令,从中恢复固定角度与瞄准角度的计算方法。
完成算法恢复后,案例使用C++重建相关计算,并将重建结果与当年编译器生成的输出进行对比,用于验证恢复实现与原始程序之间的对应关系。