文章目录
-
- 声明
- 前言
- 目标站点与现象
- 初步判断：这不是单纯的首页传感器问题
- 第一阶段：先把首页纯协议链打通
-
- 首页相关脚本
- 本地 helper 的职责
- 结果
- 第二阶段：428 crypto challenge 正式登场
- Challenge 页的真实结构
- 一度很迷惑的点：`bmak` 明明活着，为什么没用？
- 静态分析：把 challenge 核心片段抠出来
- 动态调试为什么一度不顺
-
- 1. challenge 初始化时机非常早
- 2. 关键数据不一定走明文 URL
- 3. 页面里偷偷起了 `blob` worker
- 真正的转折点：`canvas 未实现` 不是噪音，是线索
- 真正的工程解法：补环境，不是只压警告
-
- 1. `OffscreenCanvas`
- 2. `URL.createObjectURL`
- 3. `SharedWorker`
- 4. `self.close()`
- 补完环境后的变化
- Cookie Snapshot：逆向不只是“解”，还是“缓存”
-
- 1. 保存 cookie snapshot
- 2. 启动时优先走 snapshot 快路
- 稳定性增强：别让 DNS 和随机性把你气死
-
- 1. 网络重试
- 2. candidate 扩展与去重
- 这次逆向得到的几个关键认知
-
- 1. 428 不等于“算法错了”
- 2. jsdom 报错有时候是线索，不是垃圾日志
- 3. 浏览器调试的价值，不只是为了“拿到最终参数”
- 4. 最终实现最好是“状态机”，不是“一次性脚本”
- 当前方案的实际形态
-
- 快路
- 主链
- fallback
- 一些经验
-
- 经验一：先分清“算法问题”和“环境问题”
- 经验二：优先找证据链，不要靠直觉恋爱
- 经验三：逆向的最后一公里通常是工程
- 结语
- 附：本次最实用的落地结论
声明
本文章中所有内容仅供学习交流，严禁用于商业用途和非法用途，否则由此产生的一切后果均与作者无关，若有侵权，请私信我立即删除！
一次典型的“本来只是查个物流，最后把 Akamai challenge、canvas、SharedWorker、snapshot 快路全都掀开看了个遍”的记录。
前言
这次目标很朴素：
- 输入 DHL 单号
- 直接请求 utapi
- 稳定拿到结果
- 尽量脱离浏览器
听起来像个平平无奇的接口对接任务。
实际干起来之后，事情逐渐演变成了：
- 首页偶尔 200，偶尔 428
- telemetry 明明发了，服务端就是不认
- challenge 页看着很安静，背地里却在偷偷起 blob worker
- jsdom 里一句 “canvas 未实现”，看上去像警告，实际上是线索
- 最后发现：真正的敌人不仅是算法，还有环境
一句话总结这次逆向：
这不是“把一个 sign 算出来”那么简单，而是“让 Akamai 相信你像个浏览器，又别真去开浏览器跑业务”。
