瑞数 6 双阶段 Cookie 逆向复盘：从 412 到 200 的一次纯 Python 还原经验总结
文章目录
- 声明
- 一、结果先说
- 二、这次样本最重要的判断
- 1. 它不是普通接口签名，而是页面级风控握手
- 2. 真正的关键数据在首个 412 页面里，不在“业务接口”里
- 三、最终跑通的协议链路
- 第 1 步：第一次请求页面，接受 `412`
- 第 2 步：从 `$_ts.nsd` 生成运行时映射表 `cp1`
- 第 3 步：解析 `$_ts.cd`，恢复动态任务结构
- 第 4 步：根据运行时 key 继续恢复固定段数据
- 第 5 步：拼装 `basearr`
- 不是所有“环境字段”都需要完整浏览器才能得到
- 第 6 步：两轮加密，生成挑战 Cookie
- 第 7 步：第二次请求同一页面，状态码回到 `200`
- 四、这次逆向里最关键的几个突破点
- 1. 从“分析前端大 JS”转为“分析首包协议”
- 2. 认识到 `$_ts.cd` 不是“数据”，而是“数据 + 解释器入口”
- 3. Cookie 合并而不是覆盖
- 4. 原始文本解析优先于“先 decode 成正常页面”
- 5. 当前站点并不需要“完整浏览器补环境”
- 五、值得长期复用的方法论
- 1. 把逆向目标拆成“可验证中间件”
- 2. 优先找“结构稳定”的东西，而不是“字面看起来像算法”的东西
- 3. 状态码迁移本身就是“定位地图”
- 六、需要明确规避的坑
- 七、面对瑞数 6 常规处理流程
- 第一层：先判断是不是“两阶段 Cookie 挑战”
- 第二层：先找动态种子，再找运行时 key
- 第三层：只有过不去时再怀疑环境
- 八、可复用的排查清单
- 协议侧
- 数据侧
- Cookie 侧
- 环境侧
- 验证侧
- 九、核心结论
声明
本文章中所有内容仅供学习交流，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关，若有侵权，请私信我立即删除！
一、结果先说
这次的目标已经达成：纯Python能够稳定拿到首包挑战信息，正确生成目标 Cookie，并把同一页面请求从412拉回到200。
从最终实现看，这一类站点的关键并不一定是“完整浏览器自动化”，也不一定是“把整份大 JS 全部跑起来”，而是：
- 识别这是一个两阶段握手。
- 接住首个
412响应里的动态下发数据。 - 还原服务端期望的动态 Cookie 计算链。
- 把首包
Set-Cookie与本地生成的挑战 Cookie合并后重放。
如果这四件事做对，很多看起来复杂的前端混淆，最后都会收敛为“协议问题”而不是“浏览器问题”。