前言¶
在 DeepSeek Harness（DSH）里直接挂载 REA（npm 包 rea-agents，后端可接 Ghidra、Hopper、IDA）时，单次请求往往要把两百多个 MCP 工具的 schema 带进上下文，体量在 README 给出的测算里约 19 万至 22 万 token。对以对话为主、需要反复查伪代码、交叉引用、字符串的逆向辅助场景，这种「全量工具面」既占窗口，也不利于模型按需检索。
下面介绍社区插件 dsh-rea-dispatcher（维护者 HarunaTyan，分类：客户端）。它不改变 REA 本身的能力，只在 DSH 侧做分发：默认把 207 个工具折叠成 rea_tools → rea_help → rea_call 三条可调用路径，并可选注册六个只读域入口；常驻上下文约 5 KB（相对直接挂载 REA 的约 75 万字节级工具描述），让会话里的 AI 先列目录、再看单工具说明、最后透传调用。
这是什么¶
dsh-rea-dispatcher 是 DSH 的 Cordis 插件（bundle id：rea-dispatcher）。它通过子进程对接已安装的 rea-agents MCP 入口，把 REA 的逆向工具集暴露给宿主，而不是在每次请求里塞满完整工具列表。
插件不代装 Ghidra 或 REA；引擎与全局包需自行准备。与 REA、Ghidra、DSH 无隶属关系，许可证 MIT（见仓库）。
核心功能¶
三条主命令¶
| 工具 | 作用 |
|---|---|
rea_tools |
列工具名与标题，按域分组，支持 filter |
rea_help |
单个工具的必填项、已知陷阱、参数 schema |
rea_call |
调用工具，参数原样透传 |
域入口 rea_native、rea_web、rea_apk、rea_mobile、rea_firmware、rea_general 只列本域工具名，不执行；执行一律走 rea_call。
上下文体积（README 测算）¶
| 接入方式 | 工具数 | 进入上下文 | 折算 token |
|---|---|---|---|
| 直接挂载 REA | 207 | 775,016 B | 约 19 万至 22 万 |
| 本插件（默认） | 9 | 3,404 字符 / 5,322 B | 约 1.3 K |
本插件（domainTools: false） |
3 | 1,481 字符 / 2,213 B | 可忽略 |
配置项 domainTools: false 可关掉六个域入口，只保留上述三条命令。
行为要点¶
- REA 的错误原样返回，插件仅在首行标注来源。
- REA 会话不跨轮：上一轮
open_binary成功，下一轮仍可能报No app is open；默认autoReopen: true会自动重开并重试一次，输出里会标注；可设autoReopen: false关闭。 - 返回超过
maxBytes（默认 20000）时截断，全文落盘并在尾部给出路径与行数，可用 DSH 自带的ops_read_files或ops_grep分段读（spill默认开启）。
安装与启用¶
先自备依赖，插件不代装引擎。
| 依赖 | 用途 |
|---|---|
| DSH | 宿主（版本区间 >=0.2.1-rc.1 <0.3.0-0；0.2.2-rc.x 等后续预发布不在区间内，需插件发版扩区间） |
| Node.js 22 或 24 | 运行 REA 的 MCP 入口 |
rea-agents |
提供 207 个逆向工具 |
| Ghidra 12.1.x 与 JDK 21 | 供需要引擎的工具使用 |
安装 REA 全局包并添加插件：
npm i -g rea-agents
dsh plugin --profile <profile> add github:HarunaTyan/dsh-rea-dispatcher
装好后在 DSH 插件市场启用，或由 AI 侧调用 plugin_manager set_bundle dsh-rea-dispatcher enabled=true，无需重启。执行 dsh --profile <profile> --dump-config，配置中出现 - id: rea-dispatcher 即表示生效。
引擎路径默认读环境变量 GHIDRA_INSTALL_DIR 与 JAVA_HOME。未配置也能加载并列工具目录，只有真正用到引擎的工具会报 REA 自身错误。缺少 rea-agents 时，插件会返回可直接执行的安装提示。
插件以当前 DSH 进程权限运行子进程并调用 REA；安装前建议在 GitHub 阅读源码与 MIT 许可证，确认与你的工作区隔离策略一致。
典型用法¶
这些工具由会话里的 AI 调用，一般不需要手敲。README 中的示例：
rea_tools filter=image
rea_native filter=procedure
rea_help name=inspect_native_load_image
rea_call name=inspect_native_load_image arguments={"path":"C:/target/app.exe"}
rea_help 会在开头标出必填项与高代价陷阱，例如：
# procedure_pseudo_code
必填：procedure
⚠️ `0x…` 若不是函数入口会退化成 file offset；先 procedure_info 拿入口再调用
配置¶
默认值多由环境派生，包内不含机器路径。覆盖写在 profile 的 cordis.patch.yml，entry id 为 rea-dispatcher。注意：patch 里的 config 是整体替换，不是深合并；覆盖时要把会用到的键一次写全。
- id: rea-dispatcher
config:
cwdAllow: ['D:/re-projects']
ghidraDir: "D:/tools/ghidra_12.1.4_PUBLIC"
javaHome: "D:/tools/JDK21"
callTimeoutMs: 600000
maxBytes: 40000
常用键（完整表见仓库 README）：
| 键 | 作用 | 默认 |
|---|---|---|
ghidraDir |
注入 GHIDRA_INSTALL_DIR |
同名环境变量 |
javaHome |
注入 JAVA_HOME，并将其 bin 前置到 PATH |
同名环境变量 |
cwdAllow |
会话目录白名单 | []，不限制 |
maxBytes |
单次返回上限 | 20000 |
autoReopen |
掉线自动重开一次 | true |
domainTools |
是否注册 6 个域入口 | true |
callTimeoutMs |
单次调用超时 | 300000 |
cwdAllow 只约束会话目录：空数组不限制；非空时按路径段比较，且不约束 rea_call 参数里的路径。要更硬的隔离，需把 REA 子进程放进受限账户或沙箱。
适用场景与注意¶
适合：单点可验证的查询（伪代码、交叉引用、字符串、导入导出表）与逐步缩小范围的探索。
不适合：长时间维持同一二进制状态的深挖（超时会丢子进程）；也不适合全量枚举。
REA 侧限制（插件不消除）：
- Windows 上 REA 主要支持 native PE 与 raw 6502；ELF 能
open_binary，深分析可能被 provider 拒绝，报target_format_unsupported。 - 不带符号：同目录 PDB 不会被导入，函数仍可能显示为
FUN_1400xxxxx；要符号需本地跑 GhidraanalyzeHeadless。
常见排错：
| 现象 | 处理 |
|---|---|
未找到 rea-agents 的 MCP 入口 |
npm i -g rea-agents，或配置 reaMjs / REA_MJS |
当前目录未授权 |
会话目录不在 cwdAllow 内 |
target_format_unsupported |
目标格式不支持 |
capability_unavailable |
缺外部工具，例如 tshark |
结尾¶
dsh-rea-dispatcher 把 REA 的逆向 MCP 能力以「先列、再查、再调」的方式接入 DSH，显著压低工具 schema 占用的上下文，同时保留对 207 个工具的透传调用。依赖需自行安装；宿主版本需落在插件声明的 DSH 区间内。
- 社区目录页：https://www.skillhub.cn/plugins/HarunaTyan/dsh-rea-dispatcher
- 源码与完整配置说明：https://github.com/HarunaTyan/dsh-rea-dispatcher
问题与版本信息可提交至仓库 Issues，建议附上 DSH 版本、rea-agents 版本与报错原文。
