没有源码也能逆向算法用 rea 把逆向分析台交给你的 Agent 的完整指南【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rearea 是一个 MCP 逆向工程服务一条命令注册到主流 agent 后agent 就能直接检视原生二进制、JavaScript/Electron 应用和 .NET 程序集并且每个结论都附带可复核的证据。它值得注意的原因是把AI 逆向从玄学变成了有证据链、可验证的工程。它到底想解决什么想象一个常见场景你看中某个应用里的功能想在自己的产品里实现类似的东西但手里只有编译好的二进制文件没有源码。传统做法是自己装 Ghidra 或 IDA从符号表里找入口一行行读反汇编再手写 C 代码去复现逻辑——熟练的人也要花上几天中途还可能因为引擎的默认分析选项不对而跑偏。更尴尬的是这个过程很难让 agent 参与进来。Hopper、Ghidra、IDA 各自有自己的启动方式和 APIJavaScript 应用要另找解包工具.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.javaHopper 侧则是一个跑在 Hopper 内部、适配其 Python API 的 bridge/hopper_bridge.py。上层还有 WASMWABT、EVM 字节码内嵌 EVMole worker、.NET 静态元数据、APKheadless 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 setupsetup 会列出支持的 agentClaude Code、Codex、Cursor、Gemini CLI、Grok Build、Windsurf 等 13 种以上供多选展示拟修改的配置路径等你批准后才写文件并且会对现有配置做备份。装完重启 agent它就自动获得了逆向工具集——不需要你手动写 MCP 配置。详细流程见 docs/installation.md。不想走 agent 也可以直接用终端例如对某个 Electron 应用目录npx -y rea-agentslatest 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 x64tshark/sigrok 相关能力也在 Linux 验证Linux 上还要求 PATH 里有 procps 兼容的ps。迭代快意味着要跟着升。版本推进很密集且存在破坏性变更官方 FAQ 的第一条建议就是遇到 bug 先rea update。合规上DISCLAIMER.md 的立场是rea 只服务于合法研究、教育、互操作、软件保存以及你拥有或被授权检查的软件授权责任在使用方。它下一步要解决什么对照 docs/roadmap.md 的优先级真正待解的问题是四个跨引擎的一致性原生架构、类型恢复和间接调用验证能否在 Hopper 与 Ghidra 之间给出可互相印证的结论而不是各说各话静态与运行时的缝合静态分析得到的应该是这样和运行时观测到的实际是这样证据如何跨应用层连接起来混淆托管代码被混淆的 .NET 程序集版本对比和原生链接还能不能给出可信结果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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
没有源码也能逆向算法用 rea 把逆向分析台交给你的 Agent 的完整指南【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rearea 是一个 MCP 逆向工程服务一条命令注册到主流 agent 后agent 就能直接检视原生二进制、JavaScript/Electron 应用和 .NET 程序集并且每个结论都附带可复核的证据。它值得注意的原因是把AI 逆向从玄学变成了有证据链、可验证的工程。它到底想解决什么想象一个常见场景你看中某个应用里的功能想在自己的产品里实现类似的东西但手里只有编译好的二进制文件没有源码。传统做法是自己装 Ghidra 或 IDA从符号表里找入口一行行读反汇编再手写 C 代码去复现逻辑——熟练的人也要花上几天中途还可能因为引擎的默认分析选项不对而跑偏。更尴尬的是这个过程很难让 agent 参与进来。Hopper、Ghidra、IDA 各自有自己的启动方式和 APIJavaScript 应用要另找解包工具.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.javaHopper 侧则是一个跑在 Hopper 内部、适配其 Python API 的 bridge/hopper_bridge.py。上层还有 WASMWABT、EVM 字节码内嵌 EVMole worker、.NET 静态元数据、APKheadless 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 setupsetup 会列出支持的 agentClaude Code、Codex、Cursor、Gemini CLI、Grok Build、Windsurf 等 13 种以上供多选展示拟修改的配置路径等你批准后才写文件并且会对现有配置做备份。装完重启 agent它就自动获得了逆向工具集——不需要你手动写 MCP 配置。详细流程见 docs/installation.md。不想走 agent 也可以直接用终端例如对某个 Electron 应用目录npx -y rea-agentslatest 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 x64tshark/sigrok 相关能力也在 Linux 验证Linux 上还要求 PATH 里有 procps 兼容的ps。迭代快意味着要跟着升。版本推进很密集且存在破坏性变更官方 FAQ 的第一条建议就是遇到 bug 先rea update。合规上DISCLAIMER.md 的立场是rea 只服务于合法研究、教育、互操作、软件保存以及你拥有或被授权检查的软件授权责任在使用方。它下一步要解决什么对照 docs/roadmap.md 的优先级真正待解的问题是四个跨引擎的一致性原生架构、类型恢复和间接调用验证能否在 Hopper 与 Ghidra 之间给出可互相印证的结论而不是各说各话静态与运行时的缝合静态分析得到的应该是这样和运行时观测到的实际是这样证据如何跨应用层连接起来混淆托管代码被混淆的 .NET 程序集版本对比和原生链接还能不能给出可信结果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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
