1 什么是Mach-O
Mach-O其實是Mach Object文件格式的縮寫，是mac以及iOS上可執行文件的格式， 類似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)。
如果我們想對 Mach -O 文件有所了解，可以將我們打包好的 ipa 文件后綴改成 .zip,然后解壓生成 Payload 文件，在其中就可以找到 exec 文件。或者找一個動態庫的 framework 在其中也可以找到 exec 文件。
常見的MachO文件：
- 目標文件：.o
- 庫文件：.a .dylib Framework
- 可執行文件：dyld .dsym
如何查看文件格式
file [文件路徑/文件名]
2 MachOView
官網直接下載的MachOView.app打開后不停閃退，因此最好是直接去下載源碼然后編譯出來使用。
MachOView GitHub地址
下載后記得修改源碼：
3 MachO文件結構
使用MachOView打開兩個Xcode編譯后生成的app可執行文件，文件結構分別如下：
根據圖可以看出，同時支持多種指令集的MachO文件會針對每個指令集生成一個Executable，每一個Executable里的文件結構又是一樣的。下面我們針對Executable文件來分析，先看一張官網的MachO文件結構圖，可看出MachO文件主要由三部分組成：
- Header
- Load Commons
-
Data
image.png
3.1 Mach Header
選取了Mach64 Header來分析，圖中未紅字表明的flags表示的是標示位，主要與系統的加載、鏈接相關：
3.2 Load Commands
Load commands是一張包含很多內容的表，內容包括區域的位置、符號表、動態符號表等。這里就是二進制文件加載進內存要執行的一些指令。這里的指令主要在負責我們 APP 對應進程的創建和基本設置（分配虛擬內存，創建主線程，處理代碼簽名/加密的工作），然后對動態鏈接庫（.dylib 系統庫和我們自己創建的動態庫）進行庫加載和符號解析的工作。
字段名稱及意義分別如下：
| 名稱 | 含義 |
|---|---|
| LC_SEGMENT_64 | 將文件中（32位或64位）的段映射到進程地址空間中 |
| LC_DYLD_INFO_ONLY | 動態鏈接相關信息 |
| LC_SYMTAB | 符號地址 |
| LC_DYSYMTAB | 動態符號表地址 |
| LC_LOAD_DYLINKER | 使用誰加載，我們使用dyld |
| LC_UUID | 文件的UUID |
| LC_VERSION_MIN_MACOSX | 支持最低的操作系統版本 |
| LC_SOURCE_VERSION | 源代碼版本 |
| LC_MAIN | 設置程序主線程的入口地址和棧大小 |
| LC_LOAD_DYLIB | 依賴庫的路徑，包含三方庫 |
| LC_FUNCTION_STARTS | 函數起始地址表 |
| LC_CODE_SIGNATURE | 代碼簽名 |
首先看下Load Commands目錄結構：
從上圖可知 Load Commands 主要包含了有多個 Segment 段，每個中又包含了多個 Section 段。每一部分都是系統執行指令。其中 LC_SEGMENT 包含空指針陷阱
__TEXT段主要包含程序代碼和只讀的常量，這個段的內容如果是系統動態庫的內容那么所有進程公用
__DATA 段主要包含全局變量和靜態變量，這個段的內容每個進程單獨進行維護
__LINKEDIT 主要包含鏈接器使用的符號和其他的表（比如函數名稱、地址等） 這個段的內容也是可以多進程公用的。
此外還需介紹下和 SEGMENT 并列的一些比較重要的指令：
LC_LOAD_DYLINKER 該字段標明我們的MachO是被誰加載進去的。
可以理解為LC_LOAD_DYLINKER指向的地址是微信APP加載小程序的引擎，而我們的MachO是小程序。在上圖中可以看到我們的Demo1的LC_LOAD_DYLINKER指向的地址就是dyld，dyld確實是用來加載我們app的。LC_LOAD_DYLIB
該字段標記了所有動態庫的地址，只有在LC_LOAD_DYLIB中有標記，我們MachO外部的動態庫（如：Framework）才能被dyld正確的引用，否則dyld不會主動加載。（因此很多通過這個知識點來做代碼注入）LC_MAIN 是在所有的庫都加載完成后，有其中的指令啟動程序的主線程。我們的程序也是在這個函數之后才開始執行 main() 函數的。
LC_CODE_SIGNATURE 我想每個 iOSer 都知道代碼簽名的機制，其實代碼簽名的校驗也是在這個指令下進行。實際上指令會把整個文件進行 hash 化處理并簽名，在運行時去驗證簽名的正確性。
3.3 Data
Data 通常是對象文件中最大的部分，包含Segement的具體數據，如靜態C字符串，帶參數/不帶參數的OC方法，帶參數/不帶參數的C函數。
可以看到，全局靜態C字符，方法里面的字符串都被保存在data段的cstring里了，哪怕是%d,%s等等這樣的參數類型字符串也被保存在內，但所有同樣的字符串只會被保存一次:
同樣所有的OC方法都被保存在methname里了:
4 結語
暫時通過MachOView初步窺探了一下MachO文件的結構，理解MachO文件結構是對后續學習MachO文件加載、dyld等建立知識基礎。好多知識對于自己目前的知識水平感覺真的是看著像都懂了，但一問細節卻又什么都不懂，書讀百遍其義自見吧。
參考文章：
iOS逆向(5)-不知MachO怎敢說自己懂DYLD
理解 Mach-O 并提高程序啟動速度
