Objective-C runtime机制(前传)——Mach-O格式
Mach-O
Mach-O是Mach Object文件格式的缩写。它是用于可执行文件，动态库，目标代码的文件格式。作为a.out格式的替代，Mach-O格式提供了更强的扩展性，以及更快的符号表信息访问速度。
Mach-O格式为大部分基于Mach内核的操作系统所使用的，包括NeXTSTEP, Mac OS X和iOS，它们都以Mach-O格式作为其可执行文件，动态库，目标代码的文件格式。
具体到我们的iOS程序，当用XCode打包后，会生成一个.app为扩展名的文件（位于工程目录/Products文件夹下），其实.app是一个文件夹，我们用鼠标右键选择‘Show Package contents’，就可以查看文件夹的内容，其中会发现有一个和我们工程同名的unix 可执行文件，这个就是iOS可执行文件，它是符合Mach-O格式的。
Mach-O文件结构
关于Mach-O的文件格式，在苹果官网已经找不到相关说明了，但是你可以通过下面链接获取PDF版说明：
Mach-O File Format Reference
Mach-O格式如下图所示，它被分为***header***， load commands， ***data***三大部分：
header：对Mach-O文件的一个概要说明，包括Magic Number, 支持的CUP类型等。
load commands： 当系统加载Mach-O文件时，load command会指导苹果的动态加载器(dyld)h或内核，该如何加载文件的Data数据。
data： Mach-O文件的数据区，包含代码和数据。其中包含若干Segment块（注意，除了Segment块之外，还有别的内容，包括code signature，符号表之类，不要被苹果的图所误导！），每个Segment块中包含0个或多个seciton。Segment根据对应的load command被dyld加载入内存中。
我们可以使用MachOView（一个查看MachO 格式文件信息的开源工具）工具来查看一个具体的文件的Mach-O格式。
header
我们以一个普通的iOS APP为例，看看Mach-O文件header部分的具体内容。通过MachOView打开可执行文件，可以看到header的结构：
是不是有些懵？下面我们就结合Darwin内核源码，来了解下Mach header的定义。
Mach header的定义位于Darwin源码中的 EXTERNAL_HEADERS/mach-o/loader.h 中：
32位：
struct mach_header {
uint32_t magic; /* mach magic number identifier */
cpu_type_t cputype; /* cpu specifier */
cpu_subtype_t cpusubtype; /* machine specifier */
uint32_t filetype; /* type of file */
uint32_t ncmds; /* number of load commands */
uint32_t sizeofcmds; /* the size of all the load commands */
uint32_t flags; /* flags */
};
64位：
struct mach_header_64 {
uint32_t magic; /* mach magic number identifier */
cpu_type_t cputype; /* cpu specifier */
cpu_subtype_t cpusubtype; /* machine specifier */
uint32_t filetype; /* type of file */
uint32_t ncmds; /* number of load commands */
uint32_t sizeofcmds; /* the size of all the load commands */
uint32_t flags; /* flags */
uint32_t reserved; /* reserved */
};
可以看到，32位和64位的Mach header基本相同，只不过64位header中多了一个保留参数reserved。
- magic：魔数，用来标识这是一个Mach-O文件，有32位和64位两个版本：
#define MH_MAGIC 0xfeedface /* the mach magic number */
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
- cputype：支持的CUP架构类型，如arm。
- cpusubtype：在支持的CUP架构类型下，所支持的具体机器型号。在我们的例子中，APP是支持所有arm64的机型的:CUP_SUBTYPE_ARM64_ALL
- filetype: Mach-O的文件类型。包括：
#define MH_OBJECT 0x1 /* Target 文件：编译器对源码编译后得到的中间结果 */
#define MH_EXECUTE 0x2 /* 可执行二进制文件 */
#define MH_FVMLIB 0x3 /* VM 共享库文件（还不清楚是什么东西） */
#define MH_CORE 0x4 /* Core 文件，一般在 App Crash 产生 */
#define MH_PRELOAD 0x5 /* preloaded executable file */
#define MH_DYLIB 0x6 /* 动态库 */
#define MH_DYLINKER 0x7 /* 动态连接器 /usr/lib/dyld */
#define MH_BUNDLE 0x8 /* 非独立的二进制文件，往往通过 gcc-bundle 生成 */
#define MH_DYLIB_STUB 0x9 /* 静态链接文件（还不清楚是什么东西） */
#define MH_DSYM 0xa /* 符号文件以及调试信息，在解析堆栈符号中常用 */
#define MH_KEXT_BUNDLE 0xb /* x86_64 内核扩展 */
- ncmds：load command的数量
- sizeofcmds: 所有load command的大小
- flags： Mach-O文件的标志位。主要作用是告诉系统该如何加载这个Mach-O文件以及该文件的一些特性。有很多值，我们取常见的几种：
#define MH_NOUNDEFS 0x1 /* Target 文件中没有带未定义的符号，常为静态二进制文件 */
#define MH_SPLIT_SEGS 0x20 /* Target 文件中的只读 Segment 和可读写 Segment 分开 */
#define MH_TWOLEVEL 0x80 /* 该 Image 使用二级命名空间(two name space binding)绑定方案 */
#define MH_FORCE_FLAT 0x100 /* 使用扁平命名空间(flat name space binding)绑定（与 MH_TWOLEVEL 互斥） */
#define MH_WEAK_DEFINES 0x8000 /* 二进制文件使用了弱符号 */
#define MH_BINDS_TO_WEAK 0x10000 /* 二进制文件链接了弱符号 */
#define MH_ALLOW_STACK_EXECUTION 0x20000/* 允许 Stack 可执行 */
#define MH_PIE 0x200000 /* 加载程序在随机的地址空间，只在 MH_EXECUTE中使用 */
#define MH_NO_HEAP_EXECUTION 0x1000000 /* 将 Heap 标记为不可执行，可防止 heap spray 攻击 */
MH_PIE 随机地址空间
每次系统加载进程后，都会为其随机分配一个虚拟内存空间。
在传统系统中，进程每次加载的虚拟内存是相同的。这就让黑客有可能篡改内存来破解软件。
dyld
dyld是苹果公司的动态链接库，用来把Mach-O文件加载入内存。
二级命名空间
表示其符号空间中还会包含所在库的信息。这样可以使得不同的库导出通用的符号。与其相对的是扁平命名空间。
Load commands
load commands 紧跟在header之后，用来告诉内核和dyld，如何将各个Segment加载入内存中。
load command被源码表示为struct，有若干种load command，但是共同的特点是，在其结构的开头处，必须是如下两个属性：
struct load_command {
uint32_t cmd; /* type of load command */
uint32_t cmdsize; /* total size of command in bytes */
};
苹果为cmd定义了若干的宏，用来表示cmd的类型，下面列举出几种：
// 描述该如何将32或64位的segment 加载入内存，对应segment command类型
#define LC_SEGMENT 0x1
#define LC_SEGMENT_64 0x19
// UUID, 2进制文件的唯一标识符
#define LC_UUID 0x1b
// 启动动态加载器dyld
#define LC_LOAD_DYLINKER 0xe
Segment load command
在这么多的load command中，需要我们重点关注的是segment load command。segment command解释了该如何将Data中的各个Segment加载入内存中，而和我们APP相关的逻辑及数据，则大部分位于各个Segment中。
而和我们的Run time相关的Segment，则位于__DATA类型Segment下。
Segment load command分为32位和64位：
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 */
};
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 */
};
32位和64位的Segment load command基本类似，只不过在64位的结构中，把和寻址相关的数据类型，由32位的uint32_t改为了64位的uint64_t类型。
结构体的定义，看注释基本能够看懂，就是maxprot， initprot不太明白啥意思。
这里介绍一个特殊的‘Segment’，叫做__PAGEZERO Segment。 这里说它特殊，是因为这个Segment其实是苹果虚拟出来的，只是一个逻辑上的段，而在Data中，根本没有对应的内容，也没有占用任何硬盘空间。
__PAGEZERO Segment在VM中被置为Read only，逻辑上占用APP最开始的4GB空间，用来处理空指针。
我们用MachOV点开__PAGEZERO Segment所对应的Segment load command，LC_SEGMENT_64(__PAGEZERO):
可以看到其vm size是4GB，但其真正的物理地址File size和offset都是0。
Section header
在Data中，程序的逻辑和数据是按照Segment（段）存储，在Segment中，又分为0或多个section，每个section中在存储实际的内容。而之所以这么做的原因在于，在section中，可以不用内存对齐达到节约内存的作用，而所有的section作为整体的Segment，又可以整体的内存对齐。
在Mach-O文件中，每一个Segment load command下面，都会包含对应Segment 下所有section的header。
section header的定义如下：
struct section { /* for 32-bit architectures */
char sectname[16]; /* name of this section */
char segname[16]; /* segment this section goes in */
uint32_t addr; /* memory address of this section */
uint32_t size; /* size in bytes of this section */
uint32_t offset; /* file offset of this section */
uint32_t align; /* section alignment (power of 2) */
uint32_t reloff; /* file offset of relocation entries */
uint32_t nreloc; /* number of relocation entries */
uint32_t flags; /* flags (section type and attributes)*/
uint32_t reserved1; /* reserved (for offset or index) */
uint32_t reserved2; /* reserved (for count or sizeof) */
};
struct section_64 { /* for 64-bit architectures */
char sectname[16]; /* name of this section */
char segname[16]; /* segment this section goes in */
uint64_t addr; /* memory address of this section */
uint64_t size; /* size in bytes of this section */
uint32_t offset; /* file offset of this section */
uint32_t align; /* section alignment (power of 2) */
uint32_t reloff; /* file offset of relocation entries */
uint32_t nreloc; /* number of relocation entries */
uint32_t flags; /* flags (section type and attributes)*/
uint32_t reserved1; /* reserved (for offset or index) */
uint32_t reserved2; /* reserved (for count or sizeof) */
uint32_t reserved3; /* reserved */
};
这样，关于load commonds部分，其真正的结构其实和苹果提供的图片有些许的差异：
Data
Mach-O的Data部分，其实是真正存储APP 二进制数据的地方，前面的header和load command，仅是提供文件的说明以及加载信息的功能。
Data部分也被分为若干的部分，除了我们前面提到的Segment外，还包括符号表，代码签名，动态加载器信息等。
而程序的逻辑和数据，则是放在以Segment分割的Data部分中的。我们在这里，仅关心Data中的Segment的部分。
Segment根据内容的不同，分为若干类型，类型名称均是以“双下划线+大写英文”表示，有的Segment下面还会包含若干的section，section的命名是以"双下划线+小写英文"表示。
先来看Segment，Mach-O中有如下几种Segment：
#define SEG_PAGEZERO "__PAGEZERO" /* 当时 MH_EXECUTE 文件时，表示空指针区域 */
#define SEG_TEXT "__TEXT" /* 代码/只读数据段 */
#define SEG_DATA "__DATA" /* 数据段 */
#define SEG_OBJC "__OBJC" /* Objective-C runtime 段 */
#define SEG_LINKEDIT "__LINKEDIT" /* 包含需要被动态链接器使用的符号和其他表，包括符号表、字符串表等 */
这里面注意到到SEG_OBJC，是和OC的runtime相关的。但是根据这篇文章中说所，在OC 2.0中已经废弃掉__OBJC段，而是将其放入到了__DATA段中以__objc开头的section中。这些和runtime相关的sections是本文的重点，我们稍后再分析。我们先看看其他的段。
__TEXT段
__TEXT是程序的只读段，用于保存我们所写的代码和字符串常量，const修饰常量等。
下面是__TEXT段下常见的section：
| Section | 用途 |
|---|---|
| __TEXT.__text | 主程序代码 |
| __TEXT.__cstring | C 语言字符串 |
| __TEXT.__const | const 关键字修饰的常量 |
| __TEXT.__stubs | 用于 Stub 的占位代码，很多地方称之为桩代码。 |
| __TEXT.__stubs_helper | 当 Stub 无法找到真正的符号地址后的最终指向 |
| __TEXT.__objc_methname | Objective-C 方法名称 |
| __TEXT.__objc_methtype | Objective-C 方法类型 |
| __TEXT.__objc_classname | Objective-C 类名称 |
例如，我们点击__TEXT.__objc_classname, 会看到我们程序中所使用到的类的名称：
而在__TEXT.__cstring section中，则看到我们定义的字符串常量（如@“I’m a cat!! miao miao”）：
值得注意的是，这些都是以明文形式展现的。如果我们将加密key用字符串常量或宏定义的形式存储在程序中，可以想象其安全性是得不到保障的。
__DATA段
__DATA段用于存储程序中所定义的数据，可读写。__DATA段下常见的sectin有：
| Section | 用途 |
|---|---|
| __DATA.__data | 初始化过的可变数据 |
| __DATA.__la_symbol_ptr | lazy binding 的指针表，表中的指针一开始都指向 __stub_helper |
| __DATA.nl_symbol_ptr | 非 lazy binding 的指针表，每个表项中的指针都指向一个在装载过程中，被动态链机器搜索完成的符号 |
| __DATA.__const | 没有初始化过的常量 |
| __DATA.__cfstring | 程序中使用的 Core Foundation 字符串（CFStringRefs） |
| __DATA.__bss | BSS，存放为初始化的全局变量，即常说的静态内存分配 |
| __DATA.__common | 没有初始化过的符号声明 |
| __DATA.__objc_classlist | Objective-C 类列表 |
| __DATA.__objc_protolist | Objective-C 原型 |
| __DATA.__objc_imginfo | Objective-C 镜像信息 |
| __DATA.__objc_selfrefs | Objective-C self 引用 |
| __DATA.__objc_protorefs | Objective-C 原型引用 |
| __DATA.__objc_superrefs | Objective-C 超类引用 |
可见，在__DATA段下，有许多以__objc开头的section，而这些section，均是和runtime的加载有关的。
我们将在后续的文章中，继续探讨这些section和runtime的关系。
总结
这次我们一起了解了XNU内核下的二进制文件格式Mach-O。它由header，load command以及data三部分组成:
我们重点应该了解的应该是data部分，因为这里存储着我们程序真正的数据和代码。
在data部分中，又区分为以Segment划分的部分以及代码签名等其他部分。
在Segment下，有区分有若干的section。
常用的Segment有__PAGE_ZERO, __TEXT, __DATA(注意区分Mach-O的data和这里的__DATA段名称)。
参考资料
趣探 Mach-O：文件格式分析
深入理解Macho文件（二）- 消失的__OBJC段与新生的__DATA段
mach-o格式分析
Mach-O 文件格式探索
Mach-O 维基百科