抓包对每一个开发者来说，应该说是最基本的技能之一，最近因公司需求接触了一些抓包相关，也遇到了一些奇怪的问题，于是做一个简单的记录,希望对大家有所帮助哈。
移动端常用抓包工具
工欲善其事，必先利其器 ,要抓包，怎么可能没有好的工具，对于普通抓包来说，我们有下面几个工具
Fiddler
在 windows 环境非常好，提供了一系列抓包方式及后续的脚本，划重点，脚本，这也是众多人喜欢的原因。
注意：在mac支持很差，新版软件缺少核心功能脚本，体验很差。
Charles
体验nice,在Mac，windows体验均可以，支持定时存储，不支持相关脚本。(这也是为什么不如fiddler火的原因，在mac体验很好)
AnyProxy
阿里的抓包工具，在网页上使用，使用简单，支持js脚本。批量抓包可以考虑使用。
总结
以下经验皆为个人使用体验。
如果是 windows用户，只是想随便抓抓练手，fiddler 不佳之选，mac用户 选择 Charles。
如果想抓完之后顺便分析分析数据，写入数据库，那么 AnyProxy 和 fiddler 可以满足需求，mac用户直接考虑 AnyProxy即可，不要问为什么，问就是 fiddler 在mac就是一坨稀饭。
相关的使用教程，一抓一大把，我这里就不叙述了。
温馨提示：记得安装证书，记得Android7.0以下(以上使用xp框架，或者别的方式)
常用抓包工具原理
好像有点跑题了，接下来回到正轨，上面这些抓包软件原理是什么呢？
中间人攻击
什么是中间人攻击？
一图胜千言(小灰的图)
简而言之，小红和小绿两人要通信，结果被中间人小黑偷听并分别转发了。
不是有https吗？
很多人认为，用https不就行了吗，我有证书做校验啊，但普通的https依然相当于裸奔，类似的 上面的工具通过代理加伪造根证书依然可以抓取https，具体原理看下面分析。
原理分析
我们以 charles举例。charles相当于一个中间人代理。当客户端与服务器通信时， charles 接收服务器的证书，然后动态生成一张证书发送给客户端，然后 charles 作为中间代理在客户端 和 服务器 之间通信，所以相关通信的数据 可以被 Charles 拦截。
如下图描述：
具体步骤如下：
- 客户端 向服务器 发起 HTTPS 请求
- Charles 拦截客户端请求，伪装成客户端向服务器进行请求
- 服务器 向 客户端 返回服务器的 CA证书。 (实际上已经被 Charles 拦截)
- Charles 拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，替代服务器的证书后发给 客户端。
- 客户端 接收到 服务器(实际上是Charles的证书) 的证书后，生成一个对称秘钥，并用 Charles 发送回来的证书公钥加密，发送给 服务器(实际发送给了 Charles)
- Charles 拦截客户端的响应，用自己的私钥解密对称秘钥 (这里已经拿到了对称秘钥)，然后用服务器证书公钥加密，发送给服务器。
- 服务器用自己的私钥解密对称秘钥，向客户端(实际是 Charles)发送 响应
- Charles 拦截服务器响应，替换成自己的证书会后发送给客户端。
- 至此，链接建立， Charles 拿到了 服务器证书的公钥 和 客户端和服务器协商的对称秘钥，之后就可以解密或者修改加密的报文了。
这也就是为什么抓https 需要安装相应的证书，因为我们得让客户端认为证书有效，即我们的证书也是根证书，不过Android7.0以后，用户手动安装的证书都不会被信任，所以一般我们借助xp框架或者别的方式
如何防范中间人攻击？
判断是否设置代理
网络请求时，判断客户端当前是否设置代理，如果设置代理，就禁止其访问。
客户端本地证书效验
客户端本地做证书校验,并且设置不仅仅校验公钥,设置完整的正式校验模式。这样的话,证书会校验请求的时候不仅仅校验域名,会将证书中的公钥及其他信息也进行校验,这样的话,中间人伪造的证书就无法通过验证,无法进行抓包。
Https请求和相应的数据进行加密
对证书加密的数据再次进行加密，这样即使对方已经将证书替换，那么看到的数据仍旧是一堆乱码后的数据。
最后，以上皆为本人真实理解和实际感受，抓包有风险，大家练练手即可，切勿黑灰产业哈
参考博客
- Charles抓取https数据的原理，如何防止中间人攻击
