dsh-prompt-hub

probe() 是实例地址的可用性检查，而 resolveUrl()/applyToken() 会把 dsh 访问 token 拼进该 URL（`url + '?token=' + encodeURIComponent(tk)`），token 因此出现在请求路径中。关闭证书校验后，任何网络中间人或被误连的主机都能用任意证书应答探测、获知带 token 的 URL 被轮询并读取该请求；由于服务端身份从未被验证，probe 的 `looksLikeDsh` 结论也不可信。

install({dir, registry, distro, user, version}) 用插值拼出完整 shell 命令行，再以 `wsl.exe ... bash -lc <script>` 或 `cmd.exe /d /s /c <cmd>`（windowsVerbatimArguments）执行。值里只要包含引号加 `&`、`|`、`;` 或 `$(...)` 就能逃出引号，以用户权限执行任意命令；`version` 经 specFor() 进入包描述，带空格即可追加任意 npm 参数（例如另一个 --registry）。同样的插值也出现在 verify()（第 246 行）与由 binPath 拼出的路径里。前提：这些值来自应用自身的安装界面/持久化配置，经 `install:run` 桥（src/preload/preload.js 第 32 行）传入；本次收获的文件中未发现远程页面或未认证方可提供这些值的路径，故属校验缺陷而非已证实的远程利用。

config.json 里的 `launcher.command`（以及被插值进 bash 命令的 `logFile` 路径）会在该实例启动时通过 `bash -lc` 或 `cmd.exe /c` 执行——包括 `autostart` 为真时的自动启动。appdata.js 会在旧目录（%APPDATA%\dsh-shell、'DSH套壳' 等）窗格更多时把其中的 config.json 迁移进来，因此在已废弃目录里投放的配置可能被拉取并执行。这既是设计功能，也需要对用户 AppData 配置的本地写权限（即攻击者已能以该用户身份运行），故为 low。

注释声称仅在自动化取证（--eval/--shot）时开放，但 src/main/main.js 未被收录，无法验证该开关。如果主进程的 handler 未再次校验该标志，宿主渲染层里的任何代码都能在任意窗格 webview 内执行任意 JavaScript —— 包括挂着远程 DSH 实例、登录态生效的窗格。其它文件中未发现混淆或额外的 argv/命令行处理，故属加固缺口而非已证实的利用。