为什么 iOS 14.5 下 fishhook 会 crash

现象

将 fishhook 开源版本 运行在 iOS 14.5 arm64e 的设备上，很容易可以复现一个 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 会发生在

indirect_symbol_bindings[i] = cur->rebindings[j].replacement;

这一行，crash 原因为 EXC_BAD_ACCESS。

也就是 #82 反馈的问题。

原因

在了解 fishhook 原理后，经过一些调试分析，可以发现发生 crash 的原因：

被赋值的 indirect_symbol_bindings[i] 所在的内存区域，是只读的。而“赋值”是一个写操作，于是产生了 EXC_BAD_ACCESS。

Fishhook 考虑到过内存访问权限的问题，在 If hooking in __DATA_CONST, make writable before trying to write 和 Properly restore protections for iOS 13 这两个 PR 中，对于 __DATA_CONST 段中的数据，作者在

indirect_symbol_bindings[i] = cur->rebindings[j].replacement;

这一行赋值操作之前，使用了 mprotect 将所属内存区域的访问权限改成了“读写”，在这一行赋值操作以后，再次使用 mprotect 将所属内存区域的访问权限改回了原始值。

然而这两个 PR 其实是有问题的：
1、mprotect 修改内存区域的访问权限时，传入的内存地址是需要按页对齐的，所以开源版本的 fishhook 在旧版 iOS 系统上，mprotect 都有很大概率不成功（返回 -1），官方文档也印证了这点。

⬆️ iOS 14.4 测试结果

2、oldProtection = get_protection(rebindings); 这一行的目的是保存原先的访问权限，但是传入的参数是错误的，这会导致“在这一行赋值操作以后，再次使用 mprotect 将所属内存区域的访问权限改回了原始值”在实际执行中，“改回了原始值”实际是“改成可读写”（当然由于 mprotect 页对齐的问题很大概率修改不成功），因为 rebindings 是 malloc 出来的。

所以，一直以来，这两个 PR 大概率没有发挥预期的作用， indirect_symbol_bindings[i] 所在的内存区域，如果在程序启动后是只读的，那么 fishhook 的过程中，它也是只读的。只要赋值，就会触发 crash。

为什么 crash 只发生在 iOS 14.5？

在我构造的复现环境中，crash 发生在对系统库 libxpc.dylib 的 __DATA_CONST 段 __auth_got 节的重绑定中，此时 indirect_symbol_bindings[i] 位于 __DATA_CONST 段 __auth_got 节映射到内存的区域中。我们来对比一下 iOS 14.4 和 iOS 14.5 的区别：
1、无论是 iOS 14.4 还是 iOS 14.5，mprotect 修改内存区域为读写时，都失败了（返回 -1）。
2、但是在 mprotect 修改前，iOS 14.4 上 indirect_symbol_bindings[i] 所在的内存区域是读写的，而 iOS 14.5 上变成了只读。

为了便于理解，我们可以在程序启动后、fishhook 开始前，通过 memory graph 来观察各个内存区域的访问权限：

抓取 memory graph 后，在 Xcode 中选择 File -> Export Memory Graph，导出 memory graph 后使用 vmmap 命令得到各个内存区域的快照

观察 libxpc.dylib 的 __DATA_CONST 段映射在内存中的访问权限：

# 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

可以发现，iOS 14.5 中，libxpc.dylib 的 __DATA_CONST 段是只读的，而 iOS 14.4 中是读写的。
同时观察其他系统库，能发现 iOS 14.5 中，不少系统库的 __DATA_CONST 段都从 iOS 14.4 的读写变成了只读，同时撞上了一直以来都有的 mprotect 失效的问题，所以产生了 crash。

@maniackk 在 github 上的 PR If hooking in __DATA_CONST/__AUTH_CONST, promise writable before trying to write #84 中对上文所说的两个问题做了解决。