iOS 逆向开发15：DYLD加载流程

iOS 逆向开发 文章汇总

目录

• 一、 问题引入
• 二、 编译过程及库
• 三、dyld加载流程分析
• 四、 总结

dyld源码地址、objc源码地址

本文的目的主要是分析dyld的加载流程，了解在main函数之前，底层还做了什么

一、 问题引入

• 创建一个project，在ViewController中重写了load方法，在main中加了一个C++方法，即kcFUnc，请问它们的打印先后顺序是什么？

• 运行程序，查看 load、kcFunc、main的打印顺序，下面是打印结果，通过结果可以看出其顺序是 load --> C++方法 --> main

  打印结果

为什么是这么一个顺序？按照常规的思维理解，main不是入口函数吗？为什么不是main最先执行？

下面根据这个问题，我们来探索在走到main之前，到底还做了什么。

二、 编译过程及库

在分析app启动之前，我们需要先了解iOSapp代码的编译过程以及动态库和静态库。

2.1 编译过程

其中编译过程如下图所示，主要分为以下几步：

• 源文件：载入.h、.m、.cpp等文件
• 预处理：替换宏，删除注释，展开头文件，产生.i文件
• 编译：将.i文件转换为汇编语言，产生.s文件
• 汇编：将汇编文件转换为机器码文件，产生.o文件
• 链接：对.o文件中引用其他库的地方进行引用，生成最后的可执行文件

编译过程

2.2 静态库 和 动态库

• 静态库：在链接阶段，会将可汇编生成的目标程序与引用的库一起链接打包到可执行文件当中。此时的静态库就不会在改变了，因为它是编译时被直接拷贝一份，复制到目标程序里的

  • 好处：编译完成后，库文件实际上就没有作用了，目标程序没有外部依赖，直接就可以运行

  • 缺点：由于静态库可能会有多份，所以会导致目标程序的体积增大，对内存、性能、速度消耗很大

• 动态库：程序编译时并不会链接到目标程序中，目标程序只会存储指向动态库的引用，在程序运行时才被载入

  • 优势：

    • 减少打包之后app的大小：因为不需要拷贝至目标程序中，所以不会影响目标程序的体积，与静态库相比，减少了app的体积大小

    • 共享内存，节约资源：同一份库可以被多个程序使用（UIKit、Foundation）

    • 通过更新动态库，达到更新程序的目的：由于运行时才载入的特性，可以随时对库进行替换，而不需要重新编译代码

  • 缺点：动态载入会带来一部分性能损失，使用动态库也会使得程序依赖于外部环境，如果环境缺少了动态库，或者库的版本不正确，就会导致程序无法运行

静态库和动态库的图示如图所示

静态库和动态库图示

三、dyld加载流程分析

根据dyld源码，以及libobjc、libSystem、libdispatch源码协同分析

什么是dyld？

dyld（the dynamic link editor）是苹果的动态链接器，是苹果操作系统一个重要组成部分，在系统内核做好程序准备工作之后，交由dyld负责余下链接、加载程序工作。

所以 App的启动流程图如下

App启动流程

3.1 app启动的起始点

• 在前文的demo中，在load方法处加一个断点，通过bt堆栈信息查看app启动是从哪里开始的

  app启动起点

  【app启动起点】：通过程序运行发现，是从dyld中的_dyld_start开始的，所以需要去OpenSource下载一份dyld的源码来进行分析

• 也可以通过Xcode左侧的堆栈信息来找到入口

  Xcode堆栈信息

3.2 dyld::_main函数源码分析

• 在dyld-750.6源码中查找_dyld_start,查找arm64架构发现，是由汇编实现，通过汇编注释发现会调用dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue)方法，是一个C++方法（以arm64架构为例）

  image

• 源码中搜索dyldbootstrap找到命名作用空间，再在这个文件中查找start方法，其核心是返回值的调用了dyld的main函数，其中macho_header是Mach-O的头部，而dyld加载的文件就是Mach-O类型的，即Mach-O类型是可执行文件类型，由四部分组成：Mach-O头部、Load Command、section、Other Data，可以通过MachOView查看可执行文件信息

  _main源码实现

• 进入dyld::_main的源码实现，特别长，大约600多行，如果对dyld加载流程不太了解的童鞋，可以根据_main函数的返回值进行反推，这里就不作说明。在_main函数中主要做了一下几件事情：

  • 【第一步：环境变量配置】：根据环境变量设置相应的值以及获取当前运行架构

    第一步

  • 【第二步：共享缓存】：检查是否开启了共享缓存，以及共享缓存是否映射到共享区域，例如UIKit、Foundation等

    第二步

  • 【第三步：主程序的初始化】：调用instantiateFromLoadedImage函数实例化了一个ImageLoader对象

    第三步

  • 【第四步：插入动态库】：判断DYLD_INSERT_LIBRARIES环境变量（该变量只能在获取root权限下才能修改），调用loadInsertedDylib加载

    第四步

  • 【第五步：link 主程序】

    第五步

  • 【第六步：link 插入的动态库】

    第六步

  • 【第七步：弱符号绑定】

    第七步

  • 【第八步：执行初始化方法】

    第八步

  • 【第九步：寻找主程序入口即main函数】：从Load Command读取LC_MAIN入口，如果没有，就读取LC_UNIXTHREAD，这样就来到了日常开发中熟悉的main函数了

    第九步

下面主要分析下【第三步】和【第八步】

3.2.1 第三步:主程序初始化

• sMainExecutable表示主程序变量，查看其赋值，是通过instantiateFromLoadedImage方法初始化

  instantiateFromLoadedImage初始化主程序

• 进入instantiateFromLoadedImage源码，其中创建一个ImageLoader实例对象，通过instantiateMainExecutable方法创建

  instantiateFromLoadedImage源码实现

• 进入instantiateMainExecutable源码，其作用是为主可执行文件创建映像，返回一个ImageLoader类型的image对象，即主程序。其中sniffLoadCommands函数时获取Mach-O类型文件的Load Command的相关信息，并对其进行各种校验

  instantiateMainExecutable源码实现

3.2.2 第八步：执行初始化方法

• 进入initializeMainExecutable源码,主要是循环遍历，都会执行runInitializers方法

  initializeMainExecutable源码实现

• 全局搜索runInitializers(cons,找到如下源码，其核心代码是processInitializers函数的调用

  runInitializers源码实现

• 进入processInitializers函数的源码实现，其中对镜像列表调用recursiveInitialization函数进行递归实例化

  processInitializers源码实现

• 全局搜索recursiveInitialization(cons函数,其源码实现如下

  recursiveInitialization源码实现

在这里，需要分成两部分探索，一部分是notifySingle函数，一部分是doInitialization函数，首先探索notifySingle函数

notifySingle 函数

• 全局搜索notifySingle(函数,其重点是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());这句

  notifySingle源码实现

• 全局搜索sNotifyObjCInit，发现没有找到实现，有赋值操作

  registerObjCNotifiers源码实现

• 搜索registerObjCNotifiers在哪里调用了，发现在_dyld_objc_notify_register进行了调用

  _dyld_objc_notify_register源码实现

  注意：_dyld_objc_notify_register的函数需要在libobjc源码中搜索

• 在objc4-781源码中搜索_dyld_objc_notify_register，发现在_objc_init源码中调用了该方法，并传入了参数，所以sNotifyObjCInit的赋值的就是objc中的load_images，而load_images会调用所有的+load方法。所以综上所述，notifySingle是一个回调函数

  _objc_init源码实现

load函数加载

下面我们进入load_images的源码看看其实现，以此来证明load_images中调用了所有的load函数

• 通过objc源码中_objc_init源码实现，进入load_images的源码实现

  load_images源码实现

• 进入call_load_methods源码实现，可以发现其核心是通过do-while循环调用所有类的+load方法

  call_load_methods源码实现

• 进入call_class_loads源码实现，了解到这里调用的load方法证实我们前文提及的类的load方法

  call_class_loads源码实现

所以，load_images调用了所有的load函数，以上的源码分析过程正好对应堆栈的打印信息

堆栈信息

【总结】load的源码链为：_dyld_start --> dyldbootstrap::start --> dyld::_main --> dyld::initializeMainExecutable --> ImageLoader::runInitializers --> ImageLoader::processInitializers --> ImageLoader::recursiveInitialization --> dyld::notifySingle(是一个回调处理) --> sNotifyObjCInit --> load_images(libobjc.A.dylib)

那么问题又来了，_objc_init是什么时候调用的呢？请接着往下看

doInitialization 函数

• 走到objc的_objc_init函数，发现走不通了，我们回退到recursiveInitialization递归函数的源码实现，发现我们忽略了一个函数doInitialization

  recursiveInitialization源码实现

• 进入doInitialization函数的源码实现

  doInitialization源码实现

  这里也需要分成两部分，一部分是doImageInit函数，一部分是doModInitFunctions函数

  • 进入doImageInit源码实现，其核心主要是for循环加载方法的调用，这里需要注意的一点是，libSystem的初始化必须先运行

    doImageInit源码实现

  • 进入doModInitFunctions源码实现，这个方法中加载了所有Cxx文件

    doModInitFunctions源码实现

    可以通过测试程序的堆栈信息来验证,在C++方法处加一个断点

    C++断点堆栈信息

走到这里，还是没有找到_objc_init的调用？怎么办呢？放弃吗？当然不行，我们还可以通过_objc_init加一个符号断点来查看调用_objc_init前的堆栈信息，

• _objc_init加一个符号断点，运行程序，查看_objc_init断住后的堆栈信息

  _objc_init符号断点堆栈信息

• 在libsystem中查找libSystem_initializer，查看其中的实现

  libSystem_initializer源码实现

• 根据前面的堆栈信息，我们发现走的是libSystem_initializer中会调用libdispatch_init函数，而这个函数的源码是在libdispatch开源库中的，在libdispatch中搜索libdispatch_init

  libdispatch_init源码实现

• 进入_os_object_init源码实现，其源码实现调用了_objc_init函数

  _os_object_init源码实现

  结合上面的分析，从初始化_objc_init注册的_dyld_objc_notify_register的参数2，即load_images，到sNotifySingle --> sNotifyObjCInie=参数2 到sNotifyObjcInit()调用，形成了一个闭环

所以可以简单的理解为sNotifySingle这里是添加通知即addObserver，_objc_init中调用_dyld_objc_notify_register相当于发送通知，即push，而sNotifyObjcInit相当于通知的处理函数，即selector

【总结】：_objc_init的源码链：_dyld_start --> dyldbootstrap::start --> dyld::_main --> dyld::initializeMainExecutable --> ImageLoader::runInitializers --> ImageLoader::processInitializers --> ImageLoader::recursiveInitialization --> doInitialization -->libSystem_initializer（libSystem.B.dylib） --> _os_object_init（libdispatch.dylib） --> _objc_init(libobjc.A.dylib)

第九步：寻找主入口函数

• 汇编调试，可以看到显示来到+[ViewController load]方法

  汇编调试-load

• 继续执行，来到kcFunc的C++函数

  汇编调试-kcFunc

• 点击stepover,继续往下，跑完了整个流程，会回到_dyld_start,然后调用main()函数,通过汇编完成main的参数赋值等操作

  汇编调试回到_dyld_start

  dyld汇编源码实现

  dyld中main部分的汇编源码实现

注意：main是写定的函数，写入内存，读取到dyld，如果修改了main函数的名称，会报错

报错信息

四、 总结

所以，综上所述，最终dyld加载流程，如下图所示，图中也诠释了前文中的问题：为什么是load-->Cxx-->main的调用顺序原图链接

dyld加载流程

总结

图中内容更正：class_load_methods 为call_load_methods

APP启动流程：即DYLD加载APP

• 1.配置环境、2.加载共享缓存、3.主程序的初始化、
• 4.插入动态库、5.link 主程序、6.link 插入的动态库、
• 7.弱符号绑定、8.执行初始化方法--(8.1.objc：load_images：+load）--8.2.加载所有Cxx文件、
• 9.寻找主程序入口即main函数

参考

iOS-底层原理 15：dyld加载流程

iOS-底层探索11：dyld流程分析
iOS-底层探索12：dyld和objc的关联分析（类的加载上）