iOS之武功秘籍 文章匯總

寫(xiě)在前面

我們平時(shí)編寫(xiě)的程序的入口函數(shù)都是main.m文件里面的main函數(shù)，但是這就是App的生命起點(diǎn)了嗎？玩過(guò)逆向的iOSer都知道可以往+load方法注入代碼來(lái)進(jìn)行安全攻防，而+load方法先于main函數(shù)執(zhí)行，那么main函數(shù)之前都發(fā)生了哪些有趣的事呢？本文就將帶著大家來(lái)揭開(kāi)這片神秘面紗！

本節(jié)可能用到的秘籍Demo

一、編譯過(guò)程與動(dòng)靜態(tài)庫(kù)

我們先來(lái)看個(gè)??:

• 創(chuàng)建一個(gè)project，在ViewController中重寫(xiě)了load方法，在main.m中加了一個(gè)C++方法，即cjFunc，請(qǐng)問(wèn)它們的打印先后順序是什么？

• 運(yùn)行程序，查看 load、cjFunc、main的打印順序，下面是打印結(jié)果，通過(guò)結(jié)果可以看出其順序是 load --> C++方法 --> main()

為什么是這么一個(gè)順序？按照常規(guī)的思維理解，main不是入口函數(shù)嗎？為什么不是main最先執(zhí)行？
下面根據(jù)這個(gè)問(wèn)題，我們來(lái)探索在走到main函數(shù)之前，到底還做了什么.

在探索分析app啟動(dòng)之前，我們需要先了解iOS中App代碼的編譯過(guò)程以及動(dòng)態(tài)庫(kù)和靜態(tài)庫(kù).

① 編譯過(guò)程

在日常開(kāi)發(fā)過(guò)程中，開(kāi)發(fā)者會(huì)使用成千上萬(wàn)次的Command + B/R進(jìn)行開(kāi)發(fā)調(diào)試，但可能很少有人關(guān)注過(guò)這個(gè)過(guò)程中 Xcode幫我們做了哪些事情（iOS開(kāi)發(fā)者往往會(huì)吐槽Xcode越來(lái)越難用了，但不得不承認(rèn)它越來(lái)越強(qiáng)了）

事實(shí)上，這個(gè)過(guò)程分解為4個(gè)步驟，分別是預(yù)處理(Prepressing)、編譯(Compilation)、匯編(Assembly)和鏈接(Linking).------ 摘自《程序員的自我修養(yǎng)-- 鏈接、裝載與庫(kù)》

在以上4個(gè)步驟中，IDE主要做了以下幾件事:

• 預(yù)編譯：處理代碼中的# 開(kāi)頭的預(yù)編譯指令，比如刪除#define并展開(kāi)宏定義，將#include包含的文件插入到該指令位置等(即替換宏，刪除注釋?zhuān)归_(kāi)頭文件，產(chǎn)生.i文件)
• 編譯：對(duì)預(yù)編譯處理過(guò)的文件進(jìn)行詞法分析、語(yǔ)法分析和語(yǔ)義分析，并進(jìn)行源代碼優(yōu)化，然后生成匯編代碼(即將.i文件轉(zhuǎn)換為匯編語(yǔ)言，產(chǎn)生.s文件)
• 匯編：通過(guò)匯編器將匯編代碼轉(zhuǎn)換為機(jī)器可以執(zhí)行的指令，并生成目標(biāo)文件.o文件
• 鏈接：將目標(biāo)文件鏈接成可執(zhí)行文件.這一過(guò)程中，鏈接器將不同的目標(biāo)文件鏈接起來(lái)，因?yàn)椴煌哪繕?biāo)文件之間可能有相互引用的變量或調(diào)用的函數(shù)，如我們經(jīng)常調(diào)用Foundation框架和UIKit 框架中的方法和變量，但是這些框架跟我們的代碼并不在一個(gè)目標(biāo)文件中，這就需要鏈接器將它們與我們自己的代碼鏈接起來(lái)

Foundation和UIKit這種可以共享代碼、實(shí)現(xiàn)代碼的復(fù)用統(tǒng)稱(chēng)為庫(kù)——它是可執(zhí)行代碼的二進(jìn)制文件，可以被操作系統(tǒng)寫(xiě)入內(nèi)存，它又分為靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)

② 靜態(tài)庫(kù)

靜態(tài)庫(kù)是指鏈接時(shí)完整的拷貝到可執(zhí)行文件，多次使用多次拷貝，造成冗余，使包變的更大

如.a、.lib都是靜態(tài)庫(kù)

③ 動(dòng)態(tài)庫(kù)

動(dòng)態(tài)庫(kù)是指鏈接時(shí)不復(fù)制，程序運(yùn)行時(shí)由系統(tǒng)加在到內(nèi)存中，供系統(tǒng)調(diào)用，系統(tǒng)只需加載一次，多次使用，共用節(jié)省內(nèi)存.

如.dylib、.framework都是動(dòng)態(tài)庫(kù)

二、dyld

① dyld簡(jiǎn)介

dyld(The dynamic link editor)是蘋(píng)果的動(dòng)態(tài)鏈接器，負(fù)責(zé)程序的鏈接及加載工作，是蘋(píng)果操作系統(tǒng)的重要組成部分，存在于MacOS系統(tǒng)的(/usr/lib/dyld)目錄下.在應(yīng)用被編譯打包成可執(zhí)行文件格式的Mach-O文件之后 ，交由dyld負(fù)責(zé)鏈接，加載程序.

所以 App的啟動(dòng)流程圖如下

② dyld_shared_cache

由于不止一個(gè)程序需要使用UIKit系統(tǒng)動(dòng)態(tài)庫(kù)，所以不可能在每個(gè)程序加載時(shí)都去加載所有的系統(tǒng)動(dòng)態(tài)庫(kù).為了優(yōu)化程序啟動(dòng)速度和利用動(dòng)態(tài)庫(kù)緩存，蘋(píng)果從iOS3.1之后，將所有系統(tǒng)庫(kù)（私有與公有）編譯成一個(gè)大的緩存文件，這就是dyld_shared_cache，該緩存文件存在iOS系統(tǒng)下的/System/Library/Caches/com.apple.dyld/目錄下

三、dyld加載流程

在前文的Demo中,在load方法和main方法處加一個(gè)斷點(diǎn)

點(diǎn)擊函數(shù)調(diào)用棧/使用LLDB——bt指令打印，都能看到最初的起點(diǎn)_dyld_start

接下來(lái)怎么去研究dyld呢，我們將通過(guò)dyld源碼展開(kāi)分析

① 1._dyld_start

在源碼中全局搜索_dyld_start，會(huì)發(fā)現(xiàn)它是由匯編實(shí)現(xiàn)的

在arm64中，_dyld_start調(diào)用了一個(gè)看不懂的方法

從注釋中得出可能是dyldbootstrap::start方法（其實(shí)在“函數(shù)調(diào)用?！蹦菑垐D中匯編代碼已經(jīng)把這個(gè)方法暴露出來(lái)了）

② dyldbootstrap::start

其實(shí)dyldbootstrap::start是指dyldbootstrap這個(gè)命名空間作用域里的 start函數(shù)

源碼中搜索dyldbootstrap找到命名作用空間.

再在這個(gè)文件中查找start方法，其核心是返回值調(diào)用了dyld的main函數(shù)，其中macho_header是Mach-O的頭部，而dyld加載的文件就是Mach-O類(lèi)型的，即Mach-O類(lèi)型是可執(zhí)行文件類(lèi)型，由四部分組成：Mach-O頭部、Load Command、section、Other Data，可以通過(guò)MachOView查看可執(zhí)行文件信息

在start()函數(shù)中主要做了一下幾件事：

• 根據(jù)dyldsMachHeader計(jì)算出slide， 通過(guò)slide判定是否需要重定位；這里的slide是根據(jù)ASLR技術(shù) 計(jì)算出的一個(gè)隨機(jī)值，使得程序每一次運(yùn)行的偏移值都不一樣，防止攻擊者通過(guò)固定地址發(fā)起惡意攻擊
• mach_init()初始化（允許dyld使用mach消息傳遞）
• 棧溢出保護(hù)
• 計(jì)算appsMachHeader的偏移，調(diào)用dyld::_main()函數(shù)

③ dyld::_main()

dyld::_main()主要流程為：

• 環(huán)境變量配置:根據(jù)環(huán)境變量設(shè)置相應(yīng)的值以及獲取當(dāng)前運(yùn)行架構(gòu)
• 共享緩存:檢查是否開(kāi)啟了共享緩存，以及共享緩存是否映射到共享區(qū)域,例如UIKit、CoreFoundation等
• 主程序的初始化:調(diào)用instantiateFromLoadedImage函數(shù)實(shí)例化了一個(gè)ImageLoader對(duì)象
• 插入動(dòng)態(tài)庫(kù):遍歷DYLD_INSERT_LIBRARIES環(huán)境變量，調(diào)用loadInsertedDylib加載
• link 主程序
• link 動(dòng)態(tài)庫(kù)
• 弱符號(hào)綁定
• 執(zhí)行初始化方法
• 尋找主程序入口即main函數(shù)

③.1 環(huán)境變量配置

• 平臺(tái),版本,路徑,主機(jī)信息的確定
• 從環(huán)境變量中獲取主要可執(zhí)行文件的cdHash
• checkEnvironmentVariables(envp)檢查設(shè)置環(huán)境變量
• defaultUninitializedFallbackPaths(envp)在DYLD_FALLBACK為空時(shí)設(shè)置默認(rèn)值
• getHostInfo(mainExecutableMH, mainExecutableSlide)獲取程序架構(gòu)
  
  
  

③.2 共享緩存

• checkSharedRegionDisable檢查是否開(kāi)啟共享緩存（在iOS中必須開(kāi)啟）
• mapSharedCache加載共享緩存庫(kù)，其中調(diào)用loadDyldCache函數(shù)有這么幾種情況：
  • 僅加載到當(dāng)前進(jìn)程mapCachePrivate（模擬器僅支持加載到當(dāng)前進(jìn)程）
  • 共享緩存是第一次被加載，就去做加載操作mapCacheSystemWide

  • 共享緩存不是第一次被加載，那么就不做任何處理

    
    

③.3 主程序的初始化

• ①調(diào)用instantiateFromLoadedImage函數(shù)實(shí)例化了一個(gè)ImageLoader對(duì)象
  

• ②進(jìn)入instantiateFromLoadedImage源碼，其中創(chuàng)建一個(gè)ImageLoader實(shí)例對(duì)象，通過(guò)instantiateMainExecutable方法創(chuàng)建

• ③進(jìn)入instantiateMainExecutable源碼，其作用是為主可執(zhí)行文件創(chuàng)建映像，返回一個(gè)ImageLoader類(lèi)型的image對(duì)象，即主程序.其中sniffLoadCommands函數(shù)會(huì)獲取Mach-O類(lèi)型文件的Load Command的相關(guān)信息，并對(duì)其進(jìn)行各種校驗(yàn)

③.4 插入動(dòng)態(tài)庫(kù)

遍歷DYLD_INSERT_LIBRARIES環(huán)境變量，調(diào)用loadInsertedDylib加載,通過(guò)該環(huán)境變量我們可以注入自定義的一些動(dòng)態(tài)庫(kù)代碼從而完成安全攻防，loadInsertedDylib內(nèi)部會(huì)從DYLD_ROOT_PATH、LD_LIBRARY_PATH、DYLD_FRAMEWORK_PATH等路徑查找dylib并且檢查代碼簽名，無(wú)效則直接拋出異常

③.5 link 主程序

③.6 link 動(dòng)態(tài)庫(kù)

③.7 弱符號(hào)綁定

③.8 執(zhí)行初始化方法

• ①進(jìn)入initializeMainExecutable源碼,主要是循環(huán)遍歷，都會(huì)執(zhí)行runInitializers方法

• ②全局搜索runInitializers(cons,找到如下源碼，其核心代碼是processInitializers函數(shù)的調(diào)用為初始化做準(zhǔn)備

• ③進(jìn)入processInitializers函數(shù)的源碼實(shí)現(xiàn)，其中對(duì)鏡像列表調(diào)用recursiveInitialization函數(shù)進(jìn)行遞歸實(shí)例化

• ④全局搜索recursiveInitialization(cons函數(shù),其作用獲取到鏡像的初始化,其源碼實(shí)現(xiàn)如下

在這里，需要分成兩部分探索，一部分是notifySingle函數(shù)，一部分是doInitialization函數(shù)，首先探索notifySingle函數(shù)

• ⑤全局搜索notifySingle(函數(shù),其重點(diǎn)是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());這句.

• ⑥全局搜索sNotifyObjCInit，發(fā)現(xiàn)沒(méi)有找到實(shí)現(xiàn)，有賦值操作

• ⑦搜索registerObjCNotifiers在哪里調(diào)用了，發(fā)現(xiàn)在_dyld_objc_notify_register進(jìn)行了調(diào)用,這個(gè)函數(shù)只在運(yùn)行時(shí)提供給objc使用

注意：_dyld_objc_notify_register的函數(shù)需要在libobjc源碼中搜索

• ⑧在objc4源碼中搜索_dyld_objc_notify_register，發(fā)現(xiàn)在_objc_init源碼中調(diào)用了該方法，并傳入了參數(shù)，所以sNotifyObjCInit的賦值的就是objc中的load_images，而load_images會(huì)調(diào)用所有的+load方法.所以綜上所述，notifySingle是一個(gè)回調(diào)函數(shù)

都到這了,那就順便看看load函數(shù)的加載吧
下面我們進(jìn)入load_images的源碼看看其實(shí)現(xiàn)，以此來(lái)證明load_images中調(diào)用了所有的load函數(shù)

• 通過(guò)objc源碼中_objc_init源碼實(shí)現(xiàn)，進(jìn)入load_images的源碼實(shí)現(xiàn)

• 進(jìn)入call_load_methods源碼實(shí)現(xiàn)，可以發(fā)現(xiàn)其核心是通過(guò)do-while循環(huán)調(diào)用+load方法

• 進(jìn)入call_class_loads源碼實(shí)現(xiàn)，了解到這里調(diào)用的load方法證實(shí)我們前文提及的類(lèi)的load方法

所以，load_images調(diào)用了所有的load函數(shù)，以上的源碼分析過(guò)程正好對(duì)應(yīng)堆棧的打印信息

那么問(wèn)題又來(lái)了，_objc_init是什么時(shí)候調(diào)用的呢？請(qǐng)接著往下看

• ⑨ 走到objc的_objc_init函數(shù)，發(fā)現(xiàn)走不通了，我們回退到recursiveInitialization遞歸函數(shù)的源碼實(shí)現(xiàn)，發(fā)現(xiàn)我們忽略了一個(gè)函數(shù)doInitialization,進(jìn)入doInitialization函數(shù)的源碼實(shí)現(xiàn)

這里也需要分成兩部分，一部分是doImageInit函數(shù)，一部分是doModInitFunctions函數(shù)

• ⑩進(jìn)入doImageInit源碼實(shí)現(xiàn)，其核心主要是for循環(huán)加載方法的調(diào)用，這里需要注意的一點(diǎn)是，libSystem的初始化必須先運(yùn)行

• ?進(jìn)入doModInitFunctions源碼實(shí)現(xiàn)，這個(gè)方法中加載了所有Cxx文件,這里需要注意的一點(diǎn)是，libSystem的初始化必須先運(yùn)行

走到這里，還是沒(méi)有找到_objc_init的調(diào)用？怎么辦呢？放棄嗎？當(dāng)然不行，我們還可以通過(guò)_objc_init加一個(gè)符號(hào)斷點(diǎn)來(lái)查看調(diào)用_objc_init前的堆棧信息

• ?在libsystem中查找libSystem_initializer，查看其中的實(shí)現(xiàn)

• ?根據(jù)前面的堆棧信息，我們發(fā)現(xiàn)走的是libSystem_initializer中會(huì)調(diào)用libdispatch_init函數(shù)，而這個(gè)函數(shù)的源碼是在libdispatch開(kāi)源庫(kù)中的，在libdispatch中搜索libdispatch_init

• ?進(jìn)入_os_object_init源碼實(shí)現(xiàn)，其源碼實(shí)現(xiàn)調(diào)用了_objc_init函數(shù)

結(jié)合上面的分析，從初始化_objc_init注冊(cè)的_dyld_objc_notify_register的參數(shù)2，即load_images，到sNotifySingle --> sNotifyObjCInie=參數(shù)2 到sNotifyObjcInit()調(diào)用，形成了一個(gè)閉環(huán)

也可以簡(jiǎn)單的理解為sNotifySingle這里是添加通知即addObserver，_objc_init中調(diào)用_dyld_objc_notify_register相當(dāng)于發(fā)送通知，即push，而sNotifyObjcInit相當(dāng)于通知的處理函數(shù)，即selector.

③.9 尋找主程序入口

• ①在測(cè)試程序中匯編調(diào)試，可以看到顯示來(lái)到+[ViewController load]方法

• ②繼續(xù)執(zhí)行，來(lái)到cjFunc的C++函數(shù)

• ③點(diǎn)擊stepover,繼續(xù)往下，跑完了整個(gè)流程，會(huì)回到_dyld_start,然后調(diào)用main()函數(shù),通過(guò)匯編完成main的參數(shù)賦值等操作

• ④dyld匯編源碼實(shí)現(xiàn)

最后注意：main是寫(xiě)定的函數(shù)，寫(xiě)入內(nèi)存，讀取到dyld，如果修改了main函數(shù)的名稱(chēng)，會(huì)報(bào)錯(cuò)

所以，綜上所述，最終dyld加載流程，如下圖所示，圖中也詮釋了前文中的問(wèn)題：為什么是load-->Cxx-->main的調(diào)用順序

寫(xiě)在后面

和諧學(xué)習(xí),不急不躁.我還是我,顏色不一樣的煙火.