你的支持对我意义重大！

🔥 Hi，我是小彭。本文已收录到 GitHub · Android-NoteBook 中。这里有 Android 进阶成长路线笔记 & 博客，有志同道合的朋友，欢迎跟着我一起成长。（联系方式在 GitHub）

前言

• 网络请求抓包是研发过程中常见问题，无论是开发时的接口调试，还是测试时的数据检验，都有网络抓包的需求。随着 HTTPS 协议的推广以及手机系统安全性的升级，抓包的门槛可能会逐渐变高；
• 在这篇文章里，我将带你从原理到实战全面认识 HTTPS 抓包，既理解 HTTPS 抓包背后的实现原理，又掌握市面上已有的抓包方案。对于一些方案中存在的坑点我也一一列举并给出解决方法。如果能帮上忙，请务必点赞加关注，这真的对我非常重要。

1. HTTPS 工作原理

要说清楚 HTTPS 抓包的原理，首先需要先说清楚 HTTPS 实现数据安全传输的工作原理，主要分为三要素和三阶段。

三要素分别是：

• 加密： 通过对称加密算法实现
• 认证： 通过数字签名实现（因为私钥只有 “合法的发送方” 持有，其他人伪造的数字签名无法通过验证）
• 报文完整性： 通过数字签名实现（因为数字签名中使用了消息摘要，其他人篡改的消息无法通过验证）

三阶段分别是：

• CA 证书校验： CA 证书校验发生在 TLS 的前两次握手，客户端和服务端通过 Client Hello、Server Hello 等报文获得服务端 CA 证书，客户端验证 CA 证书合法性，从而确认 CA 证书中的公钥合法性（大多数场景不会做双向认证，即服务端不会认证客户端合法性，这里先不考虑）；
• 密钥协商： 密钥协商发生在 TLS 的后两次握手，客户端和服务端分别基于公钥和私钥进行非对称加密通信，协商获得 Master Secret 对称加密私钥（不同算法的协商过程细节略有不同）；
• 数据传输： 数据传输发生在 TLS 握手之后，客户端和服务端基于协商的对称密钥进行对称加密通信。

—— 图片引用自 https 原理模板

2. HTTPS 抓包原理 - 中间人攻击

我们熟悉的 Fiddler、Charles 和 HttpCanary App 等抓包工具，其实都是采用了中间人攻击（Man-in-the-MiddleAttack，MITM）的方案： 将客户端的网络流量代理到 MITM 主机，再通过一系列的面板或工具将网络请求结构化地呈现出来。

如果拦截的是 HTTP 请求还好说，要是拦截的是 HTTPS 请求，首先就遇到第一个问题 —— 加密：

• 加密： 由于 HTTPS 通信中对称密钥 Master Secret 只有通信双方才持有，MITM 无法解密密文，导致在抓包工具上也只能看到一堆无意义的乱码。

要解决这个问题，只能想办法让 MITM 也获得这个对称密钥。此时，MITM 不仅要做流量拦截，还需要伪装成真实的客户端和服务端，与真实的通信双方分别建立独立的连接。我们来看下在中间人攻击下，HTTPS 的三阶段：

连接 1：客户端与中间人的 HTTPS 连接：

• CA 证书校验： 客户端与 MITM 握手，MITM 返回一个 “调包” 的 CA 证书（为了让客户端验证 CA 证书通过，需要提前在系统上安装 MITM 的证书）；
• 密钥协商： 客户端和 MITM 基于 “调包” 的公钥和私钥进行非对称加密通信，协商获得对称密钥；
• 数据传输： 客户端和 MITM 基于协商的对称密钥进行对称加密通信，此时 MITM 就可以解密出明文。

连接 2：中间人与服务端的 HTTPS 连接：

• CA 证书校验： MITM 与 服务端握手，服务端返回 CA 证书，由于服务端证书本来就是合法的，因此 MITM 可以拿到服务端公钥；
• 密钥协商： MITM 和服务端分别基于公钥和私钥进行非对称加密通信，协商获得 Master Secret 对称加密私钥；
• 数据传输： MITM 和服务端基于协商的对称密钥进行对称加密通信。

到这里，MITM 就成功与真实的客户端和服务端建立了独立的连接，发送的密文在 MITM 上就可以成功解密出来了。

既然 HTTPS 可以被抓包，是否说明 HTTPS 不安全的？

这需要区分不同使用场景下安全的口径，在用户不知情的场景 HTTPS 完全可以保证数据安全传输，而对于用户主动授权的场景，用户需要为这个主动的行为承担相应的安全风险。

总结一下实现 HTTPS 抓包的基本步骤：

• 部署 MITM 代理服务器；
• 通过代理等方式将网络流量归集到 MITM 主机；
• 客户端信任 MITM CA 证书；
• MITM 分别与客户端和服务端建立独立连接；
• MITM 解密客户端和服务端的通信，并结构化地呈现出来。

3. 在 Android 上安装 CA 证书

在 Android 上安装 CA 证书，可以总结为三种，其中系统证书和用户证书都可以在系统设置中 信任的凭据 中查看：

• 系统证书： 系统 CA 证书安装在 /system/etc/security/cacerts/ 目录，只允许 Root 权限才能进行添加和删除。需要注意系统 CA 证书有特殊的命名格式：哈希值.0 ，转换方法可以参考：Android 内置证书文件。
• 用户证书： 用户 CA 证书安装在 /data/misc/user/0/cacerts-added/ 目录，由用户自行安装，可以在系统设置 安装证书 中进行安装。由于 Android 7.0 行为变更，对于 targetSdkVersion ≥ 24 的应用，系统不再默认信任用户证书，需要在配置中额外声明：

应用级 AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
       ... >
        ...
    </application>
</manifest>

network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <!-- Trust preinstalled CAs -->
            <certificates src="system" />
            <!-- HERE: Additionaly trus user added CAs -->
            <certificates src="user" />
        </trust-anchors>
    </base-config>
</network-security-config>

• 应用固定证书（Certificate Pinner）： 客户端可以直接内置信任的服务端证书来限制其接受的证书集，用自定义的 TrustManager 代替系统默认的 TrustManager。在 HTTPS 请求的证书校验阶段，只有其接受的证书集合可以校验通过，这也是规避中间人攻击的一种方案。例如：

protected static SSLSocketFactory getSSLSocketFactory(Context context, @ResId int[] certificates) {
    if (context == null) {
        throw new NullPointerException("context == null");
    }
    CertificateFactory certificateFactory;
    try {
        certificateFactory = CertificateFactory.getInstance("X.509");
        // Create a KeyStore containing our trusted CAs
        KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
        keyStore.load(null, null);
        for (int i = 0; i < certificates.length; i++) {
            // 加载内置证书
            InputStream is = context.getResources().openRawResource(certificates[i]);
            keyStore.setCertificateEntry(String.valueOf(i), certificateFactory.generateCertificate(is));
            if (is != null) {
                is.close();
            }
        }
        // Create a TrustManager that trusts the CAs in our keyStore
        TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        trustManagerFactory.init(keyStore);

        // Create an SSLContext that uses our TrustManager
        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(null, trustManagerFactory.getTrustManagers(), new SecureRandom());
        return sslContext.getSocketFactory();
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

// 通过 OkHttp 的 API 设置证书
OkHttpClient.Builder builder = new OkHttpClient.Builder();

int[] certficates = new int[]{R.raw.media};
builder.socketFactory(getSSLSocketFactory(context, certficates));
...

突破 Android 7.0 用户 CA 证书限制

由于 Android 7.0 行为变更，对于 targetSdkVersion ≥ 24 的应用，系统不再默认信任用户证书，需要在应用的 AndroidManifest.xml 中增加 android:networkSecurityConfig 配置。如果你要抓包第三方应用，并且该应用没有配置，就需要采用一些手段来突破限制了：

• 方法 1 - 使用 Android 7.0 以下系统： 从源头抹平用户证书限制，这个最简单直接；
• 方法 2 - 使用平行空间等虚拟系统： 使用 HttpCanary 平行空间或 VMOS App 等虚拟系统，在手机上虚拟出 Android 7.0 以下系统环境；
• 方法 3 - 安装证书到系统证书目录： 需要 Root 权限，把 CA 证书直接安装到系统证书目录下。

4. Fiddler 使用技巧总结

Fiddler 目前主要是用在 Window 系统上的网络调试工具，最新版本的 Fiddler Everywhere 开始支持全平台了，但我体验下来觉得不少功能是缺失的，期待官方更新。下面的介绍是采用新版 Fiddler Everywhere，操作与旧版本上是类似的。

4.1 使用 Fiddler 进行 HTTPS 抓包

这里总结一下使用 Fiddler 进行抓包的主要步骤，其实就是按照 第 2 节 提到的 实现 HTTPS 抓包的基本步骤 的思路进行配置：

• 1、部署 MITM 代理服务器： 在电脑上启动 Fiddler，默认会在这台电脑的 8866 端口部署 Fiddler 的 Web 服务器，可以通过下图设置页面修改端口。因为我们是在手机上抓包，所以还必须勾选 Allow remote computers to connect ：

• 2、通过代理等方式将网络流量归集到 MITM 主机： 在电脑命令行执行 ipconfig 获得本地 IP 地址，然后将手机和电脑连接到同一个局域网下，再修改手机连接 Wifi 的高级设置，设置代理到电脑的 IP 地址和 8866 端口号。至此，你就可以在 Fiddler 上看到抓取的网络请求了，但还看不到 HTTPS 协议传输的数据，界面上会有一个 “加锁” 的图标提示：

• 3、客户端信任 MITM CA 证书： 首先需要在 Fiddler 上开启 Https 抓包功能，才能导出证书，在下图设置页面中，先点击 Trust root certificate，再勾选 Capture HTTPS traffic 选项。

然后，你需要把 CA 证书安装到手机上，有两种方式：先使用 Export root certificate 导出证书文件（默认导出到桌面），再自行将文件发送到手机上；也可以在手机浏览器上访问 ipv4.fiddler:8866/，点击 FiddlerRoot certificate 直接下载证书。

现在你已经成功把 CA 证书下载到手机上了，还需要手动安装证书。在系统设置中搜索 安装证书，找到刚才下载的 CA 证书并安装（不同手机系统界面不同）：

到这里，你已经顺利地在 Fiddler 上抓取到 HTTPS 请求了。最好在筛选栏上过滤干扰项，比如不重要的域名，CONNECT 握手验证请求：

• 过滤域名：contains juejin
• 过滤 Method：is not equals to CONNECT、HEAD
• 过滤 Content-Type：does not contains image/

提示： 事实上，Fiddler 能做的不止是 HTTP 抓包这么简单，它还支持非常多高级功能。如果你需要深入研究 Fiddler，建议你直接购买肖佳写的《HTTP抓包实战》，下面我总结一些我玩过的一些技巧。

4.2 Fiddler 报文重放测试

重放攻击（Replay Attacks）是指攻击者通过抓包的方式，得到一个客户端向服务端发送的真实请求报文，并重复发送给服务端的攻击行为。比如攻击者抓取到一个点赞、投票或领奖的请求报文，并重复发送给服务器。因为这个请求本身就是合法的，而且攻击者并未篡改请求内容，所以服务端会误以为是一个真实的有效请求。

在 Fiddler 上重放请求很简单，有两种方式：右键点击一个请求，选择 Replay→Reissue Requests 直接重放；或者选择 Edit in Composer 先编辑再重放。

我在项目中实际遇到过重放攻击，一个比较聪明的用户抓取到了 App 类似领金币的请求报文，然后用重放攻击薅了一波羊毛。防范重放方法是在请求中增加标识参数和数字签名（防篡改）：

• 时间戳： 服务端将当前请求的时间戳与服务器时间对比，如果超过了阈值（如 60s），则判定为过时请求。缺点是 60s 内的重放请求依然会被判定为有效；
• 流水号： 服务端将当前请求的流水号与服务端记录的流水号对比，如果收到一个非升序（相等或小于）则判定为过时请求。缺点是需要保证报文顺序。
• 一次性口令： 服务端用当前请求的一次性口令在服务端维护的口令表中查找，如果已经使用过该口令则判断为过时请求。缺点是需要维护口令表，实践中可以综合使用时间戳 + 一次性口令的方案，这样既避免了短时间内的重放攻击，服务端也只需要维护一小段时间窗口内的口令表。

4.3 Fiddler 弱网模拟

目前最新版本的 Fiddler Everywhere 还不支持弱网模拟，需要使用旧版本的 Fiddler Classic，配置路径为：Rules→Performances→Simulate Modem Speeds。

4.4 Fiddler 修改 HTTP 请求

Fiddler 本身是一个代理服务器，可以拦截 HTTP 请求 / 响应进行修改后再放行。在 Fiddler 上配置 Rule：

5. Charles 使用技巧总结

5.1 使用 Charles 进行 HTTPS 抓包

这里总结一下使用 Charles 进行抓包的主要步骤，其实就是按照 第 2 节 提到的 实现 HTTPS 抓包的基本步骤 的思路进行配置：

• 1、部署 MITM 代理服务器： 在电脑上启动 Charles，默认会在这台电脑的 8888 端口部署 Charles 的 Web 服务器，可以通过下图设置页面修改端口，这里最好不要使用默认端口号。

• 2、通过代理等方式将网络流量归集到 MITM 主机： 在电脑命令行执行 ipconfig 获得本地 IP 地址（也可以通过 Charles 的 Help→Local Ip Address 查看），然后将手机和电脑连接到同一个局域网下，再修改手机连接 Wifi 的高级设置，设置代理到电脑的 IP 地址和 8888 端口号。
• 3、客户端信任 MITM CA 证书： Charles 抓包也需要在手机上信任 Charles CA 证书。根据指引，会让你在手机浏览器访问 chls.pro/ssl 下载证书，安装证书的方法与 Fiddler 相同（踩坑记录：使用默认端口号 8888 时，访问 chls.pro/ssl 一直不会自动下载，修改端口号就可以了）。

到这里，你已经顺利地在 Charles 上抓取到 HTTPS 请求了。最好在筛选栏中过滤掉干扰项：

5.2 Charles 报文重放测试

在 Charles 上重放请求很简单，有两种方式：右键点击一个请求，选择 Repeat 或 Repeat Advanced 直接重放；或者选择 Compose 先编辑再重放。其中 Repeat Advanced 适合做压力测试。

5.3 Charles 弱网模拟

打开 Proxy→Throttle Settings 进入弱网配置页面，其中 Throttle preset 提供了多种预置的网络环境模拟配置，可以直接在此基础上修改。各个选项的含义如下：

• Bandwidth 带宽： 单位时间内通过通信链路的数据量，即每秒传输的数据量；
• Utilisation 利用率： 带宽利用率；
• Round-trip latency 往返时延： 传输层概念，指报文在客户端和服务端之间一次往返通信的时延；
• MTU 最大传输单元： 数据链路层概念，指数据帧可携带最大的有效载荷，在以太网中一般是 1500 字节。如果一个 IP 包大小超过了 MTU，则会进行 IP 分片；
• Reliability 可靠性 / 丢包率： 指数据传输失败的概率；
• Stability 稳定性 / 抖动率： 指网络环境的稳定性，如果网络不稳定，则数据传输的成功率也会不稳定。这个参数非常适合模拟移动网络；
• Unstable quality range 不稳定质量范围： 指网路环境的不稳定范围。

5.4 Charles 修改 HTTP 请求

Charles 本身是一个代理服务器，可以拦截 HTTP 请求 / 响应进行修改后再放行。在 Charles 上配置 Rewrite：

6. 手机本地抓包方案

前面提到的 Fiddler、Charles 或者 Wireshark 等抓包方案的整个配置过程是比较繁琐的，比如需要配置手机代理、安装证书等。最大的缺点是都依赖于一台部署代理服务器的电脑，不能满足随时随地抓包的需求。实践中可以采用综合的抓包方案：在手机上使用本地抓包方案，无法满足需求时再使用 Fiddler 等方案补齐。

6.1 VPNService API

VPNService 是 Android 4.0 引入的 API，能够对系统流量进行截取且不需要 root 权限。我们熟悉的科学上网 Ap，其实就是运行了一个 VPNService 服务。在 VPN 运行时，通常在通知栏上会有相关的提示，比如 “已激活 VPN” 等。在系统设置中搜索 VPN，可以查看当前手机中提供 VPN 服务的应用，例如：

• HttpCanary App

HttpCanary 是一款强大的针对安卓手机的网络分析工具，它的工作原理是基于 VPNService 部署了一个 MITM 代理服务器来抓取网络数据包。另外，HttpCanary 还支持破解双向认证抓包，具体操作参考：Android 平台 HTTPS 抓包全方案

不过，HttpCanary 在 Android 11 系统上抓取 HTTPS 请求会有问题，由于系统只允许从系统设置中手动选择安装证书，而目前 App 还没有适配这个问题，导致安装证书这一步就凉了。我提供两个解决方法：

• 1、使用低版本的手机（极其舒适）；
• 2、使用有 Root 权限的手机，手动把从 HttpCanary 内部存储空间中把证书捞出来，再转化为系统证书并安装。这个方案顺便还解决了第三方应用未配置 android:networkSecurityConfig 的问题。具体操作参考：安卓 11 httpcanary 小黄鸟系统证书的安装

• 有赞移动助手 App

有赞技术团队是我经常关注的团队之一，有赞移动助手 App 本地抓包方案 是他们 19 年分享的一个手机本地抓包方案。有赞助手 App 的原理也是基于 Android VPNService 或 IOS NetworkExtension 搭建的代理服务器，由助手 App 与真实服务器完成 HTTP 请求，相当于是自实现的 HttpCanary。目前以小彭的积累还不能完全消化实现这个方案，就记录在这里提供个思路吧。

6.2 OkHttp 拦截器

对于基于 OkHttp 实现网络请求的应用，可以通过拦截器监控应用内的网络数据，再通过通知栏、桌面小部件等入口查看抓取的数据。目前业内已经有开源的实现可直接使用：

• Chunk： 集成 Chunk 后，通知栏消息会显示监控到的网络请求，点击后可以进入分析页面。不过这个项目已经多年没有维护了，而且也不支持数据筛选，有些鸡肋。

• 滴滴 DoraemonKit

滴滴的 哆啦A梦 大家都比较熟悉了，是一款面向大前端产品的效率平台，目前已经发展成一个相对完整的生态，支持 Android 和 iOS 等多个平台。DoraemonKit 也提供了网络监听的能力，其原理同样是基于 OkHttp 拦截器。区别在于 DoraemonKit 是通过 AOP 注入的方式添加拦截器，所以初始化时不需要我们手动添加拦截器，这也很好地解决不同组件存在多个 OkHttpClient 的问题。相关源码：

HttpUrlConnectionProxyUtil

private static void addInterceptor(OkHttpClient.Builder builder) {
    // 判断当前是否已经添加了拦截器，如果已添加则返回
    for (Interceptor interceptor : builder.interceptors()) {
        if (interceptor instanceof DokitMockInterceptor) {
            return;
        }
    }

    builder
        //添加mock拦截器
        .addInterceptor(new DokitMockInterceptor())
        //添加大图检测拦截器
        .addInterceptor(new DokitLargePicInterceptor())
        //添加dokit拦截器
        .addInterceptor(new DokitCapInterceptor())
        //添加弱网 拦截器
        .addNetworkInterceptor(new DokitWeakNetworkInterceptor())
        // 添加扩展拦截器
        .addInterceptor(new DokitExtInterceptor());
}

• 优酷 Ribut

Ribut 是小彭交流群中的同学分享的，看了下目前这个项目还处于比较初期的阶段，期待后续的发展。它是阿里巴巴优酷技术团队研发的可视化调试架构，目标是通过工具化手段解决研发日常痛点问题，如网络抓包。其中网络抓包的大概思路分为两步：1、通过扫码建立与 PC 端连接；2、通过 OkHttp 拦截器抓取网络请求数据并转发到 PC 端。虽然严格来说还是依赖 PC 端，但是整体的体验是 OK 的。

7. 总结

说了这么多抓包的方案，让我们换个视角，App 反抓包有哪些方案，你知道吗？关注我，带你了解更多，我们下次见。

参考资料

• 《HTTP 抓包实战》—— 肖佳 著
• 网络安全配置 —— Android 官方文档
• Capturing and Inspecting Android Traffic —— Fiddler 官方文档
• Install System CA Certificate on Android Emulator —— mitmproxy 文档
• Android 平台 HTTPS 抓包全方案 —— MegatronKing 著
• Https 在 Android 中的使用添加可信证书认证 —— JoeLitterStar 著
• 有赞移动助手 App 本地抓包方案 —— 杨彬（有赞）著

你的点赞对我意义重大！希望大家可以一起讨论技术，找到志同道合的朋友，我们下次见！