iOS 14.5 下 fishhook 会 crash

github相关信息
github issue
resolve
protections ios13

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

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

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

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

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

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

查看小技巧

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。

解决参考上面issue, 核心代码如下

1	mprotect((void *)trunc_address, section->size+trunc_size, PROT_READ \| PROT_WRITE);

trunc_address = trunc_page((vm_size_t)indirect_symbol_bindings);
trunc_size =(vm_size_t)indirect_symbol_bindings -trunc_address;
pthread_mutex_lock(&mutex);
oldProtection = get_protection((void *)trunc_address);
mprotect((void *)trunc_address, section->size+trunc_size, PROT_READ | PROT_WRITE);