0x00 序
第一次尝试脱dex壳,样本是在“爱加密”官网上免费加固的,非商业版。
本文只是做些简单的笔记,给像我一样的逆向新手们提供点思路,高手们不要见笑。
0x01 加固包和原包对比
加固后的classes.dex文件变大了,脱到JEB里面发现多了一些壳代码和一些垃圾类(jpvbhn、cioub、flsye…)。
原包中,很多类方法的指令被抽空了,如下面的onCreate。
将assets目录下的libexec.so脱到IDA中,发现个别方法被加密,并且用了o-llvm进行混淆编译。导出表中的那些x、y开头的变量就是o-llvm在编译过程中,添加混淆控制流(-bcf)时创建的。
ptrace注入,从内存中dump出来一个libexec.so,看一下字符串表:
在字符串表中看到一些关键词(dvmResolveClass.c、HOOK:%s() write dex!),
![](https://i-blog.csdnimg.cn/blog_migrate/b7586fc5f06040f812645ee80f1b1394.png)
原包中,很多类方法的指令被抽空了,如下面的onCreate。
![](https://i-blog.csdnimg.cn/blog_migrate/6e464125a370b21a6fac8fbd5efe1612.png)
将assets目录下的libexec.so脱到IDA中,发现个别方法被加密,并且用了o-llvm进行混淆编译。导出表中的那些x、y开头的变量就是o-llvm在编译过程中,添加混淆控制流(-bcf)时创建的。
![](https://i-blog.csdnimg.cn/blog_migrate/3f2d1dbf3d114d1720c2e4b87aaad6f1.png)
ptrace注入,从内存中dump出来一个libexec.so,看一下字符串表:
![](https://i-blog.csdnimg.cn/blog_migrate/90c6d37761e764ec5612f9b3d03db22b.png)
在字符串表中看到一些关键词(dvmResolveClass.c、HOOK:%s() write dex!),
瞎猜爱加密可能是抽取dex中的方法指令,然后hook dalvik/art 关键函数,在
运行时加载该类时再解密指令。所以用DexHunter试一下。
https://github.com/zyq8709/DexHunter
ps:从字符串表也可以看到,爱加密为了“防模拟器”,
判断了好多系统属性(ro.product.model、ro.product.device…)。
0x02:利用DexHunter还原dex
DexHunter的大致原理是在某dex的第一个类被加载时,遍历该dex文件的所有的class_def_item,
主动加载所有的class(调用dvmDefineClass),并初始化(调用dvmIsClassInitialized和dvmInitClass),
让壳自己完成方法指令的解密,然后再做必要修复并dump。
编译带DexHunter的dalvik,刷机之后试了一下,在脱壳过程中apk进程死了。
爱加密有点意思,应该是在libexec.so或libexecmain.so被加载之后,
编译带DexHunter的dalvik,刷机之后试了一下,在脱壳过程中apk进程死了。
![](https://i-blog.csdnimg.cn/blog_migrate/a90187181c6c44ed0aed83cdd2bb68f9.png)
爱加密有点意思,应该是在libexec.so或libexecmain.so被加载之后,
在native代码中判断了“/data/”目录下是否存在dexname文件
(这也算DexHunter的一个特征),如果有则自退。
修改DexHunter源码,把dexname这个文件名改掉:
再试一次,还是挂了,这次貌似是调用com.cioub类的clinit方法导致的。
看一下com.cioub类的clinit方法的实现就明白了,上面提到的那些垃圾类(jpvbhn、cioub、flsye…),
修改DexHunter源码,把dexname这个文件名改掉:
![](https://i-blog.csdnimg.cn/blog_migrate/55d600a5b6473241b362f746962b2361.png)
再试一次,还是挂了,这次貌似是调用com.cioub类的clinit方法导致的。
![](https://i-blog.csdnimg.cn/blog_migrate/6aed9b1fd584f3a74c2807c52bf614a4.png)
看一下com.cioub类的clinit方法的实现就明白了,上面提到的那些垃圾类(jpvbhn、cioub、flsye…),
都是爱加密为了“防DexHunter”添加的。
先用笨方法解决一下,通过一个名单文件,将这些“防DexHunter”类pass掉。
再试一次,脱出了whole.dex,这实际是一个odex文件,利用baksmali和smali将其转换为dex文件,
![](https://i-blog.csdnimg.cn/blog_migrate/dc402590c2dbd2a062e364ae976203b1.png)
先用笨方法解决一下,通过一个名单文件,将这些“防DexHunter”类pass掉。
![](https://i-blog.csdnimg.cn/blog_migrate/40d3d16179065fd8a2ba2850b8ce211b.png)
再试一次,脱出了whole.dex,这实际是一个odex文件,利用baksmali和smali将其转换为dex文件,
拖到JEB中看一下:
之前被抽空的onCreate方法成功还原了,去掉那些垃圾类和shell代码应该就差不多了。
0x03 后序
1、使用DexHunter脱完之后,如果还有方法没有还原,那加固厂商可能做了函数级加解密,
![](https://i-blog.csdnimg.cn/blog_migrate/1f51513d8d48e2952680deae92adbee1.png)
之前被抽空的onCreate方法成功还原了,去掉那些垃圾类和shell代码应该就差不多了。
0x03 后序
1、使用DexHunter脱完之后,如果还有方法没有还原,那加固厂商可能做了函数级加解密,
在方法调用时再解密方法指令。
2、定位native方法指令在内存中的位置
这3个native方法是爱加密加固之后的3个核心方法,但libexec.so的JNI_Onload貌似加密了,
![](https://i-blog.csdnimg.cn/blog_migrate/043ac5b0e8c83d269e3f811bffc28542.png)
这3个native方法是爱加密加固之后的3个核心方法,但libexec.so的JNI_Onload貌似加密了,
并且导出函数的名字也混淆了(采用RegisterNative动态注册),找出对应的native函数有点费劲。
可以在dvmCallJNIMethod函数中加点log,其实这个函数中本来有log,只不过注掉了。放开的时候,
可以在dvmCallJNIMethod函数中加点log,其实这个函数中本来有log,只不过注掉了。放开的时候,
要进行一下过滤,否则打出的日志太多会淹没其它有用的信息。
3、爱加密应该已经有解释器壳了,猜测爱加密商业版以后可能会是“类抽取+解释器壳”的形式,
![](https://i-blog.csdnimg.cn/blog_migrate/0620945a21927080b6c0053153c8afcf.png)
![](https://i-blog.csdnimg.cn/blog_migrate/8760407ea4e2f5a9cd622dae75eac1c3.png)
3、爱加密应该已经有解释器壳了,猜测爱加密商业版以后可能会是“类抽取+解释器壳”的形式,
因为所有指令都解释执行的话,应该会对效率影响较大,所以二者结合是个不错的选择。