iOS 程序启动流程解密 IOS安全

hkwljs 2017-7-24 14174


main 函数是 iOS 程序的入口,我们写的代码都是在 main 函数之后执行的,但是在夜深人静的时候,我的脑海中经常会冒出这样的问题:main 函数之前到底发生了什么?用户点击程序图标之后,我们的 App 是怎样被启动的?这期间系统做了哪些事情、经历了哪些步骤才一步步地调用到程序 main 函数的?于是我又献祭了自己的空闲时间对 iOS 应用的启动流程进行了一番探究。

调研结论

咳咳,这里先把结论贴出来,然后再一步步分析,对总体流程有了一个大体的认识才不会在技术细节中迷路:

(1) 系统为程序启动做好准备

(2) 系统将控制权交给 Dyld,Dyld 会负责后续的工作

(3) Dyld 加载程序所需的动态库

(3) Dyld 对程序进行 rebase 以及 bind 操作

(4) Objc SetUp

(5) 运行初始化函数

(6) 执行程序的 main 函数

步骤比较多,不过不用担心,我会结合代码对其进行进一步的讲解。

Dyld

在用户点击应用后,系统内核会去创建一个新的进程并为应用的执行做好准备,详情可参考趣探 Mach-O:加载过程,之后会去调用 Dyld 来接管后续的工作。Dyld 是 iOS 系统的动态链接器,它的代码在这里,整体来说它的机制还是比较复杂的,所里这里只是简单概括一下,感兴趣的同志可以下载源码阅读。

Dyld 的启动代码源于 dyldStartup.s 文件,在一大串的汇编代码中有个名为 __dyld_start 的方法,它会去调用 dyldbootstrap::start() 方法,然后进一步调用 dyld::_main() 方法,里面包含 App 的整个启动流程,该函数最终返回应用程序 main 函数的地址,最后 Dyld 会去调用它。dyld::_main() 函数的源码很长,所以这里只保留关键信息,并用伪代码进行简化从而得到整体流程:

uintptr_t _main(···/省略参数/···) {     // 1. 设置运行环境     ......      // 2. instantiate ImageLoader for main executable     sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);         ......      //3. link main executable     link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);      ......      //4. run all initializers     initializeMainExecutable();       ......      //5. find entry point for main executable     result = (uintptr_t)sMainExecutable->getThreadPC();      ......      return result; }

接下来我会对以上关键代码进行解读,希望大家对启动流程有着更为清晰的认识。

加载可执行文件

二进制文件常被称为 image,包括可执行文件、动态库等,ImageLoader 的作用就是将二进制文件加载进内存。dyld::_main() 方法在设置好运行环境后,会调用 instantiateFromLoadedImage 函数将可执行文件加载进内存中,加载过程分为三步:

  1. 合法性检查。主要是检查可执行文件是否合法,是否能在当前的 CPU 架构下运行。

  2. 选择 ImageLoader 加载可执行文件。系统会去判断可执行文件的类型,选择相应的 ImageLoader 将其加载进内存空间中。

  3. 注册 image 信息。可执行文件加载完成后,系统会调用 addImage 函数将其管理起来,并更新内存分布信息。

以上三步完成后,Dyld 会调用 link 函数开始之后的处理流程。另外补充下,如果有同学对 ImageLoader 感兴趣的话,dyld 加载 Mach-O这篇文章是不错的,推荐大家看。

Load Dylibs

link(sMainExecutable, ……) 函数究竟做了些什么,我们可以从源码中一探究竟:

void ImageLoader::link(···/省略参数/···) {     //dyld::log("ImageLoader::link(%s) refCount=%d, neverUnload=%d/n", imagePath, fDlopenReferenceCount, fNeverUnload);      // clear error strings     (*context.setErrorStrings)(0, NULL, NULL, NULL);      uint64_t t0 = mach_absolute_time();     this->recursiveLoadLibraries(context, preflightOnly, loaderRPaths, imagePath);     context.notifyBatch(dyld_image_state_dependents_mapped, preflightOnly);      // we only do the loading step for preflights     if ( preflightOnly )         return;      uint64_t t1 = mach_absolute_time();     context.clearAllDepths();     this->recursiveUpdateDepth(context.imageCount());      uint64_t t2 = mach_absolute_time();      this->recursiveRebase(context);     context.notifyBatch(dyld_image_state_rebased, false);      uint64_t t3 = mach_absolute_time();      this->recursiveBind(context, forceLazysBound, neverUnload);      uint64_t t4 = mach_absolute_time();     if ( !context.linkingMainExecutable )         this->weakBind(context);     uint64_t t5 = mach_absolute_time();          context.notifyBatch(dyld_image_state_bound, false);     uint64_t t6 = mach_absolute_time();          std::vector<DOFInfo> dofs;     this->recursiveGetDOFSections(context, dofs);     context.registerDOFs(dofs);     uint64_t t7 = mach_absolute_time();          // interpose any dynamically loaded images     if ( !context.linkingMainExecutable && (fgInterposingTuples.size() != 0) ) {         this->recursiveApplyInterposing(context);     }      // clear error strings     (*context.setErrorStrings)(0, NULL, NULL, NULL);      fgTotalLoadLibrariesTime += t1 - t0;     fgTotalRebaseTime += t3 - t2;     fgTotalBindTime += t4 - t3;     fgTotalWeakBindTime += t5 - t4;     fgTotalDOF += t7 - t6;      // done with initial dylib loads     fgNextPIEDylibAddress = 0; }

link 函数不是很长,这里就全部贴出来了,它首先调用 recursiveLoadLibraries,递归加载程序所需的动态链接库。使用 otool -L 二进制文件路径 可以列出程序的动态链接库:

$ otool -L gaoda  /System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1349.55.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1349.56.0) /System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 3600.7.47)

UIKit 和 Foundation 框架相信大家已经很熟悉了,那么 libobjc.A.dylib 以及 libSystem.B.dylib 是什么呢?libobjc.A.dylib 包含 runtime,而 libSystem.B.dylib 则包含像 libdispatch、libsystem_c 等系统级别的库,二者都是被默认添加到程序中的。动态链接库的加载也是借助 ImageLoader 完成的,但是由于动态链接库本身还可能依赖其他动态链接库,所以整个加载过程是递归进行的。当程序的动态链接库加载完毕后,link 函数进入下一流程。

Rebase && Bind

因为地址空间加载随机化(ASLR,Address Space Layout Randomization)的缘故,二进制文件最终的加载地址与预期地址之间会存在偏移,所以需要进行 rebase 操作,对那些指向文件内部符号的指针进行修正,在 link 函数中该项操作由 recursiveRebase 函数执行。rebase 完成之后,就会进行 bind 操作,修正那些指向其他二进制文件所包含的符号的指针,由 recursiveBind 函数执行。

当 rebase 以及 bind 结束时,link 函数就完成了它的使命,iOS 应用的启动流程也进入到下一阶段,即 Objc SetUp。

Objc SetUp

Objc Setup 算是 iOS 系统独有的流程了,在 runtime 的初始化函数 _objc_init 中,有这样的代码:

void _objc_init(void) {      ......      // Register for unmap first, in case some +load unmaps something     _dyld_register_func_for_remove_image(&unmap_image);     dyld_register_image_state_change_handler(dyld_image_state_bound,                                              1/*batch*/, &map_2_images);     dyld_register_image_state_change_handler(dyld_image_state_dependents_initialized, 0/*not batch*/, &load_images); }

Dyld 在 bind 操作结束之后,会发出 dyld_image_state_bound 通知,然后与之绑定的回调函数 map_2_images 就会被调用,它主要做以下几件事来完成 Objc Setup:

  1. 读取二进制文件的 DATA 段内容,找到与 objc 相关的信息

  2. 注册 Objc 类

  3. 确保 selector 的唯一性

  4. 读取 protocol 以及 category 的信息

除了 map_2_images,我们注意到 _objc_init 还注册了 load_images 函数,它的作用就是调用 Objc 的 + load 方法,它监听 dyld_image_state_dependents_initialized 通知。

虽然我说的很简单,但是在读源码的时候,我发现这部分内容其实是十分复杂而又十分有趣的,鉴于本文主旨是讲启动流程,所以这一块内容先放下,以后有时间了再讲。

Initializers

Objc SetUp 结束后,Dyld 便开始运行程序的初始化函数,该任务由 initializeMainExecutable 函数执行。整个初始化过程是一个递归的过程,顺序是先将依赖的动态库初始化,然后在对自己初始化。初始化需要做的事情包括:

  1. 调用 Objc 类的 + load 函数

  2. 调用 C++ 中带有 constructor 标记的函数

  3. 非基本类型的 C++ 静态全局变量的创建

main

当初始化结束之后,可执行文件才处于可用状态,之后 Dyld 就会去调用可执行文件的 main 函数,开始程序的运行。

结语

同学们还可以开启 DYLD_PRINT_STATISTICS 选项来打印各个阶段的耗时,一般来说400ms以内是很棒的。

关于 iOS 应用启动流程的介绍到此就告一段落了,自己挖的坑总算是填上了,日后如果有了新的发现我会补充上去的,然后嘛,就开始挖新的坑了

祝贺暗组重新回来,本人发的文章只是充个数,并非原创。

最新回复 (0)
全部楼主
返回
发新帖