Android平台HTTPS抓包解决方案及问题分析-CSDN博客

本文链接：https://blog.csdn.net/2401_85384470/article/details/140182131

导出.0格式的证书后，可以使用MT管理器将.0文件复制到/etc/security/cacerts/目录下，或者通过adb remount然后push也可（这里稍微提一下，别在sdcard里找这个目录）。

4. Firefox证书安装

火狐浏览器Firefox自行搞了一套CA证书管理，无论是系统CA证书还是用户CA证书，Firefox通通都不认可。这种情况，我们需要将CA证书通过特殊方式导入到Firefox中，否则Firefox浏览网页就无法工作了。

HttpCanary v2.8.0版本提供了Firefox证书导入选项。在设置 -> SSL证书设置 -> 添加HttpCanary根证书至Firefox 中：

点击右上角复制按钮将url复制到粘贴板，然后保持此页面不动，打开Firefox粘贴输入复制的url。

出现下载证书弹框后，一定要手动勾上：信任用来标志网站和信任用来标志电子邮件用户。然后确定即可。

5. 公钥证书固定

证书固定（Certificate Pinning）是指Client端内置Server端真正的公钥证书。在HTTPS请求时，Server端发给客户端的公钥证书必须与Client端内置的公钥证书一致，请求才会成功。

在这种情况下，由于MITM Server创建的公钥证书和Client端内置的公钥证书不一致，MITM Server就无法伪装成真正的Server了。这时，抓包就表现为App网络错误。已知的知名应用，比如饿了么，就采用了证书固定。
另外，有些服务器采用的自签证书（证书不是由真正CA发行商签发的），这种情况App请求时必须使用证书固定。
证书固定的一般做法是，将公钥证书（.crt或者.cer等格式）内置到App中，然后创建TrustManager时将公钥证书加进去。很多应用还会将内置的公钥证书伪装起来或者加密，防止逆向提取，比如饿了么就伪装成了png，当然对公钥证书伪装或者加密没什么太大必要，纯粹自欺欺人罢了。
证书固定对抓包是个非常麻烦的阻碍，不过我们总是有办法绕过的，就是麻烦了点。

5.1 JustTrustMe破解证书固定

Xposed和Magisk都有相应的模块，用来破解证书固定，实现正常抓包。

例如：github.com/Fuzion24/Ju…

破解的原理大致是，Hook创建SSLContext等涉及TrustManager相关的方法，将固定的证书移除。

5.2 基于VirtualApp的Hook机制破解证书固定

Xposed和Magisk需要刷机等特殊处理，但是如果不想刷机折腾，我们还可以在VirtualApp中加入Hook代码，然后利用VirtualApp打开目标应用进行抓包。当然，有开发者已经实现了相关的功能。详见：

不过，这里CertUnpinning插件的代码有点问题，要改改。

5.3 导入真正的公钥证书和私钥

如果Client固定了公钥证书，那么MITM Server必须持有真正的公钥证书和匹配的私钥。如果开发者具有真正服务端的公钥证书和私钥，（比如百度的公钥证书和私钥百度的后端开发肯定有），如果真有的话，可以将其导入HttpCanary中，也可以完成正常抓包。

在设置 -> SSL证书设置 -> 管理SSL导入证书中，切换到服务端，然后导入公钥证书+私钥，支持.p12和.bks格式文件。

6. 双向认证

SSL/TLS协议提供了双向认证的功能，即除了Client需要校验Server的真实性，Server也需要校验Client的真实性。这种情况，一般比较少，但是还是有部分应用是开启了双向认证的。比如匿名社交应用Soul部分接口就使用了双向认证。使用了双向认证的HTTPS请求，同样无法直接抓包。

关于双向认证的原理。

首先，双向认证需要Server支持，Client必须内置一套公钥证书 + 私钥。在SSL/TLS握手过程中，Server端会向Client端请求证书，Client端必须将内置的公钥证书发给Server，Server验证公钥证书的真实性。

注意，这里的内置的公钥证书有区别于前面第5点的公钥证书固定，双向认证内置的公钥证书+私钥是额外的一套，不同于证书固定内置的公钥证书。

如果一个Client既使用证书固定，又使用双向认证，那么Client端应该内置一套公钥证书 + 一套公钥证书和私钥。第一套与Server端的公钥证书相同，用于Client端系统校验与Server发来的证书是否相同，即证书固定；第二套SSL/TLS握手时公钥证书发给Server端，Server端进行签名校验，即双向认证。

用于双向认证的公钥证书和私钥代表了Client端身份，所以其是隐秘的，一般都是用.p12或者.bks文件+密钥进行存放。由于是内置在Client中，存储的密钥一般也是写死在Client代码中，有些App为了防反编译会将密钥写到so库中，比如S匿名社交App，但是只要存在于Client端中都是有办法提取出来的。

6.1 双向认证抓包

这里以S匿名社交App为例，讲解下如何抓取使用了双向认证的App的HTTPS包。

如果服务器使用了Nginx且开启了双向认证，抓包时会出现400 Bad Request的错误，如下：

有些服务器可能不会返回404，直接请求失败。

接下来看，如何使用HttpCanary配置双向认证抓包。

首先，解压APK，提取出.p12或者.bks文件，二进制的文件一般存放都在raw或者assets目录。

将client.p12文件导入手机，然后在HttpCanary的设置 -> SSL证书设置 -> 管理SSL导入证书中，切换到客户端（因为需要配给MITM Client），然后导入.p12文件。
由于双向认证的公钥证书和私钥是受密钥保护的，所以需要输入密码：

一般通过逆向可以从APK中提取出密钥，具体操作这里略过。输入密钥后，需要输入映射域名，这里使用通配符*映射所有相关域名：
导入完成后如下：

可以点进证书详情查看细节，这个client.p12文件包含公钥证书和私钥，是用于双向认证的。

配置完成后，重新进行抓包，看看效果。

可以看到，之前400 Bad Request的两个要求双向认证的请求成功了！

7. SSL重协商

有些服务器可能会开启SSL重协商，即SSL/TLS握手成功后发送请求时服务器会要求重新握手。这种情况一般比较少，但是也不排除，已知的应用比如 10000社区就使用了SSL重协商。

由于Android系统对SSL重协商是有限支持，所以部分系统版本抓包会失败，表现为网络异常。在Android 8.1以下，SslSocket是完全支持SSL重协商的，但是SSLEngine却是不支持SSL重协商的，而HttpCanary解析SSL/TLS使用的是SSLEngine。在Android 8.1及以上，SSLEngine和SslSocket统一了实现，故是支持SSL重协商的。

所以，如果确认服务器使用了SSL重协商，请使用8.1及以上版本系统进行抓包。

8. 非HTTP协议抓包

如果确认了以上几点，HttpCanary仍然抓包失败，那么极有可能使用的并非是HTTP协议。比如像微信聊天，视频直播等，使用的就不是HTTP协议，这种情况需要使用其它的抓包工具，比如Packet Capture这种直接解析TCP/UDP协议的，但是往往非HTTP协议的数据包即使抓到了也无法解析出来，因为大概率都是二进制而非文本格式的。

##9. 结语
抓包是个技术活儿，需要对网络协议有大致的了解，对抓包感兴趣的同学可以多查阅TCP、UDP、SSL/TLS、HTTP等相关资料。

HttpCanary是专业的HTTP协议抓包工具，专注HTTP协议三十年（吹过头了），不过目前还不支持QUIC/HTTP3这种新协议，等QUIC/HTTP3正式应用起来再说吧。

原文转自：[MegatronKing](https://juejin.im/post/5cc313755188252d6f11b463
)

《设计思想解读开源框架》

第一章、热修复设计

第一节、 AOT/JIT & dexopt 与 dex2oat
第二节、热修复设计之 CLASS_ISPREVERIFIED 问题
第三节、热修复设计之热修复原理
第四节、Tinker 的集成与使用（自动补丁包生成）

第二章、插件化框架设计
第一节、 Class 文件与 Dex 文件的结构解读
第二节、 Android 资源加载机制详解
第三节、四大组件调用原理
第四节、 so 文件加载机制
第五节、 Android 系统服务实现原理

第三章、组件化框架设计
第一节、阿里巴巴开源路由框——ARouter 原理分析
第二节、APT 编译时期自动生成代码&动态类加载
第三节、 Java SPI 机制
第四节、 AOP&IOC
第五节、手写组件化架构

第四章、图片加载框架
第一节、图片加载框架选型
第二节、Glide 原理分析
第三节、手写图片加载框架实战

第五章、网络访问框架设计
第一节、网络通信必备基础
第二节、OkHttp 源码解读
第三节、Retrofit 源码解析

第六章、 RXJava 响应式编程框架设计
第一节、链式调用
第二节、扩展的观察者模式
第三节、事件变换设计
第四节、Scheduler 线程控制

第七章、 IOC 架构设计
第一节、依赖注入与控制反转
第二节、ButterKnife 原理上篇、中篇、下篇
第三节、Dagger 架构设计核心解密

第八章、 Android 架构组件 Jetpack
第一节、 LiveData 原理
第二节、 Navigation 如何解决 tabLayout 问题
第三节、 ViewModel 如何感知 View 生命周期及内核原理
第四节、 Room 架构方式方法
第五节、 dataBinding 为什么能够支持 MVVM
第六节、 WorkManager 内核揭秘
第七节、 Lifecycles 生命周期

本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…

taBinding 为什么能够支持 MVVM**

第六节、 WorkManager 内核揭秘
第七节、 Lifecycles 生命周期

[外链图片转存中…(img-zsFaJQre-1720080413515)]
本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…
[外链图片转存中…(img-5pT7oJv1-1720080413516)]