一次逆向小众视频平台的全程记录（方法论版）
声明在先：下面平台名字打码、参数脱敏、签名算法只讲思路不讲具体实现。目的不是教人破解，而是记录"当某个视频源的解析挂了，我是怎么定位问题并修好的"。对做下载工具的人，这套方法论比具体结果有用得多——因为平台永远在变，能复用的只有思路。
一、问题长啥样
某天早上，一个长期稳定的源突然返回 403。浏览器能播，工具不行。这种"浏览器行、脚本不行"的落差，99% 出在身份或签名，不是网络问题。先把这个判断钉死，能少走很多弯路。
二、工具箱
我常备三样：
1. 浏览器 F12 → Network：看真实请求长啥样，这是第一现场。
2. mitmproxy / Charles：当请求是 App 发出来的（不在浏览器里），得在手机/模拟器上挂代理抓包，看 HTTPS 明文。
3. 本地复现脚本：Python + requests，逐步把浏览器请求头、cookie 搬过去，看哪一步开始不一致。
别一上来就反编译 APK，那是最后手段。先从"浏览器能播"这件事实出发，把它的请求完整复制出来。
三、第一步：抓浏览器到底发了什么
F12 → 刷新 → 把那个 .m3u8（或 .mpd）请求完整复制，重点看三样：
- Request Headers 里的 Referer、Origin、User-Agent
- 有没有 Authorization 或某个自定义 X- 头
- Cookie 里有没有一串看着像 token 的字段
我这次很快发现：源现在要求 Referer 必须是它自己域名，否则 403。这种最好办，工具里加个 Referer 头就行。
四、第二步：cookie 是会"迟到"的
加上 Referer 能拿到清单了，但 ts 切片还是 403。说明清单和切片鉴权不是一套。回到 Network 看切片请求，发现有个 vtoken=xxxx 在播放开始后约 30 秒才出现——像后端异步下发的临时票。
这类"播放过程中才给的临时凭证"很常见。应对思路：
1. 先请求一次播放初始化接口（拿 ticket）；
2. 把 ticket 塞进后续请求的 Cookie/Header；
3. 注意 ticket 有时效，得在有效期内完成下载，不能先慢慢解析清单再慢慢拉。
我踩过的坑：把"拿清单"和"下载切片"分两个函数、中间隔了几秒，结果 ticket 过期，切片全 403。后来改成"拿到 ticket 立刻启动下载流水线"才稳。
五、第三步：URL 签名
更麻烦的一种是 URL 带 ?sign=xxxx&t=时间戳。服务端用密钥对时间戳做签名，过期失效。浏览器每次刷新都重新算，你的工具得复现这套签名算法。复现一般三步：
1. 在 JS 里搜 sign / md5 / hmac / encrypt，定位签名函数；
2. 把那段逻辑用 Python 重写（常见是 md5(secret + 参数排序拼接) 或 HMAC-SHA256）；
3. 注意参数顺序和拼接方式，差一个 &、少一个空值参数，签出来永远对不上。
这次我没遇到硬编码密钥，密钥是从某个初始接口动态拿的，所以流程是：拿密钥 → 构造签名 → 拼 URL。写成代码后稳跑了一周，后来平台又加风控，那是后话。
六、那些阴人的细节
- 时间戳毫秒还是秒：我第一次写成秒级，签出来永远错，改成毫秒立刻好。文档不会写，只能试。
- UA 必须和浏览器一致：有些源对 UA 做白名单，Python 默认的
python-requests/xx直接拒。复制浏览器完整 UA 字符串最稳。 - 参数里有随机 nonce 但服务端不校验：别被迷惑，照抄即可，不是签名的一部分。
- WASM 签名：新平台把签名逻辑放 WebAssembly 里，纯读 JS 找不到。这种情况要么用
wasm2c/反编译硬刚，要么用 Puppeteer 直接在浏览器环境里调它的签名函数（"借壳"执行），第二种省事得多。
七、反调试与风控
平台会反调试：DevTools 一开就白屏、请求频率过高就封 IP、同 cookie 并发多了就 412。应对：
- 限速：每个任务间 sleep 随机 2~6 秒；
- 限速别打满带宽：--limit-rate；
- 断点续传：--download-archive 记已下；
- 必要时换 UA、加代理池（但代理 IP 风控更狠，慎用）。
八、我最终的方案结构
定位清楚后，工具里加了三层：
1. Referer 固定为自己域名；
2. 动态 ticket 注入 Cookie，且在有效期内启动下载；
3. URL 签名实时算，请求前现算现用。
从此这个源又稳了。
九、边界，必须说
逆向本身是技术活，但落到行动上要守底线：
- ✅ 修自己的工具、服务已授权用户、修本地播放问题；
- ❌ 批量扒付费/版权内容、破解后二传牟利。
我的原则一直是"修工具不碰明文盗链"，这也是工具能长期活下来的原因。一旦沾破解分发，被投诉下架是分分钟的事，技术再牛也白搭。
十、给后来人的 checklist
遇到"浏览器能播、脚本不能"时，按顺序查：
1. Referer / Origin
2. UA 一致性
3. Cookie 里的动态 token（是不是迟到下发）
4. URL 签名 / 时间戳
5. 是否 WASM 签名（考虑 Puppeteer 借壳）
6. 频率/风控（限速、换 IP）
六步走完，基本没有定位不到的源。剩下就是"值不值得"——维护成本和技术快感得自己权衡。