同一个 App，两套抓包战场
很多逆向工程师安卓玩得转，换 iOS 就处处碰壁——不是能力问题，是两个平台的网络栈、证书体系、工具链有系统性差异。本文把差异点摊开讲，让你带着地图进新战场。
差异一：证书信任模型
Android：用户证书和系统证书分区，Android 7+ App 默认只信系统证书——所以安卓抓包的主战场是"把证书塞进系统区"（Magisk 模块方案）。
iOS：没有分区概念，用户装的 CA 证书在"设置→通用→关于本机→证书信任设置"里打开"完全信任"后即获系统级信任。iOS 的证书安装本身简单，难的是描述文件安装流程和那个隐藏的信任开关。
实战影响：iOS 上没做 Pinning 的 App，装证书+开信任就能抓；Android 上还得 root 改系统区。iOS 的入门门槛低，但 Pinning 普及率反而更高（因为苹果生态的金融 App 多）。
差异二：QUIC 的默认行为
安卓：大量 App（尤其字节系、谷歌系）默认尝试 QUIC（UDP 443），Charles/mitmproxy 这类 TCP 代理直接抓空。
iOS：苹果的 URLSession 对 QUIC 的支持策略不同，且 iOS 上 App 更倾向用 HTTP/2 over TCP。但别高兴太早——跨平台网络库（Cronet）在 iOS 上同样走 QUIC，抖音 iOS 版就是 Cronet。
两端的通用解法：封 UDP 443 逼回 TCP。
# 路由器层面封，或手机端用防火墙工具
# macOS 做热点抓包时：
sudo pfctl -e
echo "block drop quick proto udp from any to any port 443" | sudo pfctl -f -差异三：代理接管方式
Android：系统代理设置 + Postern/Drony（VPN 型全局接管）。App 可以 Proxy.NO_PROXY 绕过系统代理，所以 VPN 型工具是刚需。
iOS：WiFi 代理设置同样可被绕过，但 iOS 没有 Postern 这种用户态 VPN 工具的宽松生态（VPN 配置需要描述文件）。主流方案：
- Mac 共享热点 + 透明代理：手机连 Mac 的热点，Mac 上用 mitmproxy 的透明模式接管全部流量——不依赖手机任何设置，最干净
- Surge/Quantumult X：iOS 上的网络调试工具，自带 MITM 和脚本能力，本身就是抓包利器
差异四：绕过 Pinning 的工具链
| 维度 | Android | iOS |
|---|---|---|
| 一键工具 | objection sslpinning disable | SSL Kill Switch 2 |
| 手写 hook | Frida hook TrustManager/CertificatePinner | Frida hook SecTrustEvaluate |
| 底层通杀 | hook SSL_read/SSL_write | 同左（BoringSSL）或 CCCrypt 层 |
思路完全一致，只是 API 名字不同。真正的差异在生态：Android 的 Frida 脚本社区更活跃，iOS 的很多脚本要自己适配新系统版本。
差异五：日志与调试信息
Android 有 logcat 这个全局日志流，App 的调试日志经常直接泄露接口信息（Log.d 忘关的太多了）。iOS 的 NSLog 在 release 版通常被编译掉，但 os_log 的信息可以通过 Console.app 连设备看——很多开发者不知道 release 版的 os_log 依然可见，敏感参数经常躺在里面。
# Mac 上 Console.app 连接 iPhone，过滤进程名
# 或命令行
idevicesyslog | grep TargetApp精髓：双平台逆向的能力迁移清单
安卓转 iOS（或反向）时，这些知识直接通用：
- SSL Pinning 的本质相同（客户端写死校验），绕过思路相同（hook 校验函数或加密端点）
- QUIC 问题相同，封 UDP 443 的解法相同
- Frida 是跨平台的，Java.use 换成 ObjC.classes 而已
- 协议层完全一致——同一个 App 的双端接口 90% 相同，一端逆出签名算法，另一端直接复用结论
总结
- iOS 证书信任简单（一个开关），安卓要进系统区（root）
- QUIC 两端都要防，封 UDP 443 是通用解法
- iOS 透明代理走 Mac 热点方案，不依赖手机设置
- 双端协议相同，一端的逆向结论另一端正接复用
交流微信：run1255