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:

Two lines: 1.x and 2.x

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/