TikTok Web 与 Shop 不是一条签名能概括的保护，而是几条可以单独验收的工程链路。我把它们拆开，再分别做到可离线、可对照、可复查。
背景与约束
现场同时出现三类问题：Web API 要过签名，Shop 验证码走 WASM 加密，Shop 站点本身还有取页与商品查询。把它们揉成一次“反爬成功 / 失败”，会让已经对齐的算法被反复改写。
本案例的完成标准是分层交付：
- JavaScript 签名能在 Node 中脱离浏览器产出；
- Shop 验证码离线结果与浏览器样本字节一致；
- 文档取页、传输环境和商品接口各自给出可观察结果。
我的工作
在 Web 签名链路里，我用 Node vm 加载真实 SDK，只补齐运行时真正访问到的环境，并用 JSVMP opcode trace 记录操作数、寄存器和关键 payload。X-Bogus 与 X-Gnarly 都可以在这个最小闭包里产出，不必把完整浏览器当成运行时。
在 Shop 验证码链路里，我提取 Emscripten crypto.wasm，确认导出函数、内存布局和参数关系，随后还原 SHA-512 双链 KDF 与 AES-256-GCM。算法层用真实样本做中间值和最终密文对照，形成可以反复执行的离线实现。
Shop 文档页我先做请求头对照。拦截发生在任何页面 JavaScript 之前，说明取页是边缘层，不是客户端签名失败。来源头变化时，结果在短拒绝体和完整 HTML 之间稳定切换，这一层可以单独验收。
文档可取之后，搜索、建议词和商品详情按独立业务接口验收。页面打开、签名对齐和商品数据到达，分别记账。算法收敛后，再用单变量 A/B 看会话、请求头、TLS / HTTP2 以及浏览器与纯 HTTP 环境各自的影响。
关键链路
真实样本
→ 边缘取页（JS 之前）
→ Node vm / JSVMP 签名
→ WASM KDF 与 AES-256-GCM
→ 会话与请求头
→ TLS / H2
→ 搜索 / 建议词 / 商品详情
每一层都有自己的完成证明：HTML 与短拒绝体确认取页；中间值和密文字节确认算法；固定请求下的对照确认传输；业务字段确认商品接口。
已经实现
- Node
vm加载真实 SDK，脱离浏览器执行； - X-Bogus 与 X-Gnarly 离线产出；
- JSVMP opcode trace 与关键 payload 还原；
- Emscripten WASM 提取与内存布局确认；
- SHA-512 双链 KDF 还原；
- AES-256-GCM 参数还原；
- Shop 验证码 4/4 样本字节级一致；
- Shop 文档页边缘取页分层；
- 搜索、建议词、商品详情独立验收；
- 会话、请求头、TLS / H2 单变量对照。
验证方式
验证码链路用 4 个真实样本逐项比较，离线密文与浏览器结果 4/4 一致。这是算法层的完成证明，也是后续实验不再回改 WASM 参数的底座。
Web 签名在 Node 中重复产出，并与真实请求字段对照。Shop 文档页比较短拒绝体与完整 HTML，确认分界发生在页面 JS 之前。商品接口在取页与签名之后单独看业务字段。
传输层在固定请求内容下只改一个变量。结果随该变量稳定变化时，才把它记入该层的影响条件。分层 oracle 让每一层都可以单独复查。
从事实推出的设计判断
算法层字节对齐之后应当冻结，把会话、传输和商品接口作为下一层问题处理。新样本或中间 trace 出现差异时，再打开对应层。
环境只保留真实访问路径上的对象，并且每层用不同的完成证明。这样 SDK 更新时，可以按层对照，而不必整包重拆。
事实边界
本案例覆盖当前样本下的 Web 签名、Shop WASM 验证码、边缘取页、传输对照和商品查询。后续 SDK 与站点策略用同一套分层门禁续跑。
封面为视觉意象。
