APK加固之类抽取分析与修复

转载地址：http://mp.weixin.qq.com/s?__biz=MjM5NzAxMzk4NA==&mid=210073533&idx=1&sn=93f458546a4631e0d6633564f0d5b3c9&scene=0&key=949503d320dbced03c3805aea6a657b1e4ac0e3e85d082f52f17c67a980d7df749837be99b2025e75c000e2bf827681a&ascene=0&uin=MTY1NjQ5MjM0MA%3D%3D&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.10.1+build(14B25)&version=11020201&pass_ticket=eHSlFVpR5TFuMX3QcDGHw0eWqA82PkE4v9YLuY%2BaCuO8BGUM%2BwBR5hXkGqn8mm3%2F

注：由于篇幅有限，文章中部分代码有删减，具体请点击左下角原文链接查看。

测试环境与工具

手机系统: 华为U9508 android 4.2.2

IDA Pro 6.8

AndroidKiller 1.2

高手不要见笑，仅供小菜玩乐,有不对或不足的地方还请多多指教，不胜感激!

0x00 简单介绍

目前我己知的APK加固主要有以下两种方式（或有其它的方式有待发现）

隐藏dex文件：通过对目标DEX文件进行整体加密或压缩方式把整个dex转换为另外一个文件存放在assets文件夹中或者其它地方，然后利用类加载器技术进行内存解密并加载运行。

修改dex结构：抽取DexCode中的字节码指令后用零去填充，或者修改方法属性等操作，运行时在内存中做修正、修复等处理工作。

0x01 APK加固前后对比

整体来看一下原始APK包和加固后的APK包结构相关变化



图1

图1所示加固后的APK包变化如下:

新增2个文件夹：

assets文件夹中增加3个文件

data

dx

pk

lib文件夹中增加了2个so文件

libedog.so

libfdog.so

被修改的文件:

AndroidManifest.xml

classes.dex

0x02 壳流程分析

我们用AndroidKiller反编译加固后的APK, 反编译出错，错误日志如下:

图2

从图2可以看出反编译时出现了很多错误，我们用IDA对DEX进行反编译查看代码，发现方法指令都被零填充了，反编译后代码显示为nop样式，如图3所示。

图3

我们再来看看APK中的AndroidManifest.xml文件被修改了什么地方？

图4

从图4看到AndroidManifest.xml中的application新增了如下项做为壳的入口

android:name="com.edog.AppWrapper"该类为壳的入口，继续分析AppWrapper都做了些什么？

图5

图6

图7

从图5-7可以看出最终会调用到libedog.so中的dl函数，下面就开始动态调试分析该so的功能流程（如何动态调试就不说了，网上己经有很多的教程了）。

通过动态分析libedog.so中的dl函数主要功能是: 获得系统版本号->验证加固前后的签名是否一致->反调试->将抽走的指令映射到内存中还原指令时用到->HOOK函数dvmResolveClass->结束。

代码流程如下：

libedog.so:5D692C64
20 1C MOVS R0, R4

libedog.so:5D692C66 01 99 LDR R1, [SP,#0xF0+var_EC]

libedog.so:5D692C68 00 F0 8A FC BL _Z6verifyP7_JNIEnvP8_jobject ; 比较加固前后的签名是否一致

libedog.so:5D692C6C 16 49 LDR R1, =(aDataDataSLibLi - 0x5D692C76)

libedog.so:5D692C6E 2A 68 LDR R2, [R5]

libedog.so:5D692C70 03 A8 ADD R0, SP, #0xF0+var_E4

libedog.so:5D692C72 79 44 ADD R1, PC ; "/data/data/%s/lib/libfdog.so"

libedog.so:5D692C74 FF F7 B0 EE BLX sprintf

libedog.so:5D692C78 03 A8 ADD R0, SP, #0xF0+var_E4

libedog.so:5D692C7A 01 1C MOVS R1, R0

libedog.so:5D692C7C 00 F0 02 FD BL _Z4antiPKcS0_ ; 反调试

libedog.so:5D692C80 00 F0 3E F9 BL _Z10openMemoryv ; 将抽走的指令映射到内存中来

libedog.so:5D692C80 ; assets中的data文件

libedog.so:5D692C84 23 68 LDR R3, [R4]

libedog.so:5D692C86 A9 22 92 00 MOVS R2, #0x2A4

libedog.so:5D692C8A 9B 58 LDR R3, [R3,R2]

libedog.so:5D692C8C 00 99 LDR R1, [SP,#0xF0+var_F0]

libedog.so:5D692C8E 20 1C MOVS R0, R4

libedog.so:5D692C90 00 22 MOVS R2, #0

libedog.so:5D692C92 98 47 BLX R3

libedog.so:5D692C94 0D 49 LDR R1, =(unk_5D6A2A0D - 0x5D692C9A)

libedog.so:5D692C96 79 44 ADD R1, PC

libedog.so:5D692C98 FF F7 A4 EE BLX strstr

libedog.so:5D692C9C 00 28 CMP R0, #0

libedog.so:5D692C9E 02 D1 BNE loc_5D692CA6

libedog.so:5D692CA0 33 68 LDR R3, [R6]

libedog.so:5D692CA2 14 2B CMP R3, #0x14 ; 判断版本

libedog.so:5D692CA4 00 DD BLE loc_5D692CA8 ; 根据操作系统的版本

libedog.so:5D692CA4 ; hook对应的dvmResolveClass函数

libedog.so:5D692CA6

libedog.so:5D692CA6 loc_5D692CA6 ; CODE XREF: Java_com_edog_ELibrary_d1+86j

libedog.so:5D692CA6 01 20 MOVS R0, #1

libedog.so:5D692CA8

libedog.so:5D692CA8 loc_5D692CA8 ; CODE XREF: Java_com_edog_ELibrary_d1+8Cj

libedog.so:5D692CA8 00 F0 E8 FB BL _Z7restorei ; 根据操作系统的版本

libedog.so:5D692CA8 ; hook对应的dvmResolveClass函数

libedog.so:5D692CAC 35 9A LDR R2, [SP,#0xF0+var_1C]

libedog.so:5D692CAE 3B 68 LDR R3, [R7]

libedog.so:5D692CB0 9A 42 CMP R2, R3

libedog.so:5D692CB2 01 D0 BEQ loc_5D692CB8

libedog.so:5D692CB4 FF F7 9C EE BLX sub_5D6929F0

libedog.so:5D692CB8 ; ---------------------------------------------------------------------------

libedog.so:5D692CB8

libedog.so:5D692CB8 loc_5D692CB8 ; CODE XREF: Java_com_edog_ELibrary_d1+9Aj

libedog.so:5D692CB8 37 B0 ADD SP, SP, #0xDC

libedog.so:5D692CBA F0 BD POP {R4-R7,PC}

libedog.so:5D692CBA ; End of function Java_com_edog_ELibrary_d1

libedog.so:5D692CBA

libedog.so:5D692CBA ; -------------------------------------

0x03 指令还原算法分析

原始指令还原时机就是在dvmResolveClass的hook函数中对对指令进行解密还原，以下结构的中的几个值会用到，因为被保护后的方法中的debugInfoOff的值被修改成从0x20000000开始的一个值，该值在指令还原时起到重要作用。

struct DexCode {

u2 registersSize;

u2 insSize;

u2 outsSize;

u2 triesSize;

u4 debugInfoOff; /* file offset to debug info stream */

u4 insnsSize; /* size of the insns array, in u2 units */

u2 insns[1];

};

指令还原大致流程如下：

判断是否为保护的类->判断debuginfo值大于0x1FFFFFFF->将debuginfo值左移8位再右移6位->将移位后的值加上加密指令在内存中的开始址取4字节做为偏移->将偏移加上加密指令在内存中的开始地址定位到对应方法的指令->解密指令并还原->清零debuginfo值->结束。

解密指令算法流程如下：(每4字节进行xor)

XorArray函数中进行解密操作->将方法debuginfo值进行crc32计算得到一个值->crc32计算得到的值与指令每4字节进行xor->4字节结束后再将crc32值用PolyXorKey函数生成一个新的4字节数做为密钥,一直循环到解密完成。

代码流程如下

libedog.so:5D693174
25 4B LDR R3, =0x1FFFFFFF

libedog.so:5D693176 02 9A LDR R2, [SP,#0x38+Debug_info]

libedog.so:5D693178 9A 42 CMP R2, R3 ; 判断debuginfo值大于 0x1FFFFFFF (因为被保护的方法debuginfo从0X20000000开始)

libedog.so:5D69317A 44 D9 BLS loc_5D693206

libedog.so:5D69317C 24 49 LDR R1, =(aLandroid - 0x5D693184)

libedog.so:5D69317E 20 1C MOVS R0, R4

libedog.so:5D693180 79 44 ADD R1, PC ; "Landroid/"

libedog.so:5D693182 FF F7 30 EC BLX strstr ; 是系统的类就跳过

libedog.so:5D693186 00 28 CMP R0, #0

libedog.so:5D693188 3D D1 BNE loc_5D693206

libedog.so:5D69318A 36 78 LDRB R6, [R6]

libedog.so:5D69318C 01 96 STR R6, [SP,#0x38+var_34]

libedog.so:5D69318E 00 2E CMP R6, #0

libedog.so:5D693190 39 D1 BNE loc_5D693206

libedog.so:5D693192 20 4B LDR R3, =(aFjFj0fjFjFj4fj+0xC - 0x5D69319C)

0x04 编写修复程序

修复程序主要分为解析dex与解密两个步骤来完成，这里只贴出部分代码详细的请看工程，代码写得比较粗操，看下思路就行了，有性趣的就慢慢撸吧！

void
fixdexClassData()

{

DexFile *dexFile = &gDexFile;

char * Tag = "L";

char * ClassTag = "Landroid/";

const DexClassDef* classdef;

u4 count = dexFile->pHeader->classDefsSize;

printf("该DEX共有%d 个类\n", count);

const u1* pEncodedData = NULL;

DexClassData* pClassData = NULL;

const char *descriptor = NULL;

int FileSize = file_size();

gCodeData = (u1*)malloc(FileSize);

if (NULL == gCodeData)

{

printf("分配内存失败！\n");

return;

}

memset(gCodeData, 0, FileSize);

//获得加密指令数据

GetCodeData(gCodeData, FileSize);

if (NULL == gCodeData)

{

printf("获取加密指令数据出错！\n");

return;

}

for(u4 i=0; i<count; i++){

classdef = dexGetClassDef(dexFile, i);

descriptor = getTpyeIdString(dexFile, classdef->classIdx);

if (strstr(descriptor,Tag) == NULL)

{

continue;

}

//跳过一些系统的类

if (strstr(descriptor, ClassTag) != NULL)

{

continue;

}

pEncodedData = dexFile->baseAddr + classdef->classDataOff;

pClassData = dexReadAndVerifyClassData(&pEncodedData, NULL);

if (pClassData == NULL) {

continue;

}

FixdexMethodInsns(dexFile, pClassData, descriptor);

}

}

void FixdexMethodInsns(DexFile *dexFile, const DexClassData*classData
,const char* className)

{

int idx = 0;

DexMethod *method = NULL;

const DexMethodId* methodId = NULL;

DexCode* code = NULL;

const char* methodName;

method = classData->directMethods;

methodId = dexFile->pMethodIds;

unsigned int CodeDataOffset = 0;

u1 * tempCode = NULL;

for (int i = 0; i < (int) classData->header.directMethodsSize; i++)
{

idx = classData->directMethods[i].methodIdx;

methodId = dexGetMethodId(dexFile, idx);

methodName = dexStringById(dexFile, methodId->nameIdx);

DexCode* pCode = dexGetCode(dexFile, &classData->directMethods[i]);

if (NULL == pCode)

{

continue;

}

//判断是否为保护后的方法，如果是就修复指令

if ( (pCode->debugInfoOff > 0x1FFFFFFF) && (pCode->insns[0] == 0X00))

{

//求加密指令的偏移

CodeDataOffset = pCode->debugInfoOff << 0x8;

CodeDataOffset >>= 0x6;

//解密指令

tempCode = DecCode(gCodeData+CodeDataOffset, pCode->insnsSize*sizeof(u2),
pCode->debugInfoOff, gCodeData);

//修复指令

memcpy(pCode->insns, tempCode, (pCode->insnsSize)*sizeof(u2));

pCode->debugInfoOff = 0x00;

printf("修复%s 类中的%s 方法成功! 大小%X\n",className, methodName,pCode->insnsSize);

if (NULL != tempCode)

{

free(tempCode);

tempCode = NULL;

}

}

}

for (int i = 0; i < (int) classData->header.virtualMethodsSize; i++)
{

idx = classData->virtualMethods[i].methodIdx;

methodId = dexGetMethodId(dexFile, idx);

methodName = dexStringById(dexFile, methodId->nameIdx);

DexCode* pCode = dexGetCode(dexFile, &classData->virtualMethods[i]);

if (NULL == pCode)

{

continue;

}

//判断是否为保护后的方法，如果是就修复指令

if ( (pCode->debugInfoOff > 0x1FFFFFFF) && (pCode->insns[0] == 0X00))

{

//求加密指令的偏移

CodeDataOffset = pCode->debugInfoOff << 0x8;

CodeDataOffset >>= 0x6;

//解密指令

tempCode = DecCode(gCodeData+CodeDataOffset, pCode->insnsSize*sizeof(u2),
pCode->debugInfoOff, gCodeData);

//修复指令

memcpy(pCode->insns, tempCode, (pCode->insnsSize)*sizeof(u2));

pCode->debugInfoOff = 0x00;

printf("修复%s 类中的%s 方法成功! 大小%X\n",className, methodName,pCode->insnsSize);

if (NULL != tempCode)

{

free(tempCode);

tempCode = NULL;

}

}

}

return;

}

unsigned int PolyXorKey(DWORD crckey)

{

unsigned int dwKey;

char temp;

unsigned __int8 temp1;

unsigned __int8 temp2;

char *pKey;

int temp3;

int j;

int i;

j = 0;

temp3 = 0;

pKey = (char *)&dwKey;

temp2 = 0;

temp1 = 0;

temp = 0;

dwKey = crckey ^ 0xDF138530;

i = 0;

while ( i <= 3 )

{

temp2 = *pKey;

j = 128;

temp3 = 7;

while ( j > 1 )

{

temp = (temp2 & j / 2) >> (temp3 - 1);

temp1 = ((signed int)(unsigned __int8)(temp2 & j) >> temp3) ^ temp;

temp1 <<= temp3;

temp2 |= temp1;

j /= 2;

--temp3;

}

temp = temp2 & 1;

temp1 = temp2 & 1 ^ temp2 & 1;

*pKey = temp2;

++i;

++pKey;

}

return dwKey;

}

0x05 测试与总结

将加固后的 APK中assets文件夹中的data文件与classes.dex放在修复程序同一个目录中，然后运行修复程序。



图8

去掉AndroidManifest.xml中的壳入口，将修复后的classes.dex重新打包反编译，成功运行，如图9所示能正常反编译源码，至此，分析完毕。


壳流程总结:

AndroidManifest.xml中的壳入口->com.edog.AppWrapper->

so中Java_com_edog_ELibrary_d1->hookdvmResolveClass函数->在dvmResolveClass
hook函数中修复指令->结束。

语言表达不行,说的很杂，自己都觉得文章没有任何逻辑可言，如果大家能从中获得一些思路那也是好的, 不过这次分析让自己学到了很多，感谢APK加固作者。