问题的本质：不知道 cookie 是哪来的研究大麦抢票，接口本身不难模拟，真正的门槛是风控 cookie——cookie2、sid 这几个值。它们什么时候被写、被谁写、写之前发了什么请求，不搞清楚这些，协议模拟永远差临门一脚。网上找不到这类资料，大家只会教"抓包看参数"。我的解法是做一个 Chrome 扩展级的 cookie 溯源工具：不猜，直接监控——谁写的、什么时候写的、写之前 1 秒内页面发了哪些请求，全部记录下来自动关联。扩展架构：三层结构MV3 扩展分三层，各司其职：injected.js：注入页面主世界，hook document.cookie 的 setter，拿 JS 写 co

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

背景做 1688 商家工具，绕不开千牛 IM：自动回复、发商品卡片、发位置消息。但 1688 的聊天不是普通的 HTTP 接口——它走的是 WebSocket + 阿里 LWP 私有协议，网上几乎找不到任何资料。这篇文章记录我从零摸透这套协议、并徒手构造一条位置消息的全过程。第一步：确定协议栈打开 1688 聊天页，F12 看 Network，会发现消息收发根本不走 XHR，全部在一条 WebSocket 连接里。所以第一件事是 hook 掉页面的 WebSocket，把真实流量看清楚：function hookWS() { if (window.__wsHooked) return

为什么需要 unidbg上一篇讲了 Frida RPC 方案：在真机上注入优酷 App，借 App 自己的代码算 x-sign。这个方案能用，但有几个硬伤：依赖常驻设备，手机一挂服务就挂单进程串行，并发上不去App 不能升级、不能清数据，维护成本高unidbg 提供了另一条路：在 JVM 里模拟 ARM 指令集，直接加载并执行 App 的 SO 库。不需要手机，不需要 App 运行，一台服务器可以起几百个实例并发跑。unidbg 原理简述unidbg 是一个基于 unicorn（CPU 指令模拟器）的 Java 库，它做了三层模拟：指令层：unicorn 模拟 ARM/ARM64 指令执行系统

背景之前的文章《优酷生成淘宝绑定二维码协议》里提到过，绑定业务的核心是调通两个 mtop 接口：mtop.alibaba.ucc.taobao.apply.usertoken：用优酷 sid 换 userTokenmtop.alibaba.ucc.getlocalsiteauthurl：用 userToken 换 request_token，生成绑定二维码这两个接口挂在阿里 mtop 网关（acs.youku.com / acs.m.taobao.com）下面，请求头里必须带齐签名四件套：x-sign：请求签名，对 data、时间戳、appKey 等计算得出x-sgext：签名扩展信息x-mi