馬上加入Android 台灣中文網,立即免費下載應用遊戲。
您需要 登錄 才可以下載或查看,沒有帳號?註冊
x
檔案頭(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
」,它的作用主要是用來標識dex檔案的,比如有一個檔案也以dex為後綴名,僅此並不會被認為是Davlik虛擬機執行的檔案,還要判斷這 四個位元組。另外Davlik虛擬機也有優化的Dex,也是通過個字段來區分的,當它是優化的Dex檔案時,它的值就變成」dey
」了。根據這四個字 節,就可以識別不同類型的Dex檔案了。 跟在「dex
」後面的是版本字段,主要用來標識Dex檔案的版本。目前支援的版本號為「035 」,不管是否優化的版本,都是使用這個版本號。
檢驗碼字段 主要用來檢查從這個字段開始到檔案結尾,這段資料是否完整,有沒有人修改過,或者傳送過程中是否有出錯等等。通常用來檢查資料是否完整的算法,有 CRC32、有SHA128等,但這裡採用並不是這兩類,而採用一個比較特別的算法,叫做adler32,這是在開源zlib裡常用的算法,用來檢查檔案 是否完整性。該算法由MarkAdler發明,其可靠程度跟CRC32差不多,不過還是弱一點點,但它有一個很好的優點,就是使用 軟體來計算檢驗碼時比較 CRC32要快很多。可見Android系統,就算法上就已經為移動設備進行優化了。 Java中可使用java.util.zip.Adler32類做校驗操作 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> |