ALICTF2014 EvilAPK4脱壳分析

相关文件可以在下面链接中下载：

http://pan.baidu.com/s/1sjpvFy9

1 简述

该apk使用libmobisec.so函数实现对dex的解密还原。真正的dex为assets目录下的cls.jar和jute.data文件。

本分析文档主要用于讨论脱壳方面的技术，并非以获取该APK的登录密码为目的。所以虽然可以使用很多动态的Android 分析工具进行API跟踪，然后快速得到登录密码，但是我还是选择进行静态脱壳，毕竟没参加比赛，不用担心时间限制啊~

分析文档只涉及核心逻辑，具体细节需要结合libmobisec.idb文档阅读，里面注释还是很详细的。

2 分析

2.1 初探

关键函数在sub_24c84(我改名为了keyFunction)，该函数进行一些准备工作后，就会在偏移值0x24eca处调用parse_dex函数(偏移值为0x26398)。此函数就是整个dex解密的核心函数！下面对它进行详细分析。

2.1.1 openWithHeader函数解析

首先在0x269c8调用openWithHeader函数。该函数的详细实现在0x285f0处，它的功能如下：

①获取真正的cr4解密key；

②打开并mmap  cls.jar，使用真正的key对cls.jar进行cr4解密，然后解压，解压算法为lzma，处理后的数据重新mmap；

③munmap掉第一次mmap的内存，将解密、解压后的cls.jar（就是一个dex文件）的首地址存放到struct1.cls_jar_mmap_addr中，将它的大小存放到struct1.umcompress_size中；

Struc1为一个辅助结构它的内容如下：

typedef struct struct1

{

int mmap_size  ; //文件mmap大小,需要注意的是，在cls.jar操作中它的大小刚好比unpacksize的大小多0x10,这是由mmap时的参数造成的！详情参见idb

void* file_mmap_addr;  //这个文件mmap在内存中的首地址，对于cls.jar其向后偏移0x10才是dex.035的开始地址！

void* file_path ; //file的绝对路径

};

④返回struct1.cls_jar_mmap_addr值,并将上层参数r2赋值为；struct1.umcompress_size, 及r1赋值为cls_jar_mmap_addr；

如何获取真正的cr4解密key？

在ali::decryptRc4函数中，先获取原apk的classes.dex的crc32校验码(32bit),然后将一个硬编码的0x18字节的字符串按4字节为单位依次同crc32结果进行异或运算。运算得到的0x18字节的字符串就是真正的rc4解密密钥。

为了以后叙诉的方便，将解密、解压后的cls.jar称作cls.dex。

2.1.2 反射调用openDexFile函数加载cls.dex

鉴于篇幅有限，这里就不详细说明了，大家可以直接移步到jack_jia大牛的博客：

http://blog.csdn.net/androidsecurity/article/details/9674251

需要提及一点，就是openDexFile加载、解析完cls.dex之后，会在内存重新生成一个经过优化后的cls.dex。之后的操作，都是针对这个优化后的cls.dex的。我们可以在libmobisec的0x27b14下断，r0的值为openDexFile加载、解析后的cls.dex的开始地址，dump出来即可。

大家可以查看openDexFile函数的具体实现，源码在：

dalvik2\vm\native\dalvik_system_DexFile.cpp

关键函数在dvmRawDexFileOpenArray(pBytes, length, &pRawDexFile)，他完成加载和解析工作。需要注意的是其中的dvmPrepareDexInMemory函数会调用rewrite函数，这又是需要重点关心的函数。这个函数完成dex的优化，认证，以及所有类的加载(loadAllClasses)和部分inline方法的加载。说个题外话，可以从loadAllClasses函数看出，对于dalvik虚拟机而言，它在解析dex文件的时候会且仅会把所有的DexclassDef结构加载到内存，而只有在使用到某个类的方法的时候才会具体地加载这个方法！这貌似就是之前有人提及过的基于方法粒度的dex加密的前提吧。

按照正常情况，分析到此，就已经可以在openDexFile函数下断点，dump出解密后的dex了。但是，现实很残酷，我们将dump出来的dex,使用backsmali反编译为smali文件，得到的却是如下结果：

所有类的所有方法都被替换成了上面这种形式！显然，得到的cls.dex并非一个完整的dex文件，它真正的方法都被替换掉了！

看来脱壳过程不是想象中的那么简单啊。没办法，继续看libmobisec的代码。

2.1.3 ali::dex_juicer.patch函数分析

在加载完cls.dex之后，会接着执行ali::dex_juicer_patch函数。从名字就可以看出它是在对dex进行修补工作。继续分析，总结此函数的功能如下：

①使用同样的方式解密解压juice.data文件，得到文件decrypted_juice；

②通过一系列算法将decrypted_juice同cls.dex结合在一起，组合成为完整的dex.

可以在libmobisec的0x27b60下断，此时的r5为juicer.data解密后的首地址，r3为解密后的长度，dump出来，保存为decrypted_juice即可。

第二个功能总结起来就一句话，但实际情况很复杂，我最初就卡在了0x2a79c的函数上(函数名原来是sub_2a79c，后来直到大牛Flanker_017发了一份某个复旦大牛的解密算法后，才发现它原来就是readUleb128函数！这可能就是一个人进行分析时面临的最大问题——思维固化。听说那位大牛是初次接触android就把它给逆出来了，我......只能给他跪下~)。当然，理解了这个函数，并不意味着，就可以轻松的进行dex还原了。挑战才刚刚开始！

如果仅仅看它的那些解密函数，是很难得到有用的信息的。我分析了一天都没理出个头绪。本着一切问题睡一觉之后都能解决的原则，我一觉睡到了第二天下午~~果然，灵感来了！

2.2 换个角度分析问题

回顾2.1.2，我发现所有的方法都被替换成了RuntimeException。现在，我们换个角度，不从逆向的角度来思索问题，转而从加固者的角度来思索：如何才能实现2.1.2的情况。

首先，我们需要认真的分析2.1.2所展示出来的信息，总结一下：

①cls.dex包含了所有的类和方法，只是每个方法的真正代码都被替换了；

②所有的方法都被替换成了RuntimeException，但是，如果细心一点，就可以发现，它们并不是完全相同的！如MainActivity.onCreate方法的registers为3，而MainActivity.<init>方法的registers为2。

如果了解dex文件结构的话，我相信大家此时已经豁然开朗：我们只需要将每个DexMehtod对应的DexCode结构体篡改为2.1.2的模式就可以了！至于修复，将DexMehtod的codeOff偏移值做个重定位，指向真正的DexCode，不就OK了？

事实是我们猜想的那样么？这就需要获取每个method对应的DexCode进行验证了。

2.2.1 获取DexCode

要想获取DexCode结构体，看雪Xbalien的一篇关于dalvik自篡改的文章可以提供思路：

http://bbs.pediy.com/showthread.php?t=176732

总结一下，要找到A类的B方法对应的DexCode结构体(为了简便，这里省去了方法声明的匹配，原理是一样的，可根据需要自行添加)那么步骤如下：

①获取A类名对应的字符串ID­——A_class_stringID和B方法名对应的字符串ID——B_method_stringID;

②获取A_class_stringID对应的A_class_typeID;

③获取A_class_typeID对应的DexClassDef结构体的起始地址A_classDefAddr；

④根据A_class_typeID和B_method_stringID获取B_methodID；

⑤根据A_classDefAddr和B_methodID获取B_codeOff，它指向的就是dexCode结构体。

为了方便大家理解和测试，我在附件中提供了读取codeOff的完整源码，这是用标准c库写的，linux和windows都可编译，只需要将main函数中的classname_string和methodname_string根据自己的需要进行赋值即可。运行效果如下：

通过查询不同的method的DexCode，得出结论：我们的猜想成立！它是将所有方法的DexCode结构体都改成了如下结构：

MainAcrivity.<init>的dexcode

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

0000F850                                        02 00[w1]  01 00[w2]

0000F860   01 00[w3]  00 00 [w4] 00 00 00 00[w5]   06 00 00 00[w6]  22 00 17 01               "

0000F870   70 10 20 06 00 00 27 00[w7]   02 00 01 00 01 00 00 00   p     '

0000F880   00 00 00 00 06 00 00 00  22 00 17 01 70 10 20 06           "   p

0000F890   00 00 27 00 02 00 01 00  01 00 00 00 00 00 00 00     '

0000F8A0   06 00 00 00 22 00 17 01  70 10 20 06 00 00 27 00       "   p

[w1]registersize = 2

[w2]inssize = 1 参数个数

[w3]outsSize = 1,调用其他方法时使用的寄存器个数

[w4]triesSize

[w5]debugInfoOff

[w6]insnsSize = 6 指令集个数，以2字节为单位，

[w7]紧跟着的6条指令

registersize和inssize会根据具体地函数进行相应的变化，除此之外，都相同。

2.2.2 修复dex

在前面说过，将DexMehtod的codeOff偏移值做个重定位，指向真正的DexCode就可以完成修复了。libmobisec中的代码也印证了此想法：

ali::dex_juicer_patch部分代码节选：

注意：由于当时分析的时候，命名规则有点乱，可能会给各位观众大老爷带来困扰，这里的juicerdata就是decrypted_juice；dex就是cls.dex；ali::juiceMem就是decrypted_juice在内存中的首地址

........

juiceMem[0] = *ali::juiceMem;  //0x401

juiceMem[1] = ali::juiceMem[1]; //0x8a8

juice_mmap_addr_Plus_0x?_ptr = (int)(ali::juiceMem + 2);

if ( juiceMem[0] > 0x1FC00000 )

m_0x1004 = -1;

else

m_0x1004 = 4 * juiceMem[0];

juiceDexCodeOff = juiceMem[1];

ali::orgOffset = operator new[](m_0x1004);

while ( v9 != juiceMem[0] )

{

dex_offset_sum += readUleb128((int **)&juice_mmap_addr_Plus_0x?_ptr);

data_offset = readUleb128((int **)&juice_mmap_addr_Plus_0x?_ptr);

orgOffset_new0x1004 = ali::orgOffset;

cur_dexaddr = dexStartAddr + dex_offset_sum;

data_offset_sum += data_offset;

*(_DWORD *)(orgOffset_new0x1004 + 4 * v9++) = readUleb128((int **)&cur_dexaddr);// 这个new_0x1004的数据有什么作用？我们在这里给他赋了值，但是却不知道在哪个地方需要用到他！

changeCodeOffInDex(

        dexStartAddr,

        dex_offset_sum,

        (char *)ali::juiceMem + data_offset_sum + juiceDexCodeOff - dexStartAddr);

/* 第三个参数很有意思，需要我们好好分析。首先它是4个变量的运算结果，但是注意，这4个变量中，ali::juiceMem, juiceDexCodeOff以及dexStartAddr均是确定的值，只有dats_offset_sum会不停变化。经过分析，发现第三个参数其实就是一个偏移值，这个偏移值表示的是juicerData中的某个DexCode数据的地址较dexStartAddr的偏移距离。*/

}

result = 0;

}

return result;

进一步分析chageCodeOffInDex，它的代码翻译过来如下：

ChangeCodeOffInDex(void* dexStartAddr, int dex_offset_sum, int rel_off){

dexStartAddr [dex_off_sumd] = (rel_off & 0x7F) | 0x80

dexStartAddr [dex_off_sumd+1] = ((rel_off >>7)&0x7F) | 0x80

dexStartAddr [dex_off_sumd+2] = ((rel_off >>14)&0x7F) | 0x80

dexStartAddr [dex_off_sumd+3] = ((rel_off >>21)&0x7F) | 0x80

dexStartAddr [dex_off_sumd+4] = ((rel_off >>28)&0x7F)

}

很明显就是一个uleb128的数据。

再详细解释下decrypted_juice的文件结构：

patchCount

constOffset

dexOffset_1

dataOffset_1

dexOffset_2

dataOffse_2

......

Real_dexCode_1

......

Real_dexCode_N

这里patchCount = 0x401, constOffset = 0x8a8。这两个参数都是固定的，前者表示共有多少个dexCode需要重定位，后者为0x401个使用uleb128编码的dexOffset+ dataOffset所占用的总共字节大小(其实它们真正的大小为0x8a5，不过为了4字节对齐所以填充为0x8a8字节)。第一个dexOffset表示cls.dex中的第一个method的codeOff变量的地址较dexStartAddr的偏移值，之后的dexOffset都是相对于第一个codeOff地址的增量。同理第一个dataOffset表示decrypted_juice中的第一个real_dexCode的地址较decrypted_juice的偏移值，之后的dataOffset都是相对于第一个real_dexCode地址的增量。

其实只要画个内存的草图就很容易理解了。虽然cls.dex与decrypted_juice在内存中并不连续，但由于decrypted_juice中存放的真正有用的信息仅仅是dexCode，所以只要将cls.dex中每个method的codeOff重定向到decrypted_juice中相应的dexCode就可以了。

3 修复

修复的话就很简单了，时间有限，我就不用C重写修复代码了，这里直接贴上那位牛人的python代码(为了方便理解，我做了一点点修改）:

import struct

# return value, length

def readLEB128(data,pos):

length = 0

tp = pos

val = 0

for i in xrange(5):

val |= (data[tp] & 0x7F) << (7*i)

length += 1

if data[tp] & 0x80:

tp += 1

else:

break

return val, length

data = bytearray(open('decrypted_juice','rb').read())

dex = bytearray(open('cls.dex','rb').read())

patch_count, data_offset = struct.unpack('<II',data[:8])

dexlen = len(dex)

pos = 8

dex_off_sumd = 0

data_off_sumd = 0

for i in xrange(patch_count):

dex_off, skip = readLEB128(data, pos)

dex_off_sumd += dex_off

pos += skip

data_off, skip = readLEB128(data, pos)

data_off_sumd += data_off

pos += skip

reloff = dexlen + data_offset  + data_off_sumd

dex[dex_off_sumd] = (reloff & 0x7F) | 0x80

dex[dex_off_sumd+1] = ((reloff>>7)&0x7F) | 0x80

dex[dex_off_sumd+2] = ((reloff>>14)&0x7F) | 0x80

dex[dex_off_sumd+3] = ((reloff>>21)&0x7F) | 0x80

dex[dex_off_sumd+4] = ((reloff>>28)&0x7F)

with open('fixed.dex','wb') as fp:

fp.write(dex)

fp.write(data)

马上使用dex2jar反编译fixed.dex，得到的smali代码如下：

解密成功！

不过，分析smali代码相对来说效率还是比较低的。最好能转换成java。果断使用dex2jar，结果悲剧了：

从上图可以看出android.support.v4.app.qn的testdex2jarcrash方法造成了dex2jar的崩溃。凭直觉，不可能只有这一个testdex2jarcrash方法，找出smali文件中的所有testdex2jarcrash方法，删掉后（最好改为无用函数），重新生成dex文件(这里推荐使用android逆向助手，集成化逆向分析工具，很方便，需要的话大家可以自行百度)。再次使用dex2jar完美编译，然后使用jd-jui打开就可得到java源码了：

鉴于jeb比jd-gui功能更强大，大家可直接将修复后的dex放到jeb进行分析。

至此整个脱壳工作告一段落。剩下的获取登录密码什么的，就交给各位去练手啦。

4 总结

说句实话，要完成此APK的脱壳所需要的技术、知识还是很多的：动态调试，静态分析，熟悉dex文件结构，熟悉Android dex动态加载机制，甚至于了解dex2jar等逆向工具的缺陷等等等等。不过收获自不用说，对dex的加固算是正式入门了`(*∩_∩*)′。

其实我这段时间一直研究的是so的加壳，但此APK并没有使用任何的so加固技术，可能是为了降低比赛难度吧，但还是有一种一拳打到空气上赶脚~算了，等以后有机会，再总结下so的加固技术吧。

---