登录握手的水下听证会：C2S 全密文的确认、发送路径的真相，与 128 字节密文的 MITM 听证

王庭的大门在夜里只说一种语言：密文。本日的五场听证会，都是为了听懂这种语言的文法。

一、全密文确认：逐包不同意味着什么

ws2_32!send 的钩子（ret 精确指向 send_wrapper 内部）给出第一份证词：所有 C2S 出站字节都是密文——32 字节的心跳、96 字节的操作，随机分布无一明文。而每个 32 字节心跳的密文都不同：相同明文产出不同密文，意味着这不是 ECB 的机械誊写，而是有 IV 或计数器参与的状态流加密。加密点不在已反编译的任何函数里——数据入 0x10020 缓冲之前已成密文，而在线期间 stream_encrypt_fn 零命中。

二、发送路径的真相：三层分工与隐身的誊写者

调用栈的铁证（ws2send ← send_wrapper ← tick_main_loop ← 外部线程）厘清了发送架构的三层分工：应用层消息先入全局队列（环形数组，带时间戳与超时监控）；tick_main_loop 出队、按 [(u16 len)(u16 msgID)][payload] 解析、经 msgID 查找表路由到 handler 的 vtable+0x30；最终 send_wrapper 把 0x10020 缓冲 flush 到 socket。加密发生在 msgID 路由的 handler 内部——誊写者藏身于官署名册的某一页。而 C2S 的登录包根本不走这条分发线（hook 零命中）：它走独立的登录通道。

三、对桩行为学：稳定复现的三段舞步

客户端对自建桩服务器的行为三次复现完全一致：连桩、收下 30 帧 S2C 突发（3ec/463/7f4/3f7/3f9/e9f/408/b07/d72……）、静默七十一秒、发出唯一一包 128 字节密文、再等七十秒无响应、CLOSED。128 字节即 ACC 票据转交/登录请求。soul.exe 的加密常量扫描同时列队：TEA delta 五处（多算法实例）、AES sbox 一处、MD5 K 表两处、SHA1 五处、CRC32 三处——128 字节的密文与 TEA 家族高度可疑。

四、水下听证会：MITM 的首次全样本

排除法收敛之后，MITM 代理链路完成了第一次完整听证：游戏→33115→官方→回包→游戏全通，官方登录确认是 128 字节密文的对称应答（1 秒内回包，5 秒后 RST——官方在等永远不来的第三步握手）。途中还破获一桩积案：redirect 脚本「打印 33115 却写 33114」的硬编码残留——此前所有「游戏连 33114」之谜原来是日志撒了谎。王庭的门第一次向旁听席敞开，虽然席上仍无一人听懂一个词——但至少，每一句话都被一字不差地记进了卷宗。