企业官网建设流程全解析

没有源码也能逆向算法？用 rea 把逆向分析台交给你的 Agent 的完整指南

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea

rea 是一个 MCP 逆向工程服务，一条命令注册到主流 agent 后，agent 就能直接检视原生二进制、JavaScript/Electron 应用和 .NET 程序集，并且每个结论都附带可复核的证据。它值得注意的原因，是把"AI 逆向"从玄学变成了有证据链、可验证的工程。

它到底想解决什么

想象一个常见场景：你看中某个应用里的功能，想在自己的产品里实现类似的东西，但手里只有编译好的二进制文件，没有源码。传统做法是自己装 Ghidra 或 IDA，从符号表里找入口，一行行读反汇编，再手写 C 代码去复现逻辑——熟练的人也要花上几天，中途还可能因为引擎的默认分析选项不对而跑偏。

更尴尬的是，这个过程很难让 agent 参与进来。Hopper、Ghidra、IDA 各自有自己的启动方式和 API，JavaScript 应用要另找解包工具，.NET 又要另一套静态分析器。你被迫在多个工具之间当人肉胶水。

rea 的切入点就一句话：把这些引擎统一挂在一个 MCP 服务后面，让你的 agent 来当那个"问问题的人"。agent 提出"这个功能是怎么实现的"，rea 负责启动引擎、执行检视、追踪引用，然后把伪代码、引用关系和未知项打包回传；agent 再用这些材料去解释行为、写出实现并测试。这条回路在 docs/mcp-prompts.md 里被固化成了六个引导式工作流，比如investigate_feature和verify_reconstruction。

拆开看它是怎么做到的

一个 MCP 接口，挂着一整套分析引擎

可以把它理解成"侦探与法医实验室"的关系：agent 是办案的侦探，Hopper、Ghidra、IDA 是实验室里各自为政的法医，而 rea 的 bridge 层就是翻译——它把统一的操作请求转成每个引擎自己的 API 调用。

具体到代码，这套桥接是真实存在的独立模块：Ghidra 侧打包了一个 JavaHeadlessScript（见 bridge/ghidra/ReaGhidraBridge.java），Hopper 侧则是一个跑在 Hopper 内部、适配其 Python API 的 bridge/hopper_bridge.py。上层还有 WASM（WABT）、EVM 字节码（内嵌 EVMole worker）、.NET 静态元数据、APK（headless JADX）、固件（Binwalk/Unblob）、浏览器运行时（CDP 捕获）等一大堆 provider，全景结构见 docs/architecture.mermaid。

值得注意的是选择策略：provider 注册表按确定规则排序并一次性选定，不做静默 fallback。引擎要么能分析就明确地分析，要么明确报错，不会"换个引擎假装成功"。这种设计对 agent 很重要——它拿到的每次结果都来自一个可指认的来源。

证据链：每个结论都要"交账"

AI 逆向工具最大的信任问题是"结果无法验证"：模型说函数是干这个的，你拿什么反驳？rea 的答案是把 Evidence（证据）、Limitations（限制）、Unknowns（未知）当作一等公民，和结论本身一起返回。

再往深一层，它有一个"重建义务账本"（reconstruction obligation ledger），实现在 src/application/。思路类似实验室报告的 chain of custody：当你声称"我重建了某个功能"，账本会逐条列出每个义务（obligation）——必须有唯一的 owner、所需的测试夹具、以及一个与原始观察权限相当的验证器通过，这条义务才算关闭；矛盾、重复定义、残留未知项都会让它保持"未关闭"或"失败"状态。账本本身通过ledger_id和closure_digest保证完整性（见 docs/reconstruction-obligation-ledgers.md）。简单说：没有证据的结论进不了账本，进不了账本就不算数。

谁在用、怎么用起来

一条命令接入 Agent 的完整步骤

前置条件只有 Node.js 22.19+ / 24.11+ / 26+ 和 npm，然后：

npx rea-agents setup

setup 会列出支持的 agent（Claude Code、Codex、Cursor、Gemini CLI、Grok Build、Windsurf 等 13 种以上）供多选，展示拟修改的配置路径，等你批准后才写文件，并且会对现有配置做备份。装完重启 agent，它就自动获得了逆向工具集——不需要你手动写 MCP 配置。详细流程见 docs/installation.md。

不想走 agent 也可以直接用终端，例如对某个 Electron 应用目录：

npx -y rea-agents@latest analyze-javascript-application /path/to/app --json

结果包含模块、导入关系、Electron 边界及其证据。静态 JavaScript 和 .NET 分析走的是纯文件读取，不需要任何原生分析引擎，这是零门槛的上手路径。

案例里有硬指标

README 的 Showcases 给出的三个案例都带可复现的数字：

• DX-Ball：从 x86 反汇编里重建音量-声像（sound-pan）计算函数，重建后的 C 代码通过了 3,205 个原始 x86 用例，并逐字节还原了全部 63 字节编译后的函数体；
• Notion：追踪 Electron 剪贴板 API 从 renderer 经 preload、IPC 进入 main 进程的完整链路；
• TH04：从 16 位 DOS 指令中恢复弹幕环的角度计算，并把重建的 C++ 与当年历史编译器的输出对照。

"3,205 个用例通过"和"63 字节精确还原"这类指标的意义在于：你不需要相信宣传，可以拿同一个标准去验证自己的目标。

冷静一点：它的边界在哪

• 深度原生分析仍然依赖商业或开源引擎。Hopper/Ghidra/IDA 三选一，而且 rea 不替你解决授权问题——README 的 License 章节明确写着必须合法获得商业工具许可，破解、盗 key、绕过许可限制都不被允许。静态 JS 路径没这个门槛，深度二进制分析有。
• Windows 还是实验性边界。docs/windows-ghidra-p0.md 定义的 P0 只覆盖 Windows 10+ x64 的只读场景：26 个 Ghidra 只读操作，目标是原生 x86/x64/ARM PE 或 raw 6502 镜像；Ghidra GUI 状态、注解、其他架构都不可用。它自己强调"这不构成 Windows 全面功能对等"。
• 部分能力绑定特定平台。基于 pwntools 的离线 ELF 布局分析限 Linux x64，tshark/sigrok 相关能力也在 Linux 验证，Linux 上还要求 PATH 里有 procps 兼容的ps。
• 迭代快，意味着要跟着升。版本推进很密集且存在破坏性变更，官方 FAQ 的第一条建议就是"遇到 bug 先rea update"。

合规上，DISCLAIMER.md 的立场是：rea 只服务于合法研究、教育、互操作、软件保存，以及你拥有或被授权检查的软件；授权责任在使用方。

它下一步要解决什么

对照 docs/roadmap.md 的优先级，真正待解的问题是四个：

1. 跨引擎的一致性：原生架构、类型恢复和间接调用验证，能否在 Hopper 与 Ghidra 之间给出可互相印证的结论，而不是各说各话？
2. 静态与运行时的缝合：静态分析得到的"应该是这样"和运行时观测到的"实际是这样"，证据如何跨应用层连接起来？
3. 混淆托管代码：被混淆的 .NET 程序集，版本对比和原生链接还能不能给出可信结果？
4. provider 的取舍：何时引入新引擎？roadmap 给了明确标准——只有当某个分析工作流暴露出真实的能力缺口，且新能力能通过共享 CLI/MCP 工作流返回可用证据时，才值得接入。

结论：什么时候值得试 rea

如果你的目标是"读懂并复刻某个没有源码的应用行为"，尤其是 JavaScript/Electron 应用——零引擎、一条命令、结论带证据，这是当前最顺滑的路径。如果你已经合法持有 Ghidra 或 Hopper，想把逆向工作流交给 agent 而不是自己坐在引擎前，rea 的 MCP 接入和证据账本也值得跑一遍。反过来，如果你只需要一次性的轻量反编译，或者目标平台还在它的实验边界之外，先看看 Windows P0 文档再决定。对一个把"可验证"写进架构的项目来说，最好的判断方式就是拿你自己的目标当第一个案例。

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea