REA：让智能体从应用到二进制调查软件行为
一个把MCP智能体接到Hopper、Ghidra和应用运行时的本地逆向工具，边调查边给证据和限制。
GitHub morluto/rea 更新 2026-10-07 分支 main 星标 9.5K 分叉 1.0K
TypeScript JavaScript 逆向工程 MCP Hopper Ghidra 本地分析

🧭 决策指南

为什么现在热： README把REA描述为连接AI agent、MCP、CLI与Hopper/Ghidra等逆向工具的本地调查工作流，并强调可从应用行为追到二进制、同时输出证据和限制；结合当日新增2,956颗星、总星数9,457及最新rea-agents v4.1.0，这些是当前受关注的明确材料，但无法仅凭材料确认具体传播原因。

适合，如果你

  • 你要从JavaScript或Electron应用树、ASAR中获得代码图和证据
    README「First result from the terminal」提供analyze-javascript-application命令，并说明返回Evidence、recovered graph、limitations和unknowns。
  • 你的AI coding assistant支持MCP，并希望在同一会话中调查后重建功能
    README「Why REA」和「The investigation model」分别说明MCP接入，以及Decompile、Understand、Recreate流程。
  • 你希望应用样本留在本机，不上传到托管分析服务
    README「Why REA」的Local by design明确写明Analysis runs locally，且不会上传应用。
  • 你已有Hopper、Ghidra或IDA，并需要原生二进制分析
    README「How it works」列出Hopper provider、Ghidra provider和IDA MCP provider；Quick start说明可记录现有Ghidra安装。

不适合，如果你

  • 你需要REA直接恢复原始源码或自动克隆完整应用
    README「The investigation model」明确写明REA不声称恢复original source code，也不自动clone application。
  • 你要分析运行时JavaScript行为，但只准备使用静态分析命令
    README「Security model」说明静态JavaScript分析不执行extracted modules，运行时行为应使用browser、Electron或process capture。
  • 你的Windows目标不是本地NTFS上的x86-64 PE应用
    README「Security model」将Windows Ghidra P0的experimental scope限定为local NTFS上的native x86-64 PE applications。
  • 你不能授予macOS Accessibility或Screen Recording权限，却需要原生UI捕获
    README「Security model」说明native UI capture依赖macOS Accessibility和Screen Recording access。

前置条件

  • 运行安装器前需要已有Node.js和npm；README「Install the rea command」原文为“It requires Node.js and npm to be installed already.”
  • JavaScript/Electron首个分析命令要求目标是“extracted JavaScript/Electron application tree or ASAR”。
  • 原生分析需要先配置analysis engine；README点名Hopper、Ghidra和IDA provider。
  • Linux Hopper demo需要Xvfb、Python 3、X11和XTEST；README说明approved setup会安装这些依赖。
  • macOS原生UI捕获需要Accessibility和Screen Recording权限。

第一步命令（README 原文）

npx rea-agents setup

要注意

  • curl安装后可能需要把~/.local/bin加入shell PATH。
    README「Linux installation and troubleshooting」明确提到curl installer场景。
  • Hopper路径异常时需设置HOPPER_LAUNCHER_PATH并运行rea doctor --json。
    README「Linux installation and troubleshooting」给出了环境变量和doctor命令。
  • Linux Hopper启动器默认路径是/opt/hopper/bin/Hopper。
    README「Linux installation and troubleshooting」列出Linux默认HOPPER_LAUNCHER_PATH。
  • REA不会自动替你决定所有运行时风险，工具和目标按用户权限运行。
    README「Security model」说明analysis tools和launched targets使用用户权限。

替代方案

  • Hopper：已有Hopper安装并希望使用REA的原生分析provider时更直接。
    Quick start；How it works
  • Ghidra：需要使用Ghidra inventory、function analysis和annotations能力时更合适。
    How it works
  • IDA MCP provider：已有IDA GUI或owned headless database，并希望接入上游MCP生命周期时更合适。
    How it works

材料未说明

  • README被省略的Requirements章节未提供完整操作系统、Node.js版本和支持的agent清单。
  • Current status章节未提供各provider的完整成熟度、稳定性或已知缺陷。
  • 材料没有给出Hopper、Ghidra、IDA、CDP和JADX各自的性能数据或大型样本耗时。
  • 材料没有说明Windows以外平台对Native macOS provider、Android JADX adapter和Firmware providers的具体兼容矩阵。
  • 材料没有说明agent模型名称、上下文限制或不同AI coding assistant的功能差异。
  • 材料没有给出5个版本和最新rea-agents v4.1.0之间的发布时间、变更内容或升级兼容性。

💡 深度解析

6
适合 我维护一个 Electron 应用，手里只有抽取后的 ASAR 和应用目录，也没有 Hopper 或 Ghidra；我能否先用 REA 静态追踪搜索或登录功能，而不执行被分析的 JavaScript 模块？
适合读者： 维护 Electron 应用、只有抽取后的 ASAR 和应用目录、没有 Hopper 或 Ghidra 的 TypeScript/JavaScript 工程师

适合：这是 README 明确支持的低依赖入口，静态 JavaScript/Electron 分析不要求 Hopper 或 Ghidra，也不会执行被分析模块。

  • 工具目录和当前能力覆盖 JavaScript、Electron 以及抽取后的应用目录或 ASAR。
  • README 明确说明静态 JavaScript 分析 needs neither engine，因此没有原生反编译器不构成启动阻碍。
  • 这种方式适合先定位字符串、模块关系和代码线索；如果问题依赖真实网络、用户操作或 Electron 运行时状态，就必须转向 CDP 或 Node/Electron V8 Inspector。
  • 输出仍是证据、推断和限制，不是原始源码的保证。
  • Quick start："Static JavaScript analysis needs neither engine."
  • How it works："Artifact graph provider"、"Browser CDP provider"
  • Current status / Tool catalog：JavaScript/Electron 静态分析可针对抽取后的应用目录或 ASAR
  • The investigation model："Decompile / Understand / Recreate"
npx rea-agents setup
材料未说明：节选未给出 analyze-javascript-application 的完整命令格式。；未说明该 Electron 版本、ASAR 是否完整，以及代码是否经过混淆或动态加载。
适合 我使用支持 MCP 的 AI coding agent，想围绕同一个闭源应用连续调查“搜索”功能，再把理解结果改写到自己的 TypeScript 产品中；REA 是否比每次单独运行 CLI 更合适？
适合读者： 使用 AI coding agent、希望通过 MCP 连续调查闭源应用功能并在自己的 TypeScript 栈中复现的软件工程师

适合：你的需求正对应 REA 的 MCP 持久会话和 Decompile–Understand–Recreate 工作流，但它提供的是实现线索，不是闭源代码复制。

  • README 说明 MCP session 可以保留活动目标和 evidence ledger，连续追踪搜索入口、调用关系和运行时观察时不必每次重新建立目标。
  • CLI 与 MCP 使用同一套 application workflows 和 evidence contracts，因此 agent 与终端结果具有共同输出契约。
  • Recreate 阶段会把理解结果适配到自己的 stack、interface 和 requirements；README 明确不声称自动克隆应用。
  • agent 必须支持 MCP 工具调用、会话上下文和配置格式，实际连续性仍取决于所用 agent。
  • The investigation model："Decompile / Understand / Recreate"
  • Why REA："Keeps context"、"From insight to code"
  • How it works："an MCP session can retain an active target and evidence ledger for the session"
  • The investigation model："It does not claim to recover original source code or automatically clone an application."
npx rea-agents setup
材料未说明：节选未列出你的具体 agent 是否已验证支持 REA 的 MCP 配置和持久会话。；未说明 REA 如何处理远程服务端逻辑、登录凭据或搜索索引等应用外部依赖。
适合 我同时处理 Android 应用和固件样本，现有流程依赖 headless JADX、Binwalk 和 Unblob；REA 能否把这些 provider 接入同一个 agent 调查，而不是只支持 Hopper 或 Ghidra？
适合读者： 需要分析 Android APK 和固件文件、希望继续使用 JADX、Binwalk 或 Unblob 而不是更换整套工具的逆向研究人员

适合：REA 的 provider 架构并不局限于 Hopper 或 Ghidra，README 明确列出了 Android JADX 以及 Binwalk/Unblob 固件适配器。

  • 架构图包含 Android static provider，并标注为 headless JADX adapter；固件部分包含 Binwalk / Unblob adapters。
  • provider registry 按能力声明和确定性选择后端，适合让同一调查入口覆盖不同目标类型。
  • CLI 与 MCP 共享工作流和证据契约，因此 Android 的代码线索与固件文件系统发现可以用统一格式返回。
  • 但这不代表所有样本都能被完整还原；格式识别、加密、压缩、架构和后端工具状态仍会限制结果。
  • How it works："Android static provider headless JADX adapter"
  • How it works："Firmware providers Binwalk / Unblob adapters"
  • How it works："A provider declares which capabilities it supports"
  • How it works："The CLI and MCP server use the same application workflows and evidence contracts."
npx rea-agents setup
材料未说明：节选未说明 JADX、Binwalk、Unblob 的最低版本和对具体 APK/固件格式的覆盖范围。；未说明加密固件、定制容器或拆分 APK 是否有专门处理流程。
视情况 我处理企业专有二进制，不能把样本发到云端，而且工作站上的 agent 配置必须在修改前审查；REA 的本地优先架构和 setup 流程是否满足这两个约束？
适合读者： 在企业工作站处理敏感闭源应用、要求本地运行并审查 agent 配置变更的安全研究人员

视情况：REA 满足本地分析和变更预览这两个产品层面要求，但不能替代企业对目标程序、第三方分析器和权限的安全审查。

  • README 明确写明 Analysis runs locally，且不会把应用上传到 hosted analysis service。
  • setup 会在应用前展示 exact paths and changes，并备份现有配置；Hopper 安装另有独立 consent。
  • doctor 可检查 agent、分析引擎、路径和部分运行环境，适合发现配置缺口。
  • 另一方面，目标程序和分析器通常以当前用户权限运行；本地执行不等于没有文件、网络、进程或系统副作用，且授权与许可边界仍由组织负责。
  • Quick start："Analysis runs locally"、"REA does not upload the app to a hosted analysis service."
  • Quick start："Choose which supported agents should use REA, then review the exact paths and changes before approving."
  • Quick start："Setup shows its changes before applying them and backs up existing configuration."
  • Security model / Usage limitations：目标软件通常以当前用户权限运行，本地执行仍可能产生系统副作用
npx rea-agents setup
材料未说明：README 节选未说明企业代理、离线环境、终端防护软件和网络隔离对 setup 或 provider 的影响。；未说明所有第三方分析器是否都提供与组织政策相符的许可和审计能力。
视情况 我在 Windows 上分析本地 NTFS 中的原生 x86-64 PE 应用，已经有 Ghidra，但样本不能上传到托管分析服务；REA 能否把静态分析和后续证据整理放进同一个 agent 会话？
适合读者： 在 Windows 上分析本地原生 x86-64 PE 应用、已有 Ghidra 但不想把样本上传云端的逆向工程人员

视情况：REA 适合做本地编排和证据串联，但 Windows 上的 Ghidra 支持范围与环境要求必须先满足。

  • README 的架构包含 Ghidra provider、目标绑定 session router 和 evidence ledger；MCP 会话可以保留活动目标与证据上下文。
  • README 明确分析在本地运行，REA 不会把应用上传到托管分析服务，符合样本留在本机的约束。
  • 文档把 Windows Ghidra 支持限定在本地 NTFS 的原生 x86-64 PE 应用，并标为实验性范围，不能直接视为通用 PE 支持。
  • 结论质量仍取决于 Ghidra、符号信息和样本本身；REA 不声称恢复原始源代码。
  • How it works："an MCP session can retain an active target and evidence ledger for the session"
  • Quick start："Analysis runs locally, and results include the evidence and limitations behind each conclusion."
  • Ghidra analysis provider / Current status：Windows Ghidra 支持主要面向本地 NTFS 上的原生 x86-64 PE 应用，且为实验性支持
  • The investigation model："It does not claim to recover original source code"
npx rea-agents setup
材料未说明：README 节选未说明你的 Ghidra 版本、Java 运行时和具体 Windows 版本是否兼容。；未说明目标是否存在加壳、混淆、反调试或动态生成代码。
视情况 我不能只看 Electron 的静态 JavaScript 图：我需要观察 Node 模块在真实运行时如何处理用户输入和网络状态。REA 的 V8 Inspector 和证据会话是否适合这个约束？
适合读者： 需要确认 Electron/Node 实际运行时行为、同时维护 TypeScript 实现的应用工程师

视情况：REA 提供了对应的 Electron/Node V8 Inspector，但运行时观察需要目标真正启动并接受调试连接，不能只依赖静态分析。

  • README 架构列出 Node and Electron V8 Inspector，且把静态 Artifact graph 与运行时观察分开，适合区分代码线索和实际行为。
  • MCP session 能保留活动目标与 evidence ledger，适合把运行时观察接回同一调查。
  • 运行目标可能受权限、网络依赖、沙箱、反调试或崩溃影响；目标进程通常以当前用户权限运行。
  • 如果行为来自服务端响应或未覆盖的动态加载，README 没有保证 Inspector 能完整解释它。
  • How it works："Node and Electron V8 Inspector observation"
  • How it works："The CLI and MCP server use the same application workflows and evidence contracts."
  • Common pitfalls：静态 JavaScript 不执行代码，需要运行时观察真实行为
  • Usage limitations：运行时观察可能受权限、反调试机制、沙箱、网络依赖和目标崩溃影响
npx rea-agents setup
材料未说明：节选未说明目标 Electron/Node 版本、调试端口发现方式和 Inspector 对具体打包方式的兼容范围。；未说明网络请求是否能在你的测试环境中重现。

✨ 核心亮点

  • MCP与CLI共享同一套逆向调查工作流
  • JavaScript分析无需Hopper、Ghidra或执行应用
  • 输出Evidence、恢复图、限制与unknowns
  • 支持Hopper、Ghidra、IDA与浏览器CDP
  • Windows Ghidra P0仅覆盖本地NTFS的x86-64 PE

🔧 工程化

  • 用npx分析JavaScript或Electron应用并返回证据
  • 通过REA调查模型完成反编译、理解与重建
  • 以Target-bound session保留目标与evidence ledger

⚠️ 风险

  • 原生分析需配置Hopper、Ghidra或IDA分析引擎
  • 静态JavaScript分析不会执行模块，运行时需CDP或进程捕获
  • macOS原生UI捕获依赖Accessibility与Screen Recording权限
  • 分析工具按用户权限运行，目标生命周期仍会产生运行时影响

👥 适合谁？

  • 需要调查JavaScript、Electron或原生二进制行为的开发者
  • 已使用AI coding assistant并希望接入MCP工作流的团队
  • 拥有Hopper、Ghidra或IDA环境的逆向工程人员