在上篇文章代碼注入，竊取微信密碼中咱們已經(jīng)簡單的提到了MachO，在用Framework做代碼注入的時(shí)候，必須先向MachO的Load Commons中插入該Framework的的相對(duì)路徑，讓我們的iPhone在執(zhí)行MachO的時(shí)候能夠識(shí)別并加載Framework！
推薦閱讀：iOS開發(fā)——BAT面試題合集（持續(xù)更新中）
窺一斑而知全豹，從這些許內(nèi)容其實(shí)已經(jīng)可以了解到MachO在我們APP中的地位是多么的重要。同樣，在咱們逆向的實(shí)踐中，MachO也是一道繞不過去門檻！
老規(guī)矩，片頭先上福利：點(diǎn)擊下載demo
這篇文章會(huì)用到的工具有：
廢話不多說，本篇文章將會(huì)從以下幾點(diǎn)細(xì)說到底什么是MachO！
- 什么是MachO
- MachO的文件結(jié)構(gòu)
- 從DYLD源碼的角度看APP啟動(dòng)流程 (重點(diǎn)?。?！)
一、什么是MachO
Mach-O其實(shí)是Mach Object文件格式的縮寫，是mac以及iOS上可執(zhí)行文件的格式， 類似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)
1、常見的MachO文件
a、目標(biāo)文件：.o
b、庫文件：.a .dylib Framework
c、可執(zhí)行文件：dyld .dsym
2、如何查看文件格式
我們可以通過file指令查看文件的具體格式
目前已知的架構(gòu)分為armv7,armv7s,arm64,i386,x86_64等等，MachO中其實(shí)也是這些架構(gòu)的集合。可以隨意建立一個(gè)空工程：Dome1（空工程就不給Demo了）
查看Build出的Dome1.ipa中的MachO
將最低版本設(shè)置為iOS 12，用release打包出的Dome1.ipa中的MachO
將最低版本設(shè)置為iOS 8，用release打包出的Dome1.ipa中的MachO
從上面三張圖就可以確定MachO可以是多架構(gòu)的二進(jìn)制文件，稱之為「通用二進(jìn)制文件」
通用二進(jìn)制文件是蘋果公司提出的一種程序代碼。能同時(shí)適用多種架構(gòu)的二進(jìn)制文件
a. 同一個(gè)程序包中同時(shí)為多種架構(gòu)提供最理想的性能。
b. 因?yàn)樾枰獌?chǔ)存多種代碼，通用二進(jìn)制應(yīng)用程序通常比單一平臺(tái)二進(jìn)制的程序要大。
c. 但是由于兩種架構(gòu)有共通的非執(zhí)行資源，所以并不會(huì)達(dá)到單一版本的兩倍之多。
d. 而且由于執(zhí)行中只調(diào)用一部分代碼，運(yùn)行起來也不需要額外的內(nèi)存。
注：其實(shí)除了更改最低版本號(hào)可以改變MachO的架構(gòu)，在XCode的中也可以主動(dòng)設(shè)置
3、拆分、重組MachO
// 使用lipo -info 可以查看MachO文件包含的架構(gòu)
$ lipo -info MachO文件
// 使用lipo –thin 拆分某種架構(gòu)
$ lipo MachO文件 –thin 架構(gòu) –output 輸出文件路徑
// 使用lipo -create 合并多種架構(gòu)
$ lipo -create MachO1 MachO2 -output 輸出文件路徑
二、MachO的文件結(jié)構(gòu)
先上一張官網(wǎng)圖：
MachO分為三部分結(jié)構(gòu)：Header、Load Commons、Data
1、Header
Header 包含該二進(jìn)制文件的一般信息
字節(jié)順序、架構(gòu)類型、加載指令的數(shù)量等。
使得可以快速確認(rèn)一些信息，比如當(dāng)前文件用于32位還是64位，對(duì)應(yīng)的處理器是什么、文件類型是什么
本文從兩個(gè)視角分析Header，分別是「用MachOView可視化后直觀的查看」和「系統(tǒng)源碼解析」
-
用MachOView可視化后直觀的查看
上篇文章已經(jīng)講過使用MacOView可以直接查看一個(gè)MachO文件，如下圖image -
系統(tǒng)源碼解析
在MachO的源碼文件中同樣有對(duì)應(yīng)的字段。如下圖：image
2、Load Commons
Load commands是一張包含很多內(nèi)容的表。
內(nèi)容包括區(qū)域的位置、符號(hào)表、動(dòng)態(tài)符號(hào)表等。
上圖Load Commons中的大部分字段在下表中可以找到相關(guān)的含義。
| 名稱 | 含義 |
|---|---|
| LC_SEGMENT_64 | 將文件中（32位或64位）的段映射到進(jìn)程地址空間中 |
| LC_DYLD_INFO_ONLY | 動(dòng)態(tài)鏈接相關(guān)信息 |
| LC_SYMTAB | 符號(hào)地址 |
| LC_DYSYMTAB | 動(dòng)態(tài)符號(hào)表地址 |
| LC_LOAD_DYLINKER | 使用誰加載，我們使用dyld |
| LC_UUID | 文件的UUID |
| LC_VERSION_MIN_MACOSX | 支持最低的操作系統(tǒng)版本 |
| LC_SOURCE_VERSION | 源代碼版本 |
| LC_MAIN | 設(shè)置程序主線程的入口地址和棧大小 |
| LC_LOAD_DYLIB | 依賴庫的路徑，包含三方庫 |
| LC_FUNCTION_STARTS | 函數(shù)起始地址表 |
| LC_CODE_SIGNATURE | 代碼簽名 |
其中LC_LOAD_DYLINKER和LC_LOAD_DYLIB
LC_LOAD_DYLINKER
該字段標(biāo)明我們的MachO是被誰加載進(jìn)去的。
可以理解為LC_LOAD_DYLINKER指向的地址是微信APP加載小程序的引擎，而我們的MachO是小程序。在上圖中可以看到我們的Demo1的LC_LOAD_DYLINKER指向的地址就是dyld。dyld確實(shí)是用來加載我們app的，在下面一節(jié)將會(huì)對(duì)dyld的源碼進(jìn)行分析，講述dyld是如何對(duì)MachO進(jìn)行加載的。LC_LOAD_DYLIB
該字段標(biāo)記了所有動(dòng)態(tài)庫的地址，只有在LC_LOAD_DYLIB中有標(biāo)記，我們MachO外部的動(dòng)態(tài)庫（如：Framework）才能被dyld正確的引用，否則dyld不會(huì)主動(dòng)加載，這也是上篇文章，代碼注入的關(guān)鍵所在！
3、Data
Data 通常是對(duì)象文件中最大的部分，包含Segement的具體數(shù)據(jù)，如靜態(tài)C字符串，帶參數(shù)/不帶參數(shù)的OC方法，帶參數(shù)/不帶參數(shù)的C函數(shù)。
在Demo1中編寫一下代碼
靜態(tài)C字符串
靜態(tài)OC字符串
帶參數(shù)的OC方法
不帶參數(shù)的OC方法
帶參數(shù)的C函數(shù)
-
不帶參數(shù)的C函數(shù)
如圖：image
查看MachO中對(duì)應(yīng)的Data段：cstring,methname,如下兩圖：
可以看到，全局靜態(tài)C字符（myCString），方法里面的字符串（myCFuncAString:%d,myCFuncString,%s,myOCFuncAString:%s,myOCFuncString:%s）都被保存在data段的cstring里了，哪怕是%d,%s等等這樣的參數(shù)類型字符串也被保存在內(nèi)。但所有同樣的字符串只會(huì)被保存一次。
同樣所有的OC方法都被保存在methname里了。
這里有個(gè)問題：
在這兩個(gè)表中并沒有看到全局的靜態(tài)OC字符串(myOCString)和C函數(shù)（myCFuncA(int a),myCFunc()）這里為什么沒有？他們應(yīng)該會(huì)被以是形式保存在哪里？
上面用cstring和methname距離了data段的作用，同樣的所有類名，協(xié)議名等也是以同樣形式存儲(chǔ)在這。
上面已經(jīng)對(duì)MachO有了一個(gè)大概的了解，接下來本文就對(duì)dyld這么一個(gè)重要的東西進(jìn)行一個(gè)初探。
三、從DYLD源碼的角度看APP啟動(dòng)流程
1、在main函數(shù)中斷點(diǎn)查看
首先思考，在main函數(shù)中掛斷點(diǎn)能不能查看到APP啟動(dòng)對(duì)應(yīng)的堆棧？
這部分其實(shí)靠想，靠猜測很難有答案，我們直接用XCode直接嘗試：
可以看到在main函數(shù)斷點(diǎn)并不能看到啟動(dòng)的對(duì)應(yīng)堆棧，說明main函數(shù)也是被別人調(diào)用的，而不是處于app啟動(dòng)的堆棧中。
既然main查不到啟動(dòng)堆棧，那么比app更早執(zhí)行的load方式是否可以找得到呢？
2、在load方法中斷點(diǎn)查看
同樣的，直接XCode調(diào)試：
在這可以發(fā)現(xiàn)更多的信息，比如在堆棧底部的匯編（這里用的是手機(jī)調(diào)試，所以是arm64架構(gòu)）可以很明顯的發(fā)現(xiàn)，是調(diào)用了用dyld中的dyldbootstrap文件中的start方法。
馬不停蹄，打開dyld源碼，找到對(duì)應(yīng)的dyldbootstrap文件中的start函數(shù)。
點(diǎn)擊這里下載dyld源碼
3、在dyldbootstrap中查看start函數(shù)
//
// This is code to bootstrap dyld. This work in normally done for a program by dyld and crt.
// In dyld we have to do this manually.
//
uintptr_t start(const struct macho_header* appsMachHeader, int argc, const char* argv[],
intptr_t slide, const struct macho_header* dyldsMachHeader,
uintptr_t* startGlue)
{
// if kernel had to slide dyld, we need to fix up load sensitive locations
// we have to do this before using any global variables
// 滑塊，ASLR技術(shù)，地址偏移，是MachO文件在內(nèi)存中的地址重定向
slide = slideOfMainExecutable(dyldsMachHeader);
bool shouldRebase = slide != 0;
#if __has_feature(ptrauth_calls)
shouldRebase = true;
#endif
if ( shouldRebase ) {
// 重定向
rebaseDyld(dyldsMachHeader, slide);
}
// allow dyld to use mach messaging
// 消息初始化
mach_init();
// kernel sets up env pointer to be just past end of agv array
const char** envp = &argv[argc+1];
// kernel sets up apple pointer to be just past end of envp array
const char** apple = envp;
while(*apple != NULL) { ++apple; }
++apple;
// set up random value for stack canary
// 棧溢出保護(hù)
__guard_setup(apple);
#if DYLD_INITIALIZER_SUPPORT
// run all C++ initializers inside dyld
runDyldInitializers(dyldsMachHeader, slide, argc, argv, envp, apple);
#endif
// now that we are done bootstrapping dyld, call dyld's main
// 正在的啟動(dòng)函數(shù)，在dyld中的_main函數(shù)中
uintptr_t appsSlide = slideOfMainExecutable(appsMachHeader);
return dyld::_main(appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}
從start函數(shù)的源碼可得知道：dlyd會(huì)內(nèi)存中找到一塊地址給MachO使用，也就是ASLR，內(nèi)存偏移。
最后start函數(shù)執(zhí)行了一個(gè)main函數(shù)（這個(gè)可以不是我們app中的main函數(shù)，而是dyld的）并返回。同樣的，我們不能只蹭一蹭，要進(jìn)去干！
4、在dlyd中查看main函數(shù)
這個(gè)函數(shù)厲害了，如下圖，足足快500行了！
我們抓住其中的關(guān)鍵代碼，足步分析在main函數(shù)之前dyld到底幫我們做了哪一些事情。
1、配置環(huán)境變量
從main函數(shù)的初始，到函數(shù)getHostInfo()之前都是在配置一些環(huán)境變量，已經(jīng)一些線程相關(guān)的，涉及內(nèi)容太過底層，這就不一一分析了(其實(shí)是能力不及??)
在這一步中有很多if判斷，其實(shí)里面都是對(duì)應(yīng)的環(huán)境變量，這些都是可以在XCode進(jìn)行相關(guān)的配置，進(jìn)行對(duì)應(yīng)的操作(如Log相關(guān)信息)。
2、加載共享緩存庫
在iOS系統(tǒng)中，每個(gè)程序依賴的動(dòng)態(tài)庫都需要通過dyld（位于/usr/lib/dyld）一個(gè)一個(gè)加載到內(nèi)存，然而如果在每個(gè)程序運(yùn)行的時(shí)候都重復(fù)的去加載一次，勢必造成運(yùn)行緩慢，為了優(yōu)化啟動(dòng)速度和提高程序性能，共享緩存機(jī)制就應(yīng)運(yùn)而生。所有默認(rèn)的動(dòng)態(tài)鏈接庫被合并成一個(gè)大的緩存文件，放到/System/Library/Caches/com.apple.dyld/目錄下，按不同的架構(gòu)保存分別保存著。其中包括UIKit，F(xiàn)oundation等基礎(chǔ)庫。
在源碼中可以看到在我們iOS系統(tǒng)中，共享緩存庫被明確一定會(huì)被加載。
因?yàn)檫@種機(jī)制的存在，使得iOS在的對(duì)這些基礎(chǔ)庫的加載的時(shí)候時(shí)間和內(nèi)存都得到節(jié)約！
但是有時(shí)因?yàn)楣蚕砭彺鎺斓臋C(jī)制的存在使得iOS在共享緩存庫里面的C函數(shù)，也就是系統(tǒng)C函數(shù)變的不是那么靜態(tài)，有了些許OC運(yùn)行時(shí)的特性！
這部分內(nèi)容將會(huì)在下一篇文章著重講解！從不一樣的角度看Runtime！
3、實(shí)例化主程序
加載主程序其實(shí)就是對(duì)MachO文件中LoadCommons段的一些列加載！
我們繼續(xù)對(duì)代碼的跟進(jìn)，如下6張圖：
補(bǔ)充：實(shí)例化完之后調(diào)用addImage(image)，將實(shí)例化出來的鏡像加入所有的鏡像列表sAllImages，主程序永遠(yuǎn)是sAllImages的第一個(gè)對(duì)象！
從源代碼可以看出，加載主程序這一步其實(shí)很簡單，就是將MachO文件中的部分信息一步一步的放入內(nèi)存。
其中從最后一張圖可以了解到：
- 最大的segment數(shù)量為256個(gè)！
- 最大的動(dòng)態(tài)庫（包括系統(tǒng)的個(gè)自定義的）個(gè)數(shù)為4096個(gè)！
4、加載動(dòng)態(tài)鏈接庫
加載動(dòng)態(tài)鏈接庫，如XCode的ViewDebug、MainThreadChecker，我們之后代碼注入的庫也是通過這種形式添加的！
5、鏈接主程序
link函數(shù)里面其實(shí)就是對(duì)之前的imges（不是圖片，這是鏡像）進(jìn)行一些內(nèi)核操作，這部分Apple沒有開源出來，只能看到些許源碼，有興許的同學(xué)可以自行查閱：
6、加載Load和特定的C++的構(gòu)造函數(shù)方法
無論是從之前斷點(diǎn)load方法還是我們現(xiàn)在一步步對(duì)源碼的根據(jù)，都能了解到，dyld的initializeMainExecutable就是就加載load的入口:
并且最后都能接到一個(gè)結(jié)論：
由dyld的notifySingle函數(shù)經(jīng)過一系列的跳轉(zhuǎn)，最終會(huì)跳轉(zhuǎn)到objc源碼中的call_load_methods函數(shù)??！
那么這中間的的過程到底是怎么樣的呢？看下方的gif：
[圖片上傳失敗...(image-e9e628-1552838495670)]
最后找到函數(shù)_dyld_objc_notify_register，就在全局都找不到一個(gè)調(diào)用的地方了，其實(shí)這個(gè)函數(shù)本身就不是給dyld調(diào)用的，而是提供給外部調(diào)用的。怎么找到是誰調(diào)用了_dyld_objc_notify_register呢？
繼續(xù)打開之前的Demo1，在工程中加上_dyld_objc_notify_register的符號(hào)斷點(diǎn)看看。
運(yùn)行工程，斷住之后再次查看函數(shù)調(diào)用棧：
這就可以很清晰的看到，原來是objc_init調(diào)用了咱們的_dyld_objc_notify_register函數(shù)。
同樣打開objc的源碼（點(diǎn)擊下載objc源碼 )
快速定位_dyld_objc_notify_register的調(diào)用位置。如圖：
這樣dyld是如何加載咱們的load方法就被找到了。
期間如果有細(xì)心的同學(xué)可能看到了在notifySingle后面緊跟著doInitialization這樣一個(gè)函數(shù)，這是一個(gè)系統(tǒng)特定的C++構(gòu)造函數(shù)的調(diào)用方法。
這種C++構(gòu)造函數(shù)有特定的寫法，如下：
__attribute__((constructor)) void CPFunc(){
printf("C++Func1");
}
有興趣的同學(xué)可以嘗試實(shí)現(xiàn)一次，在MachO文件中找到對(duì)應(yīng)的方法！
當(dāng)然，這在Demo1也是有的。
7、尋找APP的main函數(shù)并調(diào)用
當(dāng)上面的load和C++方法加載完成之后就會(huì)回到dyld的main方法里面，尋找APP的main函數(shù)并調(diào)用。
最終dyld的main函數(shù)中的主要流程就已經(jīng)走完了，當(dāng)然這7個(gè)步驟是一條主線，期間還會(huì)有很多其他的步驟，過程非常繁瑣，這就不一一舉例了。大家可以通過閱讀dyld的源碼盡收眼底。
四、總結(jié)
本文講述了MachO的概述，文件結(jié)構(gòu)，在從其中Load Commons中的LC_LOAD_DYLINKER引出dyld，接下根據(jù)dyld源碼分析了APP的啟動(dòng)流程。分別是：
1、配置環(huán)境變量
2、加載共享緩存庫
3、實(shí)例化主程序
4、加載動(dòng)態(tài)鏈接庫
5、鏈接主程序
6、加載Load和特定的C++的構(gòu)造函數(shù)方法
7、尋找APP的main函數(shù)并調(diào)用
另外dyld中LC_LOAD_DYLIB的（加載動(dòng)態(tài)鏈接庫）存在，為我們逆向注入代碼提供了無限可能。
MachO中其實(shí)還有一些符號(hào)表，為系統(tǒng)提供查詢對(duì)應(yīng)的方法名稱提供了路徑，這些在下一張文章中將會(huì)更加詳細(xì)的講到。
五、參考
1、Dynamic Linking of Imported Functions in Mach-O
2、《iOS應(yīng)用逆向工程》沙梓社，吳航 著 ，機(jī)械工業(yè)出版社
作為一個(gè)開發(fā)者，有一個(gè)學(xué)習(xí)的氛圍跟一個(gè)交流圈子特別重要，這是一個(gè)我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經(jīng)驗(yàn)，討論技術(shù)， 大家一起交流學(xué)習(xí)成長！
群內(nèi)提供數(shù)據(jù)結(jié)構(gòu)與算法、底層進(jìn)階、swift、逆向、整合面試題等免費(fèi)資料
附上一份收集的各大廠面試題（附答案） ! 群文件直接獲取
各大廠面試題
