這是Mach-O系列的第二篇刊侯，趣探 Mach-O：文件格式分析是本文的一個基礎(chǔ)
我們都知道 Mach-O是 OS X 系統(tǒng)的可執(zhí)行文件茧痒，說到可執(zhí)行文件肯定離不開進(jìn)程谒撼。在 Linux 中，我們會通過 Fork()來新創(chuàng)建子進(jìn)程泡躯，然后執(zhí)行鏡像通過exec()來替換為另一個可執(zhí)行程序儿普，至于為什么這么做崎逃，解釋如下
原因闡述：這是基于操作系統(tǒng)方面的分析。進(jìn)程可以通過
fork()系統(tǒng)調(diào)用來創(chuàng)建子進(jìn)程眉孩，子進(jìn)程得到與父進(jìn)程地址空間相同的（但是獨立的）一份拷貝个绍，包括文本、數(shù)據(jù)和bss段浪汪、堆以及用戶棧等巴柿，但是新線程只會復(fù)制調(diào)用fork的線程。所有父進(jìn)程中別的線程死遭，到了子進(jìn)程中都是突然“蒸發(fā)”掉的广恢。
我們在線程問題中經(jīng)常會提到鎖，每個鎖都有一個持有者（最后一次
lock它的線程）呀潭。為了性能钉迷，鎖對象會因為fork復(fù)制到子進(jìn)程中，但是子進(jìn)程只復(fù)制調(diào)用fork的線程蜗侈，很可能并不擁有鎖持有者線程篷牌，那么就沒有辦法解開鎖，導(dǎo)致死鎖問題踏幻、內(nèi)存泄漏
避免死鎖的方法：在子線程中馬上調(diào)用
exec函數(shù)，一個進(jìn)程一旦調(diào)用exec類函數(shù)戳杀，它本身就"死亡"了该面，系統(tǒng)把代碼段替換成新的程序的代碼夭苗，廢棄原有的數(shù)據(jù)段和堆棧段，并為新程序分配新的數(shù)據(jù)段與堆棧段隔缀，唯一留下的题造，就是進(jìn)程號，也就是說猾瘸，對系統(tǒng)而言界赔，還是同一個進(jìn)程，不過已經(jīng)是另一個程序了牵触。
綜上所述淮悼，我們在用戶態(tài)會通過exec*系列函數(shù)來加載一個可執(zhí)行文件，同時exec*都只是對系統(tǒng)調(diào)用execve的封裝揽思，那我們加載Mach-O的流程袜腥，就從execve說起。Mach-O有多種文件類型钉汗，比如MH_DYLIB文件羹令、MH_BUNDLE文件、MH_EXECUTE文件（這些需要dyld動態(tài)加載）损痰，MH_OBJECT（內(nèi)核加載）等福侈。所以一個進(jìn)程往往不是只需要內(nèi)核加載器就可以完成加載的，需要dyld來進(jìn)行動態(tài)加載配合卢未》玖荩考慮內(nèi)核加載和dyld加載兩種情況，就會有如下流程圖
execve
這個函數(shù)只是直接調(diào)用 __mac_execve()尝丐，對于源碼內(nèi)部實現(xiàn)細(xì)節(jié)显拜，可以看XNU的源代碼
__mac_execve()
源碼可以參考：
bsd/kern/kern_exec.c
主要是為加載鏡像進(jìn)行數(shù)據(jù)的初始化，以及資源相關(guān)的操作爹袁，在其內(nèi)部會執(zhí)行exec_activate_image()远荠，鏡像加載的工作都是由它完成的
int
__mac_execve(proc_t p, struct __mac_execve_args *uap, int32_t *retval)
{
struct image_params *imgp;
// 初始化imgp數(shù)據(jù)
.......
exec_activate_image(imgp);
}
exec_activate_image
源碼可以參考：
bsd/kern/kern_exec.c
主要是拷貝可執(zhí)行文件到內(nèi)存中，并根據(jù)不同的可執(zhí)行文件類型選擇不同的加載函數(shù)失息，所有的鏡像的加載要么終止在一個錯誤上譬淳，要么最終完成加載鏡像。在OS X中專門處理可執(zhí)行文件格式的程序叫execsw鏡像加載器
OS X有三種可執(zhí)行文件盹兢，mach-o由exec_mach_imgact處理邻梆，fat binary由exec_fat_imgact處理，interpreter（解釋器）由exec_shell_imgact處理
exec_mach_imgact
源碼可以參考：
bsd/kern/kern_exec.c
主要是用來對Mach-O做檢測绎秒，會檢測Mach-O頭部浦妄，解析其架構(gòu)、檢查imgp等內(nèi)容，并拒絕接受Dylib和Bundle這樣的文件剂娄，這些文件會由dyld負(fù)責(zé)加載
然后把Mach-O映射到內(nèi)存中去蠢涝，調(diào)用load_machfile()
load_machfile
源碼可以參考：
bsd/kern/mach_loader.c
load_machfile會加載Mach-O中的各種load monmand命令。在其內(nèi)部會禁止數(shù)據(jù)段執(zhí)行阅懦，防止溢出漏洞攻擊和二，還會設(shè)置地址空間布局隨機(jī)化（ASLR），還有一些映射的調(diào)整耳胎。
真正負(fù)責(zé)對加載命令解析的是parse_machfile()
parse_machfile
源碼可以參考：
bsd/kern/mach_loader.c
parse_machfile會根據(jù)load_command的種類選擇不同的函數(shù)來加載惯吕，內(nèi)部是一個Switch語句來實現(xiàn)的
常見的命令有LC_SEGMENT_64、LC_LOAD_DYLINKER怕午、LC_CODE_SIGNATURE废登、LC_UUID等，更多命令可以查看Mach-O文件格式诗轻，也可以查詢這篇文章-趣探 Mach-O：文件格式分析
對于命令的加載會進(jìn)行多次掃描钳宪，當(dāng)掃描三次之后，并且存在dylinker_command命令時扳炬，會執(zhí)行 load_dylinker()吏颖，啟動動態(tài)鏈接器 (dyld)
動態(tài)鏈接過程
動態(tài)鏈接也有區(qū)分，一種是加載主程序（很多博客里這么寫）恨樟，是由load commands指定的dylib半醉，以靜態(tài)的方式存放在二進(jìn)制文件里，一種是由DYLD_INSERT_LIBRARIES動態(tài)指定劝术。下面這種就是提前指定在二進(jìn)制文件中的動態(tài)庫缩多，下面的闡述主要是站在前者的角度，對于動態(tài)指定的后期再研究
你可以在 load 方法處打一個斷點看一下养晋，通過查看調(diào)用棾倪海可以發(fā)現(xiàn)：
0 +[XXObject load]
1 call_class_loads()
2 call_load_methods
3 load_images
4 dyld::notifySingle(dyld_image_states, ImageLoader const*)
11 _dyld_start
_dyld_start甚是耀眼，覺得是dyld的入口绳泉，然后就去看dyld的源代碼逊抡，全局搜了一下_dyld_start，就發(fā)現(xiàn)注釋零酪，于是順著注釋往下閱讀
源碼可以參考：
dyld/src/dyld.cpp
內(nèi)核會加載dyld并調(diào)用dyld_start方法冒嫡，隨后dyld_start會調(diào)用_main()，在_main函數(shù)中對數(shù)據(jù)進(jìn)行一通初始化之后四苇，就會調(diào)用instantiateFromLoadedImage函數(shù)初始化ImageLoader實例
// instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
instantiateFromLoadedImage
// The kernel maps in main executable before dyld gets control. We need to
// make an ImageLoader* for the already mapped in main executable.
static ImageLoader* instantiateFromLoadedImage(const macho_header* mh, uintptr_t slide, const char* path)
{
// try mach-o loader
if ( isCompatibleMachO((const uint8_t*)mh, path) ) {
ImageLoader* image = ImageLoaderMachO::instantiateMainExecutable(mh, slide, path, gLinkContext);
addImage(image);
return image;
}
throw "main executable not a known format";
}
instantiateFromLoadedImage這個函數(shù)內(nèi)的代碼比較容易理解孝凌，檢測Mach-O是否合法，合法的話就初始化ImageLoader實例月腋，然后將其加入到一個全局的管理ImageLoader的數(shù)組中去
isCompatibleMachO會對Mach-O頭部的一些信息與當(dāng)前平臺進(jìn)行比較蟀架，判斷其合法性瓣赂。
ImageLoader
//
// ImageLoader is an abstract base class. To support loading a particular executable
// file format, you make a concrete subclass of ImageLoader.
//
// For each executable file (dynamic shared object) in use, an ImageLoader is instantiated.
//
// The ImageLoader base class does the work of linking together images, but it knows nothing
// about any particular file format.
//
//
class ImageLoader {
}
注釋可得，ImageLoader是一個抽象基類辜窑，每一個動態(tài)加載的可執(zhí)行文件都會初始化一個ImageLoader實例
instantiateMainExecutable
源碼可以參考：
dyld/src/ImageLoaderMachO.cpp
// create image for main executable
ImageLoader* ImageLoaderMachO::instantiateMainExecutable(const macho_header* mh, uintptr_t slide, const char* path, const LinkContext& context)
{
bool compressed;
unsigned int segCount;
unsigned int libCount;
const linkedit_data_command* codeSigCmd;
const encryption_info_command* encryptCmd;
sniffLoadCommands(mh, path, false, &compressed, &segCount, &libCount, context, &codeSigCmd, &encryptCmd);
// instantiate concrete class based on content of load commands
if ( compressed )
return ImageLoaderMachOCompressed::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
else
#if SUPPORT_CLASSIC_MACHO
return ImageLoaderMachOClassic::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
#else
throw "missing LC_DYLD_INFO load command";
#endif
}
可以這里會有一個Bool類型的compressed作為判斷钩述，然后返回不同的實例寨躁。
這兩種實例都是做什么穆碎？
ImageLoaderMachOCompressed與ImageLoaderMachOClassic均繼承于ImageLoaderMachO，ImageLoaderMachO 繼承于ImageLoader
sniffLoadCommands會對Mach-O是classic還是compressed的做一個判斷
instantiateMainExecutable是對ImageLoaderMachOCompressed或ImageLoaderMachOClassic做初始化职恳，并加載load comond命令所禀，之中調(diào)用過程也比較簡單。
這篇文章寫得比較簡陋放钦，后期發(fā)現(xiàn)了更佳的文章色徘，朋友們可以參考這三篇文章學(xué)習(xí)加載過程。（更新于2017.09.25）
參考鏈接
- dyld sourcecode analysis
- 手把手教你hook以root權(quán)限運(yùn)行的App
- 你真的了解 load 方法么颓屑？
- 深入理解 MAC OS X & iOS 操作系統(tǒng)
- XNU sourcecode
- dyld sourcecode
