部分APP⽆法代理抓包的原因及解决⽅法
引⾔
HTTP应⽤层的抓包已经成为⽇常⼯作测试与调试中的重要⼀环，最近接触新项⽬突然之间发现之前的抓包⼿段都不好使了，顿时模块与模块之间的前端与服务之间的交互都变成了不可见，整个⼈都好像被蒙住了眼睛。
其实⾃⼰也很早就发现平时使⽤的⽀付宝等APP使⽤Fiddler 或 Charles这类代理抓包软件默认情况下就⽆法抓取请求的，但使⽤Wireshark 这类⽹卡抓包软件可以看到这些APP的流量，⽽已这些流量也表明这些APP使⽤的主要应⽤层协议仍然是HTTP（https），不过我们的代理抓包⼯具却失效了。如今终于在实际⼯作中遇到了，也不得不解决了，毕竟眼前有东西挡住会让我浑⾝不适。
代理抓包原理
为了弄明⽩为什么Fiddler 或 Charles对这些APP⽆效，我们有必要先了解代理抓包我原理（当然您不想了解也是完全可以的，直接看后⾯的就可以完成，原理分析什么的可以有兴趣随时回来看）
Fiddler 或 Charles 这类使⽤的代理的抓包软件与Wireshark是完全不同的（Wireshark 使⽤的⽹卡数据复制，只要是经过指定⽹卡都会被抓取），其只能对使⽤代理的应⽤层⽹络协议⽣效，⽐如常见的HTTP
（https），Websocket 。
这⾥以HTTP为例简单说明下
接下来我来看下HTTP代理是如何运作的，我们启动Fiddler 或 Charles就是启动了⼀个HTTP代理服务器，这类⼯具会通知操作系统，“现在我在系统上创建了⼀个HTTP代理，IP为XXXXXX端⼝为XX。如果您使⽤的是linux您可以⼿动通知操作系统(export http_proxy=ip:port export https_proxy=$http_proxy)，如果您使⽤的是⼿机等移动设备您可以在当前wifi设置处告诉系统你要使⽤http代理。现在我们已经告诉系统我们想要使⽤代理，这个时候运⾏在系统上的http客户端再去发送请求的时候，他就不会再去进⾏DNS解析，去连接⽬标服务器，⽽是直接连接系统告诉他代理所在的地址（代理的ip及端⼝，注意⽆论是http或https或其他⽀持代理的协议都会连接同⼀个端⼝）。然后代理服务器会与客户端建⽴连接，再然后代理服务器根据请求信息再去连接真正的服务器。
这⾥还有个细节正常在没有代理的情况下客户端向服务器发送的请求⾏⾥只包含部分URI（实际上是没有⽅案，主机名及端⼝的）
如上图如果在没有代理的情况下，对www.baidu/index.html的请求的请求⾏实际上是GET /index.html HTTP/1.1 其实并不是我们常见的完整uri。因为在原始的HTTP设计中没有考虑中间服务器（即代理）的情况，客户端在发送报⽂前已经知道服务器的地址并与之建⽴了连接，没有必要再发送
⽅案，主机名及端⼝。不过代理出现后这种做法就会有问题了，客户端连接了代理服务器，⽽代理服务器却没有办法连接正确的服务器。因此客户端发送给代理的请求其实稍有不同，客户端会在请求⾏⾥使⽤完整的uri，这样代理服务器才能解析真实的服务器的地址。
现在我们的请求实际上都是通过代理服务器（Fiddler 或 Charles）发送出去的，所以代理抓包软件不仅知道http请求及响应的所有报⽂，甚⾄还可以随时修改请求及响应。
部分应⽤不能抓包的原因
可以看到代理抓包的关键就是需要HTTP客户端按照要求去连接代理服务器，⼀般情况下我们已经在系统层⾯上设置了代理，通常http客户端都是按要求去实现的，在进⾏http请求前会先检查系统代理，如果有设置代理，客户端会直接使⽤完整uri去连接代理服务器。不同的平台通常会实现⾃⼰的的http客户端的，虽然他们都按照协议要求实现了代理功能，但是并不⼀定在默认情况下会直接使⽤系统代理。
在现实中这种况下这种情况还不少，笔者当前项⽬使⽤到的Flutter就是这种情况，默认Flutter不会主动使⽤系统代理，需要单独设置。（当然个⼈认为这种策略也是有理由，虽然给测试及调试带来了不便不过也在⼀程度上提⾼了些许）
正是因为HTTP客户端没有使⽤我们设置的系统代理，他们⾃然也不会连接Fiddler 或 Charles创建的代理服务器，最终导致我们⽆法获取任何请求。
解决⽅案
不过既然我们已经知道了Fiddler 和 Charles不能抓包的具体原因，前⾯也提到了代理抓包的原理，那我们就总有办法解决。
前⾯说到了我们APP使⽤的HTTP客户端没有连接到代理服务器，导致我们的代理抓包软件⽆法正常抓包，那我们只要想办法让客户端重新连接到代理服务器就好了（当然这⼀切都是以不修改客户端软件APP为前提的）
王力宏张惠妹⽅法1：控制DNS解析，通过修改dns的⽅式让客户端以为我们的代理服务器就是⽬标服务器。
优势：操作⽅便，通过修改设备的hosts可以⼗分⽅便的⾸先
劣势：需要为每个需要操作的域名提前添加host
在⼿机等⼿持设备上难以修改hosts（即对移动APP这类应⽤很难实现）
关于桥的谚语
⽅法2：在⽹络设备上直接做流量转发，将指定终端设备上发往80及443端⼝的数据直接转发到代理服务器的⽬标端⼝上优势：可以针对连接到⽹络设备上的终端设备进⾏分别配置，⽽⼿机等终端设备不需要进⾏任何设备
劣势：需要单独的硬件设备
⽅法3：使⽤V**将终端设备的流量转发到代理服务器
优势：使⽤V**软件不⽤添加其他测试。
劣势：终端上的V**默认会直接对所有流量进⾏转发，要进⾏合理的配置可能需要额外的学习成本
实际操作步骤
1：安装drony （这⾥⼿机使⽤的Android设备）
2：开启代理抓包软件（这⾥代理抓包软件使⽤的是Fiddler）
Fiddler的使⽤这⾥不再介绍，需要打开远程代理，并在⼿机中安装Fiddler根证书
这⾥笔者开启的远程代理的地址是192.168.2.244:8888
关于证书安装有些细节，Fiddler默认的根证书是cer格式，部分⼿机可能只能识别pem格式证书
吴芊盈直接使⽤openssl 转⼀下就⾏了（openssl x509 -inform der - -out FiddlerRoot.pem）
openssl 在中 windows/mac ⼀般都安装有，命令直接使⽤就⾏了，使⽤⽣成的FiddlerRoot.pem安装到⼿机上就⾏了（Charles默认就是pem证书）
3：配置drony转发
打开Drony（处于OFF状态），滑动到SETING页，点击选择Networks Wi-Fi 进⼊配置
在⽹络列表中选择点击当前⼿机wifi连接的⽹络（需要确保该⽹络与Fiddler代理服务器⽹络是联通的）
配置要为当前⽹络使⽤的代理⼊⼝（这⾥直接填写fiddler代理地址就可以），选择代理模式为⼿动（Manual）
注意Proxy type代理⽅式要选择 Plain http proxy
Filter default value 选择 Direct all ，然后点击下⾯的Rule设置应⽤规则
默认您的规则⾥应该是空的，这⾥直接点击上⾯的加号添加⼀个规则（符合规则要求的才会被转发）
说明⼀下后⾯的操作会以咸鱼或⽀付宝做演⽰说明，不过笔者当前测试项⽬并不是咸鱼或⽀付宝，也不是其公司的员⼯，选择这2个APP做演⽰是因为这些APP⽐较常⽤，且⽆法抓包的原因与笔者当前项⽬APP是类似的。
在Network id处选择当前wifi的SSID
Action 选择 Local proxy chain
Application 选择需要强制代理的APP
Hostname 及 Port 不填表⽰所有的都会被强制代理，因为APP可能会使⽤其他的⽹络协议不⼀定都是http，可能不希望把所有流量都引流到http代理服务器，这个时候就会使⽤这个配置指定ip及端⼝才转发
完成后保存即可，然后返回到SETTING主页，滑动到LOG页，点击下⾯按钮，使其处于ON的状态（表⽰启⽤）
这个时候启动⽀付宝或咸鱼，我们就可以在Fiddler上看到正常的流量。不过如果你的运⽓与笔者⼀样
可能只能看到这些Tunnel to （TLS管道建⽴），如果您使⽤的是Charles在列表⾥看到的可能是⼀个个红叉。
当然笔者Fiddler根证书是安装成功的，Fiddler配置也是正确的（⼿机上的Chrome https抓包都是正常的）
洪尧曹赢心既然流量已经到Fiddler了，Drony的⼯作算是完美完成了，之所部分APP以不能解密https报⽂，还是我们⾃⼰证书的问题。⾸先先简单描述下证书校验的过程（如果不想看这些过程可以直接看后⾯）
证书校验原理
⽆论Fiddler 或 Charles都使⽤中间⼈攻击的⽅式替换tls链路证书，解密报⽂然后再加密发送给真实服务器。
您可以参看了解中间⼈攻击的细节
存在代理的情况下客户端⾸先连接的是代理服务器（即是图中的攻击者），实际client是直接与Proxy建⽴的TLS通道，所以代理当然TLS通道的传输密钥然后解密报⽂。
不过由于证书的存在，client会校验证书的合法性，然后决定是否连接服务器。我们使⽤Fiddler或Charles抓取https前在设备中安装根证书正是为了通过client的证书校验。
在浏览器中任意⼀个https的⽹页，查看其证书信息。
从这⾥⾯我们能看到证书包含以下内容：
(1) Validity也即有效期，有效期包含⽣效时间和失效时间，是⼀个时间区间；
(2) 公钥信息Subject Public Key Info，包括公钥的加密算法和公钥内容；
(3) 指纹信息，指纹⽤于验证证书的完整性，也是证书校验的关键，他保证书没有被修改过。其原理就是在发布证书时，发布者根据指纹算法(此处证书使⽤了SHA-1和SHA-256算法有多个指纹是为了兼容⽼的客户端)计算整个证书的hash指纹【证书内容hash值使⽤CA私钥加密就是指纹】并和证书放在⼀起，client在打开证书时，⾃⼰也根据指纹算法计算⼀下证书的hash值，同时使⽤⾃⼰信任的根证书的公钥解密hash指纹计算出原始hash，如果hash值不⼀致，则表明证书内容被篡改过；
(4) 证书的签名Certificate Signature Value和Certificate Signature Algorithm，对证书签名所使⽤的Hash算法和Hash值；
(5) 签发该证书的CA机构Issuer；
(6) 该证书是签发给哪个组织/公司信息Subject；
(7) 证书版本Version、证书序列号Serial Number以及Extensions扩展信息等。
上图即是证书指纹校验的过程，可能看到Client校验证书的核⼼其实是CA公钥解密原始指纹，CA公钥从哪⾥来，为了确保安全设备系统会有⼀批⾃⼰信任的CA公钥列表（根证书）。这些CA公钥对应的⼀般是权威机构或组织，然后由这些权威机构颁发证书时会使⽤他们⾃⼰的私钥去签名（为证书⽣成指纹）。这样就确保了只有权威机构颁发给各个⽹站的证书才会被客户端校验通过。
Filddler没有这些证书⾥公钥对应的私钥（CA只会把为完整颁发的证书对应的私钥给⽹站的所有者），所以没有办法与客户端完成TLS握⼿。Filddler为了完成握⼿只能⾃⼰为不同的站点⽣成证书，
不过⾃⼰的⽣成的证书肯定是⽤⾃⼰的私钥签名的，客户端在⾃⼰信任的CA公钥列表不到对应根证书，肯定是不能通过证书校验的。所以Filddler要求我们安装他的根证书到设备，这样⾃⼰签发的证书就可以通过证书校验，⾃⼰就能解密https报⽂了。
不能解密的原因
其实通过上⾯的描述也很明⽩了不能正常建⽴连接解密https报⽂的原因就是证书校验失败，我们的根证书安装不够完全。
从Android7.0以后，系统允许每个应⽤可以定义⾃⼰的。有部分应⽤默认只会信任系统预装的CA证书，
⽽不会信任⽤户安装的CA证书（或者说是应⽤使⽤的开发框架默认只信任系统证书，因为开发者通常不关⼼这些配置，也不会去更改他）。⽽在Android中⽤户安装的证书都是⽤户证书，所以⽆论是Filddler还是Charles我们都只是把他们的根证书安装到了⽤户证书，这些应⽤并不使⽤他们，所以我们的安装的证书是⽆效的。
解决⽅法及操作⽅法
既然⼜知道了原因，那就总还是有办法去解决的。我们只要把代理软件的根证书安装成系统证书就可以了。
实际上将证书安装到系统区操作还是相对简单的，将证书⽤指定的名称放到指定的位置（/system/etc/security/cacerts/）就可以了
先将我们的根证书名称改为<Certificate_Hash>.<Number>
Certificate_Hash表⽰证书⽂件的hash值，Number是为了防⽌证书⽂件的hash值⼀致⽽增加的后缀（⽤0就⾏了）
下载⾃⼰的根证书，使⽤openssl x509 -subject_hash_old -in <Certificate_File> 计算证书hash ，根据hash将证书重命名为269953fb.0 （269953fb是笔者证书的hash，⼤家的肯定不⼀样）
搞笑说说
然后将269953fb.0⽂件复制到/system/etc/security/cacerts/张敏或将复出
完成后我们就可以看到代理软件的证书出现在系统区了。
这⾥还有⼀点需要单独说明，/system/etc/security/cacerts/⽬录的写权限，需要⼿机root权限。
也就是说复制证书到该⽬录需要您root⾃⼰的设备。
关于Android⼿机的root，通常⼿机⼚家都会有⾃⼰官⽅的教程，建议⼤家按官⽅的操作进⾏root
当前⼩⽶⼿机的root需要⼿机绑定⼩⽶账号7天以上才能解锁，解锁后刷⼊开发版即可完成root
效果
现在证书也被安装到了系统区，再回到Fiddler看下效果
再次打开闲鱼我们已经可以看到完整的https请求了。
下⾯我们个请求修改下请求返回数据
借助Fiddler插件FreeHttp修改这个请求的返回数据将⼆⼿⼿机修改为⼆⼿马总并将图⽚也替换掉
（FreeHttp的使⽤请参考）
再次打开闲鱼，可以看到经过代理的数据已经被篡改了（注意测试时清除咸鱼的缓存及应⽤数据，以保证每次打开APP都会请求firstdata）
发布评论