Rea：让 AI Agent 逆向任意程序的取证框架

它解决的不是“能不能逆”，而是“逆完之后怎么信”

逆向工程从来不难在工具，难在证据链。

一个反编译器能吐出伪代码，但伪代码为什么可信？

一段汇编能定位到符号，但符号是否被混淆？

安全研究者面对闭源程序时，真正耗时的不是跑工具，而是把工具输出变成可验证的结论。

Rea 的设计目标就是把这个过程交给 AI Agent。

它不承诺“自动破解一切”，而是让 agent 调用一组本地分析工具，拿到带出处和局限性的发现。

README 里反复出现一个词：evidence。

每个结论都要求附带证据，每个证据都要求标注局限。

这意味着 Rea 的产出不是一份分析报告，而是一组可追问、可复核的中间产物。

Agent 可以基于这些产物继续提问，也可以直接写代码复刻某个功能。

工具矩阵的取舍：静态优先，运行态靠后

Rea 支持的目标类型极广，从桌面安装目录到 EVM 字节码，从 SQLite 数据库到 Apple IPS 崩溃日志。

但仔细看需求列，会发现一个清晰的分层策略。

大约一半的分析能力是“内置静态检查”，不需要安装任何第三方引擎。

Go 二进制、Rust 二进制、PE 证书、ELF notes、IL2CPP 元数据、Godot PCK、PyInstaller 可执行文件，全部走内置解析。

这些目标的特点是格式相对稳定，解析逻辑可以写成确定性的 TypeScript 代码。

另一半则需要调用外部工具：Hopper、Ghidra、IDA 做原生反汇编，JADX 做 APK 反编译，pwntools 做 ELF 布局分析，WABT 做 WASM 解码。

这些工具的输出质量高，但引入安装成本和版本依赖。

比如 WASM 分析要求 WABT 精确到 1.0.42，Linux 上的固件提取要求 Binwalk 或 Unblob，Ghidra/JADX 还需要 procps 兼容的 ps 命令做进程归属检查。

这种设计暴露了一个工程判断：能自己解析的就不依赖外部程序，能静态分析的就不运行目标。

因为静态分析可复现、无副作用，运行态分析则有权限和环境污染问题。

代价是格式覆盖有限，遇到未知加壳或自定义修改的目标，内置解析可能直接失效。

Linux 的“ps 依赖”不是小事

README 在 Quick start 之前专门加了一个 IMPORTANT 块，警告用户不要从仿冒仓库下载。

紧接着 Quick start 的第一段，又单独强调 Linux 上需要 procps 兼容的 ps 命令。

这两个细节放在一起，能看出 Rea 对“进程归属”这件事的谨慎程度。

Ghidra、JADX、固件工具启动前，Rea 要检查进程归属，防止分析工具以错误权限运行。

这不是性能优化，是安全边界。

如果 ps 不在 PATH 上，分析直接失败，而不是降级运行。

文档给出的恢复步骤在 docs/installation.md 的“Linux owned-process prerequisite”一节，说明这是已知的安装门槛，不是偶发 bug。

对开发者来说，这个设计意味着 Linux 环境不能只装 Node.js 和 npm，还得确认 procps 包存在。

对安全研究者来说，这个检查恰好说明 Rea 的作者理解本地逆向工具的权限风险。

MCP 的紧凑输入模式：为上下文窗口省钱

Rea 通过 MCP 暴露给 Claude Code、Codex、Cursor、Gemini CLI 等 agent。

MCP 默认使用 compact input schemas，目的是减少上下文开销。

需要完整字段说明和嵌套校验时，可以设置 REA_MCP_INPUT_SCHEMA_PROFILE=full。

这个设计很务实。

工具数量多、参数复杂时，完整 schema 会吃掉大量 token，影响 agent 的推理空间。

紧凑模式保留完整工具集和服务端校验，只是砍掉中间层的描述文本。

代价是 agent 可能看不到某些参数的详细约束，需要切到 full 模式排查问题。

另一个值得注意的细节是更新机制。

rea update 命令保留最多 4 MiB 的 stdout 和 stderr，超出后拒绝元数据回复。

这不是随手的限制，而是防止更新过程中的海量日志把 agent 的上下文冲垮。

Verbose 安装继续运行，但诊断信息被截断。

这说明作者对“工具输出不可控”这件事有实际经验。

运行态分析的代价：你的权限就是它的权限

Rea 的能力表里有一条容易忽略的说明：静态 JavaScript 和 .NET 检查只读文件，不运行应用。

而运行时捕获会“使用你的用户权限运行或交互目标”。

每个运行时指南都描述了自己的影响。

这意味着 Rea 的行为边界取决于调用者。

如果 agent 要求分析一个恶意 APK，而用户批准了运行时捕获，那么恶意代码会以用户权限执行。

文档没有试图隐藏这一点，反而在能力表下方明确写出。

这和其他逆向框架形成对比。

很多工具默认在沙箱里跑，Rea 默认在本地跑，沙箱化是用户的额外工作。

好处是分析结果更接近真实环境，坏处是误操作的成本直接落在用户身上。

对于安全研究者来说，这未必是缺点，因为沙箱本身也会改变程序行为。

但普通开发者如果只是想“看看某个应用怎么实现搜索功能”，需要先理解这个前提。

边界与判断

Rea 的强项是证据链和 agent 集成，不是分析深度。

它依赖 Hopper、Ghidra、IDA 做原生反汇编，依赖 JADX 做 APK 反编译。

如果这些外部工具本身有局限，Rea 不会自动补齐。

它适合的场景是：你有一个明确的逆向目标，愿意接受本地工具链的安装成本，并且需要把分析过程变成可复用的 agent 工作流。

不适合的场景是：你只想点一下按钮就得到结论，或者目标经过了重度混淆和自定义修改。

综合判断：Rea 是一个认真对待证据和权限的逆向 Agent 框架，但它的价值高度依赖调用者对逆向工程本身的理解。

建议先读一遍它的 CLI 和 Evidence 指南，再用一个你知道答案的目标做一次完整分析，验证证据链是否符合你的预期。