文章目录

• • 声明
  • 前言
  • 一、目标站点
  • 二、第一轮拆链：把三个签名和一个 `471` 分开看
  • • 1. `s` 和 `x-sign` 很像统一请求层逻辑
    • 2. `td-session-sign` 的气质完全不一样
    • 3. `471` 是第四个问题，不能和签名混在一起
  • 三、为什么我第一阶段先选择“浏览器提取”，而不是直接纯算
  • 四、从“能调用”到“值得白盒”：我怎么判断继续往里挖
  • • 1. 有没有稳定样本可供对比
    • 2. SDK 内部是否存在可离线复用的核心
    • 3. 输入维度是否比想象中少
  • 五、真正的突破口：先承认 `_fmOpt.sign()` 只是包装器
  • 六、把 `fm.js` 当成“WASM 容器”看，问题就顺了
  • • 1. 提取 WASM 负载
    • 2. 搞清楚导出函数分别干什么
    • 3. 先不要急着还原所有导入函数语义
  • 七、最关键的白盒结论：真正参与签名的是环境串，而不是你想象中的整个请求体
  • • 这些字段分别来自哪里
    • 为什么这一步特别容易漏
  • 八、把“环境采集”单独建模，是这次代码落地最值的一步
  • • 1. 明确了“采集”和“拼接”的边界
    • 2. 可以同时支持“手工输入”和“浏览器采集”
  • 九、真实环境采集链为什么一定要补 `webgl`、`navigator_keys`、`screen_keys`
  • • 1. `webglVendorAndRenderer`
    • 2. `navigator_keys`
    • 3. `screen_keys`
  • 十、Python 里复用 WASM 时，我刻意没有做“过度实现”
  • • 1. 不去硬复刻整个浏览器运行时
    • 2. 不默认复用同一个 signer
    • 3. `body` 先保留接口，但不要假装它已经参与核心
  • 十一、`td-session-key` 和 `td-session-sign` 其实是两条相关但独立的输出链
  • 十二、从“白盒能跑”到“接口可用”，中间还差一个 `curl_cffi`
  • 十三、td-session-sign算法脚本实现
  • 十四、总结这次逆向最重要的五个判断
  • • 判断一：不要把所有失败都归因到签名
    • 判断二：看到 `_fmOpt.sign()`，先把它当包装器，不要当终点
    • 判断三：先让黑盒方案可用，再决定要不要白盒
    • 判断四：纯算能不能做，关键看有没有“可离线核心”
    • 判断五：真正决定结果的，不一定是你直觉里的请求体