美文网首页iOS开发Crash崩溃信息分析和解决
为什么 iOS 14.5 下 fishhook 会 crash

为什么 iOS 14.5 下 fishhook 会 crash

作者: 卖萌凉 | 来源:发表于2021-04-11 22:01 被阅读0次

    现象

    将 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 writeProperly 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 中对上文所说的两个问题做了解决。

    相关文章

      网友评论

        本文标题:为什么 iOS 14.5 下 fishhook 会 crash

        本文链接:https://www.haomeiwen.com/subject/jbuzkltx.html