Dex文件和Dalvik虚拟机
在Android系统中,dex文件是可以直接在Dalvik虚拟机中加载运行的文件。通过ADT,经过复杂的编译,可以把java源代码转换为dex文 件。 那么这个文件的格式是什么样的呢?为什么Android不直接使用class文件,而采用这个不一样文件呢?其实它是针对嵌入式系统优化的结 果,Dalvik虚拟机的指令码并不是标准的Java虚拟机指令码,而是使用了自己独有的一套指令集。如果有自己的编译系统,可以不生成class文件, 直接生成dex文件。dex文件中共用了很多类名称、常量字符串,使它的体积比较小,运行效率也比较高。但归根到底,Dalvik还是基于寄存器的虚拟机 的一个实现。
文件头(File Header)
Dex文件头主要包括校验和以及其他结构的偏移地址和长度信息。
magic | 0x0 | 8 | 'Magic'值,即魔数字段,格式如”dex/n035/0”,其中的035表示结构的版本。 |
checksum | 0x8 | 4 | 校验码。 |
signature | 0xC | 20 | SHA-1签名。 |
file_size | 0x20 | 4 | Dex文件的总长度。 |
header_size | 0x24 | 4 | 文件头长度,009版本=0x5C,035版本=0x70。 |
endian_tag | 0x28 | 4 | 标识字节顺序的常量,根据这个常量可以判断文件是否交换了字节顺序,缺省情况下=0x78563412。 |
link_size | 0x2C | 4 | 连接段的大小,如果为0就表示是静态连接。 |
link_off | 0x30 | 4 | 连接段的开始位置,从本文件头开始算起。如果连接段的大小为0,这里也是0。 |
map_off | 0x34 | 4 | map数据基地址。 |
string_ids_size | 0x38 | 4 | 字符串列表的字符串个数。 |
string_ids_off | 0x3C | 4 | 字符串列表表基地址。 |
type_ids_size | 0x40 | 4 | 类型列表里类型个数。 |
type_ids_off | 0x44 | 4 | 类型列表基地址。 |
proto_ids_size | 0x48 | 4 | 原型列表里原型个数。 |
proto_ids_off | 0x4C | 4 | 原型列表基地址。 |
field_ids_size | 0x50 | 4 | 字段列表里字段个数。 |
field_ids_off | 0x54 | 4 | 字段列表基地址。 |
method_ids_size | 0x58 | 4 | 方法列表里方法个数。 |
method_ids_off | 0x5C | 4 | 方法列表基地址。 |
class_defs_size | 0x60 | 4 | 类定义类表中类的个数。 |
class_defs_off | 0x64 | 4 | 类定义列表基地址。 |
data_size | 0x68 | 4 | 数据段的大小,必须以4字节对齐。 |
data_off | 0x6C | 4 | 数据段基地址 |
魔数字段
魔数字段,主要就是Dex文件的标识符,它占用4个字节,在目前的源码里是 “dex\n”,它的作用主要是用来标识dex文件的,比如有一个文件也以dex为后缀名,仅此并不会被认为是Davlik虚拟机运行的文件,还要判断这 四个字节。另外Davlik虚拟机也有优化的Dex,也是通过个字段来区分的,当它是优化的Dex文件时,它的值就变成”dey\n”了。根据这四个字 节,就可以识别不同类型的Dex文件了。
跟在“dex\n”后面的是版本字段,主要用来标识Dex文件的版本。目前支持的版本号为“035\0”,不管是否优化的版本,都是使用这个版本号。
检验码字段
主要用来检查从这个字段开始到文件结尾,这段数据是否完整,有没有人修改过,或者传送过程中是否有出错等等。通常用来检查数据是否完整的算法,有 CRC32、有SHA128等,但这里采用并不是这两类,而采用一个比较特别的算法,叫做adler32,这是在开源zlib里常用的算法,用来检查文件 是否完整性。该算法由MarkAdler发明,其可靠程度跟CRC32差不多,不过还是弱一点点,但它有一个很好的优点,就是使用软件来计算检验码时比较 CRC32要快很多。可见Android系统,就算法上就已经为移动设备进行优化了。
Adler32算法的C源码如下(Java中可使用java.util.zip.Adler32类做校验操作):
#define ZLIB_INTERNAL #include "zlib.h" #define BASE 65521UL /* largest prime smaller than 65536 */ #define NMAX 5552 /*NMAX is the largest n such that 255n(n+1)/2 + (n+1)(BASE-1) <=2^32-1 */ #define DO1(buf,i){adler += (buf)[i]; sum2 += adler;} #define DO2(buf,i) DO1(buf,i); DO1(buf,i+1); #define DO4(buf,i) DO2(buf,i); DO2(buf,i+2); #define DO8(buf,i) DO4(buf,i); DO4(buf,i+4); #define DO16(buf) DO8(buf,0); DO8(buf,8); /*use NO_DIVIDE if your processor does not do division in hardware */ #ifdef NO_DIVIDE #define MOD(a) \ do{ \ if(a >= (BASE << 16)) a -= (BASE << 16); \ if(a >= (BASE << 15)) a -= (BASE << 15); \ if(a >= (BASE << 14)) a -= (BASE << 14); \ if(a >= (BASE << 13)) a -= (BASE << 13); \ if(a >= (BASE << 12)) a -= (BASE << 12); \ if(a >= (BASE << 11)) a -= (BASE << 11); \ if(a >= (BASE << 10)) a -= (BASE << 10); \ if(a >= (BASE << 9)) a -= (BASE << 9); \ if(a >= (BASE << 8)) a -= (BASE << 8); \ if(a >= (BASE << 7)) a -= (BASE << 7); \ if(a >= (BASE << 6)) a -= (BASE << 6); \ if(a >= (BASE << 5)) a -= (BASE << 5); \ if(a >= (BASE << 4)) a -= (BASE << 4); \ if(a >= (BASE << 3)) a -= (BASE << 3); \ if(a >= (BASE << 2)) a -= (BASE << 2); \ if(a >= (BASE << 1)) a -= (BASE << 1); \ if(a >= BASE) a -= BASE; \ }while (0) # define MOD4(a) \ do{ \ if(a >= (BASE << 4)) a -= (BASE << 4); \ if(a >= (BASE << 3)) a -= (BASE << 3); \ if(a >= (BASE << 2)) a -= (BASE << 2); \ if(a >= (BASE << 1)) a -= (BASE << 1); \ if(a >= BASE) a -= BASE; \ }while (0) #else #define MOD(a) a %= BASE #define MOD4(a) a %= BASE #endif /*=========================================================================*/ uLong ZEXPORT adler32(adler, buf, len) uLong adler; const Bytef *buf; uInt len; { unsigned long sum2; unsigned n; /*split Adler-32 into component sums */ sum2= (adler >> 16) & 0xffff; adler&= 0xffff; /*in case user likes doing a byte at a time, keep it fast */ if(len == 1) { adler+= buf[0]; if(adler >= BASE)adler-= BASE; sum2+= adler; if(sum2 >= BASE)sum2-= BASE; return adler|(sum2 << 16); } /*initial Adler-32 value (deferred check for len == 1 speed) */ if(buf == Z_NULL)return 1L; /*in case short lengths are provided, keep it somewhat fast */ if(len < 16) { while(len--) { adler+= *buf++; sum2+= adler; } if(adler >= BASE) adler-= BASE; MOD4(sum2); /* only added so many BASE's */ return adler|(sum2 << 16); } /*do length NMAX blocks -- requires just one modulo operation */ while(len >= NMAX) { len-= NMAX; n= NMAX/16; /* NMAX is divisible by 16 */ do{ DO16(buf); /* 16 sums unrolled */ buf+= 16; }while (--n); MOD(adler); MOD(sum2); } /*do remaining bytes (less than NMAX, still just one modulo) */ if(len) { /* avoid modulos if none remaining */ while(len >= 16) { len-= 16; DO16(buf); buf+= 16; } while(len--) { adler+= *buf++; sum2+= adler; } MOD(adler); MOD(sum2); } /*return recombined sums */ return adler|(sum2 << 16); }
SHA-1签名字段
dex文件头里,前面已经有了面有一个4字节的检验字段码了,为什么还会有SHA-1签名字段呢?不是重复了吗?可是仔细考虑一下,这样设计自有道理。因 为dex文件一般都不是很小,简单的应用程序都有几十K,这么多数据使用一个4字节的检验码,重复的机率还是有的,也就是说当文件里的数据修改了,还是很 有可能检验不出来的。这时检验码就失去了作用,需要使用更加强大的检验码,这就是SHA-1。SHA-1校验码有20个字节,比前面的检验码多了16个字 节,几乎不会不同的文件计算出来的检验是一样的。设计两个检验码的目的,就是先使用第一个检验码进行快速检查,这样可以先把简单出错的dex文件丢掉了, 接着再使用第二个复杂的检验码进行复杂计算,验证文件是否完整,这样确保执行的文件完整和安全。
SHA(Secure Hash Algorithm, 安全散列算法)是美国国家安全局设计,美国国家标准与技术研究院发布的一系列密码散列函数。SHA-1看起来和MD5算法很像,也许是Ron Rivest在SHA-1的设计中起了一定的作用。SHA-1的内部比MD5更强,其摘要比MD5的16字节长4个字节,这个算法成功经受了密码分析专家 的攻击,也因而受到密码学界的广泛推崇。这个算法在目前网络上的签名,BT软件里就有大量使用,比如在BT里要计算是否同一个种子时,就是利用文件的签名 来判断的。同一份8G的电影从几千BT用户那里下载,也不会出现错误的数据,导致电影不播放。
map_off字段
这个字段主要保存map开始位置,就是从文件头开始到map数据的长度,通过这个索引就可以找到map数据。map的数据结构如下:
size | 4字节 | map里项的个数 |
list | 变长 | 每一项定义为12字节,项的个数由上面项大小决定。 |
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文件。
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格式保存。
例如,如果dex文件使用16进制显示出来内容如下:
063c 696e 6974 3e00
其实际数据则是”<init>\0”
另外这段数据中不仅包括字符串的字符串的内容和结束标志,在最开头的位置还标明了字符串的长度。上例中第一个字节06就是表示这个字符串有6个字符。
关于字符串的长度有两点需要注意的地方:
1、关于长度的编码格式
dex文件里采用了变长方式表示字符串长度。一个字符串的长度可能是一个字节(小于256)或者4个字节(1G大小以上)。字符串的长度大多数都是小于 256个字节,因此需要使用一种编码,既可以表示一个字节的长度,也可以表示4个字节的长度,并且1个字节的长度占绝大多数。能满足这种表示的编码方式有 很多,但dex文件里采用的是uleb128方式。leb128编码是一种变长编码,每个字节采用7位来表达原来的数据,最高位用来表示是否有后继字节。
它的编码算法如下:
/* * Writes a 32-bit value in unsigned ULEB128 format. * Returns the updated pointer. */ DEX_INLINE u1* writeUnsignedLeb128(u1* ptr, u4 data) { while (true) { u1 out = data & 0x7f; if (out != data) { *ptr++ = out | 0x80; data >>= 7; } else { *ptr++ = out; break; } } return ptr; }
它的解码算法如下:
/* * Reads an unsigned LEB128 value, updating the given pointer to point * just past the end of the read value. This function tolerates * non-zero high-order bits in the fifth encoded byte. */ DEX_INLINE int readUnsignedLeb128(const u1** pStream) { const u1* ptr = *pStream; int result = *(ptr++); if (result > 0x7f) { int cur = *(ptr++); result = (result & 0x7f) | ((cur & 0x7f) << 7); if (cur > 0x7f) { cur = *(ptr++); result |= (cur & 0x7f) << 14; if (cur > 0x7f) { cur = *(ptr++); result |= (cur & 0x7f) << 21; if (cur > 0x7f) { /* * Note: We don't check to see if cur is out of * range here, meaning we tolerate garbage in the * high four-order bits. */ cur = *(ptr++); result |= cur << 28; } } } } *pStream = ptr; return result; }
根据上面的算法分析上面例子字符串,取得第一个字节是06,最高位为0,因此没有后继字节,那么取出这个字节里7位有效数据,就是6,也就是说这个字符串是6个字节,但不包括结束字符“\0”。
2、关于长度的意义
由于字符串内容采用的是UTF-8格式编码,表示一个字符的字节数是不定的。即有时是一个字节表示一个字符,有时是两个、三个甚至四个字节表示一个字符。 而这里的长度代表的并不是整个字符串所占用的字节数,表示这个字符串包含的字符个数。所以在读取时需要注意,尤其是在包含中文字符时,往往会因为读取的长 度不正确导致字符串被截断。
关于计算UTF-8字符串的长度,可参见字符编码知识-UTF8编码规则
相关推荐
二、Dex文件结构 1. 头部:Dex文件的开头是固定大小的头部,包含了文件的基本信息,如文件版本、字符串索引表、类型索引表、字段索引表等的位置和大小。 2. 字符串索引表:存储所有字符串常量,通过一个16位的索引值...
Dex文件头结构是理解Dex文件内容的关键,它包含了关于整个Dex文件布局和元数据的信息。下面我们将深入探讨Dex文件头结构的解析。 Dex文件的结构基于固定大小的4字节(32位)块,这是因为Android系统是基于Little ...
一、DEX文件结构 1. **头部**:DEX文件的开头部分包含了一个头部结构,提供了文件的基本信息,如文件版本、字符串表、类型列表等的偏移量和大小,便于解析器快速定位关键数据。 2. **字符串表**:存储了所有字符串...
### 安卓反编译dex文件格式实例分析 #### 第一部分:创造一个可供分析的Hello.dex ##### 测试环境 为了进行本次实验,我们...通过以上步骤,我们可以全面了解Dex文件的结构以及它是如何在Android环境中被执行的。
#### 1.2 DEX文件结构 一个典型的DEX文件包括: - **头文件**:存储了DEX文件的基本信息,如魔数、版本号等。 - **字符串池**:包含了DEX文件中的所有字符串常量。 - **类型池**:定义了DEX文件中的所有类和接口。 -...
在Java中解析.dex文件是一项技术挑战,因为这涉及到理解Dalvik字节码和相关的文件结构。本篇将深入探讨如何进行这项工作。 首先,我们需要了解.dex文件的基本结构。一个.dex文件主要由以下几个部分组成: 1. **...
### DEX文件结构解析 #### 一、概述 在Android平台中,Dalvik虚拟机是负责执行应用程序的主要组件之一。为了使Java程序能在Dalvik虚拟机上运行,必须将其编译后的字节码(通常为.class文件)转换为Dalvik可执行...
#### 二、DEX文件结构 DEX文件由一系列的结构体组成,包括但不限于: - **魔数(Magic Number)**:用于标识文件类型,DEX文件的魔数通常是“dex\n035\033”。 - **版本号(Version)**:表示DEX文件格式的版本。 ...
“dex2jar”是一个开源项目,它的主要作用是将Android应用中的.dex文件转换成Java虚拟机(JVM)可识别的.jar文件。这使得开发者可以利用Java反编译工具,如JD-GUI或ProGuard,来查看原始的Java源代码,尽管这种反...
4. **dex转jar**:当需要查看或编辑Dex文件中的Java类时,可以使用dex2jar工具将其转换回.jar文件,然后用Java反编译器(如JD-GUI或 FernFlower)查看源代码。 5. **xml转txt**:对于APK中的XML资源,可以转换成纯...
4. **jar转dex**:与dex2jar相对应,也需要将.jar文件转换为.dex文件,以便在Android设备上运行。这个过程通常发生在APK打包过程中,通过Android的dx工具或者后来的dx替代品,即D8或R8,将.jar文件转换成.dex文件。 ...
4. **资源打包**:使用Apktool或其他类似工具,将修改后的资源文件和Dex文件打包回APK结构。 5. **签名和优化**:APK在安装前需要签名,以验证开发者身份。此外,使用zipalign进行优化,以确保文件对齐,提升性能。...
Dex文件的结构并不直接暴露字符串,它们被存储在一个字符串池中,需要通过解析Dex文件的头部信息和偏移量来获取。这个过程通常涉及到对Dex文件格式的深入理解,包括文件头、字符串索引表、类型列表等各个部分。...
- **APK文件结构**:APK文件本质上是一个ZIP格式的文件,其后缀被修改为.apk。通过解压缩APK文件,可以看到内部包含以下几个主要组成部分: - **META-INF/**:类似于Java JAR文件中常见的META-INF目录,用于存放...
然而,在进行反编译、调试或分析Android应用时,开发者往往需要将.dex文件转换为更易于理解和处理的Java字节码形式,这就是dex2jar工具的核心功能。 dex2jar工具集包括多个子工具,每个都有特定的任务。例如,`d2j-...
1. 创建一个包含所有`.smali`文件的目录结构,这个结构应该模仿原始`.dex`文件的内部结构。 2. 在这个结构完整的情况下,使用`smali`将Smali代码编译回`.dex`: ```bash java -jar smali-1.4.0.jar assemble ...
Java中的Dex文件是Dalvik虚拟机执行的字节码格式,主要用于Android应用程序。当我们谈论“java实现dex文件方法字节码隐藏”时,我们实际上是在讨论如何在Android应用的编译或打包过程中,对特定的方法进行混淆或者...
转换过程通常包括解析.dex文件结构,提取类信息,并生成对应的.class文件,最后封装到.jar档案中。 使用此类工具的一般步骤如下: 1. **下载和安装工具**:你需要找到一个可靠的“dex转jar工具”,如dex2jar或...
DEX文件是Android应用(APK)中的核心部分,它包含了应用程序的所有类和方法。而JAR文件则是Java程序的标准打包形式,通常用于方便的反编译和分析。 ### 1. DEX与JAR的区别 - **DEX文件**:Dalvik Executable格式...
分析Dex文件的结构时,可以发现它由多个部分组成,包括文件头(header)、字符串表(string_ids)、类型表(type_ids)、原型表(proto_ids)、字段表(field_ids)、方法表(method_ids)和类定义表(class_defs)...