👦百趣云

curl_cffi 为什么是当前的最优解Python 爬虫的 TLS 指纹伪装方案演进：requests（无伪装）→ pyhttpx/tls-client（半吊子）→ curl_cffi（完整方案）。curl_cffi 胜出的原因：基于 curl-impersonate，TLS 指纹逐字节级复刻（不只是 JA3，整个 ClientHello 的字节序都对）HTTP/2 指纹同步模拟（SETTINGS 帧、优先级、窗口更新全对齐浏览器）API 兼容 requests，迁移成本几乎为零pip install curl_cffi基础用法：和 requests 几乎一样from curl_cffi i

为什么抓包工具失效时要 hook libsslApp 做了 SSL Pinning 后，Charles/mitmproxy 这类中间人抓包全部失效——证书校验在客户端代码里写死，代理证书不被信任。但有一个地方永远是明文：加密前和解密后的数据。所有 HTTPS 流量最终都要经过 SSL 库的 SSL_write（加密前）和 SSL_read（解密后），在这里 hook，Pinning 形同虚设。Android 上绝大多数 App 用 BoringSSL（Google 的 OpenSSL 分支），SO 名字是 libssl.so，或静态链接进自己的 SO（比如抖音的 libttboringssl）

小红书扫码登录的入口小红书 web 端（www.xiaohongshu.com）登录弹窗默认就是扫码。它的扫码协议特点是：全程走自家 API 网关，且每个请求都带 x-s/x-t 签名（签名逆向见前文"小红书 x-s/x-t 签名参数还原"篇）——这是和别家最大的不同，扫码协议本身不复杂，但签名是前置门槛。流程拆解第一步：生成二维码POST https://edith.xiaohongshu.com/api/sns/web/v1/login/qrcode/create Headers: x-s, x-t (签名)返回 qr_id 和二维码内容（一个 URL）。qr_id 是轮询凭证。第二步：轮

为什么要监控 WebView混合开发 App 的核心逻辑经常不在 Java 层而在 H5 里：登录态的传递、支付回调、加密参数的生成，都通过 WebView 的 JSBridge 在 native 和 H5 之间穿梭。只 hook Java 层会漏掉一半的信息流。监控 WebView 要抓三个点：loadUrl（加载了什么页面）、JSBridge（双向通信内容）、evaluateJavascript（执行了什么 JS）。监控 loadUrl 与页面加载Java.perform(function() { var WebView = Java.use('android.webkit.Web

iOS 抓包的三层障碍iOS 上抓 HTTPS 比 Android 更折腾，障碍分三层：系统层：iOS 默认信任用户安装的 CA（描述文件装证书后还要在"设置→通用→关于→证书信任设置"里手动开完全信任——这一步 90% 的新手会漏）ATS（App Transport Security）：苹果强制的安全策略，但只卡"系统 CA 不信任"的场景，装了证书就过SSL Pinning：App 代码里写死证书/公钥校验，系统信任链完全被绕过——这是真正的城墙SSL Kill Switch 2：一键绕过 PinningSSL Kill Switch 2 是 iOS 上绕过证书绑定的标准工具，原理是 ho