有次接一个金融类 App 的接口调试，对方服务端开启了 HTTPS 双向认证——客户端需要出示证书才能建立连接，服务器也会验证客户端证书的有效性。Charles 挂上代理后，TLS 握手阶段直接失败，连请求列表都没出现。这类场景在金融、支付和企业级应用中越来越常见，但常规的代理抓包工具基本都走不通。
双向认证为什么让代理抓包失效
HTTPS 双向认证（也称双向 SSL/TLS）和常见的单向认证流程不同。单向认证只验证服务端证书，客户端确认服务端身份之后就可以建立加密通道。双向认证在此基础上多了一步：服务端在握手时会要求客户端出示证书，验证通过后才允许通信。
Charles 这类代理工具的抓包原理是中间人攻击。客户端连的是 Charles 的假服务端，Charles 再连真实服务端。在单向认证下，客户端只要信任 Charles 的 CA 证书就不会报错。但在双向认证下，服务端会要求 Charles 出示客户端证书——但 Charles 没有这个证书，所以握手失败，Charles 也拿不到任何数据。
常见应对方案
反编译注入：通过 frida 或 objection 在运行时 hook 证书校验逻辑，绕过双向验证。具体步骤是越狱或侧载设备，运行 objection 的 ios sslpinning disable 命令。这套方案的问题是需要越狱环境，且部分 App 做了反调试和反 hook 检测，frida 可能被检测到。
证书提取：从 App 的 IPA 里提取客户端证书 P12 文件，导入到 Charles 的 SSL Proxying Settings 里配成客户端证书。理论上可行，但实际中证书通常被加密存储在 Keychain 或二进制中，提取难度很大。
修改客户端代码：如果有源码，可以临时注释掉双向验证逻辑编译测试包。开发阶段可以这样做，但测试环境和线上环境不一致，有些问题只能在完整双向认证环境下复现。
SniffMaster 暴力抓包的方案
SniffMaster 的暴力抓包走的是 USB 设备直连模式，不经过 HTTP 代理中转。iOS 设备用 USB 线连上 Mac，选择暴力抓包模式，工具直接从底层通信通道读取 iOS 设备的网络数据。
产品描述里明确提到支持 HTTPS 双向验证爆破。暴力抓包模式下不依赖 CA 证书信任链，所以客户端是否信任某个代理证书不影响抓包结果。服务端要求客户端出示证书时，这个握手过程在设备和服务器之间直接完成，暴力抓包只是旁路读取数据，不会干扰 TLS 握手流程。
操作流程：USB 连设备 → 解锁亮屏 → 信任电脑 → 开开发者模式（iOS 17.4+） → 选择 HTTPS 暴力抓包 → 勾选只抓指定 App 过滤干扰数据 → 开始。不需要配置代理、安装描述文件或导入任何证书。
需要注意的一点是，暴力抓包对于未使用开发证书签名的 App（如 App Store 版），只能看到请求头和地址，请求体和响应体需要开发证书重签名后才能完整查看。
建议
开发阶段测试双向认证接口用暴力抓包最直接。Charles 在普通单向 HTTPS 场景下依然是主力工具，遇到双向验证或 SSL Pinning 时用Sniffmaster暴力抓包作为补充。
