iOS系統分析（二）Mach-O二進位檔案解析，

iOS系統分析（二）Mach-O二進位檔案解析，

➠更多技術乾貨請戳：聽雲部落格

0x01  Mach-O格式簡單介紹

Mach-O檔案格式是 OS X 與 iOS 系統上的可執行檔格式，類似於windows的 可攜式執行檔 與 Linux（其他 Unix like）的 ELF 檔案，如果不徹底搞清楚Mach-O的格式與相關內容，那麼深入研究 xnu 核心就無從談起。

Mach-O檔案的格式如所示：

有如下幾個部分組成：

1. Header：儲存了Mach-O的一些基本資料，包括了平台、檔案類型、LoadCommands的個數等等。

2. LoadCommands：這一段緊跟Header，載入Mach-O檔案時會使用這裡的資料來確定記憶體的分布。

3. Data：每一個segment的具體資料都儲存在這裡，這裡包含了具體的代碼、資料等等。

0x02 FAT位元據 ，資料結構定義在 \<mach-o/fat.h\>

1. 第一段為magic 魔數,這裡注意大小端，讀出來之後需要看下是0xCAFEBABE還是 0xBEBAFECA（否則即為thin），需要根據這個來轉後續讀取的位元組的位元組序。  可以看出來 前4byte 為 0xBEBAFECA ，說明為fat。

2. 第二段為arch count，也就是該App或dSYM中包含哪些CPU架構，比如armv7、arm64等，這個例子中為2（後4byte  0x 00 00 00 02），表示包含了兩種cpu架構。  

  `sizeof(struct fat-header) = 8byte`

3. 後續段中包含cputype（0x  0C 00  00 01）、cpusubtype (0x 00 00 00 00)、offset (0x 00 10 00  00)、size(0x 00  F0 27 00)等資料，根據fat中的結構定義，依次讀取，這裡需要說明的是，如果只包含一種CPU架構的話，是沒有這段fat頭定義的，可以跳過這部分，直接讀取Arch資料。

   `sizeof(struct fat-arch) = 20byte`

4. 根據fat頭中讀取的offset資料，我們可以跳到檔案對應的arch資料的位置，當然如果只有一種架構的話就不需要計算位移量了。 給出解析的函數

0x03 Mach Header位元據

通過magic我們可以區分出是32-bit還是64-bit，64-bit多了4個位元組的保留欄位，這裡同樣需要注意位元組序的問題，也就是判斷magic，來確定是否需要轉換位元組序。  

`sizeof(struct mach-header-64) = 32byte`  ; `sizeof(struct mach-header) = 28byte`

根據mach-header與mach-header_64的定義，很明顯可以看出，Headers的主要作用就是協助系統迅速的定位Mach-O檔案的運行環境，檔案類型。

FileType 

因為Mach-O檔案不僅僅用來實現可執行檔，同時還用來實現了其他內容

1. 核心擴充

2. 庫檔案

3. CoreDump

4.  其它

下面是一些精彩用到的檔案類型

1. MH-OBJECT    編譯過程中產生的  obj檔案 (gcc -c xxx.c 產生xxx.o檔案)

2. MH-EXECUTABLE  可執行二進位檔案 (/usr/bin/ls)

3. MH-CORE      CoreDump (崩潰時的Dump檔案)

4. MH-DYLIB  動態庫(/usr/lib/裡面的那些共用庫檔案)

5. MH-DYLINKER  連接器linker（/usr/lib/dyld檔案）

6. MH-KEXT-BUNDLE   核心擴充檔案 （自己開發的簡單核心模組）

flags

Mach-O headers還包含了一些很重要的dyld的載入參數。

1. MH-NOUNDEFS   目標沒有未定義的符號，不存在連結依賴

2. MH-DYLDLINK     該目標檔案是dyld的輸入檔案，無法被再次的靜態連結

3. MH-PIE      允許隨機的地址空間（開啟ASLR  -\>Address Space Layout Randomization）

4. MH-ALLOW-STACK-EXECUTION   棧記憶體可執行代碼，一般是預設關閉的。

5. MH-NO-HEAP-EXECUTION   堆記憶體無法執行代碼

0x04 LoadCommands

Load Commands 直接就跟在Header後面，所有command佔用記憶體的總和在Mach-O Header裡面已經給出了。在載入過Header之後就是通過解析LoadCommand來載入接下來的資料了。定義如下：

cmd欄位

根據cmd欄位的類型不同，使用了不同的函數來載入。簡單的列出一張表看一看在核心代碼中不同的command類型都有哪些作用。

1. LC-SEGMENT；LC-SEGMENT-64   在核心中由load-segment 函數處理（將segment中的資料載入並映射到進程的記憶體空間去）

2. LC-LOAD-DYLINKER    在核心中由load-dylinker 函數處理（調用/usr/lib/dyld程式）

3. LC-UUID 在核心中由load-uuid 函數處理 （載入128-bit的唯一ID）

4. LC-THREAD  在核心中由load-thread 函數處理 （開啟一個MACH線程，但是不分配棧空間）

5. LC-UNIXTHREAD 在核心中由load-unixthread 函數處理 （開啟一個UNIX posix線程）

6. LC-CODE-SIGNATURE 在核心中由load-code-signature 函數處理 （進行數位簽章）

7. LC-ENCRYPTION-INFO 在核心中由 set-code-unprotect 函數處理 （加密二進位檔案）

UUID 位元據    128byte

UUID是16個位元組（128bit）的一段資料，是檔案的唯一標識，前面提到的符號化時，這個UUID必須要和App二進位檔案中的UUID一致，才能被正確的符號化。dwarfdump查看的UUID就是這段資料。讀取這部分資料時通過Command結構讀取的，也就是第一段(0x0000001B)表示接下來的資料類型，第二段(0x00000018)資料的大小（包含Command資料）。 

SymTab 位元據

1. 符號表資料區塊結構，前二段依然是Command資料。後邊4段分別為符號在檔案中的位移量(0x001DF5E0)、符號個數(0x001DF5E0)、字串在檔案中的位移量(0x0020C3A0)、字串表大小(0x000729A8)。 

2. 接下來就是讀取Segment和Section資料區塊了，和上面讀取資料區塊結構一樣是根據Command結構讀取，展示的Segment資料和Section資料，它們在二進位檔案中它們是連續的，也就是每一條Segment資料後面會緊跟著多條對應的Section資料，Section的資料總數是通過Segment結構中的nsects決定的。 

3. 這裡我寫了一個簡單地Mach-O解析工具 [https://github.com/liutianshx2012/Tmacho](https://github.com/liutianshx2012/Tmacho)

Segment資料

載入資料時，主要載入的就是LC-SEGMET活著LC-SEGMENT_64。其他的Segment的用途在這裡不做深究。

LCSEGMENT以及LC-SEGMENT-64 定義如。

 

可以看出，這裡大部分的資料是用來協助核心將Segment映射到虛擬記憶體的。

nsects 欄位，標示了Segment中有多少secetion ，section是具體有用的資料存放的地方。

TEXT的vmaddr也就是程式的載入地址； —DWARF中表明了DWARF資料區塊的資訊，表示dSYM是DWARF格式的資料結構。 

` sizeof(struct segment-command) = 56byte   ;   sizeof(struct segment-command-64) = 72byte`

Section資料

從Section資料中，我們可以找到—debug-info、—debug-pubnames, —debug-line等調試資訊，通過這些調試資訊我們可以找到程式中符號的起始地址、變數類型等資訊。如果我們要符號化的話，就可以通過解析這些資料得到我們想要的資訊。

Symbol 資料

通過SymTab中的資料可以得到Symbol在檔案中的位置和個數，Symbol塊資料中包含了符號的起始地址、字串的位移量等資料，這部分資料結構可以參考\<nlist.h\> 和 \<stabl.h\>。在這部分資料全部讀取後，就可以讀取所有的符號資料了，也就是接下來的資料。 

Symbol String 資料

1. 通過SymTab和Symbo中的資料可以得到每個符號字串在檔案中的位移量和大小，每個符號資料是以0結尾的字串。 

2. 我們通過以上兩部分資料的組合就可以得到每個symbo在程式中的載入地址了。這些資料對於以後做符號工作都非常的有協助。

3. 到此，關於dSYM檔案中頭部資料讀取就完成了。頭部資料都有相應的資料結構定義，讀取時相對會比較容易些，解析資料時要注意位元組序的問題，32-bit和64-bit資料結構的差異、位元組長度的差異，DWARF版本的差異，每個資料區塊之間都是緊密聯絡的，一個位元組的讀取偏差就會造成後續資料的讀取錯誤，正所謂差之毫釐，失之千裡。

 

原文連結：http://blog.tingyun.com/web/article/detail/1341