正 文：

一般在浏览器场景下，我们可以利用Fiddler很好的完成抓包，对HTTP或HTTPS连接可以清晰地看到各种数据包。但是对于一些pc端的客户端，比如各种exe可执行文件，就很有可能无法直接使用fiddler抓包。

本文就来看下fiddler如何抓包windows系统里的pc软件的通讯数据包。

一，Fiddler下载

关于Fiddler的基本使用，飘易就不再赘述，基本属于即开即用，注意软件的左下角Capturing状态，点击这个小图标可以开启或关闭抓包。

Fiddler抓包的原理，实际上就是相当于给windows设置了一个HTTP/HTTPS代理，类似于在IE浏览器中设置代理，如[Internet 选项] — [连接] — [局域网设置] — [高级]中设置代理 [127.0.0.1:8888]，Fiddler在8888端口提供HTTP/HTTPS代理服务。

二、监听HTTPS数据包

针对HTTPS的抓包，需要开启Fiddler的HTTPS抓包功能，否则只能看到HTTP请求的内容，因为HTTPS请求的是密文。

在Fiddler中点击[Tools] — [Options] — [HTTPS]勾选如下设置：

点击[Actions] — [Trust Root Certificate]让系统信任Fiddler的根证书，这是HTTPS抓包解密的关键，接下来就可以愉快的观看HTTPS请求明文内容了。

在 [Tools] — [Options] — [Connections]勾选如下设置：

到这里，浏览器的https或部分软件的https通讯请求基本可以看到明文了。但是有部分软件，这样设置后，依然还是无法抓到明文数据包，只会出现大量的 Tunnel to xx:443 错误，请求里的提示信息是：A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.3 (TLS/1.2)

Random: 5F DC D3 69 67 7A E2 4E CB FA 53 FE FA 70 4B B2 16 85 9D 75 05 0D CC 1A C7 A0 32 E2 00 A6 B7 F5

"Time": 2026-04-07 00:16:31

SessionID: D3 17 00 00 00 B5 D9 A2 45 E4 A2 90 C9 F9 08 9F 1F 6E D4 74 EB 98 5C 47 61 5B 94 1C 65 05 3E 7D

Extensions:

supported_groupssecp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19], sect283k1 [0x9], sect283r1 [0xa], sect409k1 [0xb], sect409r1 [0xc], sect571k1 [0xd], sect571r1 [0xe], secp256k1 [0x16]

ec_point_formatsuncompressed [0x0]

signature_algsecdsa_secp521r1_sha512, rsa_pkcs1_sha512, ecdsa_secp384r1_sha384, rsa_pkcs1_sha384, ecdsa_secp256r1_sha256, rsa_pkcs1_sha256, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1

extended_master_secretempty

server_namewww.***.com

Ciphers:

[C024]TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

[C028]TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

[003D]TLS_RSA_WITH_AES_256_CBC_SHA256

[C026]TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

[C02A]TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384

[006B]TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

[006A]TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

[C00A]TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

[C014]TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

[0035]TLS_RSA_WITH_AES_256_CBC_SHA

[C005]TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

[C00F]TLS_ECDH_RSA_WITH_AES_256_CBC_SHA

[0039]TLS_DHE_RSA_WITH_AES_256_CBC_SHA

[0038]TLS_DHE_DSS_WITH_AES_256_CBC_SHA

[C023]TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

[C027]TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

[003C]TLS_RSA_WITH_AES_128_CBC_SHA256

[C025]TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

[C029]TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

[0067]TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

[0040]TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

[C009]TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

[C013]TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

[002F]TLS_RSA_WITH_AES_128_CBC_SHA

[C004]TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

[C00E]TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

[0033]TLS_DHE_RSA_WITH_AES_128_CBC_SHA

[0032]TLS_DHE_DSS_WITH_AES_128_CBC_SHA

[C02C]TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

[C02B]TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

[C030]TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

[009D]TLS_RSA_WITH_AES_256_GCM_SHA384

[C02E]TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384

[C032]TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

[009F]TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

[00A3]TLS_DHE_DSS_WITH_AES_256_GCM_SHA384

[C02F]TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

[009C]TLS_RSA_WITH_AES_128_GCM_SHA256

[C02D]TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

[C031]TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

[009E]TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

[00A2]TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

[00FF]TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Compression:

[00]NO_COMPRESSION

请求响应的信息会提示和服务端的加密算法不一致，出错。其实，这个错误是因为ssl的安全证书没有设置或设置错误导致的，https的请求的证书未通过校验。SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException 调用 SSPI 失败，请参见内部异常。

三、为什么抓不到有些应用程序的HTTP(s)的包？

开启 [All Processes] 抓包后，我们运行第三方程序，会发现有的HTTP/HTTPS包可以抓到，而有的却抓不到，这是怎么回事？那是因为Fiddler的这种设置全局代理的方式，只对以下几种情况有效：IE、Chrome等浏览器。

程序使用Windows提供的WinInet库进行HTTP/HTTPS通信。

程序内嵌WebBrowser，比较常用的是IE控件和CEF。

例如如果应用程序中使用的是libcurl库进行HTTP(s)请求，则fiddler就抓不到包了，因为libcurl没有使用windows的WinInet库，而是自己实现了http(s)协议的封装。

如果有程序源码，可以在源码中设置Libcurl使用fiddler作为本地代理。如果没有，我们也可以实现将软件的代理设置为fiddler的端口。

Fiddler之所以能抓到并解密HTTPS包的内容，是因为Fiddler使用了中间人攻击的手段，该手段要能成功实施，有一个前提条件，就是客户端信任Fiddler提供的根证书，之前我们通过[Actions] — [Trust Root Certificate]让系统信任Fiddler的根证书后，大部分浏览器以及基于WinInet库进行HTTP通信的程序，都会信任操作系统中我们添加的Fiddler根证书。但如果第三方程序使用其它HTTP库进行通信，比如libcurl，JAVA的URLConnection库，C#的System.Net.Http，Python的requests，这些HTTP库一般自带了一套可信任的SSL根证书，它们不使用操作系统自带的SSL根证书，更不会使用我们向操作系统中添加的Fiddler根证书，于是就验证出错了。

下面详细给出解决这种问题的2种方法：在请求时禁用证书验证。

在请求时，指定自己生成的证书。

1、请求时禁用证书验证

以python为例：import requests

requests.get("https://www.baidu.net", verify = False)

2、请求时信任自己的证书，请查看下面的“设置代理”。

四，设置代理

1，软件本身提供了设置代理的界面

比如迅雷下载、QQ等客户端：

Fiddler抓包的原理是在本机的8888端口开启HTTP/HTTPS代理，任何通过Fiddler代理的HTTP/HTTPS通信内容都会被解析，那么只要能给目标程序设置HTTP/HTTPS代理，目标程序的HTTP(s)通讯内容就可以被Fiddler抓到。

2，软件没有提供设置代理界面，但隐藏了代理功能

有些java开发的客户端，并没有提供设置代理的界面，但是软件其实是有这个功能的，我们可以找到配置文件，比如 config.cfg，打开并编辑，添加如下配置：[JVMOptions]

-Dhttp.proxyHost=127.0.0.1

-Dhttp.proxyPort=8888

-Dhttps.proxyHost=127.0.0.1

-Dhttps.proxyPort=8888

-Djavax.net.ssl.trustStore=e:/cer/FiddlerRoot.jks

-Djavax.net.ssl.trustStorePassword=123456

就可以设置软件的代理为fiddler的端口了，并且使用fiddler的证书。注意，-Djavax.net.ssl.trustStore 这个证书的设置非常关键，如果没有这个证书，HTTPS也是无法得到明文的。

那么这个证书是怎么来的呢？有2个途径。

2.1、访问 http://127.0.0.1:8888/，下载Fiddler的根证书

如图：

点击下载fiddlerroot 证书，得到 FiddlerRoot.cer 文件。

2.2、fiddler直接导出证书

也可以通过 fiddler - tools - options - HTTPS - actions - Export Root Certificate to Desktop 把证书导出到桌面，也一样获得 FiddlerRoot.cer 文件：

2.3、转换cer证书格式

然后利用java的keytool.exe把这个证书转换成需要的格式，比如java里需要jks证书，我们转换命令为："C:\Program Files\Java\jdk1.8.0_152\bin\keytool.exe" -import -file e:\cer\FiddlerRoot.cer -keystore e:\cer\FiddlerRoot.jks

转换的时候，需要输入密钥，一般输入 123456，如下图：

3、也可以直接把java的代理设置为系统代理

这样就可以让客户端和IE浏览器公用一个代理[JVMOptions]

-Djava.net.useSystemProxies=true

但是，请注意，这种方式可能无法对特定程序(非WinInet的HTTPS通讯请求)指定证书文件。

六、Proxifier设置全局代理

通过Proxifier设置全局sock5代理，并转发给fiddler。这种方式，也可能无法对特定程序(非WinInet的HTTPS通讯请求)指定证书文件。

1、Proxifier 代理服务器

Proxifier - 配置文件 - 代理服务器 - 添加一条指向fiddler的端口的代理：

2、Proxifier 名称解析

Proxifier - 配置文件 - 名称解析 - 勾选“通过代理解析主机名称”

这个主要是为了避免转发到fiddler后，fiddler获取的是proxifier解析后的ip地址，从而导致https的服务器端验证ssl证书失败。

让域名解析的工作交给代理服务器，而不是在Proxifier上解析。默认情况下Proxifier自行解析域名，比如www.baidu.com解析为180.97.33.108，然后发请求给Fiddler：CONNECT 180.97.33.108:443 HTTP/1.1

这样Fiddler并不知道它请求的是哪个域名，于是返回给客户端的伪造证书时，伪造的是为180.97.33.108颁发的证书，有的客户端会做校验，发现这个证书是颁发给180.97.33.108的，而不是颁发给www.baidu.com的，然后报错处理。

修改Proxifier设置后，把域名解析的工作交给代理服务器，Proxifier会直接向Fiddler发送请求：CONNECT www.baidu.com:443 HTTP/1.1

这样Fiddler就知道客户端请求的是 www.baidu.com，从而返回客户端伪造的www.baidu.com证书，客户端不报错，Fiddler才能顺利抓包解密。

3、Proxifier 代理规则

Proxifier - 配置文件 - 代理规则：

代理规则需要把fiddler或chrome等特定的程序例外掉，不要走proxifier代理，让他们直接联网，不然chrome等浏览器这些客户端是无法打开网页的。

本文结束。

参考：