这是Mach-O系列的第二篇，趣探 Mach-O：文件格式分析是本文的一个基础
我们都知道 Mach-O是 OS X 系统的可执行文件，说到可执行文件肯定离不开进程。在 Linux 中，我们会通过 Fork()来新创建子进程，然后执行镜像通过exec()来替换为另一个可执行程序，至于为什么这么做，解释如下
原因阐述：这是基于操作系统方面的分析。进程可以通过
fork()系统调用来创建子进程，子进程得到与父进程地址空间相同的（但是独立的）一份拷贝，包括文本、数据和bss段、堆以及用户栈等，但是新线程只会复制调用fork的线程。所有父进程中别的线程，到了子进程中都是突然“蒸发”掉的。
我们在线程问题中经常会提到锁，每个锁都有一个持有者（最后一次
lock它的线程）。为了性能，锁对象会因为fork复制到子进程中，但是子进程只复制调用fork的线程，很可能并不拥有锁持有者线程，那么就没有办法解开锁，导致死锁问题、内存泄漏
避免死锁的方法：在子线程中马上调用
exec函数，一个进程一旦调用exec类函数，它本身就"死亡"了，系统把代码段替换成新的程序的代码，废弃原有的数据段和堆栈段，并为新程序分配新的数据段与堆栈段，唯一留下的，就是进程号，也就是说，对系统而言，还是同一个进程，不过已经是另一个程序了。
综上所述，我们在用户态会通过exec*系列函数来加载一个可执行文件，同时exec*都只是对系统调用execve的封装，那我们加载Mach-O的流程，就从execve说起。Mach-O有多种文件类型，比如MH_DYLIB文件、MH_BUNDLE文件、MH_EXECUTE文件（这些需要dyld动态加载），MH_OBJECT（内核加载）等。所以一个进程往往不是只需要内核加载器就可以完成加载的，需要dyld来进行动态加载配合。考虑内核加载和dyld加载两种情况，就会有如下流程图
execve
这个函数只是直接调用 __mac_execve()，对于源码内部实现细节，可以看XNU的源代码
__mac_execve()
源码可以参考：
bsd/kern/kern_exec.c
主要是为加载镜像进行数据的初始化，以及资源相关的操作，在其内部会执行exec_activate_image()，镜像加载的工作都是由它完成的
int
__mac_execve(proc_t p, struct __mac_execve_args *uap, int32_t *retval)
{
struct image_params *imgp;
// 初始化imgp数据
.......
exec_activate_image(imgp);
}
exec_activate_image
源码可以参考：
bsd/kern/kern_exec.c
主要是拷贝可执行文件到内存中，并根据不同的可执行文件类型选择不同的加载函数，所有的镜像的加载要么终止在一个错误上，要么最终完成加载镜像。在OS X中专门处理可执行文件格式的程序叫execsw镜像加载器
OS X有三种可执行文件，mach-o由exec_mach_imgact处理，fat binary由exec_fat_imgact处理，interpreter（解释器）由exec_shell_imgact处理
exec_mach_imgact
源码可以参考：
bsd/kern/kern_exec.c
主要是用来对Mach-O做检测，会检测Mach-O头部，解析其架构、检查imgp等内容，并拒绝接受Dylib和Bundle这样的文件，这些文件会由dyld负责加载
然后把Mach-O映射到内存中去，调用load_machfile()
load_machfile
源码可以参考：
bsd/kern/mach_loader.c
load_machfile会加载Mach-O中的各种load monmand命令。在其内部会禁止数据段执行，防止溢出漏洞攻击，还会设置地址空间布局随机化（ASLR），还有一些映射的调整。
真正负责对加载命令解析的是parse_machfile()
parse_machfile
源码可以参考：
bsd/kern/mach_loader.c
parse_machfile会根据load_command的种类选择不同的函数来加载，内部是一个Switch语句来实现的
常见的命令有LC_SEGMENT_64、LC_LOAD_DYLINKER、LC_CODE_SIGNATURE、LC_UUID等，更多命令可以查看Mach-O文件格式，也可以查询这篇文章-趣探 Mach-O：文件格式分析
对于命令的加载会进行多次扫描，当扫描三次之后，并且存在dylinker_command命令时，会执行 load_dylinker()，启动动态链接器 (dyld)
动态链接过程
动态链接也有区分，一种是加载主程序（很多博客里这么写），是由load commands指定的dylib，以静态的方式存放在二进制文件里，一种是由DYLD_INSERT_LIBRARIES动态指定。下面这种就是提前指定在二进制文件中的动态库，下面的阐述主要是站在前者的角度，对于动态指定的后期再研究
你可以在 load 方法处打一个断点看一下，通过查看调用栈可以发现：
0 +[XXObject load]
1 call_class_loads()
2 call_load_methods
3 load_images
4 dyld::notifySingle(dyld_image_states, ImageLoader const*)
11 _dyld_start
_dyld_start甚是耀眼，觉得是dyld的入口，然后就去看dyld的源代码，全局搜了一下_dyld_start，就发现注释，于是顺着注释往下阅读
源码可以参考：
dyld/src/dyld.cpp
内核会加载dyld并调用dyld_start方法，随后dyld_start会调用_main()，在_main函数中对数据进行一通初始化之后，就会调用instantiateFromLoadedImage函数初始化ImageLoader实例
// instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
instantiateFromLoadedImage
// The kernel maps in main executable before dyld gets control. We need to
// make an ImageLoader* for the already mapped in main executable.
static ImageLoader* instantiateFromLoadedImage(const macho_header* mh, uintptr_t slide, const char* path)
{
// try mach-o loader
if ( isCompatibleMachO((const uint8_t*)mh, path) ) {
ImageLoader* image = ImageLoaderMachO::instantiateMainExecutable(mh, slide, path, gLinkContext);
addImage(image);
return image;
}
throw "main executable not a known format";
}
instantiateFromLoadedImage这个函数内的代码比较容易理解，检测Mach-O是否合法，合法的话就初始化ImageLoader实例，然后将其加入到一个全局的管理ImageLoader的数组中去
isCompatibleMachO会对Mach-O头部的一些信息与当前平台进行比较，判断其合法性。
ImageLoader
//
// ImageLoader is an abstract base class. To support loading a particular executable
// file format, you make a concrete subclass of ImageLoader.
//
// For each executable file (dynamic shared object) in use, an ImageLoader is instantiated.
//
// The ImageLoader base class does the work of linking together images, but it knows nothing
// about any particular file format.
//
//
class ImageLoader {
}
注释可得，ImageLoader是一个抽象基类，每一个动态加载的可执行文件都会初始化一个ImageLoader实例
instantiateMainExecutable
源码可以参考：
dyld/src/ImageLoaderMachO.cpp
// create image for main executable
ImageLoader* ImageLoaderMachO::instantiateMainExecutable(const macho_header* mh, uintptr_t slide, const char* path, const LinkContext& context)
{
bool compressed;
unsigned int segCount;
unsigned int libCount;
const linkedit_data_command* codeSigCmd;
const encryption_info_command* encryptCmd;
sniffLoadCommands(mh, path, false, &compressed, &segCount, &libCount, context, &codeSigCmd, &encryptCmd);
// instantiate concrete class based on content of load commands
if ( compressed )
return ImageLoaderMachOCompressed::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
else
#if SUPPORT_CLASSIC_MACHO
return ImageLoaderMachOClassic::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
#else
throw "missing LC_DYLD_INFO load command";
#endif
}
可以这里会有一个Bool类型的compressed作为判断，然后返回不同的实例。
这两种实例都是做什么？
ImageLoaderMachOCompressed与ImageLoaderMachOClassic均继承于ImageLoaderMachO，ImageLoaderMachO 继承于ImageLoader
sniffLoadCommands会对Mach-O是classic还是compressed的做一个判断
instantiateMainExecutable是对ImageLoaderMachOCompressed或ImageLoaderMachOClassic做初始化，并加载load comond命令，之中调用过程也比较简单。
这篇文章写得比较简陋，后期发现了更佳的文章，朋友们可以参考这三篇文章学习加载过程。（更新于2017.09.25）
- XNU、dyld源码分析Mach-O和动态库的加载过程(上)
- XNU、dyld 源码分析，Mach-O 和动态库的加载过程 (下)
- dylib动态库加载过程分析
参考链接
- dyld sourcecode analysis
- 手把手教你hook以root权限运行的App
- 你真的了解 load 方法么？
- 深入理解 MAC OS X & iOS 操作系统
- XNU sourcecode
- dyld sourcecode