最近看论坛里关于抓包的问题聊的火热,小弟我也借此机会献丑来分享一下我的抓包的研究成果。
毫无疑问,app逆向的第一步是抓包。通过抓包可以获取很多有用的线索,比如url,参数名等。再根据url,参数名等,可以逐步抽丝剥茧找到app收发数据的地方,然后就能找到最关键的签名所在的位置。研究清楚签名,接下来就可以做一些不可告人之事了~
安卓app常用的网络框架是okhttp,对于okhttp的抓包研究已经非常成熟了,无非是certificate pin或者hostname verify那一套。但是最近几年,出现了一些基于Google Cronet通讯框架的app,比如某音,某小破站等等。Cronet是从Chrome中抽出的给移动端使用的网络组件,目前针对Cronet抓包,证书校验的研究比较少,大多是奇技淫巧,没能从根本上挖掘。本文从Chrome源码出发,结合实例某音,研究一下使用Cronet安卓程序的正确抓包姿势。
打开手机代理,将https证书塞入手机的根目录,启动目标应用,结果:
请求全部失败,app界面也显示无网络,无所谓,我们打开日志先看看:
看到了:ERR_CERT_AUTHORITY_INVALID,很明显是检测到了证书无效。
经常使用Chrome浏览器的朋友应该对这种ERR_开头的错误有印象:
没错,这正是Chrome的报错通用的格式。
那么我们就可以从报错入手,去Chrome源码里看看这个错误的来源,以此为根据寻求bypass的方式。
打开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中找到这个函数的位置,然后修改即可。
我们观察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,发现已经可以成功抓包了:
随便打开一个视频的评论看看抓包是否正确:
其实小破站用的也是cronet,之前也有类似的证书校验,用同样的方法也能抓包。但是今天试了一下发现小破站把证书校验取消了,可能是觉得这些校验容易被绕过所以直接放弃治疗了吧哈哈。
总结起来,本文基于chrome源码,提出了一种更为通用的cronet组件证书校验的抓包方式,也更加直击cronet组件证书校验的核心。cronet的证书校验绕过可能比okhttp的还要简单,只要改8个字节就行,或者用frida hook MapCertStatusToNetError这个函数让他返回0就行。难点在于MapCertStatusToNetError函数的定位,这个可以通过各种方式去定位,小弟我采用的是字符串+编译相邻性原理定位的。
希望本文能对大家在https抓包的研究上提供一种新的思路。
看雪ID:乐子人
https://bbs.kanxue.com/user-home-872365.htm
# 往期推荐
3、安卓加固脱壳分享
球分享
球点赞
球在看
文章引用微信公众号"看雪学苑",如有侵权,请联系管理员删除!