← 返回列表
✓ 可直接安装
让智能体逆向分析应用功能并重建实现
自动检查通过:npm 包已发布且 engines 声明满足基线(声明 Node ^22.19.0 || >=24.11.0);该结论来自程序自动检查,未经人工实机验证。 · 最近上游提交 2026/9/8 · 已提供中文文档
使用智能体对任何事物进行逆向工程,从应用行为一直到原生二进制文件。
综合分
66.8
GitHub 分
66.8
用户评分
—
★ Stars
398
周下载量
—
兼容 / 相关生态插件(非 dsh 原生,请按其对应运行时安装)
git clone https://github.com/morluto/rea.git🟢实装验证通过· 2026/9/17
由 dsh-plugin-verify(GitHub Actions)在真实 dsh 环境安装成功,非静态推断。
数据截至 2026/9/8(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
安装兼容性检查✓ 自动检查通过
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出,未做人工实机验证——能装不等于用着没问题。
✓npm 包rea-agents @ 3.1.0
✓Node 引擎要求 ^22.19.0 || >=24.11.0 · 基线 Node 22.19 满足
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
验证方式:npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/16 16:51:30
用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
English · 简体中文 · 日本語 · 한국어 · العربية
REA: Reverse Engineer Anything
用智能体逆向工程任何东西,从应用行为一直到原生二进制文件。
看到一个你喜欢的功能。理解它如何工作,直到二进制层面。
npm version
CI
MCP tool catalog
Node.js 22+
MIT license
快速开始 · 当前状态 · 调查模型 · 工具目录 · 路线图 · 工作原理
npm install --global rea-agents && rea setup
在某个应用中看到一个你想在自己产品中拥有的功能?把该应用交给你的智能体——即使没有源代码也可以。借助 REA,智能体可以调查该功能,解释其工作原理,展示其证据,并构建一个适配你的技术栈和需求的版本。
REA 为智能体提供了一种一致的方式来调查软件。目前,这包括通过 Hopper 进行深度原生分析和函数档案,或在 Linux 上自带 Ghidra,此外还有一个实验性的 Windows x64 Ghidra P0,用于经批准的原生 PE 应用程序;无需执行的托管 PE/CLI 分类;可复现的 Evidence v2 记录;受控的进程捕获;被动的网站、Electron 页面和 Node/Electron V8 Inspector 观察;有界的 JavaScript/source-map 重建;以及一个版本化的领域图,用于连接 JavaScript 应用层,同时不会将静态推断与运行时观察混为一谈。更长期的工具包会将同样的智能体工作流扩展到 API、协议、移动工件、固件、更丰富的运行时行为以及版本之间的差异。
逆向工程通常会让操作者选择工具、学习其 API、在程序之间移动证据,并决定下一步检查什么。REA 通过命令、技能、结构化结果和可重复的调查工作流,将这项工作交给智能体。
只需询问你的智能体
运行一次 setup。智能体集成会同时安装一个对齐的 MCP 注册和
捆绑的路由技能:
npx rea-agents setup
然后询问:
理解 Notes 应用中的搜索是如何工作的,向我展示证据,并为我的项目构建一个类似的功能。
Notes 只是一个示例。你可以说出任何你想了解的应用,或者让 agent 从概览开始。
调查模型
反编译
打开一个应用,恢复可读的代码、字符串、名称以及其他关于其工作原理的线索。
理解
沿着代码从应用的一个部分追踪到另一个部分,直到 agent 能够解释某个功能实际是如何工作的。
重建
将 agent 学到的内容转化为你自己产品的功能,并适配你的技术栈、界面和需求。
REA 会展示它是如何得出结论的。它并不声称能够恢复原始源代码或自动克隆一个应用。
为什么选择 REA
| | |
| ------------------------ | ----------------------------------------------------------------------------------------------------- |
| 为 agent 而构建 | 询问某个应用做什么,让你的 agent 去检查它,而不是靠猜测。 |
| CLI 和 MCP | 从你的终端或 agent 运行相同的逆向工程能力。 |
| 处理复杂性 | REA 在幕后安装并管理逆向工程工具。 |
| 从洞察到代码 | 理解一个功能,然后在同一次编码会话中构建你自己的版本。 |
| 本地优先设计 | 分析在你支持的本地主机上运行。REA 不会将该应用上传到托管分析服务。 |
| 保留上下文 | 调查多个应用,而无需为每个问题重新开始。 |
快速开始
运行安装程序 — 推荐
npx --yes rea-agents@latest setup
当显示 npm 包运行器提示时,它表示批准为本次调用下载 REA;它并不批准任何安装更改。REA 向导会单独展示其完整计划,并在应用之前询问。安装程序不会更新 Homebrew、Node.js 或 npm。安装命令会先说明它所支持的工作:从 agent 调查本地应用、通过深度分析提供程序恢复证据,以及复用 REA 的引导式工作流。它会汇总检测到的 agent,然后询问要设置哪些能力:agent 集成(MCP 加上匹配的引导式工作流),以及在需要时设置 Hopper 提供程序。没有任何内容会被预先选中。选择 agent 集成会打开第二个空白清单,用于选择应接收注册的特定已检测 agent。
@latest 使所请求的版本明确,并向 npm 请求该版本
当前在该标签下发布。REA 不会静默替换 npm 所选的包版本。因此,有意回滚仍可通过精确的包请求来实现。
REA 将流程保持在内联状态,因此其历史记录保留在终端中。选择某项能力并不会选中所有检测到的目标,也不会授权更改。在任何更改发生之前,REA 会验证现有配置,打印确切的路径和外部影响,并请求最终批准,默认选项为 No。在你进行选择时,屏幕会保持可用按键可见;Ctrl-C 和拒绝操作都会使系统保持不变。
REA 会检测 Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf 和 Devin。检测到前六个时会对其进行配置;Devin 会被报告但保持不变,因为它没有文档化的本地 MCP 配置边界。注册是增量式的、备份优先的,并在写入后回读。你可以安全地重新运行 setup。
使用 rea setup --dry-run 查看计划,重复使用 --client 来选择确切的代理,使用 --accessible 获得顺序的垂直提示。机器输出仍可通过 --json 获得;提示 UI 和进度输出到 stderr。
成功完成 setup 后,REA 会报告现已可用的能力以及具体的下一步,例如在要求某个已配置的代理调查应用程序之前先重启它。除非 setup 及其最终诊断检查已验证,否则它不会声称某个集成或提供程序已就绪。
可选的 curl 包装脚本会安装相同的 CLI 包,并且仅在终端可用时启动 setup:
curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash
在 bash -s -- 之后传递安装程序选项,例如 --dry-run、--no-setup 或 --version 1.0.0。curl 包装脚本本身从不安装先决条件或配置集成。有关其确切的变更边界,请参阅 Installation and setup。
使用代理——推荐
npx --yes rea-agents@latest setup
在经过审查的 setup 计划中选择 Agent Integration。REA 会将固定的 MCP 注册及其匹配的路由技能作为一个事务进行安装。setup 完成后,重启已配置的代理,以便它加载对齐的集成。
查看 setup 计划,如合适则批准,然后描述你想要理解的应用程序或功能。Hopper 可以在其免费演示模式下运行;如果它显示首次运行提示,请选择演示或输入现有许可证。
从终端——无需安装
npx --yes rea-agents@latest setup
npx -y rea-agents@latest doctor
npx -y rea-agents@latest analyze /Applications/Notes.app
在确认之前查看 setup 计划。重启已配置的代理,以便它加载 REA。
从终端——安装 rea 命令
npm install --global rea-agents
rea setup
rea doctor
rea analyze /Applications/Notes.app
就地更新该全局安装:
rea upgrade
REA 会检查 npm 上的最新发布版本,并验证正在运行的包是否就是它将要替换的全局安装。源码副本、本地副本和 npx 副本会报告手动执行 npm install --global rea-agents@latest 命令,而不是更新一个无关的全局包。
请选择无安装命令或全局安装之一。你不需要两者都用。
不带 --global 的 npm install rea-agents 只会将 rea 安装到当前项目的 node_modules/.bin 中;它不会将 rea 添加到你的 shell PATH 中。对于一次性运行,请使用上面的 npx 命令;当你希望有一个 shell 中可见的 rea 命令时,请使用 --global。
要求
- macOS 12 或更高版本
- Ubuntu 24.04+、Fedora 41+ 或 64 位 Arch Linux
- Windows x64,用于实验性的、仅限 Ghidra 的原生 PE P0 边界
- Node.js 22.19+ 或 24.11+(包括更新的版本)
- npm;REA 不要求也不安装特定的 npm 版本
深度二进制操作使用 Hopper,这是一个具有自己许可证的独立桌面应用程序,或使用调用方选择的 Ghidra 提供程序。Ghidra 提供只读清单、函数元数据、反编译、汇编、已解析调用、类型化引用、交叉引用、CFG 和函数档案;通过该提供程序,GUI 状态和变更仍然不可用。安装程序会复用现有的 Hopper 安装或操作员提供的 Ghidra 安装。它绝不会下载 Ghidra 或安装 Java。如果两个提供程序都未就绪,交互式安装会建议使用 Hopper;无人值守的 Hopper 安装需要 rea setup --yes --install-hopper。
如果某些功能无法正常工作,请运行:
npx -y rea-agents@latest doctor
rea doctor --json 是只读的,可区分不受支持的主机、缺失的依赖项、缺失的本地分析引擎、配置漂移和健康检查。付费许可证激活是可选的:在 Linux 上,REA 会在私有的 Xvfb 显示器上运行受支持的 Hopper 演示版本,并为每个分析会话选择 Hopper 提供的演示模式。
Linux 安装和故障排除
在 macOS 上,经批准的安装程序会下载 Hopper 的官方 DMG,对其进行验证,并将应用安装到 ~/Applications,无需 Homebrew 或管理员权限。Hopper 在首次打开时可能会显示其演示或许可证提示;无需手动拖放。
在 Ubuntu 24.04+、Fedora 41+ 和 64 位 Arch Linux 上,经批准的安装程序会下载固定版本的官方 Hopper 6.4.2 软件包,将下载限制在 Hopper 的公共来源,验证发布的文件大小和校验和,并调用 apt-get、dnf 或 pacman 来安装 Hopper 以及演示会话所使用的 Xvfb、Python、X11 和 XTEST 软件包。当 REA 尚未以 root 身份运行时,pkexec 会显示系统授权提示。REA 绝不会调用 sudo。演示会话在隔离的 1280×1024 Xvfb 显示器上运行。在选择 Try the Demo 之前,REA 会验证确切受支持的 Hopper 二进制文件、其拥有的进程祖先关系、预期的对话框几何形状和桥接状态;任何不匹配都会以失败关闭方式处理。
常规的 Linux 启动器是 /opt/hopper/bin/Hopper。如果 Hopper 安装在别处:
export HOPPER_LAUNCHER_PATH=/absolute/path/to/Hopper
rea doctor --json
如果 doctor 报告缺少分析引擎,但该文件确实存在,请用以下命令检查共享库解析情况:
ldd /opt/hopper/bin/Hopper | grep 'not found'
安装缺失的发行版软件包,然后重新运行 rea setup。Linux 演示自动化需要 Xvfb、Python 3、libX11.so.6 和 libXtst.so.6;经批准的安装程序会安装这些直接运行时依赖项,并且不会与用户的桌面显示进行交互。Hopper 的免费演示版支持在厂商定义的限制内进行分析,付费许可证是可选的。curl 安装程序会将 rea 命令放置在 Linux 上的 ~/.local/bin 中;如果该目录尚未出现在未来的 shell PATH 值中,请将其添加进去。
REA 在 macOS 上将 HOPPER_LAUNCHER_PATH 默认为 /Applications/Hopper Disassembler.app/Contents/MacOS/hopper,在 Linux 上默认为 /opt/hopper/bin/Hopper。显式配置始终优先。
Ghidra 只读分析提供程序
Ghidra 适配器支持在 Linux x64 上使用 64 位完整 JDK 21 的确切官方 Ghidra 12.1.2 版本。它还提供了一个实验性的 Windows x64 P0,仅限于经批准的本地 x86-64 PE 应用程序。请自行下载并解压这些项目,然后配置绝对路径:
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.2_PUBLIC
export JAVA_HOME=/absolute/path/to/jdk-21 # optional when java and javac resolve from PATH
rea doctor --json
rea setup
rea providers --json
Doctor 会区分缺少配置、安装根目录错误、Ghidra 或 Java 版本错误、没有 javac 的 JRE、缺少 support/analyzeHeadless,以及不受支持的平台或架构。经批准的安装程序只会将经过验证的非机密路径复制到检测到的 MCP 注册中;它不会修改 Ghidra 安装,也不会安装/下载 Ghidra 或 Java。
在 Windows 上,请在 PowerShell 中设置相同的变量并运行 rea doctor --json;自动化的 rea setup 和 Hopper 安装仍然不可用。P0 目标边界会拒绝 DLL、托管 PE 文件、非 x86-64 映像、可变/恶意输入以及非 PE 格式。有关注册、确切限制、CI 证据和验收门禁,请参阅 Windows Ghidra P0 操作指南。
REA 使用 -scriptPath 加载其打包的 Java HeadlessScript,在临时运行时中复制目标并进行摘要验证,启用 -readOnly 和 -deleteProject,将自动分析限制在 300 秒内并使用两个 CPU 和 2 GiB Java 堆,并对每个请求进行身份验证。Linux 使用权限模式为 0600 的 Unix 套接字。Windows P0 使用令牌认证的 IPv4 回环以及无令牌的端点记录,因为在 Windows 上基于 Node 路径的 IPC 无法连接到 Java AF_UNIX 套接字。桥接程序在提供任何操作之前会验证 Ghidra 导入字节的 SHA-256。
Ghidra 适配器声明了 19 个直接和增强操作。其十个清单操作是 list_documents、list_procedures、list_strings、list_names、list_segments、address_name、procedure_address、resolve_containing_procedure、search_procedures 和 search_strings。它还接受 procedure_info、procedure_pseudo_code、procedure_assembly、read_function_instructions、procedure_callers、procedure_callees、procedure_references、xrefs 和 analyze_function。read_function_instructions 是用于原始指令窗口的按偏移分页快速路径:它不调用反编译器或全程序名称/字符串清单,并且还以 rea instructions 的形式暴露。这些能力支持共享的 Swift/Objective-C 清单工作流、binary_overview、batch_decompile、get_call_graph、find_xrefs_to_name、trace_feature 以及完整的函数档案。默认空间地址为小写 0x 十六进制。其他空间(包括 EXTERNAL)使用 :0x。符号结果标识主、动态、外部、类型和源事实;过程区分外部函数和 thunk;字符串标识字符集、缺失终止符状态、字节长度和值截断;内存块结束为排他性,权限直接来自 Ghidra。
桥接仅在自动分析完成后才提供操作。每个 Program 拥有一个持久化的 DecompInterface;一个有界的 32 请求 FIFO 串行化 Ghidra API 访问,并且每次反编译都有 30 秒的原生截止时间。引用结果保留 Ghidra 的调用/跳转/数据/读/写/间接/计算/外部事实,而未解析的无目标流保持显式未知。没有可操作内存来源的合成入口点引用被省略。伪代码和汇编是提供程序特定的观察结果,不是原始源代码或 Hopper 等价文本。分析超时、扫描或清单安全限制、请求超时或超大响应会显式失败,而不是返回标记为完整的部分结果。
npm run verify:ghidra 编译源拥有的 x86-64 调试和剥离 ELF、AArch64 ELF、x86-64 PE 和 x86-64 Mach-O 夹具。针对真实的 Ghidra 12.1.2,它验证每个接受的操作、直接和间接调用、导入/导出/thunk、类型化引用、字符串/xref、多块 CFG、取消、截止时间、并发、畸形输入以及完整的进程/项目清理。仅当相应编译器命令不在 PATH 上时,才设置 REA_CC、REA_CLANG 或 REA_LLD_LINK。
npm run verify:ghidra:windows 使用确定性的源拥有的原生 x86-64 PE 应用程序,并要求在受控的 Windows x64 Ghidra 12.1.2 运行器上执行所有 19 个操作、目标/快照/导入摘要链接、经过身份验证的环回传输以及清理。此证明不建立 Job Object 所有权、私有 DACL 或重解析点安全的权限。
要仅移除 REA 拥有的 MCP 注册和受管技能:
rea uninstall
rea uninstall --purge-data # 同时仅移除 ~/.rea/cache 和 ~/.rea/state
卸载会保留 Hopper、Node.js、证据、捕获、外部证据根目录、无关技能和其他 MCP 服务器。它会拒绝格式错误的客户端配置,并且绝不会跟随 purge-data 符号链接。
CLI 还是 agent?
| 如果你想…… | 使用 |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------- |
| 让 agent 调查一个应用并构建一项功能 | 安装该技能,然后与你的 agent 对话 |
| 从终端检查或反编译应用的某一部分 | rea analyze 或 rea decompile |
| 验证、规范化或比较 Evidence v2 包 | rea evidence-import、rea evidence-export 或 rea compare |
| 运行或恢复持久化的双版本产物分析 | rea investigate-versions |
| 在不执行本地 JavaScript/Electron 应用的情况下对其进行映射 | rea analyze PATH --approved 或 rea analyze-javascript-application |
| 在不重新启动提供程序的情况下复用不可变分析结果 | 将 --snapshot /approved/path/analysis.json 传给深度分析命令 |
| 将源代码作为历史参考导入 | rea import-reference-source |
| 捕获或比较受控进程行为 | rea capture-process 或 rea compare-process-captures |
在操作员批准绝对根目录之前,文件系统证据命令和 MCP 文件工具处于禁用状态:
export REA_EVIDENCE_ROOTS_JSON='["/absolute/path/to/evidence"]'
export REA_INVESTIGATION_INPUT_ROOTS_JSON='["/absolute/path/to/releases"]'
rea evidence-import /absolute/path/to/evidence/bundle.json
rea evidence-export /absolute/path/to/evidence/bundle.json /absolute/path/to/evidence/canonical.json
rea compare /absolute/path/to/evidence/left.json /absolute/path/to/evidence/right.json
rea investigate-versions /absolute/path/to/releases/v1 /absolute/path/to/releases/v2 /absolute/path/to/evidence/releases.json --yes --workspace-name releases
rea analyze /absolute/path/to/releases/app.asar --approved --json
rea analyze-javascript-application /absolute/path/to/releases/app.asar --approved --json
对于目录或 .asar,当既未提供 --provider 也未提供
--snapshot 时,通用 rea analyze 会自动选择
静态 JavaScript 应用提供程序。专用命令仍可用于显式
格式和资源限制控制。两种途径都需要 --approved 和一个
管理员批准调查的输入根目录。
如果 REA 已注册到 MCP 客户端,在设置了显式调查根目录变量的情况下运行已批准的 rea setup,然后重启该客户端。安装程序会将此非机密策略复制到受管注册中;仅更改 shell 环境无法更新已在运行的 MCP 进程。
investigate-versions 会清点两个版本,对其观察到的 Evidence 进行检查点记录,推导出工件比较结果,并记录一份行为变更报告。两个输入路径都必须解析到 REA_INVESTIGATION_INPUT_ROOTS_JSON 之下;工作区文件仍由 REA_EVIDENCE_ROOTS_JSON 独立限制。工作区使用确定性的内容标识和单调的 CAS 链接修订,因此同一请求可以恢复中断的运行,或复用已完成的运行,而不会替换先前的调查。它目前仅比较静态工件结构;它不会执行任一版本,其报告会将每一处差异都标记为行为候选。参见持久调查工作区。
历史源代码导入需要单独的允许列表,并且绝不将源代码视为当前行为权威:
export REA_REFERENCE_ROOTS_JSON='["/absolute/path/to/source"]'
rea import-reference-source /absolute/path/to/source
除非显式指定 --overwrite,否则导出绝不会替换现有文件。导入受大小/深度限制,会验证每个 Evidence v2 ID 和清单,并且绝不执行捆绑包内容。
提供方中立的分析快照会持久保存成功、不可变的 REA 调用及其 Evidence v2 记录。它们是精确缓存,而不是 Hopper 数据库:仅当二进制摘要、类型、格式、架构、操作参数、具体提供方构建和规范分析配置文件摘要都匹配时,REA 才会复用 v2 条目。Hopper 加载器默认值和配置的覆盖值由 Hopper 适配器规范化并提交到该配置文件,因此覆盖值会占据一个独立的安全缓存分区,而不是禁用快照。快照 v1 无法证明这些语义,会被拒绝并给出重新捕获指导。依赖游标和会变更的调用绝不会被缓存。快照文件可能包含专有分析结果和本地路径,因此 REA 将它们保留在本地,以仅所有者权限写入,并要求单独的已批准根目录:
export REA_ANALYSIS_SNAPSHOT_ROOTS_JSON='["/absolute/path/to/analysis"]'
rea analyze /absolute/path/to/app --snapshot /absolute/path/to/analysis/app.json
The same exact query can now be answered from the snapshot.
rea analyze /absolute/path/to/app --snapshot /absolute/path/to/analysis/app.json
精确的 CLI 证据重放会在任何提供方进程启动之前发生。在 MCP 会话中,将 snapshot_path 传递给 open_binary,以便在打开其匹配目标时原子地导入快照;MCP 提供方仍可能在缓存调用被重放之前启动。传递 snapshot_path,并在需要时传递 overwrite: true 给
close_binary 以原子方式保存,然后才释放 Hopper 资源。如果保存失败,REA 会刻意让会话保持打开。
一个提示词,一次完整调查
逆向工程 Notes 应用。找出离线搜索的工作原理,解释它,
并用 TypeScript 和 SQLite 为我的项目构建一个版本。
REA 为 agent 提供了一条从该请求到可运行代码的清晰路径:
| 步骤 | agent 做什么 | REA 工具 |
| ---: | --------------------------------------- | ---------------------------------------------------------------- |
| 1 | 打开并识别二进制文件 | open_binary、binary_overview |
| 2 | 查找可能的离线搜索线索 | search_strings、search_procedures、list_names |
| 3 | 将这些线索连接到可执行代码 | find_xrefs_to_name、xrefs、procedure_callers |
| 4 | 重建相关控制流 | get_call_graph、procedure_callees、procedure_info |
| 5 | 反编译相关例程 | procedure_pseudo_code、procedure_assembly、batch_decompile |
| 6 | 在你的项目中构建该功能 | 适配你的技术栈、产品和需求的代码 |
REA 在步骤 1–5 中处理应用分析。agent 使用其常规的文件编辑和测试工具,利用它了解到的应用信息来执行步骤 6。
agent 能做什么
- 调查你喜欢的功能,并构建一个为你的产品量身定制的版本。
- 在源代码不可用时解释某个功能的工作原理。
- 重建应用的身份验证、存储、更新或网络流程。
- 恢复足够多的结构,以记录未公开的格式或接口。
- 从字符串或符号追踪可疑行为,直到实现它的代码。
- 跨两个版本运行、检查点、恢复并复用内容寻址的工件调查。
- 将恢复的行为转化为产品功能、测试、迁移说明、移植或可互操作的替代实现。
- 分析 Swift 和 Objective-C 元数据,而无需手动解开每一个被混淆的符号。
- 在 Hopper 中留下名称、注释和书签,使人类和 agent 的分析相互促进。
用于调查的工具目录
| 工具系列 | 数量 | 示例 |
| ------------------------- | ----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 原生检查 | 36 | 过程、伪代码、汇编、字符串、名称、段、调用者、被调用者、交叉引用、注释、有界字节读取、文件偏移转换 |
| 调查工作流 | 13 | binary_overview、analyze_function、inspect_native_api、batch_decompile、trace_feature、精确字符串到代码查找、有界调用路径、调用图、Swift 和 Objective-C 发现 |
| 原生 macOS 实用工具 | 5 | Mach-O 元数据、代码签名、plist、架构、Swift 名称还原;无需 Hopper 且带来源信息 |
| 制品图 | 3 | 有界且提供方中立的检查、确定性的目录/ZIP/APK/IPA/MSIX/AppX/ASAR 清单,以及显式选择提取到不存在的自有树中 |
| 托管 PE/CLI | 8 | PE/CLI 标识、元数据成员、CIL 哈希、P/Invoke/原生边界声明与验证、应用程序图投影、反编译器重建导入、令牌重映射、运行时关联计划,以及版本比较 |
| 浏览器观察 | 9 | 精确源的被动 CDP 捕获、bundle 和 source-map 分析、WebMCP 发现、会话时间线、捕获差异、视觉证据,以及有界 Playwright 场景 |
| Electron 分析 | 5 | 被动且限定于根目录的观察、有界静态应用程序映射、有证据支持的静态/运行时协调,以及单独批准的由提供方拥有的点击/等待场景 |
| JavaScript 运行时 | 2 | 已批准的仅附加 Node/Electron Inspector 目标发现,以及有界的脚本和执行上下文观察,不进行评估或插桩 |
| 应用程序工作流 | 12 | 有界的跨层追踪、仅唯一版本匹配、历史源码到 bundle 映射、静态导出返回形状比较、已批准的 Linux 隔离提取模块重放、托管运行时特征描述、重建覆盖闭合、确定性义务账本,以及端到端就绪一致性 |
| 工作区和观察 | 23 | 目标生命周期、Evidence v2 bundle 快照、保留 bundle 发布、聚合导航/地址上下文、直接有限重放机评估、进程/工件/函数比较、证据关联的残余未知生命周期 |
公共接口描述的是智能体试图了解的内容。提供方决定如何作答。macOS 实用工具无需启动 Hopper 即可处理常见的语义检查;Hopper 处理更深入的原生分析;进程测试框架实现受控的行为捕获。
当前状态
REA 在受支持的 macOS 和 Linux 主机上已可用于原生应用程序、浏览器和 Electron 调查,外加上述有界的 Windows Ghidra P0:
- 打开 Mach-O、ELF、PE、.app、ZIP、APK、IPA、ASAR、plist、JavaScript、source-map 和通用分析数据库目标;Hopper 仍然是唯一接受旧版 .hop 数据库的适配器。
- 在不启动深度分析候选目标的情况下发现它们,确定性地选择,并保留一个不可变的提供方/配置文件绑定,直到显式切换或关闭;提供方故障绝不会触发透明回退。
- 通过配置的环回 CDP 端点附加到用户拥有的 Chrome 系列浏览器;捕获精确来源的 Web 结构、安全元数据、已批准的无值载荷形状、bundle/source-map 证据、WebMCP 声明、用户操作时间线、捕获差异,以及明确批准的截图,而不进行导航或 JavaScript 评估。
- 通过单独的规范根权限边界检查 Electron file:// 渲染器页面,而不调用 Electron API;脚本内容仍需单独批准并受字节数限制。
- 附加到一个精确批准的 Node 或 Electron V8 Inspector 目标,并保留有界的 scriptParsed 以及执行上下文生命周期元数据,而不进行评估、断点、恢复、源码读取或插桩。require/import 边、EventEmitter 活动、Electron IPC、PID 身份和角色身份仍然未知。参见被动 Node 和 Electron 运行时观察。
- 验证并规范化序列化一个提供者中立的 JavaScript Application Graph v1,涵盖包、ASAR 条目、Electron 角色、JavaScript/源映射实体、浏览器/运行时实例、IPC、端点、存储和原生附加组件。此已发布的领域契约本身不执行任何提取或 I/O。
- 通过 analyze_javascript_application 或 rea analyze-javascript-application,从已批准的本地目录或 ASAR 重建有界的静态包、入口点、Webpack/Rspack 模块、导入、worker、端点、存储、源映射、BrowserWindow、preload、contextBridge、IPC、实用进程和原生附加组件结构。仅使用 AST 的应用服务从不执行引导代码,仅配对唯一的精确字面量 IPC 通道,并将动态或模糊通道报告为未解析。
- 通过 reconcile_javascript_runtime 或 rea reconcile-javascript-runtime,将该静态图与现有的被动 web 或 Electron Evidence 进行协调。精确捕获的字节优先于调用方声明的文件/URL 映射;目标、帧、脚本、worker、缓存和资产歧义保持显式,源映射权威保持独立,且驻留在已观察 bundle 中的模块绝不会被报告为已执行。参见 JavaScript 静态/运行时协调。
- 通过经过身份验证的应用 Evidence 追踪字面量路由、字符串、API、IPC 通道、模块或原生导出,并带有显式的遍历边界,然后将精确的原生工件摘要和请求的导出交给保留的 Ghidra 或 Hopper Evidence,而不自动切换提供者。使用仅唯一摘要、源映射、结构和语义层级比较应用版本;将已提交的历史源清单映射到 bundle 节点,并带有显式的摘要和路径评分;通过唯一字面量判别式和有界 JSON Pointer 变更,比较一个精确 JavaScript 导出的静态返回形状。重复、动态、不完整、模糊和截断的事实保持未知。参见跨层 JavaScript 应用工作流。
- 使用 inspect_managed_artifact / rea inspect-managed-artifact 对 PE/CLI 托管产物进行分类,使用 inspect_managed_members / rea inspect-managed-members 检查有界元数据成员、签名、原始 CIL 哈希、有限解码指令元组 v1 哈希、单独报告的异常区域、调用边和字段访问锚点,使用 inspect_managed_native_boundaries / rea inspect-managed-native-boundaries 清点声明的 ModuleRef/ImplMap/PInvoke 和非 IL 方法边界指示符,然后使用 compare_managed_members / rea compare-managed-members 比较两个已认证的成员观察结果。verify_managed_native_boundaries / rea verify-managed-native-boundaries 根据已认证的原生导出或函数 Evidence 检查托管 P/Invoke 声明,同时保持已验证、推断、矛盾与未解决状态相互区分。比较将构建本地令牌视为构建本地,并使用唯一解码 CIL/签名和结构方法形状层级,绝不单独使用名称;v1 元组哈希本身不解析令牌,也不完全提交控制流。project_managed_application_graph / rea project-managed-application-graph 将已认证的托管产物/成员/原生边界 Evidence 投影到现有应用程序图中,以进行跨层功能追踪。import_managed_reconstruction / rea import-managed-reconstruction 仅在精确产物 SHA-256、MVID、签名以及随附的 v1 解码 IL 承诺匹配后,才将用户提供的反编译器 C#/IL/伪代码作为分析员推断接纳。另外,plan_managed_runtime_correlation / rea plan-managed-runtime-correlation 可以接纳一个默认禁用、受权限门控的运行时关联计划,该计划锁定到相同的构建证据。这些路径从不加载程序集、解析 CLR 依赖项、执行目标代码、运行反编译器,或将托管令牌转换为原生地址;完整的规范化 CIL v2 语义、原生主体桥接映射以及实际的运行时执行器仍属于未来的托管代码契约。
- 仅当你希望 doctor 和 verify:managed 将自带 ILSpy 命令作为真实重建预言机进行检查时,才配置 REA_ILSPY_CMD_PATH=/absolute/path/to/ilspycmd。REA 不安装 ILSpy,也不将反编译器文本视为规范元数据或 CIL 观察结果。
- 遍历内容寻址的产物图而不进行提取;在 macOS 上,只读 DMG 遍历还额外需要 native_mount_approved: true 和 REA_ARTIFACT_NATIVE_MOUNT_ENABLED=true。仅将已批准的实例具体化到不存在的输出根目录中。
- 构建有界函数档案,包含伪代码、汇编、CFG 边、注释、调用、引用、字符串和名称。
- 跨符号、字符串、元数据、引用和调用路径搜索并追踪功能。
- 将每个成功结果记录为确定性 Evidence v2,包含产物和提供者身份、置信度、权威性、限制和位置。
- 跨会话导出和导入证据包。
- 将自动跨版本工件运行持久化为规范的、受锁保护的工作区,并带有防篡改的修订承诺。
- 将已批准的 PTY 场景捕获为 Process Capture v4 Evidence,包括已提交的运行清单、原始和渲染的终端帧、脚本化交互、后代进程结算、命名文件系统检查点、确定性命令垫片,以及回环 HTTP/WebSocket 交换。
- 在不通过 run_replay_machine 或 rea run-replay-machine 启动目标的情况下验证有限重放机;有序事件返回类型化决策、动作、捕获的别名、转换日志、最终状态和精确限制使用,而不回显请求或捕获的值。
- 按稳定路径、内容、元数据和关系比较完整的工件清单;不完整的证据绝不意味着等价。
- 跨文本、调用、引用、字符串和地址归一化 CFG 拓扑比较显式函数档案,并带有各分面的未知项。
- 按精确成员资格、显式观察对和残余未知历史比较规范 Evidence 包,而不将遗漏转化为行为缺失。
- 将运行时比较聚合为观察到的行为变化,同时将静态工件/函数差异标记为候选。
- 按精确地址构建有界的、Evidence 引用的直接调用路径,而不将缺失的档案视为图叶子。
- 通过显式假设关联精确的静态/运行时发现,而不从共变声称因果关系。
- 验证有限行为和结构重建规范,并将通过、失败和未知保持区分。
- 通过不可变 CAS 修订、证据限定的解决、矛盾、探针和经过验证的依赖关系跟踪残余未知项。
- 在显式 unknown_registry_approved: true 的情况下,自动记录有界跟踪/捕获残余、类型化提供程序不可用和捕获分歧。
- 启动六个引导式 MCP 工作流,为文档、过程、提供程序、证据、捕获、工件 ID 和活动未知项提供实时、会话感知的补全。
Hopper 是第一个提供程序,而不是项目的边界。一些当前工作流仍然需要 Hopper 和 macOS;每条证据记录都会标识其结果背后的提供程序和限制。
使用 CDP 进行网站观察
REA 可以检查您拥有的、已在运行的 Chrome 系列浏览器。浏览器观察默认禁用,并且需要字面回环 CDP 端点以及精确批准的页面来源:
export REA_BROWSER_OBSERVE_ENABLED=true
export REA_BROWSER_CDP_ENDPOINTS_JSON='["http://127.0.0.1:9222"]'
export REA_BROWSER_ALLOWED_ORIGINS_JSON='["http://127.0.0.1:3000"]'
rea list-browser-targets http://127.0.0.1:9222 --approved --json
rea inspect-web-page http://127.0.0.1:9222 TARGET_ID --approved --json
所有八个浏览器工具都通过 CLI 和 MCP 暴露相同的 Evidence v2 契约。检查是被动的:REA 不会执行页面 JavaScript、导航、点击、关闭页面或关闭浏览器。查询值、凭据、Cookie、授权头、存储值以及原始 JSON 或 WebSocket 值永远不会被保留。单独批准的捕获可以保留有界的已脱敏控制台原语、无值的 JSON/WebSocket 形状、脚本源、无障碍文本或截图像素。附加之前的现有活动明确不可用。有关浏览器启动、模式、限制和威胁模型,请参阅使用 CDP 进行网站观察。
受控浏览器场景
capture_browser_scenario 是一个独立的、显式执行变更的浏览器边界。
它仅通过 Playwright 运行固定的、带版本号的场景词汇表,并
返回按步骤索引的 Evidence,涵盖截图、DOM、无障碍、URL/历史、
存储、控制台/错误、网络、WebSocket、框架、worker、弹出窗口和
已取消的下载。缺失或被截断的部分永远不能支持相等性
断言。
export REA_BROWSER_SCENARIO_ENABLED=true
export REA_BROWSER_SCENARIO_EXECUTABLE_ROOTS_JSON='["/usr/bin"]'
export REA_BROWSER_SCENARIO_CDP_ENDPOINTS_JSON='["http://127.0.0.1:9222"]'
export REA_BROWSER_SCENARIO_ALLOWED_ORIGINS_JSON='["http://127.0.0.1:3000"]'
export REA_BROWSER_SCENARIO_ALLOWED_ENV_JSON='["REA_TEST_PASSWORD"]'
rea capture-browser-scenario ./scenario.json --json
启动模式拥有一个临时浏览器配置文件,并在终止
所启动的浏览器后将其移除。连接模式接受一个确切的回环 CDP 目标,
并在不关闭外部浏览器的情况下断开连接。自动化没有默认
授权:使用共享的项目/会话策略,或者仅在可信的无人值守
环境中设置 REA_BROWSER_SCENARIO_AUTO_GRANT=true。场景 JSON 包含密钥引用和环境变量
名称,绝不包含密钥值。请参阅
浏览器场景契约。
Node 和 Electron V8 Inspector 观察
仅附加的 JavaScript 运行时观察默认单独禁用:
export REA_V8_INSPECTOR_OBSERVE_ENABLED=true
export REA_V8_INSPECTOR_ENDPOINTS_JSON='["http://127.0.0.1:9229"]'
export REA_V8_INSPECTOR_FILE_ROOTS_JSON='["/absolute/path/to/app"]'
export REA_V8_INSPECTOR_ALLOWED_ORIGINS_JSON='[]'
rea list-javascript-runtime-targets http://127.0.0.1:9229 --approved --json
rea observe-javascript-runtime http://127.0.0.1:9229 TARGET_ID \
--runtime-kind node --approved --json
REA 仅发送 Runtime.enable 和 Debugger.enable。它保留有界的、
经作用域授权的脚本位置和执行上下文生命周期事件;
require/import 边、EventEmitter 活动、Electron IPC、PID 身份和
Electron 角色身份保持为明确的未知项。请参阅
被动 Node 和 Electron 运行时观察。
确切的包、工具家族、提供程序、安装客户端、公共模式版本和 CLI 事实由 docs/product-catalog.json 中的源生成。PR CI 会验证此目录、叙述性文档、生成的模式以及干净的 TypeDoc 渲染。
路线图
REA 正在发展成为一个用于跨静态工件和观察行为理解软件的工具包。上面的当前状态是已交付的基线;以下项目是计划中的工作。
现在
1. 维护真实的产品元数据 —— 每当版本、工具、提供程序、模式、安装客户端或 CLI 能力发生变化时,扩展已交付的规范目录和漂移检查。
2. 跨提供程序一致性增长 —— 添加源拥有的架构以及困难的间接/Thunk 案例,同时保留语义比较和提供程序特定的文本边界。
下一步
1. 受控重放一致性增长 —— 扩展已交付的 Linux 提取模块沙箱,增加更多源拥有的敌对夹具和跨内核一致性;浏览器和 Electron 场景仍然是单独授权的权限。
2. 更广泛的应用图证据 —— 使用额外的静态提取器和单独批准的运行时权限扩展经过身份验证的跨层跟踪。
3. 专业托管代码分析 —— 扩展已交付的 PE/CLI 分类、CIL 证据、托管/原生声明清单、源拥有一致性和抗混淆比较,朝着在已接受的托管代码边界下经过验证的原生提供程序组合发展。
4. 确定性行为测试装置 —— 扩展进程所有权、协议夹具、文件系统观察、重连和跨版本行为比较。
稍后
1. 更广泛的受控应用交互 —— 将单独授权的浏览器和 Electron 场景表面扩展到当前有界点击/等待操作之外,而不扩大被动观察或提取模块重放权限。
2. 原生运行时观察 —— 经批准门控的 LLDB、Frida、系统日志、进程/文件系统观察器和原生 API 跟踪。
3. 额外的提供程序和目标 —— 评估 IDA/Hex-Rays、Binary Ninja、Rizin、LIEF、Windows 原生提供程序、移动工件、固件、文档格式和其他软件定义系统。
新提供程序必须产生与现有能力相同的证据和安全元数据,然后才能成为公共工作流的一部分。一旦 REA 拥有多个可选工具链,安装就可以变为能力选择性;该未来工作的同意规则记录在安装路线图中。
关于已交付的 Ghidra 函数分析边界、剩余准入关卡以及提供方对比矩阵,请参阅静态分析提供方评估;关于绑定、选择、配置档案、快照和兼容性决策,请参阅 ADR-0001;关于已交付的 JavaScript 重放边界,请参阅受控重放指南以及 ADR-0002;关于托管代码证据和提供方设计,请参阅 ADR-0003。
将 REA 与其他代理配合使用
安装程序会检测 Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf 和 Devin。当上述前六项存在时,它会自动进行配置;检测到的 Devin 安装会被报告,但保持不变。任何支持本地 MCP 服务器的代理都可以使用以下配置来使用 REA。
手动 MCP 配置
{
"mcpServers": {
"rea": {
"command": "npx",
"args": ["-y", "rea-agents@3.1.0", "mcp"]
}
}
}
持久注册应使用一个确切的包版本。rea setup
会维护该版本锁定,同时升级捆绑的技能,并为 Codex
在冷启动包运行器时提供 30 秒的启动宽限时间。交互式
rea upgrade 会在安装新可执行文件后打开更新后的安装计划;
结构化或非交互式升级会提示你显式运行该同步。
对于已批准注册发生变更的客户端,请重启它们。
支持提示的 MCP 客户端还可以通过 prompts/list 发现六个有序的调查
工作流。它们的可选标识符参数会使用当前会话,以提供有界的 completion/complete 建议;请参阅
引导式 MCP 提示与补全。
工作原理
flowchart LR
Agent["Agent"] --> REA["REACLI + MCP"]
Terminal --> REA
REA --> Workspace["Investigation workspaceevidence + artifacts + captures"]
REA --> Session["Target-bound session router"]
Session --> Registry["Deep-provider registrydeterministic selection"]
Registry --> Hopper["Hopper provider"]
Registry --> Ghidra["Ghidra providerread-only inventory + function analysis"]
Hopper --> Runtime["Owned provider runtimedeadline + bounded diagnostics + cleanup"]
Ghidra --> Runtime
Session --> Native["Native macOS provider"]
Session --> Artifact["Artifact graph provider"]
REA --> Browser["Browser CDP provider"]
REA --> Process["Process capture provider"]
Runtime --> Target["Target software"]
Process --> Target
Native --> Target
Artifact --> Target
CLI 和 MCP 服务器使用相同的应用程序工作流和证据契约。提供程序声明其支持哪些能力以及这些能力可能产生的副作用。终端命令是短时存在的;MCP 会话可以在一次调查中保留活动目标和证据账本。经批准的持久工作区在进程和会话生命周期内保留规范证据和可恢复的运行检查点。
CLI
上述代理工作流是使用 REA 的最简单方式。如需从终端进行一次性概览:
npx -y rea-agents@latest analyze /Applications/Notes.app
npx -y rea-agents@latest inspect /Applications/Notes.app
npx -y rea-agents@latest inspect /Applications/Notes.app --detail detailed --limit 20
npx -y rea-agents@latest search /Applications/Notes.app "offline"
npx -y rea-agents@latest function /Applications/Notes.app 0x1000
npx -y rea-agents@latest xrefs /Applications/Notes.app 0x1000
npx -y rea-agents@latest trace /Applications/Notes.app "offline"
npx -y rea-agents@latest compare /absolute/path/to/left-evidence.json /absolute/path/to/right-evidence.json
npx -y rea-agents@latest investigate-versions /path/to/v1 /path/to/v2 /absolute/path/to/evidence/releases.json --yes
npx -y rea-agents@latest capabilities
npx -y rea-agents@latest providers
运行 npx -y rea-agents@latest --help 以了解直接反编译、有界搜索和其他选项。analyze 和 inspect 共享相同的概览工作流;function、xrefs 和 trace 返回与 MCP 相同的 Evidence v2 信封。
或者全局安装 rea 命令:
npm install --global rea-agents
rea --help
rea upgrade
rea mcp
REA 直接接受 Mac .app 文件夹。如果代理无法按名称找到应用,请告诉它应用的安装位置。
选择深度分析提供程序
每次深度分析打开都会在创建其客户端之前解析提供程序。相同的选择器和优先级适用于 CLI、MCP 和启动配置:
rea providers --json
rea analyze /absolute/path/to/program --provider hopper
REA_ANALYSIS_PROVIDER=hopper rea decompile /absolute/path/to/program 0x1000
对于 MCP,在 open_binary 上传递可选选择器:
{
"path": "/absolute/path/to/program",
"provider_id": "hopper"
}
请求级别的 provider_id 或 --provider 优先于 REA_ANALYSIS_PROVIDER;两者都接受提供程序 ID 或 auto。自动选择会绑定唯一可用的深度候选;当有多个可用时报告 ambiguous,并且可以让仅制品目标保持未绑定,以便其不相交的制品操作仍然可用。显式指定未知、不可用或不支持的提供程序会失败,并给出候选 ID、稳定的拒绝代码和可操作的本地诊断信息。binary_session、rea providers 和 rea capabilities 公开权威的 analysis_provider_candidates 和 analysis_provider_binding 字段。每个打开的目标也有一个
analysis_run.run_id 在 provider 启动之前分配。当动态 provider 启动时,analysis_run.process_lineage 从 not_observed 变为 snapshots,并为每个已启动的 provider 保留一条由 provider 归属、经 token 验证的观测记录。每条观测记录都带有 observed_at,并保持为 unavailable 或 verified;已验证的空后代列表与这两者都不同。快照描述的是有界观测,而不是当前实时状态或历史缺失。
对于具有串行工作的 provider,analysis_activity 区分 idle、busy 和 timed_out_busy,并报告活动操作、已用时间、调用方状态、超时和排队请求数。因此,调用方超时并不会错误地暗示 Hopper 的 Python 线程可用。close_binary 会清除 REA 会话,但当无法验证经过身份验证的文档关闭、自有进程清理或私有运行时移除时,会返回 cleanup_incomplete。
在没有选择器的情况下重新打开同一目标会保留其绑定;运行时故障绝不会静默选择另一个 provider。
在 doctor 验证其确切安装后,Ghidra 可以作为可用且与目标兼容的候选出现。其能力列表包含 19 个已准入的只读清单和函数分析操作;选择它仍然不会使仅限 Hopper 的 GUI 或变更操作可用,并且绝不会触发静默回退。
CLI 退出状态
| 状态 | 含义 |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | 请求的操作已完成。真实的未知项、警告以及有界或截断的证据仍属于成功结果。 |
| 1 | 参数、策略、权限、provider 分析、完整性检查、取消、超时、设置、诊断、更新、卸载、输出编码或输出写入阻止了完成。当 REA 能够编码时,结构化输出会标识失败类别。 |
| 128 + N | 进程因信号 N 而结束,其中 shell 或运行时保留由信号派生的常规状态。 |
setup 在 planned、needs_confirmation 或 needs_human 时返回 1,因为配置尚未就绪;请在批准或修复后重新运行它。
doctor 在任何检查不健康时返回 1。输出格式、完整信封、过滤器和令牌控制永远不会改变操作状态。
当 REA 为 shell 管道提供输入时,启用 pipefail,这样下游格式化程序就无法隐藏其失败:
set -o pipefail
rea inventory-artifact ./app.asar --json | jq . > inventory.json
当前 Hopper 提供程序
REA 在需要时启动 Hopper;Hopper 无需预先运行。Hopper 的启动器会在内部激活应用程序,因此打开目标可能会将 Hopper 带到前台。REA 会请求 macOS 尽可能在后台以隐藏方式启动 Hopper,但无法保证它会保持在当前应用程序之后。
REA 会推导出显式的格式和架构参数,以防止常见的 FAT 和 ARM 选择对话框。其他 Hopper 或 macOS 对话框可能仍需要人工处理。REA 通过 CLI 或 MCP 结果报告超时和补救措施,而不是尝试回答 UI 提示。
Hopper 桥接调用通过一个有界的串行 FIFO 传递,因为 Hopper 的 Python API 运行在一个专用线程上。队列等待时间计入调用方截止时间;超时会结束调用方,但在 Hopper 实际回复之前不会释放线路槽位。binary_session.analysis_activity 会暴露该分离的工作,MCP 进度会报告已用时间。成功的反编译文本按文档和过程缓存,由伪代码和档案请求共享,并在重命名或注释变更后失效。
Hopper 的同步公共 Python 调用无法在调用方截止时间之后流式传输部分响应。当原始指令定位足够时,使用 read_function_instructions 或 rea instructions:此路径不会反编译或扫描整个程序的名称/字符串清单。如果档案已经超时,请检查 analysis_activity;不要假设原始请求可以进入串行桥接,直到该分离的 Hopper 调用实际返回。
关闭 REA 会话会关闭其桥接并移除其私有套接字目录。它不会退出用户可能正在使用的 Hopper 应用程序。如果无法验证关闭或清理,close_binary 会返回 cleanup_incomplete,并附带受影响的本地资源。
高级进程捕获设置
进程捕获默认禁用。启用它需要
REA_PROCESS_CAPTURE_ENABLED=true、在
REA_PROCESS_EXECUTABLE_ROOTS_JSON 和 REA_PROCESS_WORKING_ROOTS_JSON 中批准的可执行文件和工作根目录,以及
REA_PROCESS_ALLOWED_ENV_JSON 中的环境允许列表。由于当前 PTY
适配器使用主机网络,它还需要
REA_PROCESS_ALLOW_EXTERNAL_NETWORK=true。
设置 REA_PROCESS_CAPTURE_AUTO_GRANT=false,将这些进程捕获
限制配置为上限,而不隐式授予它们。此模式保持
故障关闭,直到建立更窄的授权。
捕获一个场景或比较两条已保存的 Process Capture v4 Evidence 记录:
rea capture-process ./scenario.json > authority.json
rea capture-process ./reconstruction.json > reconstruction.json
rea compare-process-captures authority.json reconstruction.json
比较会分别报告每个观察到的维度,并识别出第一个终端、交互、退出、文件系统、协议、进程或 shim 差异。有关场景字段、命令 shim 重放、检查点触发器、限制和安全行为,请参阅 Process Capture v4。
REA 为受支持的 macOS、Linux 和 Windows 架构安装预构建的 PTY 后端。如果能力检查报告该后端不可用,请为当前平台和架构重新安装 REA。
ASAR 清单会验证归档条目和 .asar.unpacked 伴随文件的 Electron 完整性元数据。完整性失败会标识逻辑路径、声明的和计算出的 SHA-256 值,以及该条目是否已解包;REA 不会静默接受不匹配的产物。如果提供的 ASAR 声明了解包后的伴随字节,但这些字节在本地产物集中不存在,REA 会将该情况保留为 unavailable,并继续分析嵌入的 JavaScript,而不是将缺失的原生/资源字节视为已验证或不存在。
安全模型
REA 不提供托管分析服务。Hopper 和 Linux Ghidra 桥接通信使用经过身份验证的私有本地套接字。Windows Ghidra P0 使用经过身份验证的 IPv4 回环,但不声称具备命名管道 DACL 或恶意本地用户隔离能力。动态能力默认禁用,并且需要同时满足操作员策略和每次调用的明确批准。随附的提供程序、被动观察器和 Process Capture 都不是安全沙箱:提供程序和启动的目标以当前用户的权限运行。提取的 JavaScript 重放是一项独立的仅限 Linux 的能力,除非 Bubblewrap 命名空间、经过架构检查的 seccomp、私有运行时挂载和委托的 cgroup 限制均可用,否则会以失败关闭方式处理;它绝不会继承浏览器、Electron 或 Process Capture 的权限。请参阅 ADR-0002。请通过 SECURITY.md 中的私有流程报告漏洞。
常见问题
我启动 REA 之前需要先运行 Hopper 吗?
不需要。当某个操作需要 Hopper 时,REA 会启动它。也支持已经运行的 Hopper 应用程序。
为什么 Hopper 会出现在我其他窗口的前面?
Hopper 的启动器会在内部激活应用程序。REA 请求后台启动,但 macOS 和 Hopper 仍可能将窗口或对话框带到前面。请参阅 Hopper 应用程序行为。
REA 包含 Hopper 吗?
不包含。安装程序可以为你安装 Hopper,但 Hopper 仍是具有自己许可证的独立软件。REA 提供 CLI、MCP 服务器和工作流,使其可供代理使用。
REA 会安装或包含 Ghidra 或 Java 吗?
不会。Ghidra 支持需要你自行准备。REA 仅打包其 Java 桥接源码,验证所支持的确切版本 Ghidra 12.1.2 和 64 位 JDK 21 安装,并在设置批准记录路径后,通过 Ghidra 的外部脚本路径加载该桥接。
REA 会上传应用吗?
REA 没有托管分析服务。当前提供程序在本地分析产物并捕获行为。你的代理或模型提供程序可能有自己的数据政策,因此请单独审查。
REA 能恢复原始源代码吗?
不能。任何反编译器都无法保证恢复原始源代码。REA 为代理提供伪代码、汇编、符号、字符串、元数据和关系,代理可用其解释或兼容地重建观察到的行为。
哪些代理可以使用 REA?
任何能运行本地 MCP 服务器的代理都可以使用手动配置。设置会检测 Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf 和 Devin;当存在前六个时,它会自动配置它们,并报告 Devin 而不对其进行修改。
开发
有关设置、架构和发布说明,请参阅 CONTRIBUTING.md;有关行为测试深度、聚焦开发者命令、覆盖率下限和 CI 证据,请参阅 docs/testing.md。PR CI 会将生成的 API 文档发布为 api-docs 工作流产物。
npm run verify:agent 通过真实的本地 Codex CLI 运行无品牌原生、JavaScript 应用程序、托管和浏览器提示。其 JSON 报告衡量自然 MCP 使用、首个工具路由、重复调用、实际 Codex token 使用量、完成质量,以及对权限和未知项的明确处理。
npm run evidence:generate 从实时验证器输出重新生成托管一致性清单和 Evidence v2 完成台账。npm run evidence:check 会重新运行验证器,并在产物、场景、提供程序、模式、声明计数、Evidence ID 或捆绑技能发生漂移时失败。不受支持的声明保持明确,且绝不计为通过。
验证器 JSON 报告包含一个临时的 verifier_run UUID,该 UUID 在验证器执行工作之前分配,并通过 REA_PROCESS_RUN_ID 由其子进程继承。最终报告包含验证器和父进程 PID,以及 process_lineage 及其 ISO observed_at 时间戳:POSIX 验证器报告经过令牌验证的、时间点启动器进程组和活动后代,而没有自有谱系原语的平台则报告 status: "unavailable" 及原因。已验证后代列表为空意味着在最终观察期间没有子进程处于活动状态;这并不声称验证器此前未启动任何子进程。嵌套验证器入口点
在同一进程中复用它自己的 UUID;每个新的验证器进程都会用全新的运行身份替换任何继承的父令牌。
生成的完成提交有意排除这种每次执行的标识,因此检查模式保持确定性,而实时报告仍可归属。
受控的 Hopper 关闭日志保留启动器 PID、进程组 ID、清理状态,以及是否需要经过验证的组信号。它们省略运行令牌和意外异常文本。真实 Hopper 验证器还会在一个独立的进程组中启动一个无关的、以 Hopper 命名的哨兵进程,并且除非该进程在每次会话关闭后仍然存活,否则验证失败;哨兵进程仅在存活检查之后由验证器移除。
项目链接
npm · Issues · Security · Contributing · Hopper · Ghidra
许可证
MIT同作者(morluto)的其他插件
扫码进群