当前位置：首页 > news >正文

Fiddler手机抓包断网原因与证书固定绕过全解

news 2026/5/24 17:59:27

1. 为什么Fiddler一开，手机就“断网”？这不是Bug，是HTTPS握手被拦在了半路

Fiddler抓包手机流量时，App突然无法联网——这个现象太常见了，几乎每个刚接触移动端抓包的测试、开发或安全同学都踩过。你打开Fiddler，勾上Capture HTTPS CONNECTs和Decrypt HTTPS traffic，手机Wi-Fi里配好代理（IP填电脑局域网地址，端口默认8888），点开微信、淘宝、银行类App，页面直接卡在“加载中”，或者弹出“网络异常”“连接超时”。但浏览器却能正常上网，甚至Chrome里还能看到Fiddler捕获到的HTTP请求。这时候你会本能地怀疑：是不是手机没连对Wi-Fi？是不是防火墙挡了？是不是Fiddler版本太老？其实都不是。问题根源不在网络层，而在TLS握手阶段的证书信任链断裂——Fiddler作为中间人（MITM），必须用自己的根证书让手机“相信”它签发的每一个域名证书；而绝大多数现代App（尤其是金融、社交、电商类）早已启用证书固定（Certificate Pinning），它们根本不看系统证书库，而是把自家服务器的公钥哈希值硬编码进App里，一旦发现通信链路上的证书不是预期的那个，立刻终止连接。这不是Fiddler的缺陷，恰恰是App开发者在主动防御中间人攻击。所以，所谓“无法连接网络”，本质是App在TLS Client Hello之后，收到Fiddler伪造的Server Certificate时，校验失败，直接RST掉TCP连接。你看到的“无网络”，其实是App主动拒绝了这次加密握手。这个问题的解决路径，从来不是调高Fiddler的超时时间或重装驱动，而是要分三层应对：第一层，确保Fiddler根证书真正在手机系统级可信（不是仅浏览器安装）；第二层，绕过那些做了强证书固定的App（需逆向或Hook）；第三层，识别并规避系统级拦截机制（如Android 7+对用户证书的默认不信任）。下面我们就一层层拆解，从最基础的证书安装，到最棘手的证书固定绕过，全部用实测过的方案说话。

2. 根证书安装：90%的人只装了一半，系统级信任才是关键

很多人以为，在手机浏览器里访问http://ipv4.fiddler:8888，点击下载并安装FiddlerRoot.cer，就算完成了证书配置。这是最大的认知偏差。FiddlerRoot证书必须进入系统信任锚存储区（System Trust Store），才能被所有App（包括微信、支付宝、招商银行App等）识别。而Android和iOS对用户安装证书的默认处理逻辑完全不同，且版本迭代带来巨大差异。

2.1 Android：从7.0开始，用户证书默认不被App信任

Android 7.0（Nougat）是一个分水岭。在此之前，只要用户安装了证书，所有App都会默认信任它。但从7.0起，Google强制要求App通过android:networkSecurityConfig属性显式声明是否信任用户证书。绝大多数商业App（尤其是targetSdkVersion ≥ 24的）都未做此声明，因此它们完全忽略用户安装的证书，只信任系统预置的CA列表。这意味着，你在设置→安全→加密与凭据→安装证书里点几下，对微信、抖音、京东这些App毫无作用。

提示：验证当前设备是否已将FiddlerRoot加入系统信任库，最直接的方法是执行ADB命令：
adb shell ls /system/etc/security/cacerts/ | grep -i fiddler
如果返回空，说明证书未进入系统区；如果返回一串哈希名（如a1b2c3d4.0），则已写入。但注意：Android 10+后，/system/etc/security/cacerts/为只读分区，普通ADB无法写入，必须刷入自定义ROM或使用Magisk模块。

实操中，我们有三条可行路径：

路径A（推荐给测试人员）：降级targetSdkVersion临时调试
若你有App源码或可获取APK，用apktool d app.apk反编译，在res/xml/network_security_config.xml中添加：
```
<domain-config> <domain includeSubdomains="true">example.com</domain> <trust-anchors> <certificates src="system" /> <certificates src="user" />  </trust-anchors> </domain-config>
```
然后apktool b app回编译并签名。这样App就能识别你安装的FiddlerRoot证书。但此法仅限内部测试，上线版App绝不会开启此项。
路径B（通用方案）：使用Magisk + Move Certificates模块（需Root）
对于已Root的Android设备（如Pixel、OnePlus等），安装Magisk Manager，再安装 Move Certificates 模块。该模块会自动将用户证书复制到/system/etc/security/cacerts/目录，并生成正确哈希名（FiddlerRoot.cer的哈希名可通过openssl x509 -inform DER -in FiddlerRoot.cer -outform PEM | openssl x509 -noout -hash计算）。实测在Android 11–13上100%生效，微信、支付宝、招行App全部可抓。
路径C（免Root应急法）：利用Shizuku + CertInstaller（成功率约70%）
Shizuku是无需Root即可获取部分系统权限的工具。配合CertInstaller应用，可尝试将证书注入系统区。操作流程：安装Shizuku → 启动Shizuku并授予ADB权限 → 安装CertInstaller → 在CertInstaller中选择FiddlerRoot.cer → 点击“Install to System Store”。此法在Samsung One UI 4.1+、Xiaomi MIUI 13+上成功率较高，但华为EMUI/HarmonyOS因深度定制，基本无效。

2.2 iOS：证书安装后必须手动开启“完全信任”

iOS的证书流程看似简单，实则暗藏陷阱。步骤是：Safari访问http://ipv4.fiddler:8888 → 下载并安装FiddlerRoot.cer → 进入设置→已下载描述文件→安装→输入密码。但到这里远未结束。iOS 10.3+起，新安装的根证书默认处于“不信任”状态，必须手动开启“完全信任”。

具体操作路径：设置 → 通用 → 关于本机 → 证书信任设置 → 找到“DO_NOT_TRUST_FiddlerRoot” → 右侧开关拨至ON。注意：此处名称可能显示为“FiddlerRoot”或“Telerik Fiddler Root Certificate”，取决于Fiddler版本。若找不到该条目，请确认Fiddler中是否勾选了Tools → Options → HTTPS → Actions → Export Root Certificate to Desktop，并确保导出的是.cer格式（非.pem），因为iOS只识别DER编码的证书。

注意：iOS 15.4+新增了更严格的证书策略，部分企业签名App（如某些内网OA）会检测证书的keyUsage扩展字段。Fiddler默认生成的根证书中keyUsage包含digitalSignature, keyCertSign, cRLSign，但某些App要求keyEncipherment也必须置位。此时需用OpenSSL重新生成FiddlerRoot：
openssl req -x509 -newkey rsa:2048 -keyout fiddler.key -out fiddler.crt -days 3650 -nodes -subj "/CN=DO_NOT_TRUST_FiddlerRoot"
然后在Fiddler中导入该密钥对（Tools → Options → HTTPS → Actions → Load from File）。

3. 证书固定（Pinning）绕过：当App说“我只信我家的钥匙”，你得换把锁

即使FiddlerRoot证书已成功进入系统信任库，仍有大量App（微信v8.0.40+、支付宝v10.4.0+、各大银行App）拒绝建立HTTPS连接。抓包日志里看不到任何HTTP请求，Wireshark里只看到TCP三次握手后立即发送RST包。这就是证书固定（Certificate Pinning）在起作用——App在代码里硬编码了目标服务器证书的公钥哈希（如SHA-256），TLS握手时，客户端会比对服务端返回证书的公钥哈希是否匹配。一旦Fiddler用自己私钥签发的证书（公钥哈希完全不同），App立刻终止连接。

绕过证书固定没有银弹，必须结合App技术栈选择方案。以下是三种经实测有效的主流方法，按侵入性由低到高排列：

3.1 Frida Hook：动态注入，实时篡改证书校验逻辑（推荐首选）

Frida是目前最轻量、最通用的绕过方案。它无需修改APK，只需在运行时Hook Java层的证书校验方法。以OkHttp为例，绝大多数现代Android App使用OkHttp作为网络库，其证书校验入口在OkHostnameVerifier.verify()和CertificatePinner.check()两个方法。

实操步骤（以微信为例）：

手机安装Frida Server（对应架构：arm64-v8a下载frida-server-16.1.4-android-arm64.xz，解压后adb push frida-server /data/local/tmp/）
adb shell "chmod 755 /data/local/tmp/frida-server" && adb shell "/data/local/tmp/frida-server &"
PC端安装frida-tools：pip install frida-tools
编写绕过脚本bypass_pinning.js：

Java.perform(function () { var OkHostnameVerifier = Java.use("okhttp3.internal.platform.OkHostnameVerifier"); OkHostnameVerifier.verify.implementation = function (hostname, session) { console.log("[*] Bypassing OkHostnameVerifier for: " + hostname); return true; // 强制返回true，跳过域名验证 }; var CertificatePinner = Java.use("okhttp3.CertificatePinner"); CertificatePinner.check.implementation = function (hostname, peerCertificates) { console.log("[*] Bypassing CertificatePinner for: " + hostname); return; // 直接返回，不执行任何校验 }; });

启动微信并Hook：frida -U -f com.tencent.mm -l bypass_pinning.js --no-pause

此方案优势在于：零APK修改、支持热更新、可精准定位到具体校验点。但需注意：微信等App会检测Frida环境（如/proc/self/maps中是否存在frida字符串），此时需配合 Frida Anti-Debug 脚本隐藏痕迹。实测在小米13（Android 13）、iPhone 14（iOS 16.5）上，微信v8.0.45、支付宝v10.4.5均可稳定抓包。

3.2 Xposed/EdXposed模块：系统级拦截，一劳永逸（需Root/越狱）

对于长期需要抓包多个App的场景，Xposed是更省心的选择。模块如JustTrustMe（Android）或SSL Kill Switch 2（iOS）可全局禁用证书校验。

Android JustTrustMe原理：HookX509TrustManager.checkServerTrusted()和SSLSocketFactory.createSocket()等关键方法，将所有证书校验结果强制设为true。安装后无需重启App，生效即时。但新版Xposed（EdXposed）在Android 10+上兼容性下降，部分App（如招商银行）会触发反调试，需配合XPrivacyLua隐藏Xposed特征。
iOS SSL Kill Switch 2原理：基于Cycript HookSecTrustEvaluate函数，截获系统证书验证调用，直接返回errSecSuccess。安装后需重启SpringBoard。此模块在iOS 14–16.4上稳定，但iOS 16.5+因内核加固，需配合Checkra1n越狱工具链才能启用。

踩坑经验：使用JustTrustMe时，若遇到App闪退，大概率是其检测到android.app.Application类被Xposed Hook。解决方案是在Xposed Installer中禁用JustTrustMe对该App的激活，改用Frida单点Hook，精准打击。

3.3 APK重打包：修改Smali代码，永久移除校验（终极方案）

当Frida和Xposed均失效（如某些金融App启用了Native层证书校验），只能回归APK重打包。核心思路是：反编译APK → 定位证书校验逻辑 → 修改Smali代码跳过校验 → 重签名安装。

以某银行App（使用OkHttp）为例：

apktool d bankapp.apk -o bank_src
搜索校验关键词：grep -r "checkServerTrusted\|CertificatePinner\|pin" bank_src/smali/
找到关键Smali文件：bank_src/smali/com/bank/ssl/MyTrustManager.smali
定位checkServerTrusted方法，原代码类似：

.method public checkServerTrusted([Ljava/security/cert/X509Certificate;Ljava/lang/String;)V .registers 4 .param p1, "chain" # [Ljava/security/cert/X509Certificate; .param p2, "authType" # Ljava/lang/String; .annotation system Ldalvik/annotation/Throws; value = { Ljava/security/cert/CertificateException; } .end annotation .prologue .line 45 new-instance v0, Ljava/security/cert/CertificateException; const-string v1, "Invalid certificate" invoke-direct {v0, v1}, Ljava/security/cert/CertificateException;-><init>(Ljava/lang/String;)V throw v0 .end method

将其替换为无操作空方法：

.method public checkServerTrusted([Ljava/security/cert/X509Certificate;Ljava/lang/String;)V .registers 2 .param p1, "chain" # [Ljava/security/cert/X509Certificate; .param p2, "authType" # Ljava/lang/String; .prologue .line 45 return-void .end method

apktool b bank_src -o bank_patched.apk→jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore bank_patched.apk alias_name

此法成功率最高，但耗时长、需熟悉Smali语法，且每次App更新都要重做。建议仅用于无法Hook的Critical App。

4. 其他致命干扰项：DNS污染、代理劫持、系统级拦截

即使证书和证书固定问题全部解决，仍有小概率出现“手机能上网，但Fiddler收不到任何请求”的情况。这往往源于更底层的网络干扰。以下是三个极易被忽略，但实际发生率极高的干扰源：

4.1 DNS解析被App自身劫持，绕过系统代理

很多App（尤其是视频、游戏类）为加速资源加载，会内置DNS解析模块（如使用dnspython或c-ares库），直接向8.8.8.8或114.114.114.114发起DNS查询，完全不走系统DNS设置。结果就是：你的手机Wi-Fi代理指向Fiddler，但App根本没用这个代理——它自己查完IP后，直接用IP建连，流量根本不经过Fiddler。

验证方法：在手机上安装Packet Capture（无需Root），启动后打开微信，观察其发出的DNS请求目标。若看到大量A记录查询指向8.8.8.8，而非你电脑的IP，则确认存在此问题。

解决方案只有两种：

方案1（治标）：在路由器层面强制DNS重定向
登录路由器后台（如华硕、小米路由器），开启“DNS劫持”功能，将所有UDP 53端口请求重定向到你的电脑IP（需在电脑上运行SimpleDNSCrypt或dnsmasq监听53端口）。此法需路由器支持，且可能影响其他设备。
方案2（治本）：使用Hosts文件强制域名解析（需Root）
adb root && adb remount→adb push hosts /system/etc/hosts，其中hosts文件内容为：
```
192.168.1.100 api.weixin.qq.com 192.168.1.100 pay.weixin.qq.com 192.168.1.100 res.wx.qq.com
```
（192.168.1.100为你电脑局域网IP）
此法让App的DNS查询直接命中Hosts，后续HTTP请求必然走系统代理。实测在Bilibili、网易云音乐上100%生效。

4.2 Windows防火墙/杀毒软件拦截Fiddler端口

Fiddler默认监听0.0.0.0:8888，但Windows Defender防火墙或第三方杀软（如360、腾讯电脑管家）会将其识别为“可疑网络服务”，自动阻止入站连接。现象是：手机ping通电脑IP，但telnet 192.168.1.100 8888失败，Fiddler日志无任何连接记录。

排查步骤：

netstat -ano | findstr :8888—— 确认Fiddler进程确实在监听
wf.msc打开高级安全Windows防火墙 → 入站规则 → 查找“Fiddler”或“8888”相关规则 → 若状态为“已禁用”，右键启用
若无对应规则，手动新建：操作 → 新建规则 → 端口 → TCP 8888 → 允许连接 → 域/专用/公用全选 → 规则名称“Fiddler HTTP Proxy”

实测教训：某次在Win11上，Fiddler始终无法被手机连接，折腾两小时才发现是McAfee LiveSafe的“Web Control”功能在后台静默拦截。关闭该模块后立即恢复。因此，抓包前务必临时关闭所有第三方安全软件。

4.3 Android 12+ 的Private DNS（DNS over TLS）强制启用

Android 12引入了Private DNS功能，默认启用dns.google（即DoT）。此功能会将所有DNS查询加密发送至Google DNS，完全绕过本地网络代理设置。即使你配了Fiddler代理，DNS请求仍直连8.8.8.8:853，导致域名解析不受控。

关闭路径：设置 → 网络和互联网 → 私有DNS → 选择“关闭”。
注意：此设置位于Wi-Fi详情页之外，很容易被忽略。若你使用的是企业Wi-Fi（如公司WPA2-Enterprise），Private DNS可能被MDM策略强制开启，此时需联系IT管理员解除策略。

5. 终极排错清单：5分钟定位问题根源

面对“Fiddler开不了，手机连不上”，别急着重装软件或换手机。按以下清单逐项验证，95%的问题可在5分钟内定位：

检查项	验证方法	预期结果	常见失败原因
1. 电脑与手机是否同网段	手机ping电脑IP（如`ping 192.168.1.100`）	返回`Reply from ...`	电脑防火墙阻止ICMP；手机连错Wi-Fi（如连了5G频段但电脑在2.4G）
2. Fiddler是否监听所有IP	Fiddler → Tools → Options → Connections → 勾选Allow remote computers to connect	日志显示`Starting WinINET proxy server on port 8888`	未勾选此项，Fiddler只监听127.0.0.1
3. 手机代理是否生效	手机浏览器访问`http://ipv4.fiddler:8888`	显示Fiddler官网首页	手机代理IP填错（应填电脑局域网IP，非127.0.0.1）；端口非8888
4. FiddlerRoot证书是否被App信任	抓包时Fiddler日志中是否有`HTTPS`请求（非`CONNECT`）	出现`GET https://api.xxx.com/xxx`等真实URL	证书未安装；未开启iOS“完全信任”；Android未Root注入系统区
5. 是否触发证书固定	Wireshark抓手机网卡，过滤`tcp.port==443 and ip.src==手机IP`	看到`TCP SYN`→`TCP SYN-ACK`→`TCP RST`三连包	App启用Certificate Pinning，需Frida/Xposed绕过

最后一个技巧：当所有检查都通过，但微信仍无法抓包时，试试关闭微信的“流量统计”功能。路径：微信 → 我 → 设置 → 通用 → 流量控制 → 关闭“在Wi-Fi下使用移动数据”。此功能会强制微信走蜂窝网络通道，绕过Wi-Fi代理。关闭后，微信立即回归Wi-Fi代理链路。

我在实际工作中，曾用这套方法帮3个不同团队定位问题：第一个是电商App，卡在DNS劫持；第二个是教育类App，死于Android 12 Private DNS；第三个是IoT设备配套App，因厂商自研TLS库未走系统API，最终靠APK重打包解决。每一次都不是Fiddler的问题，而是我们对移动端网络栈的理解不够深。抓包的本质，是理解App如何与网络对话；而解决问题的关键，永远是先问一句：“它此刻，到底想连谁？”

查看全文

http://www.jsqmd.com/news/878759/