OkHttp 通用抓包方式分析,以某小视频App为例

一、目标

太难了,这年头抓包越来越难了,某小视频更新频发,我们之前屏蔽 QUIC 的方案貌似也失效了。

幸好我们还有 OkHttpLogger-Frida

TIP: v9.10.10.22596

着急的同学可以直接拉到后面,加入 知识星球 取js吧。有理想的同学建议好好研究下原理,下次就可以自己适配了。

二、步骤

原理分析

某小视频App v8.x 签名计算方法(一) 先从抓包说起 这篇文章里面我们分析了 v8.0 使用 OkHttpLogger-Frida 抓包的方法。

那么什么类型的App适合用 OkHttpLogger-Frida 来抓包呢?

作者描述了一下原理: 由于所有使用的Okhttp框架的App发出的请求都是通过RealCall.java发出的,那么我们可以hook此类拿到request和response。

我们用jadx打开apk

main.png

简单的说,凡是很明显发现 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、有这么一个报错

1print request error : Error: writeTo(): argument types do not match any of: 2 .overload('okio.g') 3 at X (frida/node_modules/frida-java-bridge/lib/class-factory.js:563) 4 at value (frida/node_modules/frida-java-bridge/lib/class-factory.js:966) 5 at e (frida/node_modules/frida-java-bridge/lib/class-factory.js:547) 6 at printerRequest (/okhttp_poker.js:171) 7 at printAll (/okhttp_poker.js:106) 8 at <anonymous> (/okhttp_poker.js:89) 9 at <anonymous> (frida/node_modules/frida-java-bridge/lib/vm.js:16) 10 at perform (frida/node_modules/frida-java-bridge/index.js:193) 11 at buildNewResponse (/okhttp_poker.js:98) 12 at <anonymous> (/okhttp_poker.js:510) 13 at apply (native) 14 at ne (frida/node_modules/frida-java-bridge/lib/class-factory.js:613) 15 at <anonymous> (frida/node_modules/frida-java-bridge/lib/class-factory.js:592)

适配代码

先看第一个问题,在 okhttp_poker.js:160 行有个 filterUrl 判断,原意是过滤掉图片类的文件,但是如果请求值或者返回值里面包含了 "jpg" "png" 之类的字符串也会被过滤掉,所以我们要精准判断,只有末尾几个字符串匹配的时候才过滤。

1var filterArray = [".JPG", ".jpg", ".PNG", ".png", ".WEBP", ".webp", ".JPEG", ".jpeg", ".GIF", ".gif",".zip", ".data"] 2...... 3 4/** 5 * fenfei 过滤url 6 * false 显示 7 * true 拦截 不显示 返回信息 8 */ 9function filterUrl(url) { 10 11 //* 12 for (var i = 0; i < filterArray.length; i++) { 13 // if (url.indexOf(filterArray[i]) != -1) { 14 // console.log(url + " ?? " + filterArray[i]) 15 // return true; 16 //} 17 18 if (url.lastIndexOf(filterArray[i]) >= (url.length - 6) ) { 19 // console.log(url + " ?? " + filterArray[i]) 20 return true; 21 } 22 23 } 24 // */ 25 26 return false; 27} 28

第二个问题暂时看不出所以然,我们先把报错解决了。

在 at printerRequest (/okhttp_poker.js:171) 有如下代码

1 var buffer = BufferWapper.$new() 2 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分析的代码

1public interface g extends z, WritableByteChannel { 2...... 3} 4 5public final class f implements h, g, Cloneable, ByteChannel { 6...... 7}

okio.g是个接口类,okio.f才是继承他的实现类。 所以这里毫无疑问是使用 #okio.f#

这么修改一下

1// add fenfei 适配 910 2// var buffer = BufferWapper.$new() 3 4var ffBufferWapper = Java.use("okio.f"); 5var buffer = ffBufferWapper.$new();

再跑一下,这下就很漂亮了,Request和Response都打印出来了。

最后一个问题

加上这个抓包之后,突然app变得很不稳定,要么一会就卡住不动了,要么就是出现网络访问失败。

这个问题肯定是由于我们这个js导致的。但是具体是怎么导致的?如何排查问题呢?

解决这种问题,最好的办法就是 排除法

1、屏蔽printAll函数,啥都不打印了,app运行Ok, 说明 hook没问题,问题出在打印上面。

2、打印分两部分,printerRequest和printerResponse,通过屏蔽大法发现问题出在 printerResponse上面,

3、在printerResponse函数中 继续用屏蔽大法,发现问题出在 getByteString 函数中的 buffer[M_buffer_readByteArray] ,也就是说只要对 Response body 做读操作,就会出问题。

目前我感觉问题可能出在对buffer的读上面,可能是读冲突了,由于我们的hook脚本读了这个buffer,导致app读不到结果了,所以出现各种诡异问题。

然后就尝试了各种办法,换个读的函数、深拷贝这个buffer,都没有成功。 最后发现作者预留了一手,实际上作者已经对这个 Response body做了次深拷贝,并且生成了一个newResponse。

所以我们继续hook我们的,愉快的打印出来,然后把生成的新的newResponse 返回给app就ok了。

再跑一下,完美收工。

三、总结

拿来主义虽然好用,但是明白原理后自己可以适配更重要。

遇到问题,先遵循最小可用原则,一步一步屏蔽代码,来缩小范围,定义问题。

ffshow.jpeg 只要想起一生中后悔的事,梅花便落满了南山

TIP: 本文的目的只有一个就是学习更多的逆向技巧和思路,如果有人利用本文技术去进行非法商业获取利益带来的法律责任都是操作者自己承担,和本文以及作者没关系,本文涉及到的代码项目可以去 奋飞的朋友们 知识星球自取,欢迎加入知识星球一起学习探讨技术。有问题可以加我wx: fenfei331 讨论下。

关注微信公众号: 奋飞安全,最新技术干货实时推送

点赞
收藏

评论区

加载中...

相关推荐

小程序逆向分析 (一)

一、目标李老板:奋飞呀,最近耍小程序的比较多,而且貌似js好耍一点?要不咱们也试试?奋飞:你是老板,你说了算喽。第一次搞小程序,得找个软柿子捏,就找个以前分析过的某段子App的小程序吧。反编译静态分析动态调试二、步骤春天在哪里?app下载回来就是apk包,那么小程序在哪里?小程序是一个以wxapkg为后缀的文件,在android手机的/da

某电商App 返回数据加密解密分析(四)

一、目标最近在抓包某电商App的时候发现一个加密数据,它在做通讯地址请求的时候,请求数据做了加密。返回数据中的地址信息也是密文。今天我们的目标就是这个数据的加密解密。App版本:v10.3.0二、步骤分析一下1、数据的结尾是"",说明是Base64编码,那么我们可以尝试去HookBase64相关函数,然后打印堆栈。2、返回数据格式是json,那么我

某婚恋App _t 签名分析

一、目标最近也不让加班了,李老板每天早早的就回家,小视频也刷的没意思了。还是好好找个mm正经聊聊吧。今天我们的目标是某婚恋App的v11.3.2。二、步骤抓个包\t参数,看上去像是时间戳加上一个md5(掰指头数了数,一共32位)。jadx搜一搜\t,我去,10几万条结果。一时激动,都忘了我的独门秘籍了。这种签名一般会以字符串的方式存入一个m

再搞个大点的 某小视频App X-Gorgon 分析

一、目标何以解忧,除了烤串啤酒,也只有刷刷小视频了。今天我们的目标就是看看海外版的这个小视频App的XGorgonTIP:v18.9.4(180904)二、步骤Jadx搜索"XGorgon"居然只有两个结果,很容易就定位到了这里上Frida搞一下varstrUtilClsJava.use('com.ss.a.b.a');strUtilCls

某站App签名算法解析(一)

一、目标我们来分析某站App的sign签名算法,先搜索一下游戏,抓包结果:二、步骤这个sign依然是32位的字符串都9020年了,这种规模用户的App应该是不会裸奔在java层了,我们就直接一点,在so里面搜索sign可惜没有结果……藏起来的东西一定是重要的东西so层导出函数给java层调用,有两种方法,一种是静态注册,直接会体现在so的导出表

另一个生鲜App 抓包和mfsig签名分析(一)

一、目标市面上生鲜App一大堆,买菜也确实是高频次的刚需,这些生鲜App还都有一些有意思的共性:大都加壳了大都不好抓包今天我们分析的是某生鲜Appv9.9.59的mfsig签名。二、步骤上jadx看看这么少的包名和类名,基本可以断定是加壳了。那就先复习下BlackDex脱壳脱完壳的结果拖到PC上,赶紧jadx一下,搜一搜"mfsig"