上一篇博客介紹了mach_header相關內容，Mach-O文件介紹之mach_header。這篇博客主要介紹Mach-O 的加載命令。
Load command
Mach-O文件的主要功能在于加載命令（load command）。加載命令緊跟在文件頭之后，文件頭中的兩個字段——ncmds和sizeofncmds——用于解析加載命令。
每一條指令都采用“類型——長度——值”的格式：32位的cmd值（表示類型），32位的cmdsize值（32位二進制位4的倍數，64位二進制位8的倍數），以及命令本身（有cmdsize指定的任意長度）。有一些命令是由內核加載器（定義在bsd/kern/mach_loader.c文件中）直接使用的，其他命令是由動態(tài)連接器處理的。
內核加載器命令
加載過程在內核的部分負責新進程的基本設置——分配虛擬內存，創(chuàng)建主線程，以及處理任何可能的代碼簽名/加密的工作。然而對于動態(tài)鏈接的可執(zhí)行文件（大部分可執(zhí)行文件都是動態(tài)鏈接的）來說，真正的庫加載和符號解析的工作都是通過LC_LOAD_DYLINKER命令指定的動態(tài)連接器在用戶態(tài)完成的。控制權會裝交給連接器，鏈接器進而接著處理文件頭中的其他加載命令。
加載命令總共有30多條。下表列出了內核加載器使用的命令
下面詳細討論這些加載命令。
1、LC_SEGMENT以及進程虛擬內存設置
LC_SEGMENT(或LC_SEGMENT_64)命令是最主要的加載命令，這條命令知道內核如何設置新運行的進程的內存空間。這些 segment直接從Mach-O二進制文件加載到內存中。
每一條LC_SEGMENT命令都提供了段布局的所有必要細節(jié)信息，如下表：
Objectice-C中segment加載命令的定義如下：
/*
* The segment load command indicates that a part of this file is to be
* mapped into the task's address space. The size of this segment in memory,
* vmsize, maybe equal to or larger than the amount to map from this file,
* filesize. The file is mapped starting at fileoff to the beginning of
* the segment in memory, vmaddr. The rest of the memory of the segment,
* if any, is allocated zero fill on demand. The segment's maximum virtual
* memory protection and initial virtual memory protection are specified
* by the maxprot and initprot fields. If the segment has sections then the
* section structures directly follow the segment command and their size is
* reflected in cmdsize.
*/
struct segment_command { /* for 32-bit architectures */
uint32_t cmd; /* LC_SEGMENT */
uint32_t cmdsize; /* includes sizeof section structs */
char segname[16]; /* segment name */
uint32_t vmaddr; /* memory address of this segment */
uint32_t vmsize; /* memory size of this segment */
uint32_t fileoff; /* file offset of this segment */
uint32_t filesize; /* amount to map from the file */
vm_prot_t maxprot; /* maximum VM protection */
vm_prot_t initprot; /* initial VM protection */
uint32_t nsects; /* number of sections in segment */
uint32_t flags; /* flags */
};
/*
* The 64-bit segment load command indicates that a part of this file is to be
* mapped into a 64-bit task's address space. If the 64-bit segment has
* sections then section_64 structures directly follow the 64-bit segment
* command and their size is reflected in cmdsize.
*/
struct segment_command_64 { /* for 64-bit architectures */
uint32_t cmd; /* LC_SEGMENT_64 */
uint32_t cmdsize; /* includes sizeof section_64 structs */
char segname[16]; /* segment name */
uint64_t vmaddr; /* memory address of this segment */
uint64_t vmsize; /* memory size of this segment */
uint64_t fileoff; /* file offset of this segment */
uint64_t filesize; /* amount to map from the file */
vm_prot_t maxprot; /* maximum VM protection */
vm_prot_t initprot; /* initial VM protection */
uint32_t nsects; /* number of sections in segment */
uint32_t flags; /* flags */
};
對于每一個段，將文件中相對應的內容加載到內存中：從偏移量為fileoff處加載filesize字節(jié)到虛擬內存地址vmaddr處的vmsize字節(jié)。每一個段的頁面都根據initprot進行初始化，initprot指定了如何通過讀／寫／執(zhí)行位初始化頁面保護級別。段的保護設置可以動態(tài)改變，但是不能超過maxprot中指定的值（iOS中，+x 和+w 是互斥的）。
_PAGEZERO段（空指針陷阱）、_TEXT段（程序代碼）、_DATA段（程序數據）和_LINKEDIT（鏈接器使用的符號和其他表）段提供了LC_SEGMENT命令。段也可以進一步分解為區(qū)(section).
Mach-O可執(zhí)行文件中常見的段和區(qū)
段也可以設置一些<mach/loader.h>頭文件中定義的flags。其中一個flags是SG_PROTECTED_VERSION_1(0x08),表示這個段是“受保護的”，即加密的。
2、LC_MAIN
LC_MAIN設置程序主線程的入口地址和棧大小.
使用 otool -l /bin/ls 查看加載命令，LC_MAIN加載 命令中的entryoff指向的是main還是的入口地址。可以使用
*otool -vt * 反編譯出匯編代碼，查看main函數的入口。
下面是演示：
a.c文件中的代碼
#include "stdio.h"
int main(int argc, char **argv)
{
printf("hello world/n");
return 0;
}
1、使用 gcc -g a.c -o a 進行編譯a.c文件。
2、使用 otool -l /bin/ls 查看a的加載命令，其中LC_MAIN加載命令如下：
entryoff對應的數字3920，轉為16進制是 0xf50.
3、再使用 otool -vt a 反編譯出匯編代碼，查看main函數：
可以看到main函數的首句匯編代碼的地址正是 0xf50。這個位置同樣也是__TEXT段中，__text組的起始地址
動態(tài)連接器命令
Mach-O鏡像中有很多“空洞”——即對外部的庫和符號的引用——這些空洞要在程序啟動時填補。這項工作需要由動態(tài)鏈接器來完成。這個過程有時候也被稱為符號綁定（binding）。
動態(tài)鏈接器是在內核執(zhí)行LC_DYLINKER加載命令時啟動的，通常是使用/usr/lib/dyld作為動態(tài)鏈接器。
由dyld處理的加載命令
加載命令所對應的結構體在 <mach-o/loader.h> 頭文件中都可以找得到。
例如LC_SYMTAB的結構體如下：
/*
* The symtab_command contains the offsets and sizes of the link-edit 4.3BSD
* "stab" style symbol table information as described in the header files
* <nlist.h> and <stab.h>.
*/
struct symtab_command {
uint32_t cmd; /* LC_SYMTAB */
uint32_t cmdsize; /* sizeof(struct symtab_command) */
uint32_t symoff; /* symbol table offset */
uint32_t nsyms; /* number of symbol table entries */
uint32_t stroff; /* string table offset */
uint32_t strsize; /* string table size in bytes */
};
iOS符號綁定分為兩種：non-lazy和lazy綁定符號。non-lazy符號位于Mach-O文件__DATA Segment 的__nl_symbol_ptr section，lazy符號位于__DATA Segment 的__la_symbol_ptr section。對于non-lazy的符號綁定時機為動態(tài)庫加載（load），lazy符號的綁定時機則與Linux相同即函數第一次被調用。
在 iOS 系統(tǒng)中，當程序調用動態(tài)庫的函數時，它實際上是執(zhí)行__TEXT 段的 __stubs 節(jié)的代碼。外部函數的地址放在 __DATA 段的__la_symbol_ptr 中，而__stub 的作用便是找到相應的 __la_symbol_ptr，并跳轉到它所包含的地址。第一次使用printf時，__la_symbol_ptr中還沒有記錄printf的真正地址，這時的地址是指向__TEXT 段的 __stub_helper 節(jié)中的相關內容。__stub_helper 會調用 dyld_stub_binder(動態(tài)鏈接器的入口) 進行符號綁定，最后會將 printf 的地址放到 __la_symbol_ptr 處。
這里主要討論下lazy符號綁定。
測試代碼 a.c
#include <stdio.h>
int main(int argc, const char * argv[]) {
// insert code here...
printf("Hello, World!\n");
printf("Hello World Again!\n");
return 0;
}
1、編譯代碼 gcc a.c -o a
2、使用lldb調試a文件 lldb a,并反編譯出main函數的匯編代碼
3、在第一次調用printf處添加斷點 b 0x100000f42 ，然后運行代碼
4、使用MachOView打開a文件查看__TEXT段中的__stubs組，可以發(fā)現printf的調用地址就是_stubs中的樁。
__stubs會到__DATA段的__la_symbol_ptr中找到函數的入口地址。
在lldb中 si(step in)查看printf的執(zhí)行步驟
可以發(fā)現printf執(zhí)行的第一條語句就是跳轉到0x0000000100000f7c.這與__la_symbol_ptr中printf對應的值是一致的。第一次時，這個地址并沒有指向printf函數入口，而是指向了__TEXT段中的__stub_helper中的地址。
然后在下一條語句0x100000F81中，會跳轉到__stub_helper的頭部0x100000f6c。順序執(zhí)行到第三條命令就是跳轉到dyld_stub_binder進行符號綁定了。
5、在第二個printf出添加斷點。并繼續(xù)執(zhí)行
6、再次si查看第二個printf的調用,這里可以看到這里第一條指令的跳轉地址已經指向的真正的 printf函數入口。
本文作者： ctinusdev
原文鏈接： https://ctinusdev.github.io/2017/08/20/Mach-OBasis_Loadcommand/
轉載請注明出處！
