带360壳分析Umeng协议-华盟网

带360壳分析Umeng协议

华盟学院山东省第二期线下学习计划

为什么要带壳分析umeng协议啊,因为嘬呗。直接打开charles手机设置好代理,过滤掉肯定无关的链接,从手机打开需要抓包的软件,发现只有2条网络请求 (传送门)。

image.png

一看就知道是umeng的协议,但是参数加密了,只能反编译看看他是如何加密的。挂起 jadx 打开apk,发现apk 360加固了,没有办法只能脱壳。拿出我的脱壳神机google5儿子(自己编译的android4.4的系统,修改了内核代码,能过掉proc文件状态的反调试)

可是安装的时候提示:

image.png

我靠设备版本太低,没关系,反编译修改一下最低sdk版本。

image.png

加上-s参数,只反编译资源文件,然后打开apktool.yml这个文件:

image.png

把这里修改成19.ok。重打包提示签名被修改,没关系继续安装xposed hook签名模块。然后软件就可以打开了。

根据吾爱欧阳锋锋大神的帖子(传送门)过掉 时间差,rtld_db_dlactivity 这两个反调试一路走到这里

image.png

dump 出dex文件。再次拖入 jadx 发现还是不对啊。是真实代码,可是没有umeng的代码。这是怎么回事啊。和我之前脱的软件不一样,难道360又升级了。带着疑惑我又打开了我自己写的一个通用脱壳软件。

先给大家介绍下我的软件:

本工具是一个apk软件,打开后listview显示手机上安装的所有用户apk(图标➕apk名字),然后可以选择需要脱壳apk,然后再运行需要脱壳apk。即可完成脱壳。

代码实现: (java+jni)

1、xmlpull解析选择apk的apkminifest,获取其包名,ApplicationName,MainActityName。

2、Xposed hook android.content.ContextWrapper attachBaseContext得到壳的classloder

3、根据classloder继续hook真正类的oncreate。

4、继续根据classloader获取内存中的所有cookie。

5、继续调用jni。根据cookie能转换成DexFile,然后其实就是解析dex文件了。

6、在内存其实他的指向都是完整的。只不过没有在连续的地方。dump下来的也就不完整。那么我就分部dump。1。classdef之前的,2classdef之后的,3classdef4.classdata,5opcode。然后修改指向组合。

通过这个软件dump下来的dex文件有60个,我把每个dex文件都打开看看,发现jar包都单独是一个dex文件,感觉和分包一样。想了想再把他们组合再修复oncrete 肯定是需要很长时间。不修复了。只看umeng这个dex把。jadx 打开dex 搜索 host。

image.png

直接就找到了。

image.png

看到了参数传递了byte[],继续跟踪调用的地方。

image.png

跟到这里发现 调用了ch的b函数,里面肯定是处理了a变量,最后返回了 byte[].但是我怎么搜索都收拾不到a变量在哪里调用了,继续跟踪 b函数,跟了一圈发现umeng的代码写的真是好啊,各种继承,接口,越看越晕都不知道谁掉的谁。

image.png

怎么和我之前 抓包的情况不一样啊。之前抓过几次都是 几个变量拼接,然后在调用 通用加密函数,虽然加密函数可能在jni,可能有ollvm混淆,但是都能看懂大概啊。这个是越看越懵。

最后才想起原来dump出来的指令被优化了,需要修复。

image.png

image.png

修复完看到了引用的地方这下代码看懂了

image.png

image.png

image.png

他把每一个参数都单独取出来转换成byte[] 然后写入OutputStream既然看懂了那么就看看她这几个参数都是啥直接传进去就ok了。刚好他有一个tostring函数。

image.png

拖出来的dex没有修复不能 动态调试,那么我hook一下打印出来就好了。

image.png

image.png

参数是都打印出来了,简单的能看懂,看不懂的继续跟代码发现又他娘的是加密了,不过还好加密函数还是同一个,但是看了看加密的串是10个对象的100个参数。

image.png

image.png

继续xposed hook打印参数把,幸好他们的类名有规律。

image.png

并且有2个类是他们的组合。

image.png

继续看懂参数:

有的参数是设备固定值,有些参数是固定值的md5,有些参数是固定参数加上时间戳的md5.都看懂了模拟代码。ok大功告成。继续看下一条协议。 第二条协议其实还是这个接口,就是参数多了一点,多的那点就是第一条协议的返回值。虽然看懂了,但是不知道她是怎么解析返回值的啊。

image.png

install_channel 找到这个参数 hook 赋值的地方,打印堆栈。

image.png

发现是这里读的。

image.png

嗯。都找到了,模拟代码吧。测试,一摸一样……

www.idc126.com

*本文原创作者:Skyun1314,本文属FreeBuf原创奖励计划,未经许可禁止转载

本文由 华盟网 作者:AlexFrankly 发表,其版权均为 华盟网 所有,文章内容系作者个人观点,不代表 华盟网 对观点赞同或支持。如需转载,请注明文章来源。
0

发表评论