设置了 SSL Pinning 与双向 TLS 验证要怎么抓包-SniffMaster Tutorial

很多人第一次遇到带 PIN（证书绑定）或双向 TLS 验证的 App 时，都会卡在一个阶段，
代理证书装好了，Wi-Fi 代理也生效了，但请求就是消失了。

这并不是配置问题，而是网络路径已经发生了变化。

为什么 PIN + 双向验证会直接掐断代理抓包

在普通 HTTPS 代理抓包里，抓包工具本质上扮演的是中间人。
客户端信任系统证书 → 代理证书被接受 → TLS 能正常建立。

但一旦 App 做了下面任意一件事：

系统信任链这条路就不再成立。
这也是为什么 Charles、Fiddler 这类工具，在这些 App 上会直接变成什么都没有。

在真实项目环境里，我很少一上来就研究 PIN 怎么绕。
我更关心的是：有没有别的抓包方式，能先让我看到真实请求。

在这类场景下，我会直接使用抓包大师的 HTTPS 暴力抓包 模式，而不是继续在代理模式上消耗时间。

这个模式有几个关键差异点：

这意味着，即使 App 开启了 PIN 或双向验证，也不会在 TLS 阶段把你挡在门外。

这里不是理论可行，而是我实际会照着走的一套流程。

这些步骤看起来琐碎，但任何一步没完成，后面的暴力抓包都起不来。

在设备列表中选中 iOS 设备后，我不会立刻点功能按钮，而是先看左下角：

这个状态没起来，暴力抓包界面再怎么点都只是空操作。

进入 HTTPS 暴力抓包模式后，我第一件事不是点“开始”，而是：

这样做的好处很直接：
当 App 发起请求时，你能清楚看到哪一条是它产生的，而不是被系统流量淹没。

即便在暴力抓包模式下，也存在一个前提条件：App 是否使用 iOS 开发证书签名。

在我的实际经验中，常见情况是：

这不是工具限制，而是 iOS 的安全模型本身决定的。

即便 body 不可见，我仍然会做几件判断：

这些信息足以判断 App 是否在按预期工作，尤其在调试网络异常时非常有用。

在需要完整请求体的情况下，我通常会：

完成后，再通过 HTTPS 暴力抓包重新抓取。
这一步成本不低，但它是唯一稳定可控的路径。

在 PIN 和双向验证场景下，我常用的组合是：

每个工具都解决一部分问题，而不是期待某一个工具解决所有问题