REA：把逆向工具接到 Agent 手上之后

REA 的全名是 Reverse Engineer Anything，仓库上挂着 400,000 颗星、MIT 授权。它把散在逆向工作流里的老工具接到 AI 编程助手后面，让 Agent 自己判断什么时候该用哪一个。值不值得跟，取决于你想要的是「少点几下」，还是「真的会逆向」。

它没发明逆向，它做的是接线

官方用一句话概括自己：一个 MCP 服务，覆盖二进制、应用与运行时行为。翻成中文就是——原生程序、JS/Electron 应用、.NET 程序集、网站，都能从同一个入口查。

关键在动词。它不是新的反编译器，也不是新的分析引擎，而是把 Hopper、Ghidra、IDA、Kuna 这些早就在用的工具包装成 Agent 能调的接口，再补一层「什么情况该用什么工具」的流程说明。

换句话说，它卖的是调度，不是算法。

能碰的目标有四类，但成本完全不一样。静态的 JS 与 .NET 分析只读文件、不运行程序；运行时捕获则要真把应用跑起来，才能观察行为。

原生二进制那条最重：先配好 provider，Linux 上还要 Ghidra、JADX 和固件工具能正常启动，依赖一个 procps 兼容的 ps 出现在 PATH 里。任一条不满足，那条路就是断的。

安装确实只有一条：npx rea-agents setup。它往你的 Agent 里写 MCP server 配置和配套的工作流说明，覆盖 Claude Code、Codex、Cursor、Gemini CLI、Grok Build 等，改动前会备份原配置。

但装完不等于能跑。第一次做原生分析时，它会下载 Ghidra；为了跑 Ghidra，还要再拉一套 JDK。点按钮的那一刻，并不知道这些在后台发生。

另一个容易忽略的是上下文成本。工具接口很多，全挂上会吃掉大量 context：慢、贵，而且容易让模型分心去调不该调的工具。README 给了压缩方案，也就是用环境变量切换紧凑的输入 schema，默认就开着。

有位 UP 主做了个很干净的对照：用 C 写一个 7 + 5 = 12 的加法程序，编译成 a.out，删掉源码，再让装了 REA 的 Agent 还原成 C。

结果几乎一模一样。打开工具调用看，过程是三步：先用 file 认出这是 macOS 上的 64 位 arm 可执行文件；再用 Ghidra 反编译出接近源码的伪代码；最后让大模型整理成好读的 C。

三步里，前两步是用了二十年的老工具，第三步是语言模型。REA 的贡献在第零步——让 Agent 知道这三步该怎么串起来，以及每步的输出该怎么读。

Ghidra 反出来的名字通常是 param_1、param_2，Agent 交回来的却是 a、b、result。看上去像「把原始变量名读回来了」。

那位 UP 主又做了一次对照：故意改掉源码里的变量名，加些无用代码，重新编译。Agent 还原出来的还是 a、b、result 这类常见命名。

结论挺清楚：编译之后名字本来就会丢，模型是在根据程序行为猜一个「人类常写」的名字。读起来舒服，但这不是从二进制里读回来的事实。凡是把这类命名当证据的评测，结论都站不住。

已经会 Ghidra 或 IDA 的人，收益可能是负的：多一层等待、多一份输出要读、多一套配置要维护。原本点两下就能看的东西，现在要先说服一个模型去点。

真正的受益者是另一批人——知道自己想搞清楚什么、但不会读汇编的人。问一句「这个功能是怎么触发的」，拿回一份带证据的报告，比从零学 Ghidra 快得多。

还有批量场景：同一套流程要跑几十个样本时，把排期交给 Agent 比人肉重复点界面划算。

不能。它调用 Ghidra。Ghidra 缺席时，原生分析那条路直接走不通；而它给出的每条结论，最终证据仍落在 Ghidra 的输出上。

REA 值得看的不是「逆向一切」这个口号，而是它示范了一件事：把专业工具的调用顺序写成 Agent 能执行的流程，比重新训练一个模型见效快得多。至于 400,000 颗星里有多少是冲着「两句话拆软件」来的，那部分期待多半会落空。胖桃AI 的开发效率栏目里也收过几款同类工具，可以放在一起对照。

文章版权归作者所有，未经允许请勿转载。