iOS逆向实战--017：dyld源码解析

dyld：动态链接器，加载所有的库和可执行文件

加载App时的函数调用栈

搭建空项目dyldDemo，在main函数上设置断点

真机运行项目，只有start和main两个函数调用栈，显然是不合理的

想查看完整的函数调用栈，需要在main函数调用前，在load函数上设置断点

打开ViewController，写入load函数，设置断点

真机运行项目，使用bt命令，查看完整的函数调用栈

dyldDemo`+[ViewController load](self=ViewController, _cmd="load") at ViewController.m:23:1
libobjc.A.dylib`load_images + 944
dyld`dyld::notifySingle(dyld_image_states, ImageLoader const*, ImageLoader::InitializerTimingList*) + 464
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 512
dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 184
dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 92
dyld`dyld::initializeMainExecutable() + 216
dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 5216
dyld`dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, >dyld3::MachOLoaded const*, unsigned long*) + 396
dyld`_dyld_start + 56

一切的开端，由dyldbootstrap命名空间下的start函数开始

start函数

打开dyld源码，搜索dyldbootstrap，找到dyldInitialization.cpp文件

打开dyldInitialization.cpp文件，找到start函数

• 1：重定位dyld，进程启动，它的虚拟内存地址就要进行重定位
• 2：对于栈溢出的保护
• 3：初始化dyld
• 4：调用dyld的_main函数

在start函数中，最为重要的就是最后一步，调用dyld的_main函数

打开dyld2.cpp文件，找到_main函数

• 内核检查代码

---

• 1：主程序可执行文件
• 2：设置HostCPU等信息
  
• 3：设置可执行文件的Header，设置ASLR
  
• 前面的100000000是__PAGEZERO中的4G虚拟缓存
• 后面的4140000是ASLR随机地址，每次加载MachO都不一样

---

• setContext：设置上下文
  
• 全部存储在gLinkContext对象中

---

• 1：配置进程是否受限，苹果进程受AFMI保护（Apple Mobile File Integrity苹果移动文件保护）
• 2：判断是否强制使用dyld3
• 3：判断环境变量，如果发生改变，再次调用setContext设置上下文。否则检测环境变量，设置默认值

---

• 在项目中配置DYLD_PRINT_OPTS、DYLD_PRINT_ENV环境变量，可以进行打印
  

---

• 1：加载共享缓存，UIKit、Foundation等系统动态库，都存储在共享缓存中。在iOS中，必须有共享缓存
• 2：调用mapSharedCache函数，传递ASLR

加载共享缓存

进入mapSharedCache函数

• 调用loadDyldCache函数

---

进入loadDyldCache函数

• 1：满足条件，依赖库只加载到当前进程
• 2：如果已经加载共享缓存，不做任何处理
• 3：首次加载，调用mapCacheSystemWide函数

---

加载App之前，首先加载的就是共享缓存。每个App都需要UIKit、Foundation等系统动态库，但程序之前的进程不互通，所以系统动态库存放在共享缓存中

加载逻辑，根据上述三种情况进行判断

自己写的动态库和其他三方库，不会存储在共享缓存中

dyld3闭包模式

在iOS11后，引入dyld3的闭包模式，以回调的方式加载，加载更快，效率更高

在iOS13后，动态库和三方库，也使用闭包模式加载

回到_main函数

• 1：判断sClosureMode，如果是闭包模式，执行else代码分支
• 2：配置如何加载MachO
• 3：闭包也是实例对象，优先从共享缓存中获取实例对象

---

• 1：如果对象不为空，但对象已失效，重新将对象设置为nullptr
• 2：再次判断对象是否为空，如果为空，在缓存中获取对象
• 3：如果缓存中未找到对象，调用buildLaunchClosure函数创建

---

• 1：判断对象不为空，调用launchWithClosure函数启动，传入闭包对象，返回是否成功的结果
• 2：如果启动失败并且过期，再创建一次
• 3：判断再次创建的对象不为空，再次启动
• 4：如果启动成功，拿到主程序main的函数，直接返回结果

dyld2流程

如果不是dyld3的闭包模式，进入dyld2流程

• 1：不使用dyld3的闭包模式，将变量设置为0，表示使用旧模式加载
• 2：把两个回调地址放到stateToHandlers数组中
• 3：分配初始化空间，尽量分配足够大的空间，以供后续使用
• 4：把dyld加入到UUID的列表中

实例化主程序

不论执行dyld2还是dyld3的流程，后面都会执行实例化主程序的代码

实例化主程序，第一个靠dyld加载的就是主程序

• 调用instantiateFromLoadedImage函数，传入主程序的Header，ASLR，路径

---

进入instantiateFromLoadedImage函数

• 调用instantiateMainExecutable函数，返回image对象

---

进入instantiateMainExecutable函数

• 调用sniffLoadCommands函数，读取Load Commands数据

---

进入sniffLoadCommands函数

• compressed：分析MachO文件获取的值
• segCount：Segment总数
• libCount：依赖库总数
• codeSigCmd：签名
• encryptCmd：加密

来到sniffLoadCommands函数结尾处

• 1：程序的Segment总数，不能超过255
• 2：程序的依赖库总数，不能超过4095

---

回到instantiateMainExecutable函数

• 根据compressed判断，使用相应的子类实例化主程序，返回实例对象

---

回到instantiateFromLoadedImage函数

• 拿到实例化后的image对象
• 将image对象添加到image列表中
• 返回image对象

所以image列表中，第一个image一定是主程序

---

回到_main函数

• 检测代码，检查设备、系统版本等

---

• 设置加载动态库的版本

加载动态库

• 1：判断环境变量，是否有插入的动态库
• 2：如果有，遍历插入的动态库，依次调用loadInsertedDylib函数
• 3：调用link函数，链接主程序

---

进入link函数

• 1：记录起始时间
• 2：递归加载主程序依赖的库，完成之后发通知
• 3：重定向，修正ASLR
• 4：绑定非懒加载符号
• 5：绑定弱引用符号

• 1：递归应用插入的动态库
• 2：注册
• 3：记录结束时间
• 4：计算时间差，当项目配置环境变量，用于显示各步骤耗时

---

回到_main函数

• 读取动态库使用i + 1，因为起始位置是主程序
• 链接动态库

---

• 判断条件不满足，使用goto语句，跳回到reloadAllImages代码处，重新加载镜像

---

• 循环绑定插入的动态库
• 绑定弱引用符号
• 初始化main方法

初始化主程序

进入initializeMainExecutable函数

• 1：先遍历初始化动态库
• 2：调用runInitializers函数，初始化主程序

---

进入runInitializers函数

• 调用processInitializers函数

---

进入processInitializers函数

• 调用recursiveInitialization函数

---

进入recursiveInitialization函数

• 调用notifySingle函数

函数调用栈顺序，notifySingle函数中，应该会调用load_images函数

但是在notifySingle函数中，并没有发现load_images函数的调用，因为load_images是objc中的函数

libobjc.A.dylib`load_images + 944

在dyld中，是如何调用objc的函数?

进入notifySingle函数

• 如果sNotifyObjCInit不为空，使用回调指针，执行一个回调函数

---

搜索sNotifyObjCInit的赋值

• 由registerObjCNotifiers函数，将init入参赋值给sNotifyObjCInit

---

搜索registerObjCNotifiers函数的调用

• 在dyldAPIs.cpp文件中，被_dyld_objc_notify_register函数调用，init为函数的入参

---

搜索_dyld_objc_notify_register函数，找不到任何调用的代码

使用另一种方式寻找

在dyldDemo项目中，设置_dyld_objc_notify_register符号断点

• 通过符号断点看出，回调函数是_objc_init初始化时赋值的

来到objc源码，搜索_objc_init函数

• 调用_dyld_objc_notify_register函数，传入load_images

objc中，调用dyld中的_dyld_objc_notify_register函数，传入load_images函数

dyld使用回调指针，调用objc中的load_images函数

---

进入load_images函数

• 调用call_load_methods函数

---

进入call_load_methods函数

• 调用call_class_loads函数，循环调用每个类中的load方法

回到dyld源码

回到recursiveInitialization函数，调用doInitialization函数

• 调用doInitialization函数

---

进入doInitialization函数

• 调用doModInitFunctions函数

doInitialization函数的作用？

在dyldDemo项目中，打开main.m文件，加入C++构造函数：

__attribute__((constructor)) void func1(){
   printf("fun1 来了!");
}

__attribute__((constructor)) void func2(){
   printf("fun2 来了!");
}

编译项目，打开MachO文件

• MachO中多出_mod_init_func

doInitialization函数的作用，调用全局C++对象的构造函数

回到_main函数

• 1：读取MachO的LC_MAIN，找到主程序的main函数地址
• 2：经过一系列判断，返回main函数

加载顺序：load方法（objc调用），C++构造函数（dyld调用)，main函数（dyld调用）

总结

dyld：动态链接器，加载所有的库和可执行文件

start函数

• 重定位dyld
• 调用_main函数

_main函数

• 内核检查，然后一系列设置，HostCPU、可执行文件的Header、ASLR、设置上下文、配置进程是否受限（AFMI）
• 加载共享缓存
• 选择dyld3或dyld2
• 实例化主程序
  ◦ 根据compressed判断，使用相应的子类实例化主程序，返回实例对象
  ◦ 拿到实例化后的image对象，将image对象添加到image列表中，返回image对象
  ◦ 所以image列表中，第一个image一定是主程序
• 加载动态库，优先插入的动态库，依次将image对象添加到image列表中，使用环境变量DYLD_INSERT_LIBRARIES
• 链接主程序
  ◦ 递归加载主程序依赖的库，完成之后发通知
  ◦ 重定向，修正ASLR
  ◦ 绑定非懒加载符号
  ◦ 绑定弱引用符号
  ◦ 递归应用插入的动态库
  ◦ 注册
• 初始化主程序，initializeMainExecutable函数
  ◦ 调用runInitializers函数
  ◦ 调用processInitializers函数
  ◦ 调用recursiveInitialization函数
• 返回主程序的入口函数，开始进入主程序的main函数

dyld3闭包模式

• 优先从共享缓存中获取实例对象，不存在创建一个
• 调用launchWithClosure函数启动，传入闭包对象
• 如果启动成功，拿到主程序main的函数，直接返回结果

dyld2流程

• 把两个回调地址放到stateToHandlers数组中
• 分配初始化空间，尽量分配足够大的空间，以供后续使用
• 把dyld加入到UUID的列表中

recursiveInitialization函数

• 调用notifySingle函数
• 调用doInitialization函数

notifySingle函数

• 如果sNotifyObjCInit不为空，使用回调指针，执行一个回调函数
• 通过符号断点看出，回调是_objc_init函数初始化时赋值的
  ◦ _objc_init函数在objc源码中
  ◦ 调用dyld中的_dyld_objc_notify_register函数，传入load_images函数
  ◦ 调用call_class_loads函数，循环调用每个类中的load方法，动态库优先于主程序的load方法执行

doInitialization函数

• 调用doModInitFunctions函数，内部调用全局C++对象的构造函数__attribute__((constructor))的C函数

加载顺序：load方法（objc调用），C++构造函数（dyld调用)，main函数（dyld调用）