Dex文件是手机上类似Windows上的EXE文件,dex文件是可以直接在Dalvik虚拟机中加载运行的文件。
首先我们来生成一个Dex文件。
新建文件Hello.java内容如下:
class Hello{
public static void main(String[] argc){
System.out.println(“Hello!”);
}
}
javac Hello.java
dx –dex –output=Hello.dex Hello.class
这样就在当前目录下面生成了一个dex文件。
编译的时候注意Java和Android默认的jdk版本要一致,否则会出错。
Dex总体文件结构图如下:
下面 ,对应到刚刚生成的dex文件来分析:
首先是文件头:
Dex文件头主要包括校验和以及其他结构的偏移地址和长度信息。
为了方便查看,使用010 Editor打开刚刚生成的Dex文件,在官网下载一个Dex模板的脚本,然后运行。
魔数字段:
Dex文件标志符’dex ’ ,它的作用主要是用来标志dex文件的。跟在dex后面的是版本号,目前支持的版本号为035 。
校验码:
主要用来检查这个字段开始到文件结尾,这段数据是否完整。使用zlib 的adler32 所计算的32-bitsCheckSum . 计算的范围为DEX 文件的长度(Header->fileSize) 减去8bytes Magic Code 与4bytes CheckSum 的范围. 用来确保DEX 文件内容没有损毁.
SHA-1签名字段:
dex文件头里,前面已经有了面有一个4字节的检验字段码了,为什么还会有SHA-1签名字段呢?不是重复了吗?可是仔细考虑一下,这样设计自有道理。因 为dex文件一般都不是很小,简单的应用程序都有几十K,这么多数据使用一个4字节的检验码,重复的机率还是有的,也就是说当文件里的数据修改了,还是很 有可能检验不出来的。这时检验码就失去了作用,需要使用更加强大的检验码,这就是SHA-1。SHA-1校验码有20个字节,比前面的检验码多了16个字 节,几乎不会不同的文件计算出来的检验是一样的。设计两个检验码的目的,就是先使用第一个检验码进行快速检查,这样可以先把简单出错的dex文件丢掉了, 接着再使用第二个复杂的检验码进行复杂计算,验证文件是否完整,这样确保执行的文件完整和安全。
file_size:
文件的总大小
header_size:
DexHeader的大小,0x70bytes。
endian_tag:
预设值为Little-Endian, 在这栏位会显示32bits 值”0×12345678。
在Big-Endian 处理器上, 会转为“ 0×78563412。
是link_size和link_off字段,主要用在文件的静态链接上,该dex不是静态链接文件,所有为0。
map_off字段:
这个字段主要保存map开始位置,就是从文件头开始到map数据的长度,通过这个索引就可以找到map数据。
map数据排列结构定义如下:
/* *Direct-mapped "map_list". */ typedef struct DexMapList { u4 size; /* #of entries inlist */ DexMapItem list[1]; /* entries */ }DexMapList;
每一个map项的结构定义如下:
/* *Direct-mapped "map_item". */ typedef struct DexMapItem { u2 type; /* type code (seekDexType* above) */ u2 unused; u4 size; /* count of items ofthe indicated type */ u4 offset; /* file offset tothe start of data */ }DexMapItem;
DexMapItem结构定义每一项的数据意义:类型、类型个数、类型开始位置。
其中的类型定义如下:
/*map item type codes */ enum{ kDexTypeHeaderItem = 0x0000, kDexTypeStringIdItem = 0x0001, kDexTypeTypeIdItem = 0x0002, kDexTypeProtoIdItem = 0x0003, kDexTypeFieldIdItem = 0x0004, kDexTypeMethodIdItem = 0x0005, kDexTypeClassDefItem = 0x0006, kDexTypeMapList = 0x1000, kDexTypeTypeList = 0x1001, kDexTypeAnnotationSetRefList = 0x1002, kDexTypeAnnotationSetItem = 0x1003, kDexTypeClassDataItem = 0x2000, kDexTypeCodeItem = 0x2001, kDexTypeStringDataItem = 0x2002, kDexTypeDebugInfoItem = 0x2003, kDexTypeAnnotationItem = 0x2004, kDexTypeEncodedArrayItem = 0x2005, kDexTypeAnnotationsDirectoryItem = 0x2006, };
从上面的类型可知,它包括了在dex文件里可能出现的所有类型。可以看出这里的类型与文件头里定义的类型有很多是一样的,这里的类型其实就是文件头里定义 的类型。其实这个map的数据,就是头里类型的重复,完全是为了检验作用而存在的。当Android系统加载dex文件时,如果比较文件头类型个数与 map里类型不一致时,就会停止使用这个dex文件。
该dex文件的map_off = 0x24c,而便宜为0x24c的位置值为0x00d。也就是有13项!每项12个字节,所以整个map_list所占空间为12*13+4 = 160 = 0x00a0,范围为0x24c – 0x2ec.也就是到文件结尾的位置。
string_ids_size/off字段:
这两个字段主要用来标识字符串资源。源程序编译后,程序里用到的字符串都保存在这个数据段里,以便解释执行这个dex文件使用。其中包括调用库函数里的类名称描述,用于输出显示的字符串等。
string_ids_size标识了有多少个字符串,string_ids_off标识字符串数据区的开始位置。字符串的存储结构如下:
/* * Direct-mapped "string_id_item". */ typedef struct DexStringId { u4 stringDataOff; /* file offset to string_data_item */ } DexStringId;
可以看出这个数据区保存的只是字符串表的地址索引。如果要找到字符串的实际数据,还需要通过个地址索引找到文件的相应开始位置,然后才能得到字符串数据。 每一个字符串项的索引占用4个字节,因此这个数据区的大小就为4*string_ids_size。实际数据区中的字符串采用UTF8格式保存。
上面我们看到size为0×10,off为0×70。 也就是有16个字符串,每个索引占4个字节,也就是从0×70开始的16*4=64个字节是字符串的索引。
来到0×70处,看到第一个索引为0x17E,来到0x17E处。
16进制显示出来内容如下:
063c 696e 6974 3e00
其实际数据则是”<init>