dsh-plugin-rea

English · 简体中文

Which version is this? 2.x — and main is it. 2.x provisions the runtime itself (Node, the REA CLI, a JDK, Ghidra) and then wires the row: install the plugin, run scripts/setup.mjs once, restart dsh. 1.x is the older configuration-only adapter — it expects rea on PATH and Ghidra installed by you — kept on the v1 branch and on npm as dsh-plugin-rea@1.0.6. Full comparison: Two lines: 1.x and 2.x · upgrading: Upgrading from 1.x.

REA 6.8.0 — this package's pin — still accepts Ghidra 12.1.x only (12.2 is unsupported, and the whole Ghidra decompile/analysis group disappears) and the jadx bridge 0.7.1 only (0.8.0 fails on its first call with Expected engine 0.7.1, before any APK is loaded). Both gates were re-checked against 6.8.0 on 2026-10-26 and neither one moved. JDK 21.0.13 is out upstream, but Adoptium publishes no Windows build of it, so there is nothing to point at here — and it drops only three of the four eMudhra anchors. The trade-off is therefore "all tools green, CVE still open": Ghidra 12.1.4's CVE-2026-100504 / 100505 / 100503 / 113604 stay in the chain — do not analyse untrusted samples with this environment — and the JDK still trusts the eMudhra anchors. Evidence, mitigations and revisit triggers: docs/update-review-2026-10-24.md and docs/update-review-2026-10-26.md.

Ghidra 12.2 itself works — measured 2026-10-26: same 9 segments, same 341 procedures, byte-identical entry pseudocode as 12.1.4, through REA's own bridge. What blocks it is REA's version-equality check, not the bridge. If you want the CVE-fixed engine anyway, node scripts/ghidra-gate-override.mjs --enable --version 12.2 rewrites that one constant in the vendored copy, records what it changed in <bundle>/ghidra-gate-override.json, and --disable restores it; re-running setup reverts it too. It needs JDK 25+ (application.java.min=25).

You must run node scripts/setup.mjs yourself — once after installing, and once after every plugin upgrade. Nothing runs it for you: a market install or update replaces the package and stops there. Since 2.0.8 a market upgrade keeps the row working (the mirrored launcher re-execs the new one), but it does not move the bundle to the new pins — REA and the engines stay at the versions recorded by the last setup run. Skip it on a first install and the row exits MODULE_NOT_FOUND with no tools and no message; skip it after an upgrade and you keep running the old REA silently (check-updates.ps1 reports the drift). If you had enabled the Ghidra gate override (see §9 of the 2026-10-26 review), that setup run re-provisions the bundled REA and the patch goes with it — re-enable it afterwards, or accept the pinned Ghidra again. The full rule set is under Updating.

A first install and every plugin upgrade also show a one-time guide in the Web GUI. It says whether the runtime is missing or behind this package's pin, shows the exact node "<install path>/scripts/setup.mjs" command for that install, and remembers the dismissal per plugin version. It is a notice only: it never runs setup for you and never edits the bundle. Run it once, restart dsh, and the guide stays away until the next plugin version.

Brings the upstream REA — Reverse Engineer Anything MCP server into DeepSeek Harness (dsh), so its tools show up in a session as mcp__rea__*.

What this is

A Cordis bundle with a provisioning layer. package.json declares dsh.bundle.patch, and that patch inserts one row of the official MCP client plugin (@deepseek-ai/dsh-mcp-client). The row launches bin/rea-shim.mjs with the running Node executable; the shim reads the machine-local state that scripts/setup.mjs wrote and starts the REA CLI it provisioned. There is no analysis code here, and the published patch contains no machine path.

Third-party adapter. This repository is not part of REA, ships none of REA's code, and is not maintained by REA's authors. It composes one configuration row and fetches upstream's own releases. Upstream: github.com/morluto/rea (MIT) · docs · rea.tools · npm package rea-agents. REA's own problems go to its tracker; this plugin's problems go to this repository's issues.

It adds exactly three things: the tool registration under the mcp__rea__* names, the per-machine engine environment (GHIDRA_INSTALL_DIR, JAVA_HOME, REA_ADB_PATH, REA_APKTOOL_COMMAND, REA_JADX_MCP_JAR, REA_BROWSER_EXECUTABLE, …) scoped to that MCP child instead of the whole harness, and the provisioning that puts those components on disk.

What it can and cannot do

The analysis is upstream's; this section only restates upstream's own contract so expectations are right.

• It cannot recover complete source code. For native binaries upstream returns pseudocode and assembly, for Android APKs decompiled methods, for JEB units pseudocode, and for JavaScript/Electron modules and their relations. Upstream's tool contract states the pseudocode "is decompiler output, not original source and not text-equivalent" to another provider's output.
• Not recoverable in practice: original identifier names, types, comments, macros and template expansion, build scripts and assets. Optimisation (inlining, reordering), symbol stripping, obfuscation, packing and VM protection only make the output worse.
• Every result carries confidence and limitations (observed / derived / inferred, plus an explicit limitations list). Read them as evidence, never as recovered source.
• Good for: understanding behaviour, locating an implementation, interoperability and compatible re-implementation, security review, migration reference. To obtain actual source code, use the legitimate route — the upstream repository, vendor authorisation, or the vendor's own SDK.

What provisioning cannot buy you. These are upstream host gates, not settings this plugin forgot:

| Capability | Gate | |---|---| | Hopper provider | macOS only | | IDA provider | needs your own IDA and REA_IDA_MCP_CONFIG; REA never launches IDA | | firmware binwalk / unblob | Linux only | | Wakaru JS recovery, pwntools ELF/recorded-crash paths | Linux x64 only | | pwndbg / gdb core context | Linux, macOS | | native mitmproxy captures | Linux (REA_MITMDUMP_COMMAND); HAR needs no engine | | Apple toolchain (Mach-O, plist, asset catalog, LLDB) | macOS only | | capture_process_scenario | Linux/macOS PTY | | apktool (Android resource decoding) | available only when REA_APKTOOL_COMMAND points at something Node can execute directly: upstream execFiles that command without a shell, and Windows cannot execute a .bat/.cmd that way (EINVAL). This bundle wires the official apktool.bat as upstream documents, so on Windows the launcher reports no version and the capability stays unavailable; JADX (a jar) is unaffected |

Two lines: 1.x and 2.x

| | 2.x — this line, main | 1.x — v1 | |---|---|---| | What it is | the adapter plus provisioning: it prepares Node, the REA CLI, a JDK and Ghidra, then wires the row | configuration-only adapter: one MCP row pointing at a rea you installed yourself | | What you need first | nothing for the runtime — provisioning fetches what is missing (with --reuse it adopts an existing Ghidra/JDK instead) | Node.js on REA's engines, npm i -g rea-agents, and Ghidra 12.1.x for native analysis | | First run | run scripts/setup.mjs (or the bootstrap) once, then restart dsh | nothing to run | | The row launches | the running Node executable plus <DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs, which reads that machine's state | cmd.exe /c rea mcp on Windows, rea mcp on macOS/Linux | | Machine state | <DSH_HOME>/plugins/rea-bundle/ — bundle.json, vendor/, cache/ | your own REA and Ghidra installs | | Install | dsh plugin --profile <profile> add dsh-plugin-rea (npm latest ≥ 2.0.0) | … add dsh-plugin-rea@1.0.6, or github:czcdr/dsh-plugin-rea#v1.0.6 |

Both lines ship the same patch shape — one insert row of @deepseek-ai/dsh-mcp-client — and offer the same mcp__rea__* surface; they differ in who prepares the runtime. Moving from 1.x to 2.x takes two commands: see Upgrading from 1.x.

Upstream also registers itself with dsh now (rea setup --client dsh); that route is essentially the 1.x model maintained upstream — configuration only, your own Node/REA/Ghidra. This bundle is the zero-dependency route. Pick one of the three, and never keep two serverName: rea rows at once.

Install

Nothing to install first. On a bare Windows x64 machine:

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

-Reuse adopts a Ghidra/JDK you already have; omit it to download both (about 775 MB from the official releases, checksum-verified). Then install the plugin for your profile:

dsh plugin --profile <profile> add dsh-plugin-rea
# or pin this release instead of tracking npm latest:
dsh plugin --profile <profile> add github:czcdr/dsh-plugin-rea#v2.0.13

On an Electron host (the DeepSeek Harness desktop app) the profile is owned by the application. dsh plugin --profile desktop … is refused by the CLI (profile "desktop" is managed exclusively by the Electron application) — install or update through the in-app plugin manager instead. The CLI form above is for a profile you created yourself with the CLI under another name.

If Node is already installed, you can skip the bootstrap and run provisioning directly:

node scripts/setup.mjs --reuse      # or --dry-run to see the plan first

Node, when you provide it instead of letting setup fetch one, must satisfy REA's engines — ^22.23.4 || ^24.22.1 || >=26.12.1 (check with node -v). REA raised those floors in 6.8.0: the pinned 24.22.1 is now the oldest acceptable 24.x, so a 24.11–24.21 runtime that 6.7.0 accepted is rejected here. A lower Node does not fail at install time; the MCP row fails later, which reads as silence.

Installing the plugin first also works, but it takes two steps. The row resolves to <DSH_HOME>/plugins/rea-bundle/bin/rea-shim.mjs, and that file is created by setup — so until the first provisioning run the row exits with MODULE_NOT_FOUND, and nothing is there to start a background provisioning (the harness itself is unaffected: failOnStartupError: false is deliberate). Run node scripts/setup.mjs once; from then on the shim is in place, and every later missing state is picked up by the shim itself, which provisions in the background.

Which DSH versions

package.json declares engines.dsh: ">=0.1.7-rc.2 <0.3.0-0", and that declaration is the answer the plugin market reads: with it the card says compatible; without it the market can only say unknown. The range is not a guess — it is the dsh release list this plugin is checked against, and node scripts/host-compat.mjs fails the build when the two disagree:

| Host | Covered | |---|---| | 0.1.7-rc.2 … 0.2.1-rc.2 — every