fix(client): MCP 客户端 session newbind 报 not found pipeline（附 svcgen 插件）

[sss12365]

Summary

修复通过 MCP 客户端执行 session newbind --pipeline <bind_pipeline> --target <ip:port> 时报
rpc error: code = Unknown desc = not found pipeline、bind 会话无法建立的问题。
同一操作在 tui / webui 客户端正常。

Root Cause

session newbind 是两步 RPC（client/command/sessions/new.go）：
Register 注册会话 → InitBindSession 驱动 listener dial 目标。失败发生在第二步：

• 服务端 loadPipelineStreamForSession（server/rpc/generic.go:324）查找 listener 流，
  而 pipelinesCh 的写入方（server/rpc/rpc-listener.go:86）只写 listenerID/pipelineID 复合键，
  命中查找要求 sess.ListenerID 非空且与 listener 注册时一致。
• sess.ListenerID 来自客户端注册时提交的 RegisterSession.ListenerId（server/internal/core/session.go:112），
  但修复前客户端根本没有设置该字段 → 复合键不匹配、退化路径也被跳过 → 返回 ErrNotFoundPipeline。
• tui / webui 构建的 RegisterSession 携带 ListenerId，所以正常。

旁证：失败时 Register 成功、session_register 事件正常发出，但 listener 从未收到 init 请求、从未发起 dial——与失败点在第二步完全吻合。

Fix

唯一改动文件：client/command/sessions/new.go（+22 / −0）

1. Register 时携带 ListenerId: resolvePipelineListenerID(con, PipelineID)
2. 新增 resolvePipelineListenerID：通过客户端缓存中已有的 pipeline→listener 映射
   （common.FindCachedPipeline）自动解析，对用户透明、不改变 CLI 用法
3. import 增加 client/command/common

设计取舍：

• 修客户端而非服务端：RegisterSession.ListenerId 在 proto 中本就存在（第 3 字段），
  服务端原样落库，tui/webui 也依赖它工作——契约早已定义，是 MCP 客户端未履行；
  改服务端兼容空值属于放大改动面。
• 查不到返回空串而非报错：保持与旧行为一致的降级路径（服务端有空 ListenerId 的兜底逻辑），
  不引入新的失败模式。

Test Plan

• MCP 客户端执行 session newbind --pipeline <p> --target <ip:port> 成功建立 bind 会话
• tui / webui 客户端同操作行为不变
• pipeline 名不存在时降级行为与旧版一致

---

附：svcgen 插件（Windows 服务版 implant 生成工具）

本 PR 同时携带了 svcgen 插件源码：svcgen/（mal.yaml、main.lua、svcgen-guide.md）。安装方式见下方「部署方式」。
说明：main.lua 注册的命令行 flag 已与本指南统一为 --src / --dst / --addrs（--wait 为 console 全局 flag）。

svcgen 是一个 IoM mal（Lua）插件，作用是生成 Windows 服务版本的 implant（beacon）：把「构建一次 → 按 C2 地址批量 patch」的流程固化为一条客户端命令，每个 C2 地址产出一个 exe，换 IP 不用重新编译。

命令用法

svcgen --src <基础implant.yaml> --dst <输出目录> --addrs ip1:port,ip2:port --wait

示例：

svcgen --src /home/kali/Desktop/iom/implant-svc.yaml --dst /home/kali/Desktop/iom/out --addrs 192.168.59.141:5001,10.10.10.10:5001 --wait

参数	说明
--src	基础 implant.yaml 路径（client 侧绝对路径），决定编译期特性（windows_service、模块等）与固定 obf_seed
--dst	输出目录（client 侧），不存在会自动创建
--addrs	逗号分隔的 C2 地址列表（tcp+tls 协议，与 targets 配置一致）
--wait	全局 flag，阻塞等待完成（建议带上）

产物

• <dst>/base.exe — docker 全量编译的基础 beacon
• <dst>/svc_beacon_<ip_port>.exe — 每个地址一个变体（服务端模板 patch，秒级）

执行流程（插件内部）

1. rpc.Build（Source=docker）全量编译 base exe（约 30-60 秒），轮询 rpc.ListArtifact 直到完成
2. rpc.DownloadArtifact 下载 base.exe
3. 对每个地址：改写 yaml 的 targets.address 与 tls.sni → rpc.Build（Source=patch，模板 patch，约 1 秒）→ 下载

通过 MCP 触发：execute_command("svcgen --src ... --dst ... --addrs ... --wait")；需要一个 active session（仅借用其 RPC context，对目标无操作）。

部署方式

前置条件（一次性）

依赖	说明
新版 malefic-mutant	服务端 .malice/bin/malefic-mutant 必须支持 tool patch -i ... --from-implant（旧版不兼容）。注意 server 重启会还原该二进制，需重新替换
patch 模板	服务端 <ServerRoot>/templates/ 下放带固定 obf_seed 的模板 exe，命名 malefic-<transport>-<target>[.exe]，如 malefic-tcp_tls-x86_64-pc-windows-gnu.exe。建议同时放 malefic-http_tls-... 别名（pulse 段的 http: 会导致传输类型误判）
基础 yaml	必须含固定 obf_seed（patch 靠它派生 prefix 定位配置槽；随机 seed 的产物无法 patch），且含 windows_service: true

安装 / 更新插件

# 插件源为 svcgen/（mal.yaml + main.lua）
cp -r svcgen /root/.config/malice/mals/svcgen

mal load svcgen        # 成功输出: Loaded lua plugin: svcgen, register 1 commands
# 更新: mal remove svcgen -> 覆盖 main.lua -> mal load svcgen

常见问题

现象	原因	处理
mutant tool failed: unexpected argument '-i'	服务端 mutant 是旧版	重编 release 版替换 .malice/bin/malefic-mutant（备份旧版）
implant.yaml is missing basic.obf_seed	yaml 没带固定 seed	basic: 下加 obf_seed: <固定整数>，重新构建基础 exe
patch 报 template not found for transport=http_tls	pulse 段 http: 导致传输类型误判	templates 补 malefic-http_tls-<target>.exe（可与 tcp_tls 同文件）
prefix+seed pattern not found in binary	被 patch 的二进制不是用该 seed 构建的	模板 exe 必须是用带固定 seed 的 yaml 构建的那个
生成的 exe 在 Win7 弹缺失 DLL	旧产物依赖 RoOriginateErrorW	构建端 .cargo/config.toml 的 windows-gnu rustflags 加 "--cfg=windows_slim_errors"