趣探 Mach-O:加载过程

96
作者 Joy___
2017.01.25 21:44* 字数 1841

这是Mach-O系列的第二篇,趣探 Mach-O:文件格式分析是本文的一个基础

我们都知道 Mach-OOS 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-oexec_mach_imgact处理,fat binaryexec_fat_imgact处理,interpreter(解释器)由exec_shell_imgact处理

exec_mach_imgact

源码可以参考:bsd/kern/kern_exec.c

主要是用来对Mach-O做检测,会检测Mach-O头部,解析其架构、检查imgp等内容,并拒绝接受DylibBundle这样的文件,这些文件会由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_64LC_LOAD_DYLINKERLC_CODE_SIGNATURELC_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作为判断,然后返回不同的实例。

这两种实例都是做什么?

ImageLoaderMachOCompressedImageLoaderMachOClassic均继承于ImageLoaderMachOImageLoaderMachO 继承于ImageLoader

sniffLoadCommands会对Mach-Oclassic还是compressed的做一个判断

instantiateMainExecutable是对ImageLoaderMachOCompressedImageLoaderMachOClassic做初始化,并加载load comond命令,之中调用过程也比较简单,可以参考网络的这个图片,比较清晰,具体内容可以看源代码


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

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

参考链接

iOS Develop