dsh-plugin-rea

dsh-plugin-rea

English · 简体中文

这是哪个版本？2.x —— 而 `main` 就是它。 2.x 自己准备运行时（Node、REA CLI、JDK、Ghidra）再把那一行接好：

装插件 → 跑一次 scripts/setup.mjs → 重启 dsh。

1.x 是更早的纯配置适配器 —— 它假设 rea 在 PATH 上、Ghidra 由你自己装好 —— 保留在

v1 分支，npm 上仍是 dsh-plugin-rea@1.0.6。

完整对比：两条线：1.x 与 2.x · 升级：从 1.x 升级。

REA 6.8.0（本包钉子）只认 Ghidra 12.1.x（12.2 判 unsupported，

Ghidra 系的反编译/分析工具整组消失）和 jadx 桥接 0.7.1（0.8.0 会在第一次调用就报

Expected engine 0.7.1，失败点在加载 APK 之前）。这两道闸门 2026-10-26 对着 6.8.0 重新核过，一道都没动。

JDK 21.0.13 上游已发，但 Adoptium 仍没给 Windows 构建，本机无处可指，而且它只移除 4 个 eMudhra 锚里的

3 个。所以现在的取舍是「工具全绿、CVE 未清」：Ghidra 12.1.4 的 CVE-2026-100504 / 100505 / 100503 / 113604

仍在链上 —— 别拿这套环境分析来源不可信的样本；JDK 也仍信任 eMudhra 锚。证据、缓解与重开条件：

docs/update-review-2026-10-24.md 与

docs/update-review-2026-10-26.md。

Ghidra 12.2 本身是可用的 —— 2026-10-26 实测：经 REA 自己的桥接，段表（9 段）、函数表（341 个）与 entry

伪代码与 12.1.4 逐字节相同。挡住它的不是兼容性，是 REA 那条版本等值判定。如果你就是要用修掉 CVE 的那一版：

node scripts/ghidra-gate-override.mjs --enable --version 12.2 只改 vendored 副本里那一个常量、把改动记进

/ghidra-gate-override.json，--disable 还原；重跑 setup 也会还原。它要求 JDK 25+

（application.java.min=25）。

`node scripts/setup.mjs` 要你自己跑 —— 装完跑一次，之后每次升级插件版本再跑一次。 没有东西会替你跑：

市场里的安装/更新只替换包，然后到此为止。从 2.0.8 起，市场升级能保证那一行继续可用（镜像启动器会

转发执行新的那份），但它不会把 bundle 换到新的钉子 —— REA 与引擎仍是上一次 setup 时记下的版本。

首次安装不跑：行以 MODULE_NOT_FOUND 退出，工具消失且没有任何提示；升级后不跑：仍旧跑旧 REA 且没有症状

（check-updates.ps1 会报出这条漂移）。若你开过 Ghidra 闸门覆盖，这一次 setup 会重新供给内置 REA、覆盖随之

消失 —— 跑完再 --enable 恢复，或者接受回到钉住的那一版。完整规则见更新。

首次安装与每次升级插件后，Web GUI 会显示一次操作指南。 它会说明运行时是缺失、还是落后于本插件钉的版本，

给出这次安装对应的完整 node "/scripts/setup.mjs" 命令，并按插件版本记住“已看过”。

它只是提示：不会替你运行 setup，也不会改动 bundle。跑一次、重启 dsh，提示就会消失，直到下一个插件版本。

把上游 REA — Reverse Engineer Anything 的 MCP 服务接入 DeepSeek Harness（dsh），让它的工具在会话里以 mcp__rea__* 出现。

这是什么

一个带供给层的 Cordis bundle。package.json 声明 dsh.bundle.patch，该 patch 插入一行官方 MCP 客户端 插件（@deepseek-ai/dsh-mcp-client）。这一行用当前运行的 Node 可执行文件启动 bin/rea-shim.mjs，由 shim 读取 scripts/setup.mjs 写下的本机状态，再拉起它供给的 REA CLI。这里没有任何分析代码，且发布出去的 patch 里不含任何机器路径。

第三方适配。 本仓库不属于 REA，不携带 REA 的任何代码，也不由 REA 作者维护；它只组装一行配置，

并从上游官方源拉取上游自己的发布物。

上游：github.com/morluto/rea（MIT）·

中文文档 ·

rea.tools · npm 包 rea-agents。

REA 自身的问题请提给上游；本插件的问题提到

本仓库 issues。

它只做三件事：注册 mcp__rea__* 这批工具名；把每台机器各自的引擎环境 （GHIDRA_INSTALL_DIR、JAVA_HOME、REA_ADB_PATH、REA_APKTOOL_COMMAND、REA_JADX_MCP_JAR、 REA_BROWSER_EXECUTABLE 等）限定在那一个 MCP 子进程上、而不是整个 harness；以及把这些组件装到盘上。

能做什么、不能做什么

分析能力属上游，本节只是复述上游自己的契约，避免预期错位。

• 它无法还原完整源码。 原生二进制上游给的是*伪代码与汇编*，APK 是*反编译方法*，JEB 单元是*伪代码*，

JavaScript/Electron 是*模块及其关系*。上游的工具契约明确写着伪代码"是反编译器输出，不是原始源码， 也不与另一 provider 的输出文本等价"。

• 实际上拿不回来的：原始标识符名、类型、注释、宏与模板展开、构建脚本与资源。优化（内联、重排）、

符号剥离、混淆、加壳、VM 保护只会让输出更差。

• 每个结果都带置信度与限制（observed / derived / inferred，外加一份明确的 limitations 列表）。

请当证据读，别当还原出来的源码。

• 适合：理解行为、定位实现、互操作与兼容重写、安全审阅、迁移参考。要拿真正的源码，走正规渠道 ——

上游仓库、厂商授权，或厂商自己的 SDK。

供给解决不了的部分。 这些是上游的宿主门槛，不是本插件漏配了什么：

能力 · 门槛 Hopper provider · 仅 macOS IDA provider · 需要你自己的 IDA 与 REA_IDA_MCP_CONFIG；REA 从不启动 IDA 固件 binwalk / unblob · 仅 Linux Wakaru JS 还原、pwntools 的 ELF/宕机转储路径 · 仅 Linux x64 pwndbg / gdb 核心上下文 · 仅 Linux、macOS 原生 mitmproxy 抓包 · 仅 Linux（REA_MITMDUMP_COMMAND）；HAR 不需要引擎 苹果工具链（Mach-O、plist、资源目录、LLDB） · 仅 macOS capture_process_scenario · 仅 Linux/macOS 的 PTY apktool（Android 资源解码） · 仅当 REA_APKTOOL_COMMAND 指向 Node 能直接执行的文件时才可用：上游用 execFile 不加 shell 直接起这个命令，而 Windows 上 Node 无法直接执行 .bat/.cmd（EINVAL）。本包按上游文档接的是官方 apktool.bat，所以在 Windows 上它拿不到版本、该能力不可用；JADX 走 jar，不受影响

两条线：1.x 与 2.x

· 2.x —— 当前这条，main · 1.x —— v1 是什么 · 适配器加供给：自己准备 Node、REA CLI、JDK、Ghidra，再把那一行接好 · 纯配置适配器：一行 MCP 行，指向你自己装好的 rea 前置 · 运行时什么都不用装 —— 缺什么它去取（--reuse 则复用机器上已有的 Ghidra/JDK） · Node.js（满足 REA engines）、npm i -g rea-agents，原生分析还要 Ghidra 12.1.x 首次运行 · 先跑一次 scripts/setup.mjs（或引导脚本），再重启 dsh · 不用跑任何东西 那一行启动什么 · 当前 Node 可执行文件 + /plugins/rea-bundle/bin/rea-shim.mjs（由 shim 读本机状态） · Windows 上 cmd.exe /c rea mcp，macOS/Linux 上 rea mcp 机器状态 · /plugins/rea-bundle/ —— bundle.json、vendor/、cache/ · 你自己的 REA 与 Ghidra 安装 安装 · dsh plugin --profile add dsh-plugin-rea（npm latest ≥ 2.0.0） · … add dsh-plugin-rea@1.0.6，或 github:czcdr/dsh-plugin-rea#v1.0.6

两条线发布的是同一种 patch 形态（一条 insert 行，@deepseek-ai/dsh-mcp-client），对外也提供同一套 mcp__rea__* 工具面；区别只在"谁准备运行时"。从 1.x 到 2.x 只要两条命令，见 从 1.x 升级。

上游现在也能自己注册进 dsh（rea setup --client dsh）：那基本就是上游维护的 1.x 模式 —— 只写配置， Node/REA/Ghidra 由你准备。本包是零依赖路线。三条路选一条，不要同时留两行 serverName: rea。

安装

前置什么都不用装。 在干净的 Windows x64 机器上：

powershell -ExecutionPolicy Bypass -File scripts\rea-bundle-bootstrap.ps1 -Reuse

-Reuse 会复用你已有的 Ghidra/JDK；去掉它则从官方发布下载两者（约 775 MB，逐个校验和验证）。然后为你的 profile 安装插件：

dsh plugin --profile <profile> add dsh-plugin-rea
# 或钉住这个版本，而不是跟着 npm latest 走：
dsh plugin --profile <profile> add github:czcdr/dsh-plugin-rea#v2.0.13

Electron 宿主（DeepSeek Harness 桌面版）的 profile 由应用独占。 那种机器上 dsh plugin --profile desktop …

会被 CLI 直接拒绝（profile "desktop" is managed exclusively by the Electron application），请改用**应用内的

插件管理器**安装/更新；上面这条 CLI 只适用于你自己用 CLI 建的非 desktop profile。

如果机器上已经有 Node，可以跳过引导脚本直接供给：

node scripts/setup.mjs --reuse      # 或先 --dry-run 看计划

如果 Node 由你自备（而不是让 setup 去取），它必须满足 REA 的 engines： ^22.23.4 || ^24.22.1 || >=26.12.1（用 node -v 核对）。REA 在 6.8.0 抬了这条下限：钉住的 24.22.1 现在是 24 线最低可接受版本，6.7.0 能吃下的 24.11–24.21 在这里会被拒。版本偏低不会在安装时失败， 而是到 MCP 行启动时才失败 —— 表现就是"没有反应"。

反过来先装插件也可以，但要分两步：发布的行指向 /plugins/rea-bundle/bin/rea-shim.mjs， 而那个文件只有 setup 会创建——所以在第一次供给之前，该行会以 MODULE_NOT_FOUND 退出，也就没有 任何东西能去启动后台供给（harness 本身不受影响：failOnStartupError: false 是刻意的）。先手动跑一次 node scripts/setup.mjs；此后 shim 就位，之后每一次「状态缺失」都由它自己发现并在后台补供给。

支持哪些 DSH 版本

package.json 里声明了 engines.dsh: ">=0.1.7-rc.2 <0.3.0-0"，这就是插件市场读的那句话：有它，卡片显示 兼容；没有它，市场只能说*未声明*。这个范围不是猜的——它对应本插件实际核对过的 dsh 发布列表， node scripts/host-compat.mjs 会在两者不一致时让构建失败：

宿主版本 · 是否覆盖 0.1.7-rc.2 … 0.2.1-rc.2（中间的 alpha 与 rc 全部在内） · 是 0.3.0 及以后 · 否 —— 新的小版本线是还没为它核对过这一行的宿主

真正被比对过的是「行提供方」：packages/mcp/mcp-client 在 dsh-v0.1.7-rc.2 与 dsh-v0.2.1-rc.2 两个 tag 上， 暴露的配置面与发布的行完全一致（serverName、transport、command、args、env、failOnStartupError）， 并且两个 tag 都有 dsh.bundle.patch。范围之外的宿主可能照样能用，只是没有替它声明。

机器上已有 REA 就直接用它

2.x 存在的意义是补上机器缺的东西。如果 REA 已经装好——rea 在 PATH 上，也就是 1.x 的形态——这一行就直接跑它， 和 1.x 一模一样，不再做任何供给：

机器上的情况 · 这一行跑什么 rea 在 PATH 上，且不比供给的版本旧 · 你自己那份（rea mcp），用你的 Node 和你的 PATH rea 在 PATH 上，但比供给的版本旧 · 供给出来的 bundle —— 旧的全局 CLI 会把工具数往回退（6.4.0 是 170 个，6.7.0 是 207 个，6.8.0 是 229 个） PATH 上没有 rea · 供给出来的 bundle，首次使用时自行供给

• REA_BUNDLE_LAUNCH=auto|system|bundle 覆盖这个判断（默认 auto）；REA_BUNDLE_SYSTEM_REA= 用来点名一个

不在 PATH 上的可执行文件。

• 探测用的是 CLI 自己的 --version，上限 8 秒：Windows 上的 .cmd 垫片要 ~2.4 秒才答得出来，所以这个检查每次启动

只做一次，而且只在真的存在 rea 时才做。

• --shim-status 会把判断结果打出来 —— launch.mode、launch.reason、launch.systemRea，launch.rejected 里