25 万 Star 的 REA：看上哪个功能，让 AI Agent 直接逆向过来
25 万 Star 的 REA：看上哪个功能，让 AI Agent 直接逆向过来
又双叒叕出一个爆火项目？这次它把门槛最高的手艺交给了 Agent。
你大概有过这种时刻：用一个 App，发现某个功能做得特别妙，想知道它是怎么实现的——然后发现没有源码，网上也没有现成分析，只能作罢。
传统解法叫逆向工程：把二进制丢进 IDA 或 Ghidra，读懂汇编和伪代码，再手工拼出业务逻辑。这门手艺的门槛高到什么程度？光是认全反汇编界面上的东西，就够新手啃上几个月。
REA（Reverse Engineer Anything）给出了另一种可能：把 Hopper、Ghidra、IDA 这些专业引擎包装成 MCP 接口，交给 Claude Code、Codex、Cursor 这样的 AI Agent 调用。你用自然语言问一句"这个 App 的搜索功能是怎么实现的"，Agent 自己调用工具，深入到字节码和汇编层面，带着证据链回来，再照着写一个类似的实现放进你的项目。
项目 2026 年 4 月 14 日创建，截至 10 月 15 日已经积累 254,259 Star、63,880 Fork。半年 25 万 Star，这个增速放在整个 GitHub 的历史上都算罕见。
本文提纲
- REA 是什么：一个 MCP 服务器，不是逆向平台
- 最聪明的设计：只出证据，不下结论
- 能分析什么：23 类目标，从网站到固件
- 上手：三条命令就够
- 三个 Showcase：AI 逆向的真实上限
- 冷静判断：它做不到什么
一、REA 是什么：一个 MCP 服务器，不是逆向平台
先纠正一个常见误解。REA 没有重新发明反编译引擎——那件事的工程量太大，Hopper、Ghidra、IDA 各自积累了十几年。它做的是另一件事：把这些引擎的能力标准化，暴露给 Agent。
| 项目信息 | 值 |
|---|---|
| 作者 | morluto |
| 创建时间 | 2026-04-14 |
| Star / Fork | 254,259 / 63,880（截至 2026-10-15，GitHub API 实测） |
| 语言 | TypeScript |
| 许可证 | MIT |
| npm 包 | rea-agents，当前 6.4.0 |
| 官网 | rea.tools |
理解它的定位，关键是看清这层分工：逆向分析所需的专业工具链早就存在，真正缺的是一层能让 Agent 自主调用这些工具、并把结果组织成可信证据的接口。REA 补的就是这一层。
这也解释了它为什么以 MCP 服务器的形态存在，而不是又一个逆向 GUI。2026 年的开发者日常已经泡在 Claude Code、Codex、Cursor 里，让分析能力长进 Agent 生态，比再造一个独立平台合理得多。npx rea-agents setup 一条命令，setup 会列出即将写入的改动，经你确认后才修改配置，并自动备份原有配置，目前官方支持 Claude Code、Codex、Cursor、Gemini CLI、Grok Build 等 Agent，其他客户端可以走手动 MCP 注册。
二、最聪明的设计：只出证据，不下结论
很多"AI 分析工具"的思路是让模型直接告诉你"这段代码在做什么"。问题我们都知道：模型会幻觉，而且你没法验证它没幻觉。
REA 的架构选择完全不同——它自己不下结论。Agent 通过 MCP 调用 REA，REA 返回的是发现（findings）和支撑每个发现的证据：反汇编的某几行、字符串引用、模块依赖关系。真正的推理、解释、代码生成，全部留给调用它的 Agent。
graph LR
A["You: ask about a feature"] --> B["Agent: plans the investigation"]
B --> C["REA MCP server"]
C --> D["Engines: Hopper, Ghidra, IDA, JADX, Binwalk"]
D --> E["Findings plus evidence"]
E --> F["Agent: explains, implements, tests"]
F --> G["Working code in your project"]这个分工有两层好处。一是可审查性：Agent 给出的每个结论都能追溯到具体的反汇编行，你觉得可疑就自己去核对；二是职责单一：REA 保持工具本色，不用在 prompt 里跟模型的幻觉倾向搏斗。
静态 JS 和 .NET 分析只读取你提供的文件，不运行目标；涉及运行时行为的采集（比如网站交互、进程观察）会以你当前用户权限真实运行或与目标交互，每种场景的指南都会说明具体影响范围。这个"静态优先、运行时按需"的分层，让大多数轻量分析完全不碰运行时风险。
三、能分析什么：23 类目标，从网站到固件
README 里那张分析目标表是全项目最硬核的部分。挑有代表性的几行：
| 目标 | 返回内容 | 依赖 |
|---|---|---|
| Native 二进制 | 伪代码、汇编、符号、调用关系 | Hopper / Ghidra / IDA |
| JavaScript / Electron | 模块、导入、Source Map、路由、IPC、Native 插件关系 | Node.js + npm |
| 网站 | 页面结构、脚本、网络观察、截图 | Chrome 系浏览器 |
| .NET 程序集 | 元数据、CIL 指令、声明的 Native 依赖 | 无（纯静态） |
| Android APK | Manifest、类、反编译方法、引用关系 | Headless JADX + JDK |
| Go / Rust 二进制 | 编译器版本、模块、crate 依赖 | 内置静态解析，无需安装 Go/Rust |
| EVM 字节码 | 调度选择器、字节偏移、参数推断 | Linux x64 本地离线分析 |
| 固件 | 分区、提取结果、Native 分析交接 | Binwalk / Unblob |
| 抓包文件 | 请求、响应、暴露的 Payload、来源代码位置 | HAR / Fiddler SAZ |
| SQLite 数据库 | 表、列、索引、触发器、选中行 | 本地快照 |
| 进程行为 | 终端输出、文件系统观察、运行对比 | PTY |
全部算上是 23 类，还包括 WASM、Flutter、adb 连接的真机、JEB 工程、逻辑信号录制（sigrok-cli）这些偏门场景。覆盖广度的意图很明显：一个 MCP 尽可能覆盖所有逆向场景，而不是只做某一类专精分析。安全研究者、CTF 玩家、想理解竞品的产品开发者，都能在里面找到自己要的工具。
引擎侧是可插拔的。原生二进制分析需要 Hopper、Ghidra、IDA 三选一，setup 可以在你批准后代为安装 Hopper，Ghidra 和 IDA 直接用现有安装，此外还支持调用方自备的 GNU objdump 和 Rizin。而 JS、.NET、Flutter 这类静态分析内置完整解析能力，完全不依赖第三方引擎——哪怕你没有任何逆向工具链，也能先用这部分起步。
两个实用细节：大文件分析可以调 REA_GHIDRA_STARTUP_TIMEOUT_MS 或 REA_HOPPER_STARTUP_TIMEOUT_MS 延长引擎启动时限；Windows 上的 Ghidra 支持目前还是实验性。README 有 19 种语言版本，中文读者可以直接看简体中文版。
四、上手：三条命令就够
前置要求只有一个：Node.js 22.19+、24.11+ 或 26+，外加 npm。Linux 上做 Ghidra、JADX 或固件分析，需要 PATH 里有 procps 兼容的 ps。
第一步，配置 Agent：
npx rea-agents setup第二步，用自然语言提问：
Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.把 Notes 换成你的目标应用，把 search 换成你想理解的功能。第三步，不经过 Agent 也可以直接在终端跑：
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json输出包含模块、依赖导入、Electron 进程边界和对应证据。常用的话就全局安装 rea 命令，更新用 rea update——这个项目发版很勤，遇到 bug 先更新再报 issue。
还有一个容易被忽略的细节：rea-agents 的 npm 发布走的是 GitHub Actions OIDC trusted publisher，带 SLSA provenance 签名；README 里专门警告"仓库名相似或 README 被复制不代表下载渠道官方"。火到需要防假冒仓库，这个细节比 Star 数更能说明问题。
五、三个 Showcase：AI 逆向的真实上限
rea.tools 的 showcase 页面有三个完整案例，每个都有可验证的交付物。这是我对这个项目从"怀疑"转到"认真"的关键。
DX-Ball：重建音效声像算法
从一次音效调用追进 position-to-pan 辅助函数，检视指令，把不完整的伪代码补成 C。重建结果通过了 3,205 个原始 x86 测试用例，63 个编译后函数字节完全一致。不是"差不多能用"，是二进制级别的一致。
Notion：追踪 Electron 剪贴板桥接
从 renderer 的剪贴板 API 出发，穿过 preload 和 IPC 进入 main process，看清楚富剪贴板格式怎么处理。做 Electron 开发的人应该知道这条链路有多难从外部看清。
TH04：恢复 DOS 游戏的子弹环计算
检视 PC-98 游戏的 16 位指令，恢复固定角和瞄准角的计算逻辑，再把重建的 C++ 与历史编译器输出对比。仓库 topics 里甚至有个 touhou 标签——TH04 正是东方 Project 的早期作品。
三个案例横跨 x86、Electron、16 位 DOS，共同点是有明确的事后验证手段（字节对比、指令比对），而不是"Agent 说它看懂了"。
六、冷静判断：它做不到什么
分析质量的上限取决于底层引擎。REA 不提升伪代码质量，它只是让 Agent 能驱动这些引擎——Ghidra 反编译不动的混淆代码，REA 也一样没办法。
原生分析依赖商业或重型引擎。Hopper 是商业软件，首次运行会弹 demo/激活对话框；IDA 付费且不便宜；Ghidra 免费但吃内存。很多目标类型只在 Linux 上验证过（pwntools、TShark 4.x、sigrok-cli），macOS 和 Windows 用户要先查文档确认自己的场景被支持。
运行时采集有真实副作用。静态分析不碰目标，但进程观察、网站交互这类能力会用你的用户权限真实运行目标。分析来路不明的二进制之前，先想清楚这句话的分量。
法律边界写在项目的 DISCLAIMER.md 里：合法研究、教育、互操作性、软件保护，以及分析你拥有或已获授权的软件。"看上哪个功能就让 Agent 抄过来"听起来很爽，但抄什么、抄多少，授权问题得自己把关。企业合规审计也别指望它替代专业审计公司——它是研究工具，不是合规背书。
还有一个诚实的观察：25 万 Star 的增速难免让人怀疑刷量。我查了仓库数据：907 个 open issues、多贡献者的稳定提交记录（作者 morluto 一千多次提交，N0zoM1z0 五百多次）、Trendshift 官方趋势徽章、真实可复现的 showcase——不像刷出来的样子，但 Star 数字本身参考意义有限，项目质量看 showcase 和文档就够了。
参考文档与链接
- GitHub: morluto/rea — 项目主仓库，254k Star，TypeScript，MIT
- GitHub API: repos/morluto/rea — 本文 Star/Fork/创建时间等数据的来源
- REA 官网 — 安装指南与文档入口
- DX-Ball showcase — 音效声像算法重建，3,205 用例全过
- Notion showcase — Electron 剪贴板桥接追踪
- TH04 showcase — PC-98 游戏子弹环计算恢复
- npm: rea-agents — 当前版本 6.4.0，含 SLSA provenance
- 安装与 setup 文档 — 支持的 Agent 列表与引擎配置
- N0zoM1z0/dx-ball — DX-Ball 重建仓库
- N0zoM1z0/th04 — TH04 重建仓库
- 开源项目第 235 期：REA（掘金） — 中文社区的深度测评
试过了？评论区说说你逆向了什么。还没试？收藏起来周末折腾一个。
作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
