带360壳分析Umeng协议 – 作者:skyun1314-安全小百科

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

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

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

可是安装的时候提示：

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

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

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

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

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。

直接就找到了。

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

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

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

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

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

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

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

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

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

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