1. 概述
在Mac的开发中， 有没有想过当我们点击可执行文件之后，Mac究竟做了什么事情才让我们的程序运行起来？操作系统启动一个程序时, 内核会为程序创建一个进程空间，并且会为进程创建一个主线程。主线程会执行各种初始化操作，完成后才开始执行我们在程序中定义的main函数。也就是说main函数并不是主线程最开始执行的函数，在main函数之前其实还发生了很多的事情。
我们称每个映射到内存空间中的可执行文件以及动态库文件的副本为image(镜像)。系统内核所加载的可执行程序以依赖的动态库是符合苹果操作系统ABI规则的 Mach-O 格式的二进制数据，这些数据要被加载到内存中，对应的代码才能被执行以及变量才能被访问。
注意：当所有的image加载完毕后，内核会为进程创建一个主线程，并将这些image在内存中的地址作为参数压入用户态的堆栈中，把dyld中的_dyld_start函数作为主线程执行的入口函数。这时内核将控制权交给用户，系统由内核态转换为用户态。dyld来实现加载和初始化可执行文件、动态库的逻辑。
对于应用层开发人员或者普通的用户而言， 其实无需知道的这么详细；但是对于内核开发人员而言， 如果能了解这一系列的过程， 那么将增强我们的内核的开发功底。
2. 准备工作
1）可以下载 XNU内核源代码以及dyld源代码；
2）Xcode、vim 或者其他什么浏览源代码的工具，下载 MachOView 工具。
在分析加载过程的时候， 需要涉及到内核和应用层两个部分。Mac的内核经过多次的发展， 目前这部分被称作XNU。具体为什么叫这个名字， 大家可以去搜索一下。在最初开始设计XNU的时候， Apple是打算设计一个微内核， 也就是将最重要的事情放在内核里面并且内核只负责仲裁而非逻辑处理。 这个内核也就是在Mac OS 9上面使用的内核，但是这个产品是一个效率底下系统。因此当乔布斯回归以后对内核进行了大改， 在内核部分引入了FreeBSD的部分， 这个产品就是我们现在在使用的Mac OSX的内核XNU。
3. Mach-O 文件的结构
Mach-O 文件在结构上分为三部分：
1）文件头
2）命令区域
3）数据区域（包括数据， 代码等等）
3.1 文件头
Mach-O 文件Header定义包含了32bit和64bit两部分，定义如下：
// struct mach_header(_64)
//代码来自：${XNU_ROOT}/EXTERNAL_HEADER/mach-o/loader.h
struct mach_header {
uint32_t magic;
cpu_type_t cputype;
cpu_subtype_t cpusubtype;
uint32_t filetype;
uint32_t ncmds;
uint32_t sizeofcmds;
uint32_t flags;
};
struct mach_header_64 {
uint32_t magic;
cpu_type_t cputype;
cpu_subtype_t cpusubtype;
uint32_t filetype;
uint32_t ncmds;
uint32_t sizeofcmds;
uint32_t flags;
uint32_t reserved;
};
字段的含义如下（下面是以64bit的头部说明的）：
| 命令 | 含义 | 说明 |
|---|---|---|
| magic | 魔数字 | 主要用来区分当前Mach-O所支持的CPU架构(当前只有32bit和64bit)。 |
| cputype | CPU类型 | 主要的CPU类型(32/64bit), 以及其他的属性。 |
| cpusubtype | CPU子类型 | cpu具体的类型。 |
| filetype | 文件类型 | 文件类型比较多，比如MH_EXECUTE代表可执行文件。 |
| ncmds | 命令个数 | 也就是下一个segment中得segment的数量。 |
| sizeofcmd | 第三个部分的大小 | None。 |
| flags | 当前Mach-O的属性 | 比较常见的属性包括MH_PIE(当前文件执行ASLR)等。 |
3.2 命令区域
这是 Mach-O 文件中最重要的部分，我们从上面的Mach-O结构图中可以看到， 所谓的segment其实是数据区域的一个索引，每个segment都在数据区域对应了一段自己的区域，我们需要做的就是找到这些部分并执行他们。Segment的结构定义如下:
// struct load_command
// 代码来自:${XNU_ROOT}/EXTERNAL_HEADER
struct load_command {
uint32_t cmd; /* type of load command */
uint32_t cmdsize; /* total size of command in bytes */
};
其中，cmd代表当前段的类型，cmdsize当前段的大小。 下面我们列出一部分cmd命令， 以下并不是命令的全部，只是这些命令在内核加载过程中被调用。
| 命令 | 十六进制 | 作用 |
|---|---|---|
| LC_SEGMENT LC_SEGMENT_64 | 0x01/0x19 | 将这些段加载到对应的进程空间上去(区分32位和64位) |
| LC_LOAD_DYLINKER | 0x0E | 加载dyld, 值得注意的是，每个Mach-O文件只能有一个段 |
| LC_UUID | 0x1B | 将UUID这个值保存到执行进程的上下文中，同样每个Mach-O文件只能有一个段 |
| LC_THREAD | 0x04 | 开启一个Mach线程， 但是不分配栈（这个不常见） |
| LC_UNIXTHREAD | 0x05 | 开启一个UNIX线程，其实最主要的用途是告诉加载器当前主函数的位置. |
| 这条命令在10.8之后被LC_MAIN取代。 | ||
| LC_MAIN | 0x80000028 | 在10.8之后代替LC_UNIXTHREAD， 告诉加载器当前主函数的位置 |
| LC_CODE_SIGNATURE | 0x1D | 这个是数字签名段 |
| LC_ENCRYPTION_INFO | 0x21 | 加密二进制文件， 貌似在IOS下使用的比较频繁。 |
下面是Mac for QQ的二进制文件格式：
上图右侧是QQ可执行文件Header的内容， 可知该文件是一个32位的Mach-O文件，文件类型是MH_EXEXUTE，即可执行文件。 这个执行文件一共有56个segment， 全部的segment的大小有6580。最后一个数据是flag， 则在加载的时候必须使用 ASLR 内存保护技术，除此之外还有一个标志位MH_NO_HEAP_EXECUTION，这个标志位是防止当前的可执行文件的数据部分有执行权限， 一旦有执行权限， 黑客可以进行所谓的“堆喷射攻击”。
我们发现当前segment中LC_SEGMENTM可以存在多个；对于LC_UUID、LC_MAIN、LC_LOAD_DYLINKER等段来说，有且仅有一个。
注：当前这个可执行文件中存在段LC_MAIN， 说明当前QQ的编译环境是Mac OSX 10.8+（LC_MAIN是在10.8的时候引入的）， 因此只有10.8或者更高版本的系统才能编译出这个二进制文件。
3.3 数据区域
这部分是除了 Header 和 Commands 外所有的原始数据。Commands 是对数据区的汇总提示，而数据区则是真实的数据。
接下来先介绍几个比较重要的模块：
- (__TEXT,__text)
这里存放的是汇编后得到的代码，每个.m文件会经过预编译->编译->汇编形成.o文件，称之为目标文件。所有的代码汇编后形成的汇编指令存储在.o文件的中，链接后，所有的.o文件会合并成一个文件，所有.o文件都会按链接顺序存放到应用文件的(__TEXT,__text）中，而（__DATA,__data）也是类似。
- (__DATA,__data)
存储数据的 section，static 在进行非零赋值后会存储在这里，如果 static 变量没有赋值或者赋值为0，那么它会存储在（__DATA,__bss）中。
- Symbol Table
符号表，这个是重点中的重点，符号表是将地址和符号联系起来的桥梁。符号表并不能直接存储符号，而是存储符号位于字符串表的位置。
- String Table
字符串表，所有的变量名、函数名等都以字符串的形式存储在字符串表中。
- 动态符号表
动态符号表存储的是动态库函数位于符号表的偏移信息。(__DATA,__la_symbol_ptr) section 可以从动态符号表中获取到该section位于符号表的索引数组。
动态符号表并不存储符号信息，而是存储其位于符号表的偏移信息。Fishhook源码看起来比较复杂主要是因为hook的是动态链接的函数，索引和链接关系比较绕。但是我们自己编写的C函数不是动态链接的，而是在编译链接后代码指令就存储在文件内部的函数，因此不会用到动态符号表。接下来我们以static 函数为例，看看如何动态的查找自己编写的函数地址。
3.4 动态调用static函数
我们发现Mach-O文件中存放了所有编译过的的函数指令，static 函数也一定在其中。假设在文件中有如下函数：
在Mach-O文件中，搜索代码段，可以发现静态函数存放在代码段中，其地址为0x1000010C0
那么我们如何通过函数的名称获取到函数地址呢？所谓的函数名实际上就是函数符号，因此函数地址与函数名是强关联的。
符号表其实是个结构体数组，结构体nlist_64中包括该符号位于字符串表的偏移，section索引，以及对应的地址信息等。在符号表中，我们不能直接获取到其对应的符号，在图中能看到的符号“_s_cleanup”实际上是工具帮我们获取好后展示出来的，在代码中只能拿到其位于字符串表中的索引，在_s_cleanup的符号表中其索引为0x594，也就是说字符串表+0x594即为_s_cleanup字符串符号。
从上图中可以看出字符串表的起始地址为0x6004，0x6004+0x594 = 0x6598。
获取到字符串符号后，我们可以知道这个符号是不是我们想要的符号，如果是我们想要的符号，那么获取其函数地址。到这里，应该说通过Mach-O文件获取静态链接函数地址已经完美解决了。注意：从cpu的角度看，这个函数地址并不是真实的地址，需要计算出其相对于真实地址的偏移，再加上真实文件地址即为真实函数地址。
那么如何获取函数符号表、字符串表呢？实际上segment和符号表在Commands中是顺序存放的，_mh_execute_header.ncmds可以根据索引遍历所有的Command。
找到LC_SYMTAB后，LC_SYMTAB会告诉我们符号表位于可执行文件的偏移以及字符串表位于可执行文件的偏移。地址计算后即可得到符号表和字符串表
最终效果如下：
细心的同学可能会发现一个bug，static 函数在不同的文件中是可以同名的，参数只有一个函数符号的话如何确定是哪个文件中函数？实际上在符号表中，是可以存在相同符号的，即如果两个文件中都存在s_cleanup函数，那么符号表中会存在两个_s_cleanup,只不过他们的函数地址不同。那么如何区分同名静态函数呢？实际上在链接时，各个段可以理解为按文件的顺序存放的，也就是说符号表实际上也是存在文件顺序的。
符号表的type可以区分出这个符号是否是文件相关信息，type == 0x64则是文件相关信息，因此在遍历符号表时可以判断出当前正在遍历哪个文件的符号。能判断出正在遍历哪个文件，那么bug就迎刃而解。
另外，如果static 函数只是在代码中实现了，但是并没有任何调用的地方，那么在编译时，编译器会将static函数优化掉，不会生成相关指令。因此符号表中不会存储static函数相关信息，也就无法实现动态调用。如果想要做到static 数据存取，那么方式与此类似，只不过获取到的地址不是函数地址，而是数据存储地址，如果static 是函数内的局部变量，那么其符号需要加上函数符号，比如：
那么它的静态变量s_iData符号为"_application:didFinishLaunchingWithOptions:.s_iData”。通过memset即可修改变量的值。
关于Mach-O还有个比较有意思的是，我们可以自定义section，将数据和函数指令放入我们指定的section中，
编译链接后，其文件中多了个(__TEXT,__mysection)，并且函数还能正常运行。这为我们进行代码混淆又提供了一个手段。
参考文章：
https://www.jianshu.com/p/5c2c7c39f6aa
https://www.bbsmax.com/A/1O5E3rQ3z7/
https://www.cnblogs.com/feng9exe/p/8260053.html
关于 dyld 的细节、FishHook ？？？
