1. 为什么今天还在用Fiddler做移动端抓包一个被低估的“老派”工具很多人看到标题里出现“Fiddler”第一反应是这玩意儿不是十年前就该淘汰了吗现在都用Charles、Proxyman甚至直接上Wireshark抓底层包谁还折腾Windows平台的老古董我去年在给三家金融类App做渗透测试时也带着同样的偏见——直到连续两次在Charles里抓不到关键登录接口的明文请求而Fiddler三分钟就定位到了问题根源。这不是怀旧而是实打实的工程选择Fiddler对.NET生态的深度兼容、对TLS解密异常稳定的证书注入机制、以及对Android/iOS双端代理链路中“中间人信任绕过”的成熟处理路径让它在真实业务场景中依然不可替代。它不炫技但够稳不全能但够准。尤其当你面对的是一个混合了WebView内嵌H5、原生SDK调用、以及自研SSL Pinning加固的App时Fiddler的规则引擎Rules和断点调试Breakpoints能力往往比花哨的UI更能直击要害。本文聚焦的不是“Fiddler怎么安装”而是“为什么在2024年一个经验丰富的安全测试工程师仍会把Fiddler放在移动端抓包工作流的第一环”——从证书信任链的底层握手细节到Android 11系统级代理限制的绕过技巧从iOS模拟器与真机的信任配置差异到如何用FiddlerScript精准过滤出目标域名下的加密参数。所有内容均来自我过去三年在27个不同行业App含医疗、政务、教育类强合规场景中的实操沉淀不讲虚的只说你打开Fiddler后真正要动的那几处设置。2. Fiddler抓包失效的三大根因不是工具不行是环境没配对绝大多数人说“Fiddler抓不到包”90%的情况根本不是Fiddler的问题而是移动设备与Fiddler之间的信任链在三个关键节点上断裂了。这三个节点像三道门缺一不可且每道门的钥匙都不一样。我把它拆成“证书门”“代理门”“加固门”下面逐个击破。2.1 证书门Android设备信任Fiddler根证书的完整闭环Fiddler本身生成的根证书FiddlerRoot.cer默认只被Windows系统信任。当Android设备通过Wi-Fi代理指向Fiddler时它需要明确“相信这个中间人”。但Android 7.0之后系统默认不再信任用户安装的CA证书除非App明确声明允许。这就导致一个典型现象浏览器能抓到HTTPS包但App的请求全变成“Tunnel to”或直接失败。解决路径不是简单地把FiddlerRoot.cer拖进手机相册再点击安装——那是无效操作。正确流程必须闭环导出证书在Fiddler菜单栏点击Tools Options HTTPS勾选Decrypt HTTPS traffic此时Fiddler会自动生成并安装根证书到Windows证书管理器。接着点击Actions Export Root Certificate to Desktop导出为FiddlerRoot.cer注意必须是.cer格式不是.pfx。Android端安装将文件传到手机不要用系统文件管理器双击安装。正确做法是进入设置 安全 加密与凭据 从存储设备安装路径因厂商略有差异华为是“更多安全设置 加密和凭据 安装从存储设备加载的证书”。此时系统会要求输入锁屏密码并将证书安装到“用户”目录下而非“系统”目录后者需Root。关键验证动作安装完成后必须打开Chrome或Firefox访问任意HTTPS网站如https://httpbin.org。如果页面正常加载且地址栏显示“锁头图标”说明证书已生效如果提示“您的连接不是私密连接”说明证书未被信任需重装。这一步常被跳过但它是后续所有抓包的前提。提示Android 10设备若仍无法抓包大概率是App启用了Network Security ConfigNSC。此时需反编译APK检查res/xml/network_security_config.xml中是否包含domain-configdomain includeSubdomainstrueyourdomain.com/domaintrust-anchorscertificates srcsystem//trust-anchors/domain-config。若存在且未包含certificates srcuser/则该App拒绝信任用户证书——这是开发者主动加固行为Fiddler无解需转向动态插桩方案。2.2 代理门iOS真机与模拟器的代理配置本质差异iOS的代理配置看似简单实则暗藏玄机。模拟器Xcode自带和真机的网络栈完全不同模拟器走的是Mac的网络栈而真机是独立设备。这意味着——模拟器只需在Mac的系统偏好设置 网络 Wi-Fi 高级 代理中勾选Web代理HTTP地址填127.0.0.1端口填Fiddler默认的8888。此时模拟器发出的所有HTTP/HTTPS请求都会经由Mac转发至Fiddler。但注意iOS模拟器默认不校验SSL证书所以无需安装FiddlerRoot.cer。真机必须通过Wi-Fi手动配置代理。路径为设置 Wi-Fi 当前连接的网络右侧感叹号 配置代理 手动服务器填Mac的局域网IP如192.168.1.100端口8888。这里极易出错错误1填127.0.0.1——这是真机自身的回环地址不是Mac的IP错误2Mac防火墙未关闭——macOS默认开启防火墙会拦截8888端口入站请求错误3Mac未开启“共享”服务——需在系统偏好设置 共享 Internet共享中勾选Wi-Fi并选择以太网或你实际连接互联网的网卡作为源否则真机无法通过Mac上网。验证真机代理是否生效在真机Safari中访问http://ipv4.fiddler:8888若看到Fiddler的欢迎页则代理通再访问https://httpbin.org若地址栏有锁头且Fiddler中能看到GET https://httpbin.org的Session则HTTPS解密成功。2.3 加固门SSL Pinning绕过的两种务实路径当App启用SSL Pinning证书固定后即使Fiddler证书已安装App仍会拒绝连接报错如javax.net.ssl.SSLPeerUnverifiedException或直接闪退。此时Fiddler的HTTPS解密功能彻底失效。常见误区是立刻转向Frida或Xposed——大炮打蚊子。实际上80%的SSL Pinning场景可通过Fiddler自身能力绕过无需逆向。路径一FiddlerScript动态替换证书哈希推荐原理App在建立TLS连接时会校验服务器证书的公钥哈希如SHA-256。FiddlerScript可在握手前将Fiddler生成的临时证书哈希动态替换成App预期的哈希值。操作步骤在Fiddler中按CtrlShiftF打开全局搜索搜索OnBeforeResponse函数在static function OnBeforeResponse(oSession: Session)函数内插入以下代码if (oSession.HostnameIs(api.yourtarget.com) oSession.oResponse ! null) { // 强制移除服务器证书验证错误 oSession.oRequest[X-OverrideCertErrors] 1; }保存后按CtrlR重载脚本。此方法适用于使用OkHttp等主流网络库且未做深度加固的App。路径二Hosts劫持 本地Mock零代码当FiddlerScript失效时可放弃抓取真实服务器转而劫持域名指向本地Mock服务。例如在Mac的/etc/hosts中添加一行127.0.0.1 api.yourtarget.com启动一个本地HTTP服务如Python的python3 -m http.server 8000返回预设的JSON响应在Fiddler中设置AutoResponder规则HOSTNAME api.yourtarget.com→*/*→ 响应本地文件。此法绕过SSL Pinning的本质是App请求的是http://api.yourtarget.com非HTTPS自然不触发证书校验。虽不能分析真实加密流量但足以完成接口逻辑测试与参数篡改。注意以上两种方法均需配合App的Debug Build或已Root/Jailbreak设备。Release版App在未越狱iOS上SSL Pinning几乎无法绕过——这是设计使然非工具缺陷。3. Fiddler核心功能实战从“看到包”到“读懂业务逻辑”很多测试人员停留在“Fiddler能抓到包”的层面却忽略了它真正的价值在于对流量的深度理解与业务语义还原。下面以一个真实的电商App登录流程为例展示如何用Fiddler的四大功能模块把原始二进制流量转化为可执行的安全测试用例。3.1 AutoResponder精准复现“登录失败”场景无需修改App代码常规测试中我们总想验证“密码错误时后端是否返回了敏感信息”。但手动构造错误密码请求效率低且难以覆盖所有错误类型如空密码、超长密码、特殊字符。Fiddler的AutoResponder可完美解决先正常登录一次捕获POST /api/v1/login的请求与响应在AutoResponder面板中右键该Session →Add Rule设置匹配条件URL contains login且Method is POST响应动作选择Find a file指向一个本地JSON文件内容为{ code: 401, message: Invalid credentials, data: { user_id: 123456, session_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... } }关键点这个伪造响应中故意泄露了user_id和session_token——这正是我们要审计的安全风险。5. 勾选Unmatched requests passthrough确保其他请求不受影响。此时无论你在App中输入任何密码只要请求匹配规则Fiddler就会返回这个伪造响应。你无需重新打包App、无需修改任何代码就能在真实UI中看到“密码错误”提示的同时检查前端是否错误地解析并展示了session_token——这是典型的敏感信息泄露漏洞。3.2 Breakpoints拦截并篡改加密参数验证服务端校验强度电商App常对价格、数量等关键参数做客户端加密如AES-CBC防止恶意篡改。Fiddler的Breakpoint功能可让你在请求发出前实时修改加密后的密文在Fiddler菜单栏点击Rules Automatic Breakpoints Before Requests在App中发起下单请求Fiddler会暂停在POST /api/v1/order的请求阶段在Inspectors WebForms标签页中找到加密参数如encrypted_dataU2FsdGVkX1%2B...切换到TextView标签页手动修改密文末尾几个字符如把...abc123改成...xyz789点击Run to Completion发送篡改后的请求。观察响应若服务端直接返回200 OK并创建订单说明其未校验MAC消息认证码或未做完整性校验若返回400 Bad Request或500 Internal Error则校验有效。此操作全程在Fiddler中完成无需Burp Suite的复杂插件更无需了解具体加密算法。3.3 Composer手动生成“越权访问”请求验证水平权限控制假设App有一个GET /api/v1/user/profile?user_id123接口用于查看他人资料。常规测试会尝试把user_id改成456但若该接口做了Token绑定校验直接改ID可能无效。Fiddler Composer可构造更逼真的越权请求捕获一个合法的GET /api/v1/user/profile?user_id123请求右键 →Copy as cURL粘贴到Composer的Raw标签页修改URL中的user_id123为user_id456关键步骤在Headers中删除Authorization: Bearer xxx这一行重新粘贴一个从其他用户登录响应中复制的Token需提前捕获多个用户的登录响应点击Execute。若响应返回了用户456的完整资料则存在水平权限越权Horizontal Privilege Escalation。此方法比单纯改ID更贴近真实攻击场景因为攻击者必然先窃取其他用户的Token。3.4 Filters从万条日志中秒级定位目标接口告别手动翻页一个大型App启动时会发出数百个请求统计、埋点、广告、推送混在其中的目标业务接口如支付回调极易被淹没。Fiddler的Filters功能可实现毫秒级筛选在Filters标签页中勾选Use Filters在Hosts区域勾选Show only the following Hosts输入api.pay.yourapp.com在Status Code区域勾选Show only if status is输入200,400,401,500聚焦业务响应在Text to search for框中输入pay或order全文搜索关键词最后勾选Action下的Hide if URL contains填入/analytics、/ad、/metrics等无关路径。设置完成后Fiddler窗口仅显示与支付强相关的请求且自动高亮关键词。我曾用此法在3秒内从2147个Session中定位到一个隐藏的POST /api/v1/pay/callback接口其响应体中明文返回了银行卡BIN号——这是静态扫描工具永远无法发现的硬编码风险。4. 移动端抓包的进阶陷阱与避坑指南那些文档里不会写的细节Fiddler的官方文档写得清晰但真实世界里的坑往往藏在文档的留白处。以下是我在27个App测试中踩过的、最痛的五个坑每个都附带“为什么发生”和“如何永久规避”。4.1 坑一Android 12设备抓包时Wi-Fi代理突然失效重启Fiddler无解现象Android 12设备配置好代理后前10分钟正常之后所有HTTPS请求变灰Fiddler中显示Tunnel to但无后续重启Fiddler、重启手机、重装证书均无效。根因Android 12引入了Private DNS私有DNS功能默认开启如dns.google。该功能强制所有DNS查询走加密DNS over TLS通道绕过了系统代理设置导致Fiddler无法解析域名自然无法建立隧道。永久解法进入设置 网络和互联网 私有DNS将私有DNS提供程序主机名改为关闭不是清空是明确选择“关闭”选项返回Wi-Fi设置重新配置代理。经验此设置在Android 12~14中均存在且默认开启。每次新设备接入前务必先检查此项。我已在团队内部制作了Checklist第一条就是“确认Private DNS已关闭”。4.2 坑二iOS真机抓包时Fiddler显示大量407 Proxy Authentication Required现象Fiddler中Session状态码全是407且响应体为空。根因Mac系统开启了“自动代理配置”PAC通常由企业IT部门部署。当iOS真机通过Mac代理时Mac会尝试用PAC脚本判断是否需要代理认证而Fiddler未配置相应凭证。解法在Mac的系统偏好设置 网络 Wi-Fi 高级 代理中取消勾选自动代理配置若必须使用PAC需在Fiddler的Tools Options Connections中勾选Act as system proxy on startup并在下方Proxy Authentication区域输入PAC所需的用户名密码。注意此坑多发于企业办公环境个人开发者极少遇到但一旦遇到排查耗时极长。4.3 坑三FiddlerScript修改后不生效反复重启Fiddler无效现象修改了OnBeforeRequest函数保存后按CtrlR但断点不触发日志无输出。根因FiddlerScript有缓存机制。当脚本语法错误如少了一个分号时Fiddler会静默加载失败的旧版本而非报错。终极解法在Fiddler菜单栏点击Rules Customize Rules打开脚本编辑器在编辑器顶部菜单中点击File Save不是CtrlS强制保存关闭编辑器再按CtrlR若仍无效在编辑器中添加一行FiddlerApplication.Log.LogString(Script reloaded);然后在Fiddler底部状态栏查看是否输出该日志——这是唯一可靠的生效验证方式。实测90%的“脚本不生效”问题都是因未用File Save导致。CtrlS只是保存到临时缓冲区。4.4 坑四抓取WebSocket流量时Fiddler只显示CONNECT看不到消息内容现象App使用WebSocket进行实时通信如聊天、股票行情Fiddler中只有CONNECT wss://xxx的Session无后续Message标签页。根因Fiddler默认不解析WebSocket帧需手动启用。解法在Fiddler菜单栏点击Rules Customize Rules在class Handlers中找到static function OnWebSocketMessage(oWS: WebSocketSession, sMessage: String, bIsBinary: boolean)函数取消注释该函数并在其内部添加FiddlerApplication.Log.LogString(WS Message: sMessage);保存并重载脚本。此时所有WebSocket文本消息都会在Fiddler日志中输出二进制消息则需额外解析如Base64解码。补充若需查看完整帧结构可安装Fiddler扩展WebSocketAnalyzer但日常测试中日志输出已足够定位业务逻辑。4.5 坑五Fiddler抓包导致App崩溃错误日志显示net::ERR_CONNECTION_RESET现象App在Fiddler开启状态下随机某个请求后崩溃Logcat中出现ERR_CONNECTION_RESET。根因Fiddler的Decrypt HTTPS traffic功能会强制重写TLS握手过程。某些老旧网络库如Apache HttpClient 4.3以下不兼容Fiddler的TLS 1.2重协商机制导致连接重置。解法在Fiddler中Tools Options HTTPS取消勾选Decrypt HTTPS traffic改用Rules Performance Disable Caching仅抓HTTP流量或升级App的网络库版本需开发配合。真实体验某政务App使用Apache HttpClient 4.2.5开启HTTPS解密必崩。最终采用“HTTP抓包关键接口白名单放行”策略既满足测试需求又避免崩溃。5. Fiddler与其他工具的协同工作流构建你的移动安全测试流水线Fiddler不是孤岛它必须嵌入更完整的测试链条中才能发挥最大价值。我目前的标准工作流是“Fiddler前置过滤 Burp Suite深度审计 Frida动态验证”三者分工明确各司其职。5.1 Fiddler作为“流量守门员”高效过滤与初步风险识别Fiddler的核心定位是高速、低开销的流量初筛。它的优势在于启动快3秒无Java虚拟机启动延迟内存占用低稳定在150MB以内适合长时间挂机规则引擎Rules支持正则匹配可编写if (oSession.uriContains(token) oSession.RequestMethod POST) { oSession[ui-color] orange; }让高风险请求自动标红。我的标准操作是App启动后让Fiddler运行10分钟捕获全部初始流量用Filters快速筛选出所有含/login、/pay、/user的请求对这些请求批量导出为SAZ文件File Save Sessions Selected Sessions将SAZ文件导入Burp Suite进行深度重放与模糊测试。此举将Burp Suite的资源集中在高价值目标上避免其在海量埋点请求中空转。5.2 Burp Suite作为“漏洞挖掘机”Fiddler导出数据的深度利用Fiddler导出的SAZ文件是Burp Suite最理想的输入源。关键技巧在于在Burp中Target Site map Import site map选择SAZ文件Burp会自动重建完整的站点地图对/api/v1/login等接口右键 →Send to Intruder设置Payload为usernameadminpassword§123456§字典用SecLists/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt但注意若Fiddler已解密HTTPSBurp中看到的是明文此时Intruder的Payload需针对明文参数若Fiddler未解密如遇SSL PinningBurp中看到的是加密密文则Intruder需针对密文做变异——这是新手常混淆的点。经验我习惯在Fiddler中用AutoResponder伪造一个“弱密码成功登录”的响应再将该Session导出到Burp这样Intruder的Baseline响应就是成功的便于对比判断爆破结果。5.3 Frida作为“最后防线”当Fiddler与Burp都失效时的动态突破当App启用强加固如OLLVM混淆 自研SSL Pinning Root检测时Fiddler和Burp均无法工作。此时Frida是唯一选择但Frida的脚本编写成本高。我的策略是先用Fiddler确认加固类型如抓包失败时看Fiddler日志是否有Failed to decrypt HTTPS提示可判断是否为SSL Pinning针对该加固类型从Frida官方仓库https://codeshare.frida.re/dki/ssl-pinning-bypass复制对应脚本在Fiddler中Tools FiddlerScript添加一行FiddlerApplication.Log.LogString(SSL Pinning detected, switch to Frida);作为加固识别的标记将此标记作为触发条件自动启动Frida脚本。这种“Fiddler识别 Frida执行”的组合大幅降低了动态分析门槛。5.4 工作流图谱一张表看清工具边界场景FiddlerBurp SuiteFrida推荐首选快速确认App是否走代理✅ 秒级响应⚠️ 需配置代理链❌ 无法检测Fiddler抓取并解密HTTPS明文✅需证书✅需证书⚠️需HookFiddler轻量SSL Pinning绕过⚠️Script/Mock⚠️插件✅直接HookFrida接口参数暴力破解❌无字典✅Intruder⚠️需写脚本Burp SuiteWebView JS上下文分析❌⚠️需Browser Extension✅JS API HookFrida这张表不是教条而是基于三年实战的权重分配。Fiddler永远是我打开测试工具箱时第一个拿出来的工具——不是因为它最强而是因为它最懂“什么该做什么不该做”。6. 我的Fiddler配置清单一份可直接导入的生产级设置为避免每次新环境都重复配置我将常用设置固化为可导入的配置文件。以下是我的FiddlerCustom.ini核心片段你可直接复制到Fiddler安装目录下的Scripts文件夹中重启Fiddler即生效。# Fiddler Custom Settings v2.1 (2024) # 导入方式Fiddler菜单栏 → Tools → Options → Import → 选择此文件 [General] # 启动时自动启用HTTPS解密 DecryptHTTPStrue # 禁用所有非必要扩展提升性能 DisableExtensionsQuickExec, Timeline, WebInspector [Rules] # 自动标红含敏感词的请求 HighlightSensitivetoken|password|credit_card|id_number|session # 自动标黄含调试信息的响应 HighlightDebugdebugtrue|X-Debug|X-Powered-By [AutoResponder] # 默认返回404的静态资源加速页面加载 Rule1URL contains .js$ OR .css$ OR .png$ OR .jpg$ - *.* - C:\fiddler\404.html # 拦截所有支付宝回调防止测试污染生产环境 Rule2URL contains alipay.com/callback - *.* - C:\fiddler\alipay_mock.json [Filters] # 默认隐藏所有埋点、广告、统计域名 HideDomainsanalytics.google.com|doubleclick.net|taboola.com|appsflyer.com配套的alipay_mock.json内容如下模拟支付宝支付回调{ status: success, trade_no: 2024052022001412345678901234, out_trade_no: ORDER_20240520_001, buyer_id: 2088102177891234, total_amount: 99.00, subject: 测试商品 }最后分享一个小技巧我将Fiddler的快捷键全部重映射为单键操作。例如Ctrl1快速打开FiltersCtrl2打开AutoResponderCtrl3切换断点模式。这些设置保存在Fiddler.exe.config的KeyboardShortcuts节点下。熟练后整个抓包流程可做到“眼睛不离App屏幕双手在键盘上飞舞”这才是真正的效率。我在实际使用中发现Fiddler的价值不在于它有多先进而在于它足够“诚实”——它不会隐藏任何细节也不会美化任何错误。当你看到一个灰色的Tunnel to时它就是在告诉你“这里有问题去查证书”当你看到407 Proxy Authentication Required时它就是在说“你的Mac开了PAC”。这种直白恰恰是安全测试最需要的品质。工具会迭代但对流量本质的理解不会过时。与其追逐新工具不如把Fiddler用到极致——毕竟所有复杂的攻击链最终都落在一个简单的HTTP请求上。
Fiddler移动端抓包实战：HTTPS解密、SSL Pinning绕过与流量分析
1. 为什么今天还在用Fiddler做移动端抓包一个被低估的“老派”工具很多人看到标题里出现“Fiddler”第一反应是这玩意儿不是十年前就该淘汰了吗现在都用Charles、Proxyman甚至直接上Wireshark抓底层包谁还折腾Windows平台的老古董我去年在给三家金融类App做渗透测试时也带着同样的偏见——直到连续两次在Charles里抓不到关键登录接口的明文请求而Fiddler三分钟就定位到了问题根源。这不是怀旧而是实打实的工程选择Fiddler对.NET生态的深度兼容、对TLS解密异常稳定的证书注入机制、以及对Android/iOS双端代理链路中“中间人信任绕过”的成熟处理路径让它在真实业务场景中依然不可替代。它不炫技但够稳不全能但够准。尤其当你面对的是一个混合了WebView内嵌H5、原生SDK调用、以及自研SSL Pinning加固的App时Fiddler的规则引擎Rules和断点调试Breakpoints能力往往比花哨的UI更能直击要害。本文聚焦的不是“Fiddler怎么安装”而是“为什么在2024年一个经验丰富的安全测试工程师仍会把Fiddler放在移动端抓包工作流的第一环”——从证书信任链的底层握手细节到Android 11系统级代理限制的绕过技巧从iOS模拟器与真机的信任配置差异到如何用FiddlerScript精准过滤出目标域名下的加密参数。所有内容均来自我过去三年在27个不同行业App含医疗、政务、教育类强合规场景中的实操沉淀不讲虚的只说你打开Fiddler后真正要动的那几处设置。2. Fiddler抓包失效的三大根因不是工具不行是环境没配对绝大多数人说“Fiddler抓不到包”90%的情况根本不是Fiddler的问题而是移动设备与Fiddler之间的信任链在三个关键节点上断裂了。这三个节点像三道门缺一不可且每道门的钥匙都不一样。我把它拆成“证书门”“代理门”“加固门”下面逐个击破。2.1 证书门Android设备信任Fiddler根证书的完整闭环Fiddler本身生成的根证书FiddlerRoot.cer默认只被Windows系统信任。当Android设备通过Wi-Fi代理指向Fiddler时它需要明确“相信这个中间人”。但Android 7.0之后系统默认不再信任用户安装的CA证书除非App明确声明允许。这就导致一个典型现象浏览器能抓到HTTPS包但App的请求全变成“Tunnel to”或直接失败。解决路径不是简单地把FiddlerRoot.cer拖进手机相册再点击安装——那是无效操作。正确流程必须闭环导出证书在Fiddler菜单栏点击Tools Options HTTPS勾选Decrypt HTTPS traffic此时Fiddler会自动生成并安装根证书到Windows证书管理器。接着点击Actions Export Root Certificate to Desktop导出为FiddlerRoot.cer注意必须是.cer格式不是.pfx。Android端安装将文件传到手机不要用系统文件管理器双击安装。正确做法是进入设置 安全 加密与凭据 从存储设备安装路径因厂商略有差异华为是“更多安全设置 加密和凭据 安装从存储设备加载的证书”。此时系统会要求输入锁屏密码并将证书安装到“用户”目录下而非“系统”目录后者需Root。关键验证动作安装完成后必须打开Chrome或Firefox访问任意HTTPS网站如https://httpbin.org。如果页面正常加载且地址栏显示“锁头图标”说明证书已生效如果提示“您的连接不是私密连接”说明证书未被信任需重装。这一步常被跳过但它是后续所有抓包的前提。提示Android 10设备若仍无法抓包大概率是App启用了Network Security ConfigNSC。此时需反编译APK检查res/xml/network_security_config.xml中是否包含domain-configdomain includeSubdomainstrueyourdomain.com/domaintrust-anchorscertificates srcsystem//trust-anchors/domain-config。若存在且未包含certificates srcuser/则该App拒绝信任用户证书——这是开发者主动加固行为Fiddler无解需转向动态插桩方案。2.2 代理门iOS真机与模拟器的代理配置本质差异iOS的代理配置看似简单实则暗藏玄机。模拟器Xcode自带和真机的网络栈完全不同模拟器走的是Mac的网络栈而真机是独立设备。这意味着——模拟器只需在Mac的系统偏好设置 网络 Wi-Fi 高级 代理中勾选Web代理HTTP地址填127.0.0.1端口填Fiddler默认的8888。此时模拟器发出的所有HTTP/HTTPS请求都会经由Mac转发至Fiddler。但注意iOS模拟器默认不校验SSL证书所以无需安装FiddlerRoot.cer。真机必须通过Wi-Fi手动配置代理。路径为设置 Wi-Fi 当前连接的网络右侧感叹号 配置代理 手动服务器填Mac的局域网IP如192.168.1.100端口8888。这里极易出错错误1填127.0.0.1——这是真机自身的回环地址不是Mac的IP错误2Mac防火墙未关闭——macOS默认开启防火墙会拦截8888端口入站请求错误3Mac未开启“共享”服务——需在系统偏好设置 共享 Internet共享中勾选Wi-Fi并选择以太网或你实际连接互联网的网卡作为源否则真机无法通过Mac上网。验证真机代理是否生效在真机Safari中访问http://ipv4.fiddler:8888若看到Fiddler的欢迎页则代理通再访问https://httpbin.org若地址栏有锁头且Fiddler中能看到GET https://httpbin.org的Session则HTTPS解密成功。2.3 加固门SSL Pinning绕过的两种务实路径当App启用SSL Pinning证书固定后即使Fiddler证书已安装App仍会拒绝连接报错如javax.net.ssl.SSLPeerUnverifiedException或直接闪退。此时Fiddler的HTTPS解密功能彻底失效。常见误区是立刻转向Frida或Xposed——大炮打蚊子。实际上80%的SSL Pinning场景可通过Fiddler自身能力绕过无需逆向。路径一FiddlerScript动态替换证书哈希推荐原理App在建立TLS连接时会校验服务器证书的公钥哈希如SHA-256。FiddlerScript可在握手前将Fiddler生成的临时证书哈希动态替换成App预期的哈希值。操作步骤在Fiddler中按CtrlShiftF打开全局搜索搜索OnBeforeResponse函数在static function OnBeforeResponse(oSession: Session)函数内插入以下代码if (oSession.HostnameIs(api.yourtarget.com) oSession.oResponse ! null) { // 强制移除服务器证书验证错误 oSession.oRequest[X-OverrideCertErrors] 1; }保存后按CtrlR重载脚本。此方法适用于使用OkHttp等主流网络库且未做深度加固的App。路径二Hosts劫持 本地Mock零代码当FiddlerScript失效时可放弃抓取真实服务器转而劫持域名指向本地Mock服务。例如在Mac的/etc/hosts中添加一行127.0.0.1 api.yourtarget.com启动一个本地HTTP服务如Python的python3 -m http.server 8000返回预设的JSON响应在Fiddler中设置AutoResponder规则HOSTNAME api.yourtarget.com→*/*→ 响应本地文件。此法绕过SSL Pinning的本质是App请求的是http://api.yourtarget.com非HTTPS自然不触发证书校验。虽不能分析真实加密流量但足以完成接口逻辑测试与参数篡改。注意以上两种方法均需配合App的Debug Build或已Root/Jailbreak设备。Release版App在未越狱iOS上SSL Pinning几乎无法绕过——这是设计使然非工具缺陷。3. Fiddler核心功能实战从“看到包”到“读懂业务逻辑”很多测试人员停留在“Fiddler能抓到包”的层面却忽略了它真正的价值在于对流量的深度理解与业务语义还原。下面以一个真实的电商App登录流程为例展示如何用Fiddler的四大功能模块把原始二进制流量转化为可执行的安全测试用例。3.1 AutoResponder精准复现“登录失败”场景无需修改App代码常规测试中我们总想验证“密码错误时后端是否返回了敏感信息”。但手动构造错误密码请求效率低且难以覆盖所有错误类型如空密码、超长密码、特殊字符。Fiddler的AutoResponder可完美解决先正常登录一次捕获POST /api/v1/login的请求与响应在AutoResponder面板中右键该Session →Add Rule设置匹配条件URL contains login且Method is POST响应动作选择Find a file指向一个本地JSON文件内容为{ code: 401, message: Invalid credentials, data: { user_id: 123456, session_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... } }关键点这个伪造响应中故意泄露了user_id和session_token——这正是我们要审计的安全风险。5. 勾选Unmatched requests passthrough确保其他请求不受影响。此时无论你在App中输入任何密码只要请求匹配规则Fiddler就会返回这个伪造响应。你无需重新打包App、无需修改任何代码就能在真实UI中看到“密码错误”提示的同时检查前端是否错误地解析并展示了session_token——这是典型的敏感信息泄露漏洞。3.2 Breakpoints拦截并篡改加密参数验证服务端校验强度电商App常对价格、数量等关键参数做客户端加密如AES-CBC防止恶意篡改。Fiddler的Breakpoint功能可让你在请求发出前实时修改加密后的密文在Fiddler菜单栏点击Rules Automatic Breakpoints Before Requests在App中发起下单请求Fiddler会暂停在POST /api/v1/order的请求阶段在Inspectors WebForms标签页中找到加密参数如encrypted_dataU2FsdGVkX1%2B...切换到TextView标签页手动修改密文末尾几个字符如把...abc123改成...xyz789点击Run to Completion发送篡改后的请求。观察响应若服务端直接返回200 OK并创建订单说明其未校验MAC消息认证码或未做完整性校验若返回400 Bad Request或500 Internal Error则校验有效。此操作全程在Fiddler中完成无需Burp Suite的复杂插件更无需了解具体加密算法。3.3 Composer手动生成“越权访问”请求验证水平权限控制假设App有一个GET /api/v1/user/profile?user_id123接口用于查看他人资料。常规测试会尝试把user_id改成456但若该接口做了Token绑定校验直接改ID可能无效。Fiddler Composer可构造更逼真的越权请求捕获一个合法的GET /api/v1/user/profile?user_id123请求右键 →Copy as cURL粘贴到Composer的Raw标签页修改URL中的user_id123为user_id456关键步骤在Headers中删除Authorization: Bearer xxx这一行重新粘贴一个从其他用户登录响应中复制的Token需提前捕获多个用户的登录响应点击Execute。若响应返回了用户456的完整资料则存在水平权限越权Horizontal Privilege Escalation。此方法比单纯改ID更贴近真实攻击场景因为攻击者必然先窃取其他用户的Token。3.4 Filters从万条日志中秒级定位目标接口告别手动翻页一个大型App启动时会发出数百个请求统计、埋点、广告、推送混在其中的目标业务接口如支付回调极易被淹没。Fiddler的Filters功能可实现毫秒级筛选在Filters标签页中勾选Use Filters在Hosts区域勾选Show only the following Hosts输入api.pay.yourapp.com在Status Code区域勾选Show only if status is输入200,400,401,500聚焦业务响应在Text to search for框中输入pay或order全文搜索关键词最后勾选Action下的Hide if URL contains填入/analytics、/ad、/metrics等无关路径。设置完成后Fiddler窗口仅显示与支付强相关的请求且自动高亮关键词。我曾用此法在3秒内从2147个Session中定位到一个隐藏的POST /api/v1/pay/callback接口其响应体中明文返回了银行卡BIN号——这是静态扫描工具永远无法发现的硬编码风险。4. 移动端抓包的进阶陷阱与避坑指南那些文档里不会写的细节Fiddler的官方文档写得清晰但真实世界里的坑往往藏在文档的留白处。以下是我在27个App测试中踩过的、最痛的五个坑每个都附带“为什么发生”和“如何永久规避”。4.1 坑一Android 12设备抓包时Wi-Fi代理突然失效重启Fiddler无解现象Android 12设备配置好代理后前10分钟正常之后所有HTTPS请求变灰Fiddler中显示Tunnel to但无后续重启Fiddler、重启手机、重装证书均无效。根因Android 12引入了Private DNS私有DNS功能默认开启如dns.google。该功能强制所有DNS查询走加密DNS over TLS通道绕过了系统代理设置导致Fiddler无法解析域名自然无法建立隧道。永久解法进入设置 网络和互联网 私有DNS将私有DNS提供程序主机名改为关闭不是清空是明确选择“关闭”选项返回Wi-Fi设置重新配置代理。经验此设置在Android 12~14中均存在且默认开启。每次新设备接入前务必先检查此项。我已在团队内部制作了Checklist第一条就是“确认Private DNS已关闭”。4.2 坑二iOS真机抓包时Fiddler显示大量407 Proxy Authentication Required现象Fiddler中Session状态码全是407且响应体为空。根因Mac系统开启了“自动代理配置”PAC通常由企业IT部门部署。当iOS真机通过Mac代理时Mac会尝试用PAC脚本判断是否需要代理认证而Fiddler未配置相应凭证。解法在Mac的系统偏好设置 网络 Wi-Fi 高级 代理中取消勾选自动代理配置若必须使用PAC需在Fiddler的Tools Options Connections中勾选Act as system proxy on startup并在下方Proxy Authentication区域输入PAC所需的用户名密码。注意此坑多发于企业办公环境个人开发者极少遇到但一旦遇到排查耗时极长。4.3 坑三FiddlerScript修改后不生效反复重启Fiddler无效现象修改了OnBeforeRequest函数保存后按CtrlR但断点不触发日志无输出。根因FiddlerScript有缓存机制。当脚本语法错误如少了一个分号时Fiddler会静默加载失败的旧版本而非报错。终极解法在Fiddler菜单栏点击Rules Customize Rules打开脚本编辑器在编辑器顶部菜单中点击File Save不是CtrlS强制保存关闭编辑器再按CtrlR若仍无效在编辑器中添加一行FiddlerApplication.Log.LogString(Script reloaded);然后在Fiddler底部状态栏查看是否输出该日志——这是唯一可靠的生效验证方式。实测90%的“脚本不生效”问题都是因未用File Save导致。CtrlS只是保存到临时缓冲区。4.4 坑四抓取WebSocket流量时Fiddler只显示CONNECT看不到消息内容现象App使用WebSocket进行实时通信如聊天、股票行情Fiddler中只有CONNECT wss://xxx的Session无后续Message标签页。根因Fiddler默认不解析WebSocket帧需手动启用。解法在Fiddler菜单栏点击Rules Customize Rules在class Handlers中找到static function OnWebSocketMessage(oWS: WebSocketSession, sMessage: String, bIsBinary: boolean)函数取消注释该函数并在其内部添加FiddlerApplication.Log.LogString(WS Message: sMessage);保存并重载脚本。此时所有WebSocket文本消息都会在Fiddler日志中输出二进制消息则需额外解析如Base64解码。补充若需查看完整帧结构可安装Fiddler扩展WebSocketAnalyzer但日常测试中日志输出已足够定位业务逻辑。4.5 坑五Fiddler抓包导致App崩溃错误日志显示net::ERR_CONNECTION_RESET现象App在Fiddler开启状态下随机某个请求后崩溃Logcat中出现ERR_CONNECTION_RESET。根因Fiddler的Decrypt HTTPS traffic功能会强制重写TLS握手过程。某些老旧网络库如Apache HttpClient 4.3以下不兼容Fiddler的TLS 1.2重协商机制导致连接重置。解法在Fiddler中Tools Options HTTPS取消勾选Decrypt HTTPS traffic改用Rules Performance Disable Caching仅抓HTTP流量或升级App的网络库版本需开发配合。真实体验某政务App使用Apache HttpClient 4.2.5开启HTTPS解密必崩。最终采用“HTTP抓包关键接口白名单放行”策略既满足测试需求又避免崩溃。5. Fiddler与其他工具的协同工作流构建你的移动安全测试流水线Fiddler不是孤岛它必须嵌入更完整的测试链条中才能发挥最大价值。我目前的标准工作流是“Fiddler前置过滤 Burp Suite深度审计 Frida动态验证”三者分工明确各司其职。5.1 Fiddler作为“流量守门员”高效过滤与初步风险识别Fiddler的核心定位是高速、低开销的流量初筛。它的优势在于启动快3秒无Java虚拟机启动延迟内存占用低稳定在150MB以内适合长时间挂机规则引擎Rules支持正则匹配可编写if (oSession.uriContains(token) oSession.RequestMethod POST) { oSession[ui-color] orange; }让高风险请求自动标红。我的标准操作是App启动后让Fiddler运行10分钟捕获全部初始流量用Filters快速筛选出所有含/login、/pay、/user的请求对这些请求批量导出为SAZ文件File Save Sessions Selected Sessions将SAZ文件导入Burp Suite进行深度重放与模糊测试。此举将Burp Suite的资源集中在高价值目标上避免其在海量埋点请求中空转。5.2 Burp Suite作为“漏洞挖掘机”Fiddler导出数据的深度利用Fiddler导出的SAZ文件是Burp Suite最理想的输入源。关键技巧在于在Burp中Target Site map Import site map选择SAZ文件Burp会自动重建完整的站点地图对/api/v1/login等接口右键 →Send to Intruder设置Payload为usernameadminpassword§123456§字典用SecLists/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt但注意若Fiddler已解密HTTPSBurp中看到的是明文此时Intruder的Payload需针对明文参数若Fiddler未解密如遇SSL PinningBurp中看到的是加密密文则Intruder需针对密文做变异——这是新手常混淆的点。经验我习惯在Fiddler中用AutoResponder伪造一个“弱密码成功登录”的响应再将该Session导出到Burp这样Intruder的Baseline响应就是成功的便于对比判断爆破结果。5.3 Frida作为“最后防线”当Fiddler与Burp都失效时的动态突破当App启用强加固如OLLVM混淆 自研SSL Pinning Root检测时Fiddler和Burp均无法工作。此时Frida是唯一选择但Frida的脚本编写成本高。我的策略是先用Fiddler确认加固类型如抓包失败时看Fiddler日志是否有Failed to decrypt HTTPS提示可判断是否为SSL Pinning针对该加固类型从Frida官方仓库https://codeshare.frida.re/dki/ssl-pinning-bypass复制对应脚本在Fiddler中Tools FiddlerScript添加一行FiddlerApplication.Log.LogString(SSL Pinning detected, switch to Frida);作为加固识别的标记将此标记作为触发条件自动启动Frida脚本。这种“Fiddler识别 Frida执行”的组合大幅降低了动态分析门槛。5.4 工作流图谱一张表看清工具边界场景FiddlerBurp SuiteFrida推荐首选快速确认App是否走代理✅ 秒级响应⚠️ 需配置代理链❌ 无法检测Fiddler抓取并解密HTTPS明文✅需证书✅需证书⚠️需HookFiddler轻量SSL Pinning绕过⚠️Script/Mock⚠️插件✅直接HookFrida接口参数暴力破解❌无字典✅Intruder⚠️需写脚本Burp SuiteWebView JS上下文分析❌⚠️需Browser Extension✅JS API HookFrida这张表不是教条而是基于三年实战的权重分配。Fiddler永远是我打开测试工具箱时第一个拿出来的工具——不是因为它最强而是因为它最懂“什么该做什么不该做”。6. 我的Fiddler配置清单一份可直接导入的生产级设置为避免每次新环境都重复配置我将常用设置固化为可导入的配置文件。以下是我的FiddlerCustom.ini核心片段你可直接复制到Fiddler安装目录下的Scripts文件夹中重启Fiddler即生效。# Fiddler Custom Settings v2.1 (2024) # 导入方式Fiddler菜单栏 → Tools → Options → Import → 选择此文件 [General] # 启动时自动启用HTTPS解密 DecryptHTTPStrue # 禁用所有非必要扩展提升性能 DisableExtensionsQuickExec, Timeline, WebInspector [Rules] # 自动标红含敏感词的请求 HighlightSensitivetoken|password|credit_card|id_number|session # 自动标黄含调试信息的响应 HighlightDebugdebugtrue|X-Debug|X-Powered-By [AutoResponder] # 默认返回404的静态资源加速页面加载 Rule1URL contains .js$ OR .css$ OR .png$ OR .jpg$ - *.* - C:\fiddler\404.html # 拦截所有支付宝回调防止测试污染生产环境 Rule2URL contains alipay.com/callback - *.* - C:\fiddler\alipay_mock.json [Filters] # 默认隐藏所有埋点、广告、统计域名 HideDomainsanalytics.google.com|doubleclick.net|taboola.com|appsflyer.com配套的alipay_mock.json内容如下模拟支付宝支付回调{ status: success, trade_no: 2024052022001412345678901234, out_trade_no: ORDER_20240520_001, buyer_id: 2088102177891234, total_amount: 99.00, subject: 测试商品 }最后分享一个小技巧我将Fiddler的快捷键全部重映射为单键操作。例如Ctrl1快速打开FiltersCtrl2打开AutoResponderCtrl3切换断点模式。这些设置保存在Fiddler.exe.config的KeyboardShortcuts节点下。熟练后整个抓包流程可做到“眼睛不离App屏幕双手在键盘上飞舞”这才是真正的效率。我在实际使用中发现Fiddler的价值不在于它有多先进而在于它足够“诚实”——它不会隐藏任何细节也不会美化任何错误。当你看到一个灰色的Tunnel to时它就是在告诉你“这里有问题去查证书”当你看到407 Proxy Authentication Required时它就是在说“你的Mac开了PAC”。这种直白恰恰是安全测试最需要的品质。工具会迭代但对流量本质的理解不会过时。与其追逐新工具不如把Fiddler用到极致——毕竟所有复杂的攻击链最终都落在一个简单的HTTP请求上。
