現(xiàn)象
將 fishhook 開源版本 運(yùn)行在 iOS 14.5 arm64e 的設(shè)備上，很容易可以復(fù)現(xiàn)一個(gè) 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 會(huì)發(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ū)域，是只讀的。而“賦值”是一個(gè)寫操作，于是產(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 這兩個(gè) 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)限改回了原始值。
然而這兩個(gè) PR 其實(shí)是有問題的：
1、mprotect 修改內(nèi)存區(qū)域的訪問權(quán)限時(shí)，傳入的內(nèi)存地址是需要按頁對齊的，所以開源版本的 fishhook 在舊版 iOS 系統(tǒng)上，mprotect 都有很大概率不成功（返回 -1），官方文檔也印證了這點(diǎn)。
2、oldProtection = get_protection(rebindings); 這一行的目的是保存原先的訪問權(quán)限，但是傳入的參數(shù)是錯(cuò)誤的，這會(huì)導(dǎo)致“在這一行賦值操作以后，再次使用 mprotect 將所屬內(nèi)存區(qū)域的訪問權(quán)限改回了原始值”在實(shí)際執(zhí)行中，“改回了原始值”實(shí)際是“改成可讀寫”（當(dāng)然由于 mprotect 頁對齊的問題很大概率修改不成功），因?yàn)?rebindings 是 malloc 出來的。
所以，一直以來，這兩個(gè) PR 大概率沒有發(fā)揮預(yù)期的作用， indirect_symbol_bindings[i] 所在的內(nèi)存區(qū)域，如果在程序啟動(dòng)后是只讀的，那么 fishhook 的過程中，它也是只讀的。只要賦值，就會(huì)觸發(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é)的重綁定中，此時(shí) 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寫時(shí)，都失敗了（返回 -1）。
2、但是在 mprotect 修改前，iOS 14.4 上 indirect_symbol_bindings[i] 所在的內(nèi)存區(qū)域是讀寫的，而 iOS 14.5 上變成了只讀。
為了便于理解，我們可以在程序啟動(dòng)后、fishhook 開始前，通過 memory graph 來觀察各個(gè)內(nèi)存區(qū)域的訪問權(quán)限：
抓取 memory graph 后，在 Xcode 中選擇 File -> Export Memory Graph，導(dǎo)出 memory graph 后使用 vmmap 命令得到各個(gè)內(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 中是讀寫的。
同時(shí)觀察其他系統(tǒng)庫，能發(fā)現(xiàn) iOS 14.5 中，不少系統(tǒng)庫的 __DATA_CONST 段都從 iOS 14.4 的讀寫變成了只讀，同時(shí)撞上了一直以來都有的 mprotect 失效的問題，所以產(chǎn)生了 crash。
@maniackk 在 github 上的 PR If hooking in __DATA_CONST/__AUTH_CONST, promise writable before trying to write #84 中對上文所說的兩個(gè)問題做了解決。
