前言¶
在 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 版本與報錯原文。
