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\n’ ,它的作用主要是用來標志dex文件的。跟在dex后面的是版本號，目前支持的版本號為035\0 。
校驗碼：
主要用來檢查這個字段開始到文件結尾，這段數據是否完整。使用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>\0”
另外這段數據中不僅包括字符串的字符串的內容和結束標志，在最開頭的位置還標明了字符串的長度。上例中第一個字節06就是表示這個字符串有6個字符。
關於字符串的長度有兩點需要注意的地方：
1、關於長度的編碼格式
dex文件里采用了變長方式表示字符串長度。一個字符串的長度可能是一個字節（小於256）或者4個字節（1G大小以上）。字符串的長度大多數都是小於 256個字節，因此需要使用一種編碼，既可以表示一個字節的長度，也可以表示4個字節的長度，並且1個字節的長度占絕大多數。能滿足這種表示的編碼方式有很多，但dex文件里采用的是uleb128方式。leb128編碼是一種變長編碼，每個字節采用７位來表達原來的數據，最高位用來表示是否有后繼字節。若第一個 Byte 的最高位為 1 ，則表示還需要下一個 Byte 來描述 ，直至最后一個 Byte 的最高位為 0 。每個 Byte 的其余 Bit 用來表示數據 ，如下表所示 。
它的編碼算法如下：
/*
* 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格式編碼，表示一個字符的字節數是不定的。即有時是一個字節表示一個字符，有時是兩個、三個甚至四個字節表示一個字符。 而這里的長度代表的並不是整個字符串所占用的字節數，表示這個字符串包含的字符個數。所以在讀取時需要注意，尤其是在包含中文字符時，往往會因為讀取的長 度不正確導致字符串被截斷。
type_ids_size/off字段：
type_ids 區索引了 .dex 文件里的所有數據類型 ，包括 class 類型 ，數組類型（array types）和基本類型(primitive types) 。 本區域里的元素格式為type_ids_item , 結構描述如下 ：
struct type_ids_item
{
uint descriptor_idx;
}
type_ids_item 里面 descriptor_idx 的值的意思 ，是 string_ids 里的 index 序號 ，是用來描述此type 的字符串 。
根據 header 里 type_ids_size = 0×07 , type_ids_off = 0xb0 , 找到對應的二進制描述區 。
03 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00
07 00 00 00 08 00 00 00 0A 00 00 00
分別對應：
proto_ids_size/off字段：
proto 的意思是 method prototype 代表 java 語言里的一個 method 的原型 。proto_ids 里元素為 proto_id_item , 結構如下 。
uint 32-bit unsigned int, little-endian
struct proto_id_item
{
uint shorty_idx;
uint return_type_idx;
uint parameters_off;
}
shorty_idx , 跟 type_ids 一樣 ，它的值是一個 string_ids 的 index 號 ，最終是一個簡短的字符串描述 ，用來說明該 method 原型 。
return_type_idx , 它的值是一個 type_ids 的 index 號 ，表示該 method 原型的返回值類型 。
parameters_off , 后綴 off 是 offset , 指向 method 原型的參數列表 type_list ; 若 method 沒有參數 ，值為0 。參數列表的格式是 type_list ，結構從邏輯上如下描述 。
size 表示參數的個數 ；type_idx 是對應參數的類型 ，它的值是一個 type_ids 的 index 號 ，跟 return_type_idx 是同一個品種的東西 。
uint 32-bit unsigned int, little-endian
ushort 16-bit unsigned int, little-endian
struct type_list
{
uint size;
ushort type_idx[size];
}
header 里 proto_ids_size = 0×03 , proto_ids_off = 0xcc , 它的二進制描述區如下 ：
08 00 00 00 05 00 00 00 00 00 00 00 V V 無參數
09 00 00 00 05 00 00 00 70 01 00 00 VL V 參數偏移0×170
09 00 00 00 05 00 00 00 78 01 00 00 VL V 參數偏移0×178
0×170:
01 00 00 00 03 00 一個參數 Ljava/lang/String;
0×178
01 00 00 00 06 00 一個參數 [Ljava/lang/String;
field_ids_size/off字段：
filed_ids 區里面有被本 .dex 文件引用的所有的 field 。本區的元素格式是 field_id_item ，邏輯結構描述如下：
ushort 16-bit unsigned int, little-endian
uint 32-bit unsigned int, little-endian
struct filed_id_item
{
ushort class_idx;
ushort type_idx;
uint name_idx;
}
class_idx , 表示本 field 所屬的 class 類型 , class_idx 的值是 type_ids 的一個 index ， 並且必須指向一個class 類型 。
type_idx , 表示本 field 的類型 ，它的值也是 type_ids 的一個 index 。
name_idx , 表示本 field 的名稱 ，它的值是 string_ids 的一個 index 。
header 里 field_ids_size = 1 , field_ids_off = 0xf0 。說明本 .dex 只有一個 field ，這部分的二進制描述如下 ：
04 00 01 00 0D 00 00 00 Ljava/lang/System; Ljava/io/PrintStram; out
method_ids_size/off字段：
method_ids 是索引區的最后一個條目,它索引了 .dex 文件里的所有的 method.
method_ids 的元素格式是 method_id_item ， 結構跟 fields_ids 很相似：
ushort 16-bit unsigned int, little-endian
uint 32-bit unsigned int, little-endian
struct filed_id_item
{
ushort class_idx;
ushort proto_idx;
uint name_idx;
}
class_idx , 表示本 method 所屬的 class 類型 , class_idx 的值是 type_ids 的一個 index ， 並且必須指向一個 class 類型 。
name_idx , 表示本 method 的名稱 ，它的值是 string_ids 的一個 index 。
proto_idx 描述該 method 的原型 ，指向 proto_ids 的一個 index 。
header 里 method_ids_size = 0×04 , method_ids_off = 0xf8 。本部分的二進制描述如下 ：
00 00 00 00 00 00 00 00 LHello; V()V <init>
00 00 02 00 0C 00 00 00 LHello; VL([Ljava/lang/String;)V main
01 00 01 00 0E 00 00 00 Ljava/io/PrintStram; VL(Ljava/lang/String;)V println
02 00 00 00 00 00 00 00 Ljava/lang/Object; V()V <init>
對 .dex 反匯編的時候 ，常用的 method 表示方法是這種形式 :
Lpackage/name/ObjectName;->MethodName(III)Z
將上面可整理為：
LHello;-><init>()V
LHello;->main([Ljava/lang/String;)V
Ljava/io/PrintStram;->println(Ljava/lang/String;)V
Ljava/lang/Object;->init()V
至此 ，索引區的內容描述完畢 ，包括 string_ids , type_ids，proto_ids , field_ids , method_ids 。每個索引
區域里存放着指向具體數據的偏移地址 （如 string_ids ) ， 或者存放的數據是其它索引區域里面的 index 號。
class_def_size/off字段：
從字面意思解釋 ，class_defs 區域里存放着 class definitions , class 的定義 。它的結構較 .dex 區都要復雜些 ,
因為有些數據都直接指向了 data 區里面 。
class_defs 的數據格式為 class_def_item ， 結構描述如下 ：
uint 32-bit unsigned int, little-endian
struct class_def_item
{
uint class_idx;
uint access_flags;
uint superclass_idx;
uint interfaces_off;
uint source_file_idx;
uint annotations_off;
uint class_data_off;
uint static_value_off;
}
(1) class_idx 描述具體的 class 類型 ，值是 type_ids 的一個 index 。值必須是一個 class 類型 ，不能是數組類型或者基本類型 。
(2) access_flags 描述 class 的訪問類型 ，諸如 public , final , static 等 。
(3) superclass_idx , 描述 supperclass 的類型 ，值的形式跟 class_idx 一樣 。
(4) interfaces_off , 值為偏移地址 ，指向 class 的 interfaces , 被指向的數據結構為 type_list 。class 若沒有
interfaces ,值為 0。
(5) source_file_idx , 表示源代碼文件的信息 ，值是 string_ids 的一個 index 。若此項信息缺失 ，此項值賦值為
NO_INDEX=0xffff ffff 。
(6) annotions_off , 值是一個偏移地址 ，指向的內容是該 class 的注釋 ，位置在 data 區，格式為annotations_direcotry_item 。若沒有此項內容 ，值為 0 。
(7) class_data_off , 值是一個偏移地址 ，指向的內容是該 class 的使用到的數據 ，位置在 data 區，格式為class_data_item 。若沒有此項內容 ，值為 0 。該結構里有很多內容 ，詳細描述該 class 的 field ， method, method 里的執行代碼等信息 。
(8) static_value_off , 值是一個偏移地址 ，指向 data 區里的一個列表 ( list ) ，格式為 encoded_array_item。若沒有此項內容 ，值為 0 。
header 里 class_defs_size = 0×01 , class_defs_off = 0x 0118 。則此段二進制描述為 ：
00 00 00 00 LHello;
00 00 00 00 無，默認包訪問權限
02 00 00 00 Ljava/lang/Object;
00 00 00 00 無接口
02 00 00 00 Hello.java
00 00 00 00 無注解
3E 02 00 00 0x23E
00 00 00 00 無
class_data_item：
class_data_off 指向 data 區里的 class_data_item 結構 ,class_data_item 里存放着本 class 使用到的各種數
據 ，下面是 class_data_item 的邏輯結構 ：
uleb128 unsigned little-endian base 128
struct class_data_item
{
uleb128 static_fields_size;
uleb128 instance_fields_size;
uleb128 direct_methods_size;
uleb128 virtual_methods_size;
encoded_field static_fields [ static_fields_size ];
encoded_field instance_fields [ instance_fields_size ];
encoded_method direct_methods [ direct_method_size ];
encoded_method virtual_methods [ virtual_methods_size ];
}
encoded_field 的結構如下 ：
struct encoded_field
{
uleb128 filed_idx_diff; // index into filed_ids for ID of this filed
uleb128 access_flags; // access flags like public, static etc.
}
encoded_method 的結構如下 ：
struct encoded_method
{
uleb128 method_idx_diff;
uleb128 access_flags;
uleb128 code_off;
}
（1）method_idx_diff , 前綴 methd_idx 表示它的值是 method_ids 的一個 index ，后綴 _diff 表示它是於另外一個 method_idx 的一個差值 ，就是相對於 encodeed_method [] 數組里上一個元素的 method_idx 的差值 。
其實 encoded_filed – > field_idx_diff 表示的也是相同的意思 ，只是編譯出來的 Hello.dex 文件里沒有使用到class filed 所以沒有仔細講。
（2）access_flags ， 訪問權限 ， 比如 public、private、static、final 等 。
（3）code_off , 一個指向 data 區的偏移地址 ，目標是本 method 的代碼實現 。被指向的結構是code_item ，有近 10 項元素 。
0x23E：
00 static_fields_size
00 instance_fields_size
02 direct_methods_size
00 virtual_methods_size
00 80 80 04 B8 02 01 09 D0 02 0D 00 00 00
名稱為 LHello; 的 class 里只有 2 個 directive methods 。 directive_methods 里的值都是 uleb128 的原始二
進制值 。按照 directive_methods 的格式 encoded_method 再整理一次這 2 個 method 描述 ，得到結果如下
表格所描述 。method 一個是 <init> , 一個是 main 。
其中兩個directive methods為：
00 LHello;-><init>()V
80 80 04 0×10000 ACC_CONSTRUCTOR
B8 02 0×0138
01 LHello;->main([Ljava/lang/String;)V
09 ACC_PUBLIC|ACC_STATIC
D0 02 0×0150
class_def_item –> class_data_item –> code_item:
code_item 結構里描述着某個 method 的具體實現 。它的結構如下描述 ：
struct code_item
{
ushort registers_size;
ushort ins_size;
ushort outs_size;
ushort tries_size;
uint debug_info_off;
uint insns_size;
ushort insns [ insns_size ];
ushort paddding; // optional
try_item tries [ tyies_size ]; // optional
encoded_catch_handler_list handlers; // optional
}
末尾的 3 項標志為 optional , 表示可能有 ，也可能沒有 ，根據具體的代碼來 。
(1) registers_size, 本段代碼使用到的寄存器數目。
(2) ins_size, method 傳入參數的數目 。
(3) outs_size, 本段代碼調用其它method 時需要的參數個數 。
(4) tries_size, try_item 結構的個數 。
(5) debug_off, 偏移地址 ，指向本段代碼的 debug 信息存放位置 ，是一個 debug_info_item 結構。
(6) insns_size, 指令列表的大小 ，以 16-bit 為單位 。 insns 是 instructions 的縮寫 。
(7) padding , 值為 0 ，用於對齊字節 。
(8) tries 和 handlers ， 用於處理 java 中的 exception , 常見的語法有 try catch 。
那先來分析下main的執行代碼，它的code_off為0×150,對應的二進制代碼如下：
03 00 registers_size
01 00 ins_size
02 00 outs_size
00 00 tries_size
37 02 00 00 debug_info_off 0×0237
08 00 00 00 insns_size 0×08
62 00 00 00 1A 01 01 00 6E 20 02 00 10 00 0E 00 insns
0×0062 0×0000 0x011a 0x 0001 0x 206e 0×0002 0×0010 0x 000e
insns 數組里的 8 個二進制原始數據 ， 對這些數據的解析 ，需要對照官網的文檔 《Dalvik VM Instruction Format》和《Bytecode for Dalvik VM》。分析
http://source.android.com/devices/tech/dalvik/instruction-formats.html
http://source.android.com/devices/tech/dalvik/dalvik-bytecode.html
分析思路整理如下:
《Dalvik VM Instruction Format》 里操作符 op 都是位於首個 16bit 數據的低 8 bit ，起始的是 op =0×62。
在 《Bytecode for Dalvik VM》 里找到對應的 Syntax 和 format 。
syntax = sget_object
format = 0x21c 。
在《Dalvik VM Instruction Format》里查找 21c ， 得知 op = 0×62 的指令占據 2 個 16 bit 數據 ，格式是 AA|op BBBB ，解釋為 op vAA, type@BBBB 。因此這 8 組 16 bit 數據里 ，前 2 個是一組 。對比數據得 AA=0×00, BBBB = 0×0000。
返回《Bytecode for Dalvik VM》里查閱對 sget_object 的解釋， AA 的值表示 Value Register ，即0 號寄存器； BBBB 表示 static field 的 index ，就是之前分析的field_ids 區里 Index = 0 指向的那個東西,也就是Ljava/lang/System; -> out:Ljava/io/printStream;
所以前兩個16bit數據解釋為：
前 2 個 16 bit 數據 0x 0062 0000 , 解釋為
sget_object v0, Ljava/lang/System; -> out:Ljava/io/printStream;
其余的 6 個 16 bit 數據分析思路跟這個一樣 ，依次整理如下 ：
0x011a 0×0001: const-string v1, “Hello!”
0x206e 0×0002 0×0010:
invoke-virtual {v0, v1}, Ljava/io/PrintStream; -> println(Ljava/lang/String;)V
0x000e: return-void
所以整個main方法為：
ACC_PUBLIC ACC_STATIC LHello;->main([Ljava/lang/String;)V
{
sget_object v0, Ljava/lang/System; -> out:Ljava/io/printStream;
const-string v1,Hello, Android!
invoke-virtual {v0, v1}, Ljava/io/PrintStream; -> println(Ljava/lang/String;)V
return-void
}
然后再使用baksmali.jar反編譯成smali。
.class LHello;
.super Ljava/lang/Object;
.source “Hello.java”
# direct methods
.method constructor <init>()V
.registers 1
.prologue
.line 1
invoke-direct {p0}, Ljava/lang/Object;-><init>()V
return-void
.end method
.method public static main([Ljava/lang/String;)V
.registers 3
.parameter “argc”
.prologue
.line 3
sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;
const-string v1, “Hello!”
invoke-virtual {v0, v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
.line 4
return-void
.end method
和我們分析的一樣。