趣探 Mach-O：加载过程

[http://ios.jobbole.com/92734/]

这是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()，镜像加载的工作都是由它完成的

1

2

3

4

5

6

7

8

9

10

11

12

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 方法处打一个断点看一下，通过查看调用栈可以发现：

1

2

3

4

5

6

0  +[XXObjectload]

1  call_class_loads()

2  call_load_methods

3  load_images

4  dyld::notifySingle(dyld_image_states,ImageLoaderconst*)

11_dyld_start

_dyld_start甚是耀眼，觉得是dyld的入口，然后就去看dyld的源代码，全局搜了一下_dyld_start，就发现注释，于是顺着注释往下阅读

源码可以参考：dyld/src/dyld.cpp

内核会加载dyld并调用dyld_start方法，随后dyld_start会调用_main()，在_main函数中对数据进行一通初始化之后，就会调用instantiateFromLoadedImage函数初始化ImageLoader实例

1

2

// instantiate ImageLoader for main executable

sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);

instantiateFromLoadedImage

1

2

3

4

5

6

7

8

9

10

11

12

13

// The kernel maps in main executable before dyld gets control.  We need to

// make an ImageLoader* for the already mapped in main executable.

staticImageLoader*instantiateFromLoadedImage(constmacho_header*mh,uintptr_tslide,constchar*path)

{

    // try mach-o loader

    if(isCompatibleMachO((constuint8_t*)mh,path)){

        ImageLoader*image=ImageLoaderMachO::instantiateMainExecutable(mh,slide,path,gLinkContext);

        addImage(image);

        returnimage;

    }

 

    throw"main executable not a known format";

}

instantiateFromLoadedImage这个函数内的代码比较容易理解，检测Mach-O是否合法，合法的话就初始化ImageLoader实例，然后将其加入到一个全局的管理ImageLoader的数组中去

isCompatibleMachO会对Mach-O头部的一些信息与当前平台进行比较，判断其合法性。

ImageLoader

1

2

3

4

5

6

7

8

9

10

11

12

13

//

// 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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

// create image for main executable

ImageLoader*ImageLoaderMachO::instantiateMainExecutable(constmacho_header*mh,uintptr_tslide,constchar*path,constLinkContext&context)

{

    boolcompressed;

    unsignedintsegCount;

    unsignedintlibCount;

    constlinkedit_data_command*codeSigCmd;

    constencryption_info_command*encryptCmd;

    sniffLoadCommands(mh,path,false,&compressed,&segCount,&libCount,context,&codeSigCmd,&encryptCmd);

 

    // instantiate concrete class based on content of load commands

    if(compressed)

        returnImageLoaderMachOCompressed::instantiateMainExecutable(mh,slide,path,segCount,libCount,context);

    else

#if SUPPORT_CLASSIC_MACHO

        returnImageLoaderMachOClassic::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命令，之中调用过程也比较简单，可以参考网络的这个图片，比较清晰，具体内容可以看源代码

至此，主二进制文件的加载就结束，然后会链接各种DYLD_INSERT_LIBRARIES动态库，以上就是非常粗略的了解了下加载Mach-O的过程，后期有需要再深入研究

写的比较仓促，难免有错误的地方，望包涵并告知

参考链接

• dyld sourcecode analysis
• 手把手教你hook以root权限运行的App
• 你真的了解 load 方法么？
• 深入理解 MAC OS X & iOS 操作系统
• XNU sourcecode
• dyld sourcecode