十分钟上手 rea：用 CLI 让 AI 逆向你手头的第一个二进制程序
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
「让 AI 帮你逆向」在过去一年里从一个口号变成了肉眼可见的技术潮流：社区里涌现出 AI 驱动的 JS 逆向工具链、基于 MCP 协议的浏览器抓包与 Hook 方案、AI 辅助的小程序反编译工作流，甚至连 radare2 这类老牌框架也开始讨论接入 AI 助手。但绝大多数这类方案都停留在「Web 逆向」的舒适区——一旦目标是 ELF、Mach-O、PE 这类原生二进制，你依然要面对 IDA、Ghidra、Hopper 的图形界面、漫长的学习曲线和成堆的脚本。rea 想做的事情，就是把这条路也变成一条命令行：它把原生二进制、JavaScript/Electron 应用、.NET 程序集、Android 包、固件乃至网站分析全部收敛进同一个 CLI 和 MCP 服务，让 AI Agent 和你本人用同一条命令去「看懂」一个程序，并返回带证据（Evidence）的结论。本文带你用十分钟完成安装、跑通第一个原生二进制的逆向，并读懂输出里的门道。
为什么是 rea：逆向的门槛正在被 CLI 抹平
rea 的定位一句话就能说清：Reverse engineer anything with agents, from app behavior down to native binaries。它不是一个反编译器，也不是一个调试器，而是把「谁来当分析引擎」和「谁来提问」解耦的一层编排层：
- 分析引擎可插拔：原生深分析支持 Hopper、Ghidra、IDA，静态 JavaScript 与 .NET 分析甚至不需要任何原生引擎；
- 一个入口两套用法：同样的工作流既能被 Agent 通过 MCP 调用，也能由你在终端直接执行；
- 证据先行：每条结论都附带观察（observations）、推断（inferences）与未解问题（unknowns），不会把伪代码包装成「原始源码」。
截至仓库状态，该项目在 GitHub 已收获 3 万 star，README 首页展示的正是它在 Hopper 中启动分析桥检查原生二进制的场景——这也是 rea 最典型的形态：分析引擎的 GUI 照常打开，但操作和取数的动作全部由桥接层替你完成。
对新手最友好的部分是终端路径：分析完全在本机运行，不要求你会上传文件、不要求理解 MCP 传输细节，npx一条命令就能跑起来。
安装与依赖准备
第一步：确认运行时
rea 对 Node.js 版本有明确要求：22.x（>=22.19）、24.x（>=24.11）或 26+，Node 23、25 及预发布版本不受支持。它的包名是rea-agents，CLI 可执行文件同时注册为rea和rea-agents（见 package.json 的bin字段）。
第二步：三种安装方式
方式 A：用 npx 做一次性分析（零全局安装）
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json方式 B：全局安装 CLI，作为日常命令使用
npm install --global rea-agents rea --help方式 C：完整 setup（推荐，如果你想接上自己的 Agent）
npx rea-agents setupsetup是一个「计划先行」的事务：先列出将修改的每个配置路径、备份方式和外部软件安装计划，得到你的确认后才写入。它支持 Claude Code、Codex、Cursor、Gemini CLI、Grok Build、VS Code、Copilot CLI 等十余种客户端（完整列表见 docs/installation.md）。注意setup只负责注册 MCP 与安装工作流指引，永远不替你安装 Node.js、npm、Java、Ghidra、IDA、JADX 等外部依赖。
第三步：准备原生分析引擎（可选但推荐）
如果你只想先试水 JavaScript/Electron 或 .NET 静态分析，可以跳过这一步——它们不需要任何反编译引擎。但要走通「逆向你手头的第一个二进制程序」，需要三选一：
- Hopper：
setup可以在你批准后自动下载并安装（macOS 走官方 DMG，Linux 走官方 deb/rpm 包，运行在私有 Xvfb 上）；已有安装则直接复用，macOS 上首次运行需手动选择 demo 模式或激活授权； - Ghidra：复用你已有的 12.1.x 安装，用环境变量指认路径：
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC export JAVA_HOME=/absolute/path/to/jdk-21 # 可选，若 java/javac 已在 PATH rea doctor --json- IDA：通过现有 IDA MCP 配置接入，复用你已有的
.idb/.i64工作流。
安装后先用rea doctor做一次只读体检，它会逐项检查宿主平台、Node 版本、引擎可执行文件与 Agent 配置，并在每个失败项后给出精确的修复命令：
rea doctor --provider ghidra --jsonCLI 基本命令与参数速览
rea 的 CLI 是「one-shot」设计：每次调用都是独立进程，命令名与 MCP 工具一一对应。原生分析的核心命令如下（目标路径、搜索词、函数名/地址按需替换）：
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 # 沿引用追踪一个功能 rea instructions /absolute/path/to/program main --provider ghidra --json # 只读汇编，不反编译几个高频参数需要记住：
| 参数/环境变量 | 作用 |
|---|---|
--json | 结构化输出；默认终端格式是 TOON，适合人读 |
--provider hopper\|ghidra\|ida | 显式绑定分析引擎；不传则按确定性规则自动选择 |
--snapshot <path> | 把分析结果缓存到本地快照，相同目标+参数直接复用，省去重复启动引擎 |
--procedure=,--pattern=,--query= | 等号形式传参，避免以-开头的名字（如 Objective-C selector）被当成选项 |
--kind strings\|procedures/--mode literal\|regex | search的搜索范围与匹配模式 |
REA_ANALYSIS_PROVIDER | 设置默认提供方，命令行--provider优先 |
GHIDRA_HEADLESS_MAXMEM=512M | 限制 Ghidra JVM 堆大小，适合小目标、小内存机器 |
两个「体检」类命令帮你理解当前环境的能力边界：
rea providers --json # 可用分析引擎及其支持的操作 rea capabilities --json # 辅助能力清单实战：逆向一个小型二进制并解读输出
准备一个练手目标
仓库自带一个非常适合新手的目标：scripts/fixtures/binary-layout.c。它只有几十行，包含全局变量、线程局部变量、一个read_values()辅助函数和main，是理解「符号、字符串、函数、引用」的最小样本：
int stored_value = 7; __thread int tls_value; __attribute__((noinline)) int read_values(const char *text) { char buffer[32]; snprintf(buffer, sizeof(buffer), "%s", text); return buffer[0] + stored_value + tls_value; } int main(int argc, char **argv) { return read_values(argc > 1 ? argv[1] : "source-owned"); }在 Linux/macOS 上编译出调试版和 stripped 版各一份（stripped 版本最能体现 rea 的价值——没有符号表它依然能还原函数边界）：
gcc -O0 -g -o hello_debug scripts/fixtures/binary-layout.c gcc -O0 -s -o hello_stripped scripts/fixtures/binary-layout.c rea analyze /absolute/path/to/hello_stripped --provider ghidra --json第一步：概览（analyze）
analyze走的是binary_overview工作流，返回目标摘要：架构与格式、符号表、字符串清单、函数清单与调用关系。关键是要看懂输出里三件事：
- Artifact identity：路径、SHA-256、大小——它是后面所有结论的「锚点」，目标字节一旦变化，结果身份就会失配；
- Coverage：哪些分析完整、哪些是部分观察；
unknowns里列出的东西是「确实没解出来」，而不是被悄悄忽略； - Limitations：Ghidra 的伪代码是反编译器输出，永远不是原始源码，rea 从不在结果里伪装这一点。
第二步：追一个函数（function / decompile / instructions）
对main建一份完整档案：
rea function /absolute/path/to/hello_stripped main --provider ghidra --json rea decompile /absolute/path/to/hello_stripped 0x401146 --provider ghidra --json rea instructions /absolute/path/to/hello_stripped main --provider ghidra --jsonfunction返回函数档案（dossier），包含入口地址、调用者/被调用者、控制流图、最多 3000 条高一级 p-code 操作与 12000 条 def-use 边；decompile返回可读伪代码；instructions则只读 Ghidra Listing 的原始指令，不启动反编译器。三者的语义边界在 rea 里被严格区分，这也是它与「一把梭反编译」类工具最大的不同。
第三步：看引用与字符串（xrefs / search）
rea xrefs /absolute/path/to/hello_stripped 0x401146 --provider ghidra --json rea search /absolute/path/to/hello_stripped "source-owned" --provider ghidra --json rea search /absolute/path/to/hello_stripped "^read_" --provider ghidra --mode regex --kind procedures --jsonxrefs返回有界引用列表（调用/跳转/数据/读写/间接/条件等分类都保留原始 ReferenceManager 类型），search支持字面量与 Java 正则两种模式、可分别搜索字符串和过程名。在这个例子里，你能亲眼看到main对read_values的调用边，以及"source-owned"字符串的落点——一条从入口到数据的完整证据链就此闭环。
第四步：两条「零引擎」路径
不是每次逆向都需要启动 Ghidra。对两类常见目标，rea 提供了不需要任何反编译引擎的路径：
JavaScript/Electron 应用或 ASAR（纯静态解析）：
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json rea analyze /path/to/some/dir --json # 目录或 .asar 且未指定 --provider/--snapshot 时自动路由返回模块、导入、Electron IPC 边界及各自证据。离线 ELF 布局诊断（inspect-binary-layout，需要自带 pwntools 4.15.0 + pyelftools + Unicorn 的 Python 环境）：
REA_PWNTOOLS_PYTHON=/absolute/isolated-env/bin/python \ rea inspect-binary-layout ./hello_stripped --json它不启动任何反汇编器数据库，直接回答「这个文件里有什么」：节区/段布局、原始符号与重定位、静态链接名，以及 canary、PIE、NX、RELRO 等缓解措施的静态推断。刚才编译的binary-layout.c正是这条验证路径的官方 fixture（见 docs/binary-diagnostics.md）。
常见报错与下一步学习路径
读懂退出码
| 退出码 | 含义 |
|---|---|
0 | 操作完成——注意结果里可能仍含部分证据、警告或未解问题 |
1 | 操作未完成：输入无效、权限不足、取消、超时或其它失败（结构化输出会给出原因） |
128 + N | 进程被信号N终止 |
在管道中使用时建议打开pipefail，让下游格式化工具保留 rea 的失败状态：
set -o pipefail rea inspect-artifact ./app.asar --json | jq . > inspection.json三类高频失败及其标准解法
1. Provider 不可用或选择歧义
analyze报capability_unavailable时，看details.selection_reason：ambiguous表示多个引擎都支持该目标，需要从details.candidate_ids里显式选一个；provider_unavailable表示选中的引擎有问题。标准动作是：
rea doctor --provider ghidra --json # 替换为实际失败的引擎 ID2. Ghidra 启动超时
默认启动期限是 330000ms（约 5.5 分钟，覆盖导入+自动分析+桥接）。大二进制会超出它，此时：
export REA_GHIDRA_STARTUP_TIMEOUT_MS=9000003. 版本类错误
- Node 版本不达标：
Install Node.js 22.x (>=22.19), 24.x (>=24.11), or 26+. - 遇到疑似 bug：先
rea update（只更新 npm 安装的所有者）或npx rea-agents@latest setup刷新注册；多数近期问题已被新版修复。
另外记住一个原则：rea 对用户可见的错误信息经过专门打磨（仓库维护着一张逐条审核的 docs/user-visible-errors.csv），当它提示「Retry once; if it continues, runrea doctor」时，照做即可，不要自行猜测内部原因。
下一步：把结论变成「重建」
CLI 只是入口。当你真正想从「看懂」走到「写出来」，官方 showcase 给出了三条可复现的路径：DX-Ball 案例把一个声音定位的 pan 计算从汇编还原成 C，重建结果通过 3205 个原始 x86 用例并复现全部 63 字节编译产物；TH04 案例在 16 位 DOS 指令上恢复子弹环的角度计算并与历史编译器输出比对；Notion 案例则展示了从 Electron renderer 一路追踪到主进程 IPC 剪贴板桥的完整链路。这些案例在 README.md 中有完整记录，对应的重建仓库与验证方法也在其中。
更系统的下一步是精读三份文档：想摸清所有命令与快照/导入导出机制看 docs/cli.md；想理解 Agent 侧会话、证据与工具契约看 docs/mcp-contracts.md；想了解每个引擎的能力边界与验证责任看 docs/provider-evaluation.md。十分钟上手只是开始——rea 真正的价值，在于当你追完第一个main之后，它已经替你把「下一层」的路铺好了。
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
