前言

首选抓包工具是非常多的，抓包的手段也是非常多，在本文中主要是结合实际的使用场景和工作需要，选择较为常见的抓包方式和工具。同时，现在开发者的安全意识也是在逐步加强，对流量的保护上也是在下苦功夫，因此针对不同的保护选择不同的绕过方式。本文大致分为以下两个部分：
1、抓包工具的使用和环境的搭建
2、常见的绕过解决疑难杂症

抓包工具使用和环境搭建

参考：
1、https://xz.aliyun.com/t/6551
就上面的参考文章中已经提到很多工具抓包，我这里就直接重复讲解，直接进入正题，我在抓包过程中经常使用的工具。

burpsuite

环境搭建

这个抓包工具相信都知道，可想而知其功能的强大，并且该工具的社区也是非常活跃，WEB必备工具之一，更新频繁。
首选我们来介绍环境的搭建
我喜欢使用Linux系统来搭建我的分析环境，当然其他环境下搭建是没有任何问题的。
下载地址：
https://down.52pojie.cn/Tools/Network_Analyzer/
至于版本可以根据自己的喜好来选择，尽可能的选择比较新的版本
当然该项目是基于Java开发，那我们肯定需要使用到Java环境，首选对于我们开发人员来讲，可以直接使用JDK就可，笔者使用的JDK11版本

注：比较新的BP是需要JDK8以上，不太支持JDK8
使用比较新的JDK版本还是有很多好处的，比如可以兼容JEB pro工具
如下图是笔者使用版本
简单的修改一下启动脚本就可以直接运行起来，非常方便

具体的注册方式在这里就不过多的讲解。接下来启动工具开始准备抓包环境

代理抓包

1、首选在Options中选择配置我们的代理
2、设置端口
3、配置代理服务的IP
其中重要的是配置我们代理服务器的IP
如果我们是本地抓包，那我们可以直接配置本地地址就可以，浏览器代理上这个IP便可以实现抓包。
如果是借助路由器抓包，也就是手机或者其他设备抓包，只要处于同一局域网中，我们配置的IP就应该是本机的IP地址，然后被抓包的设备代理上就可以实现抓包。
大致的结构图如下：

但是目前可能我们只讨论可以使用WIFI来进行上网服务的应用和设备，如果应用的流量是通过4G、网线上网那我们使用BP就不是这样来进行抓包，BP抓包的数据流量是位于应用层，如果是使用4G上网或者网线可能就需要借助接下来会介绍的TCPdump、wireshark等工具对网卡进行抓包分析。

随着HTTP进入到HTTPS时代，上面这样简单的配置是没有办法实现抓包的。
我们用一张图片来解释HTTP->HTTPS的差异

HTTPS的实现就是在传输过程中添加了一个SSL/TLS环节，使得我们的传输的流量是处于加密状态。
那是如何加密的呢？当然这里不是我们深入研究的主题
实际上就是使用RSA、DES等加密方式，在网络建立之前会使用秘钥协商来商定对称加密的秘钥，通常秘钥协商是会使用RSA算法，或者其他非对称的加密算法来实现（比如蓝牙中的秘钥协商就不完全采用RSA），协商完成后我们就可以使用对称加密来进行加密我们的流量。（具体的原理这里就不展开分析，后面开文章进行单独讲解）

既然如此就引入了CA证书的概念
证书的作用验证我们客户端和服务端，但是在很多开发者这里就不会很好的使用这样的机制，因此出现安全问题。相关的演变或者难易变化在第二节中讲解。

证书安装

我们可以在配置好代理后直接访问http://burp.cn就可以直接下载证书，并选择安装，这样安装的证书是用户证书，如果没有系统证书校验的情况下是可以实现多https流量抓包的。
当然我们也可以直接导出证书文件，将证书放置在系统证书的目录下来实现抓包。


导出der文件，并不能直接用于Android系统安装，如果想要安装用户证书，可以导出.cer后缀安装，如果想安装系统证书，我们还需要对证书进行处理。
我们可以去看一下我们的系统证书的格式是什么
下图使用的是 nexus6p Android 8.1.0

如果想要转换成上面的形式，需要使用到openssl工具来进行转换，具体操作如下：
如果我们导出为der文件，先将der转换成pem文件
openssl x509 -inform DER -in burpder1545.der -out burpder1545.pem
然后我们再计算我们的hash值
openssl x509 -inform PEM -subject_hash_old -in xx.pem
然后可以直接改后缀，也可以使用cat xx.pem > hash.0生成我们的证书文件
注：这里的后缀是不一定为.0,如果出现hash值是一样的我们可以修改成.1、.2之类的。
如果为其他类型的文件我们可以使用下面的命令转换
openssl x509 -inform DER -subject_hash_old -in xxx.cer
证书生成后我们需要放到系统证书目录下，
如果是Android系统上，我们放置的位置是在system/etc/security/cacerts目录下
通常我们系统没有root权限的情况下是没办法操作的。
Android手机root情况下：
1、可以尝试重新挂载系统分区
mount -o remount,rw /
然后再复制我们的证书就可以成功。但是也是有失败的情况。这个时候建议推荐使用第二种思路
2、使用magisk插件
root的手机上，我们是可以任意折腾的，站在系统的高度下看APP可谓是降维打击。
https://www.freebuf.com/articles/terminal/158492.html
https://github.com/Magisk-Modules-Repo/movecert
当然使用未root的手机上也是可以实现，只是复杂一点
非手机设备上（比如车机、其他搭载Android系统的设备）
在这样的情况下我们想要移动证书就显得局促。
同样的使用Android手机端的第一种办法也是可以达到目的，前提是有root权限
如果不能重新挂载Android系统的根目录，可能想要绕过校验系统证书抓包的方式就不太可能。但是想要抓取流量也是可以实现的，比如使用frida hook + tcpdump来实现https流量抓取。
回归正题，在这里我们还是假设我们系统证书也是可以实现的，继续展开研究。
既然证书已经安装完成，那我们如何抓取的https流量，充当中间人攻击的呢？
我们还是用一张图片来解释这一个原理：

如果开发者没有足够的安全意识，我们在这里是可以抓取到https流量的。在后面的章节中会讲解详细讲解如何防护又如何破除防护。
开始抓包
抓包之前我们是需要设置设备上的代理情况的，需要将我们待抓包的设备连接上我们的代理服务器中。
通常情况下我们有两种凡是来设置我们的代理：
1、更改wifi的代理设置


修改网络中的高级设置，设置我们的代理。
填入我们的代理IP和port就可以实现代理抓包。
2、设置全局代理
第二个方法设置全局代理，需要使用到如下的命令
adb shell settings put global http_proxy 192.168.xx.xxx:8888
这样设置全局代理效果和上面的手动设置是一样的效果。

Fiddler

Finder抓包原理上和burpsuite是相识的，具体的操作也是相似，可能差异就在使用上面。我们还是简单的把环境搭建代理抓包证书安全讲一下。
在官网上我们可以看到fiddler支持多个系统，我们windows下为例进行安装。
基本上就是next下去就行
我们就直接安装证书，在点击Tools->option->https

就会给我们提示请求安装证书。
设置连接

这里主要是配置我们的端口
可以在我们的电脑中看到代理配置

fiddler已经将我们本地的代理给设置好了，现在本地的流量就是可以直接抓取。
比如我们访问的流量

那我们如何去配置抓取移动设备的https流量呢？当然是需要配置证书。
首选我们是需要让我们的设备连接上我们代理，设置代理的方法和上一个抓包工具是一样的。设置完成代理，我们可以在待抓包设备上访问http://ip:port的方式去下载我们的fiddler证书，进行安装即可。当然这里想要安装系统证书也是一样的方法。
配置代理可以参考上一个工具的配置方法。

TCPdump+wireshark

如果在上面的方法都不好使的情况下，我们可以采用TCPdump工具来进行流量分析，但是这种分析方法可能并没有上面的工具那么直接，需要借助wireshark工具来进行查看和分析。
通常情况下，使用tcpdump抓https流量是出于加密状态的，我们也没办法像BP一样设置中间人代理，但也不是不能分析，只是相对来讲复杂一点。
想要抓取https流量并且分析，这里推荐一种方法：
https://www.52pojie.cn/thread-1405917-1-1.html

常见的绕过解决疑难杂症

在这一小节中主要就是从防护的难度从低到高进行讲解，攻防兼备。

1、忽略证书校验

这中情况通常是出现在测试版本中，为了方便开发者自己测试，发布版本中也不一定不存在这样的情况。忽略证书校验到底是什么意思呢？我们还是用图片的形式来进行说明。

那这样的情况下，https流量和http流量是一样的效果，实际上达到的效果是信任所有的证书。我们以okhttp为例：
在okhttp中，默认是使用系统证书进行校验的。如果我们重写checkClientTrusted、checkServerTrusted、verify等方法，使其处理逻辑为空，便能够达到忽略证书校验的目的。

对抗方法

证书都忽略了，那我们想要抓包不是直接代理上就可以抓包嘛。不存在什么对抗之法。

2、系统证书校验

系统证书校验就是使用系统证书信任链中的证书来进行校验。在开始分析之前，还是区分一下用户证书和系统证书信任链。
在Android7之前，应用的请求是可以信任我们的用户证书的，那如果我们是在抓取Android6.0之前的应用，我们可以直接将证书放置在用户证书信任链下，如果是要抓取Android7.0之后的，就需要将证书放在系统证书目录下。相关的移动方法在上面有介绍。
如何实现呢？
实际上就是默认就会信任系统证书链，以okhttp为例，只要我们没有重写上面的方法，那就已经实现了。
如何验证有系统证书校验呢？
如果我们安装了客户证书抓包，出现下面这样的情况：

我们的TLS客户端无法链接，这样就可以确定是在校验系统证书。

对抗方法

1、一种简单的对抗方法当然是将抓包工具的证书移动到系统证书目录下便可以绕过这种校验。这样的方式需要前置条件，手机是root环境下。
2、既然我们在Android7.0以下是信任了我们的用户证书，如果我们可以重打包我们的应用，将应用的目标版本强制修改为6.0或者更加低，我们就可以实现信任用户证书来抓包。
具体修改方法：
比如我们的platformBuildVersionCode指定为23，版本为Android 6.0.0，然后重新打包安装。
当然对抗的方法显然第一种比较容易实现，思路多点也是可以应对不同环境。

3、SSL pinning 单边校验

单边校验的意思就是只校验了一端，通常情况下都是客户端去校验服务端。实际上第二种方法就是单边校验。只是我们校验的是系统证书。
那为啥又要引入SSL pinning技术呢？实际上就是为了解决被中间人攻击。
SSL pinning技术又分为两种：锁定证书和锁定公钥。
如果对该技术不太熟悉的可以参考下面两篇文章：
1、https://www.mdpi.com/1099-4300/21/12/1136/htm#B13-entropy-21-01136
2、https://juejin.cn/post/6844903809068564493

看上面的这张图片我们也可以大致的理解单边校验的概念。
如果没有加SSL pinning技术，那我们依旧可以中间人。相关的图例在第二篇的参考链接中有，同样在第一小节中也有图例，这里就不再重复。
那我们来理解一下SSL pinning技术是怎样避免中间人攻击的。
证书锁定
既然是要锁定证书，那么我们客户端上应该事先存在一个证书，我们才能锁定这个证书来验证我们真正的服务端，而不是代理工具伪造的服务端。
如果是锁定证书，那通常情况下会将证书放置在app/asset目录下
具体操作：将APP代码内置仅接受指定域名的证书，而不接受操作系统或者浏览器内置的CA根证书对应的任何证书。通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此移动端APP与服务端（例如API网关）之间的通信可以保证绝对的安全。
公钥锁定
具体做法：公钥锁定是提前证书中的公钥并内置到移动端APP内，通过与服务器对比公钥值来验证连接的合法性。
如果是这样的话，我们想要抓包，那么就的突破锁定。

对抗方法

对于这种SSL pinning的单边校验，想突破，那我们就需要让这个SSL pinning形同虚设，这样我们就可以抓包。如何实现呢？
1、使用xposed工具JustTrustMe
2、使用frida 比如：https://github.com/BigFaceCat2017/frida_ssl_logger
3、反编译修改逻辑
为了不重复造轮子，这里直接推荐一篇文章
https://xz.aliyun.com/t/8047

4、SSL pinning 双边校验

顾名思义，双边校验就是客户端校验服务端，服务端校验客户端。已经被逼迫到这个地步。我们还是用一张图来看一下双边校验。

（引用于：https://juejin.cn/post/6844903809068564493）
既然如此，看完上面这张图，可以明白双边校验是在单边校验的基础上进行的，那我们想要突破双边校验就需要先把单边校验给绕过，绕过后我们才能来继续绕过服务端校验客户端的环节。
如果我们能够找到客户端的证书，然后导入到我们的抓包工具伪造的客户端中，是不是就可以绕过我们的校验呢？确实是这样。因为这个校验的代码并不在我们的手上，我们也没办法修改。只能欺骗服务端。

对抗方法

找到证书，导入抓包工具，使用上一种方法绕过单边校验。
具体的实现方法：
发现网上有很多优秀的师傅提供的实战的案例，参考如下：
1、https://xz.aliyun.com/t/8047#toc-7
2、https://blog.csdn.net/qq_38316655/article/details/104176882
3、https://xz.aliyun.com/t/6551
上面三篇文章基本上用的都是同一个案例
4、https://bbs.pediy.com/thread-265404.htm
当然还会遇到一种情况就是本地APK中并没有发现证书的情况，处理方法大致有两个途径。
1、使用r0ysue写的通杀脚本（https://github.com/r0ysue/r0capture)
2、自己逆相关逻辑，寻找到私钥文件

5、代理检测

目前的对抗已经进入双向认证的环节了，但是依然可以绕过，那接下来我们还能怎样进行下去呢？对抗永不停止。可以看出，上面几乎所有的对抗办法都是基于代理来完成的，如果没有代理的情况下，那我们中间人攻击就相对来讲更加难以实现，如果我们在对绕过的工具进行专门的对抗，相对情况也是会增加难度的，（https://www.mdpi.com/1099-4300/21/12/1136/htm#B13-entropy-21-01136）在这里面也提到一些处理方法，比如：代码混淆、加固、反重打包之类的实现方法。
如何实现代理检测呢？又如何绕过代理检测呢？这是一场持续的对抗。
比如在okhttp中可以设置无代理模式，不走系统代理

比如检测我们是否使用了http.proxyHost之类的函数

实现的方式多种多样，没有比较固定的方式。

对抗方法

1、hook相关函数
2、反编译修改代码逻辑
3、可以使用iptables对请求进行强制转发，ProxyDroid全局代理工具就是通过iptables实现的，所以使用ProxyDroid开启代理，可以比较有效的绕过代理检测。

后记

1、首选感谢前辈们的分析，使得更加容易理解
2、尽管提到了这么多校验，但是我相信对抗永不止步，肯定还含有很多针对独特环境的。
3、本人能力确实有限，所能想到的策略也很局限，希望各位大佬们不吝赐教，一起补充。

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界