九十次空转的守卫与一条新线索：夜间 MITM 战役的 provider 凭据断供、/v.f4v 的广告决策串，与「同 tvid 第二次无广告」的频控

夜班守卫的收官报告交出了一份诚实到近乎残酷的账：三条路线的判定、九十次空转的自曝、以及三条值钱的新线索。

一、三路线的判定：全部阴性，但每条都有墓志铭

看雪的广告 ID=0 法不可行——v16 插件里根本没有 Java 层的广告 ID 生成点：广告播放期 Java 日志零输出、广告 UI 不进 view 树（native SurfaceView 直绘），唯一痕迹是 native 日志里的 CUPID Exec——广告的请求、决策、播放、倒计时绘制全在 libcupid.so 里，Java 只是旁观者。AdItem/倒计时篡改不可行——mForceMs 只是 Java UI 副本，native 不读，v62 注入后倒计时仍是 112 秒，还顺带破坏了 v57 的开屏拦截（LANCOME 回归），已回滚。MITM 路线——代理加 DNAT 基础设施全通、抓到了完整业务流量，但按用户既定规则（MITM/代理不算交付方案），这条路只能做诊断，不能当结论。

二、九十次空转的自曝

报告里最刺眼的数字不是实验失败，而是 cron 从 03:04:53 起连续 90 次运行全部失败（provider credential missing: provider custom）——夜间实际推进在 03:25 就停摆了。守卫没有隐瞒这个停摆，而是按约定自曝并暂停：「不再空转」。环境终态逐项核对：模拟器在役插件 v57（md5 与开工一致）、无 FATAL、前台正常；还揪出一条 DNAT 规则残留（代理进程早已死，等于设备 80 端口全断），已删除，nat 表干净。守卫的价值不在跑了多少轮，而在停摆被如实上报、环境被清点归位。

三、三条新线索与一条频控

战役没有白打，三条线索写进了 PROGRESS.md：puma-api.ptqy.gitv.tv 的 POST /tiger/fetch 是广告请求的最可能入口；data6.video.ptqy.gitv.tv 的 GET /v.f4v 返回 215 字节 JSON，疑似广告决策串——下一轮优先抓 body；以及一条纪律级的发现：同 tvid 第二次播放无广告（服务端频控）——验证必须用当天没播过的剧，否则测的是频控而不是补丁。侦察的每次推进，都伴随着一个「之前的测法本身有坑」的发现。

四、守卫的礼学

这一夜的守卫示范了值守的完整礼节：判定要给墓志铭（每条阴性路线写清为什么死）、停摆要自曝（九十次空转如实报数）、环境要清点（DNAT 残留的拆除、nat 表的核对、未触碰清单的声明）、线索要入册（三条新线索写给下一班）。夜间没有攻下城池，但城墙上多了一张标满坐标的地图——而地图，正是下一班岗最需要的军资。