简单尝试脱“爱加密”官网加固的DEX壳
0x00序第一次尝试脱dex壳，样本是在“爱加密”官网上免费加固的，非商业版。
http://upload-images.jianshu.io/upload_images/20238-bb245233230c1a4b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
本文只是做些简单的笔记，给像我一样的逆向新手们提供点思路，高手们不要见笑。
0x01加固包和原包对比
http://upload-images.jianshu.io/upload_images/20238-5212f502cb323149.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
加固后的classes.dex文件变大了，脱到JEB里面发现多了一些壳代码和一些垃圾类（jpvbhn、cioub、flsye…）。
http://upload-images.jianshu.io/upload_images/20238-17bcefbe8de682e9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
原包中，很多类方法的指令被抽空了，如下面的onCreate。
http://upload-images.jianshu.io/upload_images/20238-ae0bdc63ca67aeec.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
将assets目录下的libexec.so脱到IDA中，发现个别方法被加密，并且用了o-llvm进行混淆编译。导出表中的那些x、y开头的变量就是o-llvm在编译过程中，添加混淆控制流（-bcf）时创建的。
http://upload-images.jianshu.io/upload_images/20238-3d89b3744f880b1b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
ptrace注入，从内存中dump出来一个libexec.so，看一下字符串表：
http://upload-images.jianshu.io/upload_images/20238-4af52532872bc43b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
在字符串表中看到一些关键词（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进程死了。
http://upload-images.jianshu.io/upload_images/20238-32db88ad129653f9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
爱加密有点意思，应该是在libexec.so或libexecmain.so被加载之后，在native代码中判断了“/data/”目录下是否存在dexname文件（这也算DexHunter的一个特征），如果有则自退。
修改DexHunter源码，把dexname这个文件名改掉：
http://upload-images.jianshu.io/upload_images/20238-4940f59f5c2ad331.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
再试一次，还是挂了，这次貌似是调用com.cioub类的clinit方法导致的。
http://upload-images.jianshu.io/upload_images/20238-ed863d5fbdb078b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
看一下com.cioub类的clinit方法的实现就明白了，上文中提到的那些垃圾类（jpvbhn、cioub、flsye…）都是爱加密为了“防DexHunter”添加的。
http://upload-images.jianshu.io/upload_images/20238-b01738c0bcc7767b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
先用笨方法解决一下，通过一个名单文件，将这些“防DexHunter”类pass掉。
http://upload-images.jianshu.io/upload_images/20238-15186385ba0f304e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
再试一次，脱出了whole.dex，这实际是一个odex文件，利用baksmali和smali将其转换为dex文件，拖到JEB中看一下：
http://upload-images.jianshu.io/upload_images/20238-02cc1f550b42b50c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
之前被抽空的onCreate方法成功还原了，去掉那些垃圾类和shell代码应该就差不多了。
0x03后序
1、使用DexHunter脱完之后，如果还有方法没有还原，那加固厂商可能做了函数级加解密，在方法调用时再解密方法指令。
2、定位native方法指令在内存中的位置
http://upload-images.jianshu.io/upload_images/20238-b5b6aaf8fc1323a1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
这3个native方法是爱加密加固之后的3个核心方法，但libexec.so的JNI_Onload貌似加密了，并且导出函数的名字也混淆了（采用RegisterNative动态注册），找出对应的native函数有点费劲。
可以在dvmCallJNIMethod函数中加点log，其实这个函数中本来有log，只不过注掉了。放开的时候，要进行一下过滤，否则打出的日志太多会淹没其它有用的信息。
http://upload-images.jianshu.io/upload_images/20238-4e12c691b179dd3c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
http://upload-images.jianshu.io/upload_images/20238-b573d7baf03a206f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
3、爱加密应该已经有解释器壳了，猜测爱加密商业版以后可能会是“类抽取＋解释器壳”的形式，因为所有指令都解释执行的话，应该会对效率影响较大，所以二者结合是个不错的选择。
文／S18（简书作者）
原文链接：http://www.jianshu.com/p/2ed471bc9b15#
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。
感谢楼主分享！！
页:
[1]