随意在安卓应用市场上下载了一个电子书app，发现还是有点东西的：
Charles首次抓包报错如下：

第一反应就是有sslpinning，感觉挺简单的，但是几乎找了所有公开的unsslpinning脚本都无济于事， dump证书也如此。

对apk解包时发现里面有okhttp3，以为使用了okhttp3库，但hook后发现并不如此。

既然okhttp3 hook不到，就找了更深层次点的函数SSLOutputStream的write, 奇怪的是也没发现有调用，突然意识到事情可能没那么简单了！。

对于这种情况，貌似就只能多对一些底层或者基础的涉及网络的函数进行hook，终于在java.net.url函数打开了突破口

看这个调用栈大概能看出，这个app因该是自己根据okttp3魔改了一个自己的框架，看后面的文件名感觉有点熟悉。

这不就是okhttp的拦截器吗？
Ok直接看源码

这个地方能看出来跟okhttp还是有区别的，决定hook下打印出所有的拦截器类。

在okhttp3中，tls连接的部分在倒数第二个拦截器中，但是在本app上并没有这样做，所以重要分析了最后一个拦截器callServerInterceptor，具体如下：
看这个excutecall函数很关键，继续往下跟，其实hook这个地方就已经能拿到请求体和响应内容了，但是以学习为目的的话还是要搞明白它是怎么做的。

这个executel最终会调到com.ttnet.org.chromium.net.impl.CronetUrlRequest$1 中，然后就进入了native层。

至此在java层也没发现在哪里有对证书的操作，所以有充分的理由相信他在native层做了校验。

尝试hook了下libssl.so中的SSL_write函数，居然也没发现有调用，惊出了一生冷汗，难不成是用了自己的ssl库？尝试搜了以下app已加载的so库，果不其然：

查了下这个boringssl是google开源的openssl分支，于是尝试hook了下 boringssl中的SSL_write函数，果然有调用，所以可以基本确定它使用了自己的ssl库。

根据SSL_write的调用栈，判断该函数的调用来自libsscronet.so，于是在该库中搜索判断是否有调用boringssl中涉及证书验证的函数。

上面的不管，只看导入函数，有两个函数比较可疑 SSL_CTX_set_custom_verify和SSL_CTX_set_reverify_on_resume，于是下载了一份boringssl的源码，分别看了下这两个函数，果然是用来做证书校验的，并且都有调用。

该函数的原型为：

第二个参数为校验模式：

第三个参数为回调函数。
回调函数的返回值用来确认证书验证是否成功，具体如下：

Hook之：



这里有个问题，不能直接替换他原本的回调函数，必须要调用一次，不然会出问题，具体是什么原因懒得去研究。
验证：

既然这个函数可以unpinning,另一个函数现在就懒得去看了，有空在研究下。

后来大概查了下，这个app是今日头条旗下的，难怪如此。接下来去干签名算法了。。。。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课