🔖抖音

扫码登录的本质：一场三方接力扫码登录协议的设计目标是"用已登录的 App 给无登录态的 web 端授权"。参与三方：web 端（展示二维码）、App 端（扫码确认）、服务端（状态仲裁）。整个流程是一场状态机接力：web 生成二维码(含 token) → 轮询状态 ↓ App 扫码 → 解析出 token → 带 App 登录态请求"确认登录" ↓ 服务端确认后 → web 轮询到"已确认" → 换取登录 cookie逆向的关键是搞清楚每个状态的接口和参数。抖音 web 端扫码流程实测第一步：获取二维码GET https://sso.dou

先认清对手：a_bogus 是 VMP 保护的抖音 web 端的签名参数从 _signature 到 X-Bogus 再到现在的 a_bogus，防护强度一路升级。当前版本的生成代码在 webmssdk.js 里，整个文件跑在字节自研的 JS 虚拟机上——你看到的不是 JS 代码，而是一堆字节码和一个巨大的 switch-case 解释器。这意味着"读源码理解算法"这条路基本被堵死：不是不能，是投入产出比极低。工程上成熟的打法是整段抠出 + 补环境，让这段 VMP 代码在 Node 里原样跑起来，我们只管调它的导出函数。第一步：确认签名入口webmssdk 加载后会在 window 上挂出入口

为什么常规套路对抖音全部失效想抓抖音 App 的包，网上教程的套路是：装 Charles/Fiddler 证书 → 上 JustTrustMe → 完事。真上手才发现对抖音一个都不好使：JustTrustMe 无效：抖音不信任用户证书，且 SSL Pinning 不止一处hook okhttp3 报错：java.lang.ClassNotFoundException: okhttp3.RealCall——抖音根本不用 okhttp，网络库是字节自己封的 com.bytedance.retrofit2.SsHttpCallJava 层全 hook 了还是看不到明文：因为 TLS 加解密发生在 N