現(xiàn)象
將 fishhook 開源版本 運(yùn)行在 iOS 14.5 arm64e 的設(shè)備上篮绰，很容易可以復(fù)現(xiàn)一個 crash：
static void (*orig_dispatch_async)(dispatch_queue_t queue, dispatch_block_t block);
static void hooked_dispatch_async(dispatch_queue_t queue, dispatch_block_t block) {
orig_dispatch_async(queue, block);
}
- (void)startHook {
struct rebinding r[] = {
{"dispatch_async", hooked_dispatch_async, (void *)&orig_dispatch_async}
};
rebind_symbols(r, sizeof(r)/sizeof(struct rebinding));
}
Crash 會發(fā)生在
indirect_symbol_bindings[i] = cur->rebindings[j].replacement;
這一行氯夷，crash 原因?yàn)?EXC_BAD_ACCESS检痰。
也就是 #82 反饋的問題缤言。
原因
在了解 fishhook 原理后心俗，經(jīng)過一些調(diào)試分析，可以發(fā)現(xiàn)發(fā)生 crash 的原因：
被賦值的 indirect_symbol_bindings[i] 所在的內(nèi)存區(qū)域恶守，是只讀的狐援。而“賦值”是一個寫操作，于是產(chǎn)生了 EXC_BAD_ACCESS某筐。
Fishhook 考慮到過內(nèi)存訪問權(quán)限的問題比搭，在 If hooking in __DATA_CONST, make writable before trying to write 和 Properly restore protections for iOS 13 這兩個 PR 中，對于 __DATA_CONST 段中的數(shù)據(jù)南誊，作者在
indirect_symbol_bindings[i] = cur->rebindings[j].replacement;
這一行賦值操作之前身诺，使用了 mprotect 將所屬內(nèi)存區(qū)域的訪問權(quán)限改成了“讀寫”，在這一行賦值操作以后抄囚，再次使用 mprotect 將所屬內(nèi)存區(qū)域的訪問權(quán)限改回了原始值霉赡。
然而這兩個 PR 其實(shí)是有問題的：
1、mprotect 修改內(nèi)存區(qū)域的訪問權(quán)限時幔托，傳入的內(nèi)存地址是需要按頁對齊的穴亏，所以開源版本的 fishhook 在舊版 iOS 系統(tǒng)上蜂挪，mprotect 都有很大概率不成功（返回 -1），官方文檔也印證了這點(diǎn)嗓化。
2棠涮、oldProtection = get_protection(rebindings); 這一行的目的是保存原先的訪問權(quán)限，但是傳入的參數(shù)是錯誤的刺覆，這會導(dǎo)致“在這一行賦值操作以后严肪，再次使用 mprotect 將所屬內(nèi)存區(qū)域的訪問權(quán)限改回了原始值”在實(shí)際執(zhí)行中，“改回了原始值”實(shí)際是“改成可讀寫”（當(dāng)然由于 mprotect 頁對齊的問題很大概率修改不成功）隅津，因?yàn)?rebindings 是 malloc 出來的诬垂。
所以劲室，一直以來伦仍，這兩個 PR 大概率沒有發(fā)揮預(yù)期的作用， indirect_symbol_bindings[i] 所在的內(nèi)存區(qū)域很洋，如果在程序啟動后是只讀的充蓝，那么 fishhook 的過程中，它也是只讀的喉磁。只要賦值谓苟，就會觸發(fā) crash。
為什么 crash 只發(fā)生在 iOS 14.5协怒？
在我構(gòu)造的復(fù)現(xiàn)環(huán)境中涝焙，crash 發(fā)生在對系統(tǒng)庫 libxpc.dylib 的 __DATA_CONST 段 __auth_got 節(jié)的重綁定中，此時 indirect_symbol_bindings[i] 位于 __DATA_CONST 段 __auth_got 節(jié)映射到內(nèi)存的區(qū)域中孕暇。我們來對比一下 iOS 14.4 和 iOS 14.5 的區(qū)別：
1仑撞、無論是 iOS 14.4 還是 iOS 14.5，mprotect 修改內(nèi)存區(qū)域?yàn)樽x寫時妖滔，都失敗了（返回 -1）隧哮。
2、但是在 mprotect 修改前座舍，iOS 14.4 上 indirect_symbol_bindings[i] 所在的內(nèi)存區(qū)域是讀寫的沮翔，而 iOS 14.5 上變成了只讀。
為了便于理解曲秉，我們可以在程序啟動后采蚀、fishhook 開始前，通過 memory graph 來觀察各個內(nèi)存區(qū)域的訪問權(quán)限：
抓取 memory graph 后承二，在 Xcode 中選擇 File -> Export Memory Graph榆鼠，導(dǎo)出 memory graph 后使用 vmmap 命令得到各個內(nèi)存區(qū)域的快照
觀察 libxpc.dylib 的 __DATA_CONST 段映射在內(nèi)存中的訪問權(quán)限：
# iOS 14.5
__DATA_CONST 1edadef10-1edae35c0 [ 18K 18K 4K 0K] r--/rw- SM=COW /usr/lib/system/libxpc.dylib
# iOS 14.4
__DATA_CONST 1f30167b0-1f301ae70 [ 18K 18K 6K 0K] rw-/rw- SM=COW /usr/lib/system/libxpc.dylib
可以發(fā)現(xiàn)，iOS 14.5 中矢洲，libxpc.dylib 的 __DATA_CONST 段是只讀的璧眠，而 iOS 14.4 中是讀寫的。
同時觀察其他系統(tǒng)庫，能發(fā)現(xiàn) iOS 14.5 中责静，不少系統(tǒng)庫的 __DATA_CONST 段都從 iOS 14.4 的讀寫變成了只讀袁滥，同時撞上了一直以來都有的 mprotect 失效的問題，所以產(chǎn)生了 crash灾螃。
@maniackk 在 github 上的 PR If hooking in __DATA_CONST/__AUTH_CONST, promise writable before trying to write #84 中對上文所說的兩個問題做了解決题翻。
