抖音直播伴侣 5 层协议位欺骗 — 工具链架构总报告

🛑 勘误（2026-05-14 11:55）：本报告原标题为"6 层协议位欺骗"，将 SunnyNet 的 WebSocket 拦截能力作为第⑤层"已覆盖"结论。该论断站不住脚 —— a_SunnyNet__ws_callback 这个 Nuitka mangled 名只要 Python 端 class SunnyNet 定义了这个属性就会出现在二进制字符串表里，并不能反推出 query_tool 实际给 ws_callback 注册了业务回调。本版降级为 5 层确认 + 1 附录未确认，剔除推测性结论，保留作为后续待验证方向。

核心论断（修订后）：这套工具是一个沿协议栈纵向覆盖至少 5 个不同层位的字段替换引擎。任意一个层位被抖音风控盯死都不会让整条链路失败 —— 因为还有其他层在同步伪造同一套抖音身份。这是这套工具能稳定运行的真正原因，而不是任何单一 hook 的精妙。

本报告基于 2026-05-14 完成的： - Ghidra 11.3.2 headless 对 rtmp-hook.dll / mate-launcher.exe / query_tool.dll (15MB Nuitka) 的全量反编译 - ilspycmd 对 画面去重.dll 的 .NET 8 还原 - Sandbox runtime OpenProcess + ReadProcessMemory dump（MediaSDK_Server.exe PID 13472）字节级闭环验证 - query_tool.dll Nuitka 字符串审计（从 mangled 标识符反推 Python 类结构） - 沙盒 SSH 直读 D:\BaiduNetdiskDownload\config.ini 实际字段

完整证据见 08_bonus.md §9、07_external_connections.md §5、decompile/verify_*.py、decompile/verify_hook_sandbox.ps1。

1. 全景图

                    ┌─────────────────────────────────────────────────┐
                    │           直播伴侣 webcast_mate (Electron)      │
                    │             v12.0.3.358280890                   │
                    │      C:\Program Files (x86)\webcast_mate\       │
                    └────┬──────────────┬──────────────────┬──────────┘
                         │              │                  │
        ┌────────────────┘              │                  └─────────────────┐
        │                               │                                    │
        ▼                               ▼                                    ▼
  StreamPlugin.dll                 libssl-3-x64.dll                MediaSDK_Server.exe
   (FLV/RTMP 封装)                   (OpenSSL 3.x)                   (推流主进程)
        │                               │                                    │
        │   ① onMetaData tag           │   ② SSL_write payload              │   ⑤ .rdata literals
        │   build_meta(meta_struct)    │   SSL_write(ssl, buf, len)          │   "windows" string
        │                               │                                    │
        └──── HOOKED by rtmp-hook ─────┴─── HOOKED by rtmp-hook ──────────── HOOKED by rtmp-hook
                                                                              [STR-PATCH] segment

        ┌────────────────────────────────────────────────────────────┐
        │           query_tool.dll (Nuitka onefile / SunnyNet MITM)   │
        │     ③ HTTPEvent.http_callback (webcast REST API Cookie)    │
        │     ④ HTTPSetH2Config + HTTPSetRandomTLS (协议指纹)         │
        │     ──────────────────────────────────────────────────     │
        │     [附录 A] QueryTool.{tcp,ws,udp}_callback 方法存在       │
        │            但 Nuitka 编译后方法体未反编译，行为未验证       │
        └────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
                  ┌───────────────────────────────────┐
                  │      抖音后端 (amemv.com / *.snssdk)    │
                  └───────────────────────────────────┘

5 层中每一层都对应抖音侧具体的、独立的检测点。下面逐层展开。

2. 五层分工详表

层 ① 明文 RTMP onMetaData （FLV tag 层）

层 ② RTMP-over-TLS payload (TLS 加密前的 SSL_write 缓冲区)

关键观察：StreamPlugin.dll 编译时没有导出 SSL_write（静态链接 OpenSSL），所以 rtmp-hook 用 FUN_1800028b0 即 [BORING] 路径做"靠 .rdata 里 "SSL_write" 字面量 + LEA xref + 6 种 prologue 指纹反查"的内联函数定位（实测 sandbox 没命中内联路径 —— webcast_mate 现在用动态加载的 libssl-3-x64.dll 而非内联）。

层 ③ HTTPS webcast REST API Cookie / Header (应用层 HTTP)

层 ④ HTTP/2 + TLS 协议指纹 (传输层握手)

层 ⑤ .rdata 字面量 patch (进程内存常量替换)

3. 为什么 5 层都不可省 — 反向论证

设想抖音风控团队挨个堵每一层：

任何一层失效，其它 4 层仍能维持"伪 Android 移动端 webcast_mate 推流"这个统一身份。这就是它的纵深防御设计 —— 不是任何一处巧妙，而是每一处都覆盖了一个独立的检测维度。

4. 抖音检测点 vs 工具链覆盖矩阵

结论：工具针对协议+设备身份+握手指纹这三个维度做了深度立体覆盖（5 层），但对内容指纹和行为指纹没有协议层手段（依赖另外 2 个二进制）。对手如果在 TCP/IP 内核层或行为时序上做检测，工具链整体仍会暴露。

5. 工程美学评注

这套工具的作者对抖音协议栈的理解极其精细：

1. 知道抖音同时在两个协议层消费 fp_* / p_id 字段 —— 所以两个二进制各自 cover 一层（rtmp-hook 改 RTMP TLS 层，query_tool 改 webcast HTTPS 层）
2. 知道 BoringSSL/OpenSSL JA3 差异是 spoof 的硬伤 —— 用 curl_cffi 模板填了这个洞
3. 知道 .rdata 字面量需要单独处理 —— 因为 webcast_mate 内部不只通过 onMetaData 上报 OS，还在别的地方读 .rdata 字符串
4. 知道 RTMP 流参数恒定 = 录播指纹 —— 加入 jitter (而不是简单替换为静态值)
5. 知道 webcast_mate 后端有 4 个特定 endpoint 需要劫持 —— 不是粗暴地拦截所有请求

但作者也留下了清晰的可识别点（被 §08_bonus.md §5 列出来的）： - flashVer = "BytedanceDouyinLive/30.5.0 (Linux; Android 15; SM-S938B …)" —— Android 设备的 flashVer 一般不会写 Linux - os_version=26.3.1 —— Android 16 最新，26.3.1 是 iOS 版本号（改造时漏改的痕迹，sandbox 实测 config.ini 里仍然是 26.3.1） - webcast_mate/11.7.1 vs sandbox 实装 v12.0.3 —— 工具落后 1 个大版本，UA 不匹配 - windows → Android 只改 1 处，其它涉及 windows 字符串的位置都没碰

也就是说 —— 工具用纵深覆盖换稳定性，但每个层位的细节都有可识别点。这是个精细但不完美的工程产品。

6. 证据来源清单

字节级运行时闭环验证（层① 的 14B JMP-abs64 patch chain）：

real build_meta @ 0x7FFE31EB1F50 (StreamPlugin.dll 内), patch:
    ff 25 00 00 00 00         ← JMP rip+0
    10 17 03 32 fe 7f 00 00   ← abs64 = 0x7FFE32031710 = rtmp-hook+0x1710
                                       = FUN_180001710 = build_meta_replacement
    90 90 90                  ← NOP padding (stolen 17 - JMP 14)

完整 dump 见 decompile/verify_hook_sandbox.ps1 输出。

7. 附录 A：未验证层位 — QueryTool.{tcp,ws,udp}_callback

为什么单独放附录：本附录所述的"潜在层位"在 query_tool.dll 字符串表里有方法名证据，但方法体在 Nuitka 编译后的 .const_data blob 里，Ghidra 反编译未解出实际行为。可能是空 stub，也可能是真实 spoof —— 当前证据不足以分辨。严谨起见不列入"5 层已覆盖"主结论，但记录在此供后续验证。

A.1 SunnyNet 通用属性 ≠ query_tool 业务实现

最初的"6 层"版本错误地把 SunnyNet 通用类 SunnyNet 的 mangled 属性 _SunnyNet__ws_callback / _SunnyNet__tcp_callback / _SunnyNet__udp_callback 当作业务证据。SunnyNet 是开源 MITM 库（qtgolang/SunnyNet），这些属性是 Python 端 class 定义自带的 —— 只要 import SunnyNet，Nuitka 编译时就会把这些 mangled 名字写入字符串表，与 query_tool 是否实际使用无关。

A.2 实际新证据：QueryTool 类自己的方法槽

query_tool.dll 字符串表中有：

uQueryTool.http_callback
uQueryTool.http_callback.<locals>.<lambda>
uQueryTool.tcp_callback
uQueryTool.ws_callback
uQueryTool.udp_callback
uQueryTool.script_log_callback
uQueryTool.script_code_callback
uQueryTool.start_proxy
uQueryTool.start_proxy_thread
uQueryTool.do_query
uQueryTool.manual_query
uQueryTool.extract_text
uQueryTool.update_info
uQueryTool.update_ui_started
uQueryTool.update_ui_stopped
uQueryTool.setup_ui
uQueryTool.show_log_menu
uQueryTool.clear_log
uQueryTool.log
uQueryTool.on_closing
uQueryTool.__init__
uQueryTool.run
uQueryTool.stop_proxy

QueryTool 是 query_tool.dll 自定义的业务类（不是 SunnyNet 库的）。它确实定义了 tcp_callback / ws_callback / udp_callback 三个方法 —— 这是 query_tool 可能给 SunnyNet 注册了非 HTTP 层回调的暗示。

A.3 但仍不能证明的事

注意 http_callback 同时还有 <locals>.<lambda> 符号（说明该方法内部至少创建了一个 lambda 闭包，是有逻辑的，不是空 stub）；而 tcp_callback / ws_callback / udp_callback 没有同样的 <locals> 符号，间接暗示这三个可能是更简单的方法（甚至 def cb(event): pass）。这只是辅助线索，仍非确定证据。

A.4 验证方向（如需补强）

1. Reqable 已抓的 35976 个文件离线分析 — 找是否有 webcast WebSocket 流量被 MITM 改写迹象（response 体里 IM 协议 frame 异常）
2. 沙盒动态 hook — Frida-trace SunnyNetSetCallback 看 ws/tcp/udp 是否真的注册了非 None 回调
3. Ghidra 手动定位 Nuitka 编译产物 — 找 impl_<module>__QueryTool__ws_callback 这种命名规则的 C 函数，看是不是只有 prologue + return None 的几行

完成任一项验证后即可把层⑤"复活"或永久关闭。

8. 后续可深化的方向

1. 附录 A 三 callback 行为验证 — 详见 §7.A.4，本次未做
2. 层③ Cookie 完整审计 — 解密 webcast get_latest_room 请求/响应，对照 fp_* / p_id 在 webcast Cookie 和 RTMP AMF0 两处的具体值是否完全一致
3. 层④ JA3 实测对照 — 用 mitmproxy ja3 plugin 抓 query_tool 出站的 ClientHello，验证选择的 fp 模板是否真的让 JA3 落在 curl_cffi 已知模板范围内
4. 检测点反推 — 如果能拿到抖音风控团队的真实检测脚本，可以挨个验证 5 层每个层位 spoof 的具体应对项
5. 工具链 v2 推测 — 这套工具是 v1，可能将来作者会补充：TCP/IP 层 spoof (用 raw socket / WinDivert)、process name 隐藏 (Detours rename) 、视频内容帧指纹改写

9. 一句话总结

这套工具的本质不是"把 PC 改成手机"，而是"沿着抖音协议栈的每一个会被风控读到的字段位置都做一次伪造"。5 层位 × 字段一致性 × 算法多样性（jitter / type-aware 替换 / fingerprint 模板） —— 这才是它能稳定运行的真正原因。

修订历史

作者：Claude (Opus 4.7)，2026-05-14 依据：Ghidra 11.3.2 + ilspycmd + Nuitka 字符串审计 + Sandbox runtime ReadProcessMemory 字节级验证