Android抓包思想总结

---

前言

现在大部分应用都会做防抓包保护，今天我们就反向从如何抓包来看看防抓包的策略都有哪些。
注意在这篇文章中我并不会介绍具体如何操作，我只会讲抓包的方法和思路，像代理抓包工具Charles的使用网上一搜一大片，我就不在这里多说了。所以阅读下文需要了解以下知识点：

• Charles工具的使用
• Https建立加密连接的流程
• SSL Pinning的原理
• 最好懂得一些Android逆向知识（如Xposed的使用）

---

一、简介

Android中的网络请求一般有三种类型：HTTP、HTTPS、Socket。
Http和Https都是基于socket封装的上层框架，一般都是使用他们，但也不排除一些对安全要求比较高的应用使用Socket自己封装网络请求，这种就比较麻烦，关键是抓到了数据也不好分析，我们主要分析一下Http和Https。

二、Http抓包

Http的抓包比较简单，使用Charles或者Friddler就可以抓到。

三、Https抓包

没有防护的Https抓包也很简单，我简单说一下原理：我们把代理工具理解成中间人，客户端向服务端发送数据时，中间人就假装自己是服务端。将自己证书的公钥发送给客户端，然后拿到客户发送的数据后，再假装自己是客户端，把自己的证书公钥发送给服务端。大概可以想象成一个双面间谍。客户端面前冒充服务端，服务端面前冒充客户端。
并且由于https的特性需要在手机上安装中间人的证书，让应用能够信任中间人，并且能够解密传输的数据，之后就可以愉快的抓包了。但是你会发现这样操作之后大部分的应用还是不能抓包，这里分为两种情况，一种是网络请求根本没走代理服务器，这时候虽然应用可以正常使用但代理工具却没有任何数据，还有一种是代理工具可以拦截到网络请求，但是请求直接失败，我们先来分析发送失败可能的原因：

1.Android系统限制

Android系统对于证书是分为，系统预装证书 和 用户安装证书。

其中Android 6.0（API 级别 23） 及更低版本，应用默认信任 系统预装证书和用户安装证书

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

Android 7.0（API 级别 24） 以后则默认仅信任 系统预装证书。

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

如果应用没有配置信任证书类型，可以使用Android 6.0以下的机器进行抓包，如果应用配置了只信任系统预装证书或者只有Android 7.0以上的设备有两个解决办法。

---

其一是修改应用重新打包，具体操作就是使用apktools反编译安装包，修改android:networkSecurityConfig配置之后再重新打包，这样做可能会遇到很多坑，比如很多应用会做应用签名认证，如果启动时检测到不是自己的签名就退出，又或者一些应用加固了，那么反编译也会麻烦很多。

---

其二是将手机root之后把Charles的证书导入到系统证书里面，这样无论怎么配置都不会影响抓包。这里我来简单说一下流程：

1.计算证书名：

• openssl x509 -subject_hash_old -in charles-ssl-proxying-certificate_saved.pem
• 算出数值，比如3a1074b3

2.证书文件改名

• 然后把原Charles证书charles-ssl-proxying-certificate_saved.pem改名为3a1074b3.0

3.放到系统分区

• 放到/system/etc/security/cacerts/

经过上面的配置如果还没有抓到包哪这个应用可能使用了最常见的防抓包方式：服务端或客户端证书校验。

2.证书校验（SSL Pinning）

尽管前面我们已经把中间人的证书放到系统目录绕过Https的证书校验了，但是如果应用内部有自己的对服务端证书校验的逻辑，也就是说客户端收到请求后会去校验服务端的证书，那中间人不就凉了吗，通俗点说就是客户端有服务端的名片，中间人冒充服务端的时候客户端不认他，反之服务端有客户端的名片，中间人冒充客户端的时候服务端也不认他。这就是证书校验。怎么破呢？

客户端校验服务端

首先客户端校验的实现方式就是本地保存一份服务端的证书或者证书的hash用来校验，证书也可以是服务端通过网络发送给客户端。既然是客户端校验，那校验逻辑肯定在客户端，我们可以使用hook工具跳过校验，比如android中常用的网络请求框架okhttp已经提供了证书校验的api，我们可以直接hook这个api跳过验证，这样所有使用okhttp的应用就都能抓到包了，这里就不展开说具体方法了，推荐大家两个通用工具，这两个工具涵盖了Android大部分网络请求框架，使用他们可以跳过绝大多数应用的证书校验。

• xposed解决方案：JustTrustMe
• frida解决方案：DroidSSLUnpinning

除了一些通用的网络框架外，还有一些厂商为了安全会去自己定制框架，比如头条的网络框架就是魔改的okhttp3，并且里面的ssl验证也换成了boringssl（google开源的openssl分支），这样的话我们就只能自己去查看代码找到hook点进行修改，难度就比较大了。

服务端校验客户端

服务端校验客户端的实现方式就是反过来，我们没办法修改服务端的校验逻辑，但是校验证书在客户端呀，我们把客户端的证书拿出来给到中间人，中间人用这个证书就可以冒充客户端和服务端进行通信了，所以服务端校验的难点在于如何找到客户端保存的证书或者证书的hash，一般的方法就是查看安装包中的证书或者dump内存中的证书，如果找不到的话就也只能去看代码了，找到证书之后配置到Charles的SSL Proxying Settings。

3.不走代理的情况

前面我们说过有一种情况是网络请求不走代理，这种一般是在代码中设置的，一种方法是hook代码设置的位置，改为走系统代理；另一种方法比较简单，既然不走代理就在手机上挂一个VPN，通过VPN将设备的流量转发到代理服务器，所以我们首先要在手机上安装一个VPN，这里使用一个十分方便的VPN软件drony，drony会在你的手机上创建一个VPN，将手机上的所有流量都重定向到drony自身（不是流向vpn服务器） ，这样drony就可以管理所有手机上的网络流量，甚至可以对手机上不同APP的流量进行单独配置。具体的使用方法可以参考这篇文章https://www.codeprj.com/blog/ada83a1.html。

四、socket抓包

简单说一下socket抓包，首先Charles和Fiddler都是基于Http协议开发的，所以他们并不能抓到socket的包，只能使用wireshark这样的软件直接抓网卡的流量，其次就算抓到socket的包也没有太大意义，使用socket自己封装协议的应用一定会对传输的数据进行加密，抓到的包也是一堆乱码，所以对于这样的应用我劝你放弃，真想试试就去反编译他的源码在加密之前拦截。

总结

到这里关于抓包的一些方法就讲完了，我也只是把我知道的讲出来，肯定有不完善的地方，而且很多地方也没有深入分析，前面我也说了我这篇文章更多的是提供一个思路，起一个抛砖引玉的效果，真想完整的把抓包分析一遍又岂是几篇文章能讲完的，后面就看自己了。