0.前言

最近看论坛里关于抓包的问题聊的火热，小弟我也借此机会献丑来分享一下我的抓包的研究成果。

毫无疑问，app逆向的第一步是抓包。通过抓包可以获取很多有用的线索，比如url，参数名等。再根据url，参数名等，可以逐步抽丝剥茧找到app收发数据的地方，然后就能找到最关键的签名所在的位置。研究清楚签名，接下来就可以做一些不可告人之事了~

安卓app常用的网络框架是okhttp，对于okhttp的抓包研究已经非常成熟了，无非是certificate pin或者hostname verify那一套。但是最近几年，出现了一些基于Google Cronet通讯框架的app，比如某音，某小破站等等。Cronet是从Chrome中抽出的给移动端使用的网络组件，目前针对Cronet抓包，证书校验的研究比较少，大多是奇技淫巧，没能从根本上挖掘。本文从Chrome源码出发，结合实例某音，研究一下使用Cronet安卓程序的正确抓包姿势。

1.从报错入手

打开手机代理，将https证书塞入手机的根目录，启动目标应用，结果：

请求全部失败，app界面也显示无网络，无所谓，我们打开日志先看看：

看到了：ERR_CERT_AUTHORITY_INVALID

很明显是检测到了证书 无效。

经常使用Chrome浏览器的朋友应该对这种ERR_开头的错误有印象：

没错，这正是Chrome的报错通用的格式。

那么我们就可以从报错入手，去Chrome源码里看看这个错误的来源，以此为根据寻求bypass的方式。

2.撸源码

打开Chrome Code Search（在线的Chrome源码浏览网页，提供了强大的交叉引用和全文搜索功能）

全局搜索ERR_CERT_AUTHORITY_INVALID

出现了很多结果，观察后发现 net/cert/cert_status_flags.cc这个文件比较可疑，点进去看看：

发现 一个叫做MapCertStatusToNetError 的函数里，返回了这个ERR_CERT_AUTHORITY_INVALID。

（MapCertStatusToNetError ）映射证书状态至网络错误类型，查看这个函数的被谁引用：

在一个cert_verify_proc_android.cc的文件里被引用。这个文件名已经暗示了在检查/校验证书，我们点进去看看：

在VerifyInternal这个函数里，先用TrustManager校验了一番，如果发现校验结果verify_result的cert_status出现了error，则直接将错误映射后返回。如果没有错误则检查了证书的发布者是否为known_root，然后返回OK。

我们再往上回溯VerifyInternal这个函数：

看到一个更抽象的名字：cert_verify_proc.cc(证书校验程序)，点进去看看：

在这个函数中，rv保存了VerifyInternal的结果，如果结果是OK,则再继续进行了更多的检查：

比如证书是否使用了较弱的hash算法，是否过期，是否有效期过长（ssl证书有效期通常为1年）等等。

最后将rv返回。

我们看到无论是哪一步返回，rv的值都是MapCertStatusToNetError 这个函数赋予的。所以如果我们直接将这个的返回值改为OK，那么无论怎么校验，最终Verify的结果都是通过。换句话说，就是证书校验的过程被bypass了。所以我们考虑在app的so中找到这个函数的位置，然后修改即可。

3.实战

我们观察MapCertStatusToNetError这个函数的特征：

很明显的，每次通过一个flag与cert_status作与运算，如果通过则返回。

我们打开某音的lib目录，找到目标so：

打开之后发现并不好定位MapCertStatusToNetError函数的位置，因为函数名被抹去了。

我们考虑从其他的地方入手，尤其是一些有字符串常量，或者打log的地方入手。

我们看到Verify函数调用了很多次MapCertStatusToNetError函数，但是Verify函数里并没有可提供搜索的字符串信息。

结合编译原理的知识，我们知道源码中相邻的函数通常在编译结果中也是相邻的。

我们到Verify函数下面的一个函数里有一个字符串信息：

我们全局搜索这个字符串，果然有:

通过交叉引用定位到引用这个字符串的函数，查看与他相邻的上一个函数：

发现了与Verify函数相似的结构：判断rv是否ok，ok则进一步检查，并通过MapCertStatusToNetError函数给赋值。

我们点进去这个sub_31ff58函数：

看到了与MapCertStatusToNetError函数一样的结构：通过flag与判断，然后返回。

所以我们找到了MapCertStatusToNetError函数，通过修改汇编指令，直接让他在入口处直接返回OK(0)：

修改前：

修改后：

修改完后把so扔回手机替换app包里的so，再次打开app，发现已经可以成功抓包了：

随便打开一个视频的评论看看抓包是否正确：

嗯，对的，收工！

4.后记

其实小破站用的也是cronet，之前也有类似的证书校验，用同样的方法也能抓包。但是今天试了一下发现小破站把证书校验取消了，可能是觉得这些校验容易被绕过所以直接放弃治疗了吧哈哈。

总结起来，本文基于chrome源码，提出了一种更为通用的cronet组件证书校验的抓包方式，也更加直击cronet组件证书校验的核心。cronet的证书校验绕过可能比okhttp的还要简单，只要改8个字节就行，或者用frida hook MapCertStatusToNetError这个函数让他返回0就行。难点在于MapCertStatusToNetError函数的定位，这个可以通过各种方式去定位，小弟我采用的是字符串+编译相邻性原理定位的。

希望本文能对大家在https抓包的研究上提供一种新的思路。

————————————————————————————————————————————————
2023.8.3 更新
在实际中发现，有时候Verify函数里并没有调用MapCertStatusToNetError函数就直接返回了，观察源码后看到是：

直接调用了VerifyInternal这个虚函数，返回RV后有可能是非0值，同时verify->result并不符合后面的每一种条件，这样就会不经过MapCertStatusToNetError函数而直接返回。所以也可以定位到Verify函数之后，直接Hook Verify函数让他返回0（OK），这样更保险一点

[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。