一、目标
太难了，这年头抓包越来越难了，某小视频更新频发，我们之前屏蔽 QUIC 的方案貌似也失效了。
幸好我们还有 OkHttpLogger-Frida
TIP: v9.10.10.22596
二、步骤
原理分析
在 某小视频App v8.x 签名计算方法(一) 先从抓包说起 这篇文章里面我们分析了 v8.0 使用 OkHttpLogger-Frida 抓包的方法。
那么什么类型的App适合用 OkHttpLogger-Frida 来抓包呢？
作者描述了一下原理: 由于所有使用的Okhttp框架的App发出的请求都是通过RealCall.java发出的，那么我们可以hook此类拿到request和response。
我们用jadx打开apk
简单的说，凡是很明显发现 Okhttp 这个类的App，大概率可以用这个脚本抓包，如果没有很明显发现 Okhttp，也有可能是被混淆了，可以运行这个脚本的 find 命令来尝试寻找一下。
分析问题
有些朋友会说，我试了这个脚本，不好使，抓不到包。
大佬们都是抛砖引玉的，没有人会去苦哈哈的帮你适配每个版本。所以我们需要领悟脚本的原理来自己做适配。
首先将 okhttpfind.dex 拷贝到 /data/local/tmp/
然后 frida -U -l okhttp_poker.js -f com.example.demo –no-pause 跑起来了。
首先跑一下 find() 命令，从打印的结果可以看出，这个App使用了 okhttp3 ，然后记下这一行的输出。
var Cls_okio_Buffer = "okio.f";
现在可以开始抓包了，敲一下 hold() 命令
漂亮，已然可以输出 url和 Request Headers 信息了。
这里有两个问题:
1、Request Body没有打印出来， 就提示了一个 ” File Request Body Omit…..”
2、Response 数据没有打印出来。
3、有这么一个报错
print request error : Error: writeTo(): argument types do not match any of:
.overload('okio.g')
at X (frida/node_modules/frida-java-bridge/lib/class-factory.js:563)
at value (frida/node_modules/frida-java-bridge/lib/class-factory.js:966)
at e (frida/node_modules/frida-java-bridge/lib/class-factory.js:547)
at printerRequest (/okhttp_poker.js:171)
at printAll (/okhttp_poker.js:106)
at <anonymous> (/okhttp_poker.js:89)
at <anonymous> (frida/node_modules/frida-java-bridge/lib/vm.js:16)
at perform (frida/node_modules/frida-java-bridge/index.js:193)
at buildNewResponse (/okhttp_poker.js:98)
at <anonymous> (/okhttp_poker.js:510)
at apply (native)
at ne (frida/node_modules/frida-java-bridge/lib/class-factory.js:613)
at <anonymous> (frida/node_modules/frida-java-bridge/lib/class-factory.js:592)
适配代码
先看第一个问题，在 okhttp_poker.js:160 行有个 filterUrl 判断，原意是过滤掉图片类的文件，但是如果请求值或者返回值里面包含了 “jpg” “png” 之类的字符串也会被过滤掉，所以我们要精准判断，只有末尾几个字符串匹配的时候才过滤。
var filterArray = [".JPG", ".jpg", ".PNG", ".png", ".WEBP", ".webp", ".JPEG", ".jpeg", ".GIF", ".gif",".zip", ".data"]
......
/**
* fenfei 过滤url
* false 显示
* true 拦截 不显示 返回信息
*/
function filterUrl(url) {
//*
for (var i = 0; i < filterArray.length; i++) {
// if (url.indexOf(filterArray[i]) != -1) {
// console.log(url + " ?? " + filterArray[i])
// return true;
//}
if (url.lastIndexOf(filterArray[i]) >= (url.length - 6) ) {
// console.log(url + " ?? " + filterArray[i])
return true;
}
}
// */
return false;
}
第二个问题暂时看不出所以然，我们先把报错解决了。
在 at printerRequest (/okhttp_poker.js:171) 有如下代码
var buffer = BufferWapper.$new()
requestBody[M_reqbody_writeTo](buffer)
意思是把requestBody的值 writeTo 到 BufferWapper 类型的 buffer变量里面。
BufferWapper 类型是 var Cls_okio_Buffer = “com.singleman.okio.Buffer”;
这里解决方案已经有两个提示了:
1、报错的提示提示我们这里需要一个 okio.g 类型
2、开头我们find的时候提示我们在这个app里面 var Cls_okio_Buffer = “okio.f”;
那么到底是用 okio.g 还是 okio.f 呢？
我们看看jadx分析的代码
public interface g extends z, WritableByteChannel {
......
}
public final class f implements h, g, Cloneable, ByteChannel {
......
}
okio.g是个接口类，okio.f才是继承他的实现类。 所以这里毫无疑问是使用 #okio.f#
这么修改一下
// add fenfei 适配 910
// var buffer = BufferWapper.$new()
var ffBufferWapper = Java.use("okio.f");
var buffer = ffBufferWapper.$new();
再跑一下，这下就很漂亮了，Request和Response都打印出来了。
最后一个问题
加上这个抓包之后，突然app变得很不稳定，要么一会就卡住不动了，要么就是出现网络访问失败。
这个问题肯定是由于我们这个js导致的。但是具体是怎么导致的？如何排查问题呢？
解决这种问题，最好的办法就是 排除法。
1、屏蔽printAll函数，啥都不打印了，app运行Ok， 说明 hook没问题，问题出在打印上面。
2、打印分两部分，printerRequest和printerResponse，通过屏蔽大法发现问题出在 printerResponse上面，
3、在printerResponse函数中 继续用屏蔽大法，发现问题出在 getByteString 函数中的 bufferM_buffer_readByteArray ，也就是说只要对 Response body 做读操作，就会出问题。
目前我感觉问题可能出在对buffer的读上面，可能是读冲突了，由于我们的hook脚本读了这个buffer，导致app读不到结果了，所以出现各种诡异问题。
然后就尝试了各种办法，换个读的函数、深拷贝这个buffer，都没有成功。 最后发现作者预留了一手，实际上作者已经对这个 Response body做了次深拷贝，并且生成了一个newResponse。
所以我们继续hook我们的，愉快的打印出来，然后把生成的新的newResponse 返回给app就ok了。
再跑一下，完美收工。
三、总结
拿来主义虽然好用，但是明白原理后自己可以适配更重要。
遇到问题，先遵循最小可用原则，一步一步屏蔽代码，来缩小范围，定义问题。