[原创]iOS Hook 终极兵器库：九种拦截机制到硬件级 PAC 绕过的硬核指南-iOS安全-看雪安全社区

# iOS Hook 终极兵器库：九种拦截机制到硬件级 PAC 绕过的硬核指南

![](upload/attach/202606/1075084_BK8GEVWFU25N5JM.webp)

> 想要掌控 iOS 程序的底层执行流？本文为你深度拆解四层 Hook 机制，从基础的 OC 运行时交换，一路打穿到极度硬核的 ARM64e PAC 绕过与内核级劫持。硬核剖析 fishhook、Dobby 等工具源码与实战陷阱，助你构建真正的终极逆向兵器库！

## 1. 一行代码，让系统时间倒流

```objc
// 一行代码，整个 App 里所有对 [NSDate date] 的调用全部返回 2020-01-01
Method original = class_getClassMethod([NSDate class], @selector(date));
Method fake     = class_getClassMethod([NSDate class], @selector(fakeDate));
method_exchangeImplementations(original, fake);
```

Hook，中文叫"钩子"，本质是一句话：**在不修改源码的前提下，拦截并改变程序的执行流程**。从 Objective-C 的方法交换，到 Mach-O 的符号表篡改，再到 ARM64 的指令级劫持——iOS 上的 Hook 技术已经形成了四个层级的能力栈。本文将结合 fishhook、Dobby、ElleKit 等开源工具的源码，从底层原理到实战踩坑，完整拆解这四层机制。

---

## 2. Hook 为什么不是"一个方案就够了"——四层能力栈的必然性

iOS 的代码世界由三种语言交织而成：

| 语言层 | 绑定方式 | 典型 Hook 目标 | 经典工具 |
| --- | --- | --- | --- |
| Objective-C | 动态运行时，SEL → IMP 查表 | `[UIApplication openURL:]`、`[NSFileManager fileExistsAtPath:]` | Method Swizzling、Substrate |
| C / C++ | 静态链接 + 动态链接，GOT/PLT 符号绑定 | `open()`、`ptrace()`、`sysctl()` | fishhook、GOT rebinding |
| 纯地址（无符号） | 编译时固定地址，无运行时符号表 | 私有 C++ 函数、内联函数、strip 后的函数 | Inline Hook（Dobby、litehook） |

**为什么不能一个方案通吃？**

- Method Swizzling 只能 hook OC 消息，对纯 C 函数（如 `printf`）无能为力
- fishhook 只能 hook **外部符号**（GOT 相关 section 中的条目，包括 `__la_symbol_ptr`、`__nl_symbol_ptr`、`__got`、`__auth_got` 等），对本文件内 static 函数或定义在框架内部的私有符号无效
- Inline Hook 能 hook 任意地址的函数，但它直接改写二进制指令——写错一个字节就 crash

三个方案不是竞争关系，而是覆盖了三个不同的攻击面。而 Substrate、libhooker、ElleKit 这类框架，本质上是**对这三层的统一封装**。

---

## 3. Hook 质量的三维标准

在拆解具体方案前，定义衡量标准：

| 维度 | 指标 | 含义 |
| --- | --- | --- |
| **覆盖率** | 能 hook 的目标类型 | OC 方法？C 函数？私有符号？strip 后的函数？ |
| **安全性** | crash 风险、线程安全性 | 并发调用会不会崩？改错字节能不能恢复？ |
| **穿透性** | 绕过 hook 检测的能力 | 越狱检测 / 反 Hook 机制能不能发现？ |

行话叫"三层穿透"——穿透语言层（OC）、穿透符号层（C 的外部链接）、穿透地址层（只剩下一个无名地址）。

---

## 4. 十二种 Hook 工具全景对比

| 工具 | 原理 | 覆盖层 | 代表用途 |
| --- | --- | --- | --- |
| **Method Swizzling** | ObjC Runtime SEL-IMP 交换 | OC 层 | 系统 API 行为拦截 |
| **fishhook** | Mach-O GOT 符号重绑定 | C 层（外部符号） | Hook 系统 C 函数 |
| **Dobby** | ARM64 Inline Hook | 全层（任意地址） | 无符号私有函数 |
| **Cydia Substrate** | 统一框架（OC+C+Inline） | 全层 | tweak 标准 hook 环境 |
| **Substitute** | Substrate 的开源社区替代（Rootful 时代） | 全层 | Electra/unc0ver/Chimera 基板 |
| **libhooker** | 统一下层 hook 引擎 | 全层 | Taurine/Odyssey/Odysseyra1n |
| **ElleKit** | SW JIT 汇编器 + 内存 patch | 全层 | Dopamine/palera1n 基板 |
| **litehook** | 分支跳转 + GOT 重绑定 | C 层 + 地址层 | 轻量级符号查找+hook |
| **hwbphook** | ARM 硬件断点（watchpoint） | 全层（无痕） | 绕过内存校验检测 |
| **jrmemory** | VMMap 直接改内存页 | 全层 | 绕过代码签名保护 |
| **replaceMethod** | 直接替换 `class` 的方法列表 | OC 层 | 简单 OC 方法替换 |
| **CaptainHook** | 基于 Substrate 的声明式 hook | OC + C 层 | Logos 语法的底层引擎 |

---

## 5. 选择 Hook 方案的核心决策树

面对一个 hook 需求，按以下顺序做决策：

![图片描述](upload/attach/202606/1075084_HF7CJYWWDA3N8QA.webp)

**核心取舍**：
- **选 Method Swizzling**：代价最小，但只能 hook OC
- **选 fishhook**：不改代码段，但只能 hook 外部符号
- **选 Inline Hook**：无所不能 hook，但需要 ARM64 汇编功底，还要处理 PAC/BTI
- **选统一框架**：省心，但依赖越狱环境

---

## 6. Hook 的底层战场：Mach-O 的符号绑定与 ARM64 指令

### 6.1 Mach-O 中的符号生命周期

![图片描述](upload/attach/202606/1075084_Q5TAP7H228VJRRW.webp)

> **iOS 15 分水岭**：dyld4 用 `LC_DYLD_CHAINED_FIXUPS` 彻底替换了 `LC_DYLD_INFO`。Chained Fixups 改变了符号绑定的**方式**——把 bind/rebase 信息编码成一个**自引用的链表**，每个链节点（`dyld_chained_ptr_*` 结构，具体格式因 pointer format 不同而异，如 `DYLD_CHAINED_PTR_64` / `ARM64E` / `ARM64E_USERLAND`）包含 `next` 字段用于指向链中下一个待修复节点。但 `__got` / `__auth_got` / `__la_symbol_ptr` 等 section 仍然存在于 Mach-O 中，只是 dyld 不再通过 `LC_DYLD_INFO` 的 opcode 来填充它们，而是通过 Chained Fixups 链表逐节点绑定。fishhook 或其他 GOT 解析工具如果只认识 `LC_DYLD_INFO`，在 iOS 15+ 二进制上将直接解析扑空。现代 fishhook 必须先识别 `LC_DYLD_CHAINED_FIXUPS`，深入 `__LINKEDIT` 逐节点遍历链表，才能定位并替换目标符号。

### 6.2 ARM64 函数序言——Inline Hook 的"手术部位"

任何 ARM64 C 函数的开头都是标准序言：

```asm
; 典型的 ARM64 函数序言（函数入口第一条指令）
sub  sp, sp, #0x30     ; 分配栈空间
stp  x29, x30, [sp, #0x20]  ; 保存 frame pointer 和 link register
stp  x20, x19, [sp, #0x10]
...
```

Inline Hook 做的事情，是把第一条指令（4 字节）替换成一条无条件跳转：

```asm
; 原始序言被替换为 →
b    _my_hook_function   ; 无条件跳转到自定义 hook 函数
; 剩余的原始指令被搬到了 trampoline（跳板）页面
```

ARM64 的 `b` 指令跳转范围是 ±128MB——如果目标函数超出这个范围，就需要用更复杂的间接跳转（`adrp + br`），这也是 ElleKit 等框架区分"远程 hook"并通过异常处理路径来解决的原因。

---

## 7. 源码深潜：三个 Hook 机制的硬核实现

### 7.1 Method Swizzling：Runtime 的 SEL → IMP 重映射

```objc
// 以下为伪代码，还原 Method Swizzling 的核心运行时操作
// 参考 objc4 源码中 method_exchangeImplementations 的实现
// 注意：ObjC 2.0 中 Method（struct objc_method *）对外不透明
//       不能直接 ->imp，需通过标准 Runtime API 操作

void method_exchangeImplementations(Method m1, Method m2) {
    // 1. 参数校验
    if (!m1 || !m2) return;

// 2. 获取当前 class 的 method list，加写锁（伪代码：表示 Runtime 内部获取写锁）
    rwlock_writer_t lock(runtimeLock);

// 3. 交换两个 method 的 IMP（函数指针）
    //    底层操作：直接交换 class_rw_t → method_list_t 中对应条目
    //    对外接口：必须走 method_getImplementation / method_setImplementation
    IMP imp1 = method_getImplementation(m1);
    IMP imp2 = method_getImplementation(m2);
    method_setImplementation(m1, imp2);
    method_setImplementation(m2, imp1);

// 4. method_setImplementation 内部会自动触发 method cache 的失效与重建
    //    现代 ObjC Runtime 通过 cache 更新/失效/重建一整套机制保证一致性，
    //    并非简单的 flushCaches() 调用，无需手动干预
}
```

**关键陷阱**：`method_exchangeImplementations` 是**全局交换**，影响所有调用者。`class_addMethod` 和 `class_replaceMethod` 同样作用在**类对象 (Class)** 层面，会波及该类的所有实例。如果真正需要只 hook 单个实例对象，业界做法是 **ISA Swizzling**（类比系统的 KVO 机制）：动态创建一个该类的子类，重写目标方法，然后将那个特定实例的 `isa` 指针指向这个动态子类。

### 7.2 fishhook：GOT 表热修补

```c
// 以下为伪代码，还原 fishhook 的核心逻辑
// 注意：iOS 15+ 的 LC_DYLD_CHAINED_FIXUPS 彻底改变了绑定结构
// 现代实现必须同时处理两种路径：
//   Legacy: 遍历 LC_DYLD_INFO → 间接符号表 → __la_symbol_ptr
//   Modern: 遍历 LC_DYLD_CHAINED_FIXUPS → __LINKEDIT 链表 → 逐节点替换

// ===== Legacy 路径（iOS 14 及之前） =====
int rebind_symbols_legacy(struct rebinding rebindings[], size_t rebindings_nel) {
 // 1. 遍历所有已加载的 Mach-O image
 uint32_t c = _dyld_image_count();
 for (uint32_t i = 0; i < c; i++) {
 const struct mach_header_64 *header = _dyld_get_image_header(i);
 intptr_t slide = _dyld_get_image_vmaddr_slide(i);

// 2. 先检查是否为 Chained Fixups 格式，是则走 Modern 路径
        if (has_chained_fixups(header)) {
            rebind_symbols_chained(header, slide, rebindings, rebindings_nel);
            continue;
        }

// 3. Legacy 路径：解析 LC_DYLD_INFO_ONLY — 获取间接符号表
        struct symtab_command *symtab  = find_load_command(header, LC_SYMTAB);
        struct dysymtab_command *dysym = find_load_command(header, LC_DYSYMTAB);
        struct segment_command_64 *data_seg = find_segment(header, "__DATA");

// ★ 计算 __LINKEDIT 段在内存中的真实基址
        //    indirectsymoff / stroff / dataoff 都是 File Offset
        //    直接加 header（VM Address）会飞到不可读的垃圾内存
        struct segment_command_64 *linkedit = find_segment(header, "__LINKEDIT");
        uintptr_t linkedit_base = linkedit->vmaddr - linkedit->fileoff + slide;

// 4. 在 __DATA 段中定位 __la_symbol_ptr section（传统懒绑定表）
        struct section_64 *la_sym = find_section(data_seg, "__la_symbol_ptr");
        if (!la_sym) continue;

// indirectsymoff 是文件偏移 → 加 linkedit_base，不是加 header
        uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysym->indirectsymoff);

// 5. 遍历 __la_symbol_ptr 中的每个条目
 uint32_t entry_count = la_sym->size / sizeof(void *);
 for (uint32_t j = 0; j < entry_count; j++) {
 // 间接符号表中对应的符号索引
 uint32_t sym_index = indirect_symtab[la_sym->reserved1 + j];

// 从字符串表中读取符号名 — symoff 定位 nlist_64 数组，nsyms 是总数不是数组
            //    symtab_command { uint32_t symoff; uint32_t nsyms; ... }
            struct nlist_64 *nlist = (struct nlist_64 *)(linkedit_base + symtab->symoff);
            uint32_t strx = nlist[sym_index].n_un.n_strx;
            char *sym_name = (char *)(linkedit_base + symtab->stroff + strx);

// 匹配 → 改写 GOT 表项
 for (size_t k = 0; k < rebindings_nel; k++) {
 if (strcmp(sym_name, rebindings[k].name) == 0) {
 void **got_entry = (void **)((uintptr_t)la_sym->addr + slide
 + j * sizeof(void *));
 *got_entry = rebindings[k].replacement;
 }
 }
 }
 }
 return 0;
}

// ===== Modern 路径（iOS 15+，LC_DYLD_CHAINED_FIXUPS） =====
void rebind_symbols_chained(const struct mach_header_64 *header, intptr_t slide,
                            struct rebinding rebindings[], size_t n) {
    struct linkedit_data_command *fixups = find_load_command(header,
                                            LC_DYLD_CHAINED_FIXUPS);

// ★ fixups->dataoff 是文件偏移，必须用 __LINKEDIT 基址定位
    struct segment_command_64 *linkedit = find_segment(header, "__LINKEDIT");
    uintptr_t linkedit_base = linkedit->vmaddr - linkedit->fileoff + slide;

// Chained Fixups 把所有 bind 信息编码为链表，不再有固定的指针表
    struct dyld_chained_fixups_header *chain_hdr =
        (void *)(linkedit_base + fixups->dataoff);

// 遍历 imports 表（绑定符号列表）
    struct dyld_chained_import *imports =
        (void *)(linkedit_base + fixups->dataoff + chain_hdr->imports_offset);

for (uint32_t seg_idx = 0; seg_idx < chain_hdr->imports_count; seg_idx++) {
 // 对每个 segment 的绑定链表逐节点遍历
 struct dyld_chained_starts_in_segment *seg =
 get_chain_starts(chain_hdr, seg_idx);

for (uint32_t page_idx = 0; page_idx < seg->page_count; page_idx++) {
 uint16_t offset_in_page = seg->page_start[page_idx];
 if (offset_in_page == DYLD_CHAINED_PTR_START_NONE) continue;

// 链表遍历：当前指针 → 读 next offset → 跳到下一个指针
            while (offset_in_page != 0) {
                void **ptr_loc = page_ptr(seg_idx, page_idx, offset_in_page, slide, header);
                uint64_t raw_ptr = *(uint64_t *)ptr_loc;

// 从指针中提取绑定序号 → 查到符号名
            //    dyld_chained_import 使用位域压缩，没有 name 指针成员：
            //      struct { uint32_t lib_ordinal:8, weak_import:1, name_offset:23; }
            //    符号名 = symbols_offset（符号池基址） + name_offset（名字偏移）
            uint32_t bind_idx = extract_bind_index(raw_ptr, chain_hdr);
            const char *sym_name = (const char *)(linkedit_base
                + fixups->dataoff + chain_hdr->symbols_offset
                + imports[bind_idx].name_offset);

for (size_t k = 0; k < n; k++) {
 if (strcmp(sym_name, rebindings[k].name) == 0) {
 // ★ ARM64e 下需注意 PAC：若目标指针受签名保护，
 // 需参照 dyld 签名逻辑用 ptrauth_sign 重签名后写入
 *ptr_loc = (void *)rebindings[k].replacement;
 }
 }

// 指针的 next 字段指向链表中下一个待修复项
                offset_in_page = extract_next_offset(raw_ptr, chain_hdr);
            }
        }
    }
}
```

**为什么 fishhook 不能 hook 静态函数？** 因为静态函数（`static void foo()`）不经过 GOT——它的地址在编译时就确定了，代码里用 `bl #imm26` 直接跳转，dyld 不参与绑定。GOT 只存**外部符号**的地址。

### 7.3 Dobby：Inline Hook 的指令级替换

```c
// 以下为伪代码，还原 Dobby 的 ARM64 Inline Hook 核心
// 参考 jmpews/Dobby 源码

typedef struct {
    void *target;          // 被 hook 的函数地址
    void *replacement;     // 自定义替换函数
    void *origin_call;     // 生成的跳板（trampoline），用于调用原函数
    int   origin_code_len; // 被覆盖的原始指令长度（字节）
    uint8_t origin_code[16]; // 被覆盖的原始指令的备份
} DobbyHookContext;

int DobbyHook(void *target, void *replace, void **origin_call) {
    DobbyHookContext ctx;
    ctx.target = target;
    ctx.replacement = replace;

// 1. 计算需要覆盖的指令数
    //    "b replacement" 在 AArch64 上是一条 4 字节指令
    //    跳转范围有限 (±128MB)，如果超限需要 "adrp + add + br"（12 字节）
    //    Apple 从 iOS 11 / A7 起彻底废弃 ARM32，AArch64 所有指令严格定长 4 字节
    //    不存在 Thumb 可变长问题，只需按 4 字节对齐即可
    int tramp_len = calculate_trampoline_length(target, replace);
    ctx.origin_code_len = tramp_len;

// 2. 备份原始指令
    //    这些指令将来放到 trampoline 中，让 origin_call 能正常工作
    memcpy(ctx.origin_code, (void *)target, tramp_len);

// 3. 申请一块可执行内存页，构造 trampoline
    //    trampoline 结构：
    //    [原始被覆盖的指令] + [跳回 target + tramp_len 的指令]
    //    注意：iOS ARM64 设备的虚拟内存页大小通常为 16KB (0x4000)，
    //    但也有 4KB 页面的情况。应运行时通过 vm_page_size 查询而非写死。
    //    MAP_JIT 需要 com.apple.developer.dynamic-codesigning entitlement
    //    非越狱环境极难获取；越狱环境因 AMFI 被 patch 可直接使用
    void *tramp_page = mmap(NULL, 0x4000,
                            PROT_READ | PROT_WRITE | PROT_EXEC,
                            MAP_PRIVATE | MAP_ANONYMOUS | MAP_JIT, -1, 0);

// 4. 写入 trampoline
    memcpy(tramp_page, ctx.origin_code, tramp_len);
    //   附加一条跳回原函数剩余部分的指令
    emit_branch(tramp_page + tramp_len, target + tramp_len);

*origin_call = tramp_page;

// 5. 修改目标函数所在内存页的权限
    //    iOS 启用 W^X（Write XOR Execute）：内核通常拒绝同一页同时拥有 W + X 权限
    //    mprotect(PROT_WRITE|PROT_EXEC) 在大多数情况下会触发 KERN_PROTECTION_FAILURE
    //    但这并非绝对——取决于 entitlement（如 MAP_JIT）、越狱环境的 AMFI patch 状态、
    //    以及页面原始属性。标准做法分两步：
    //      a) mprotect → PROT_READ|PROT_WRITE（暂时移除执行权限，获得写权限）
    //      b) 写入 hook 指令（此时页不可执行，但反正这段代码还没被调用）
    //      c) mprotect → PROT_READ|PROT_EXEC（恢复执行权限，移除写权限）
    //    越狱环境中，内核的 AMFI W^X 检查可能已被 patch，允许更宽松的操作
    //    非越狱环境的更稳健做法：通过 mach_vm_remap 重映射物理页为可写副本，或通过
    //    远程 task port 用 mach_vm_write + mach_vm_protect 操作
    uintptr_t page_start = (uintptr_t)target & ~(PAGE_SIZE - 1);
    mprotect((void *)page_start, PAGE_SIZE, PROT_READ | PROT_WRITE);

// 6. 写入 hook 跳转指令（此时页权限为 RW，不可执行但可写入）
    //    把 target 处的第一条（或前 3 条）指令替换为 jump to replacement
    emit_branch((void *)target, replace);

// 7. 恢复内存权限为 r-x（移除写权限，恢复执行权限）
    mprotect((void *)page_start, PAGE_SIZE, PROT_READ | PROT_EXEC);

// 8. 刷新指令缓存
    //    ARM 有独立的指令缓存和数据缓存
    //    修改了代码段的字节后，必须调用 sys_icache_invalidate
    sys_icache_invalidate((void *)target, tramp_len);

return 0;
}
```

**Dobby 最难的不是写跳转指令，而是处理边界条件**——被覆盖的指令恰好在调用 `mprotect` 的范围内？目标函数只有不到 4 字节？ARM64e 的 PAC 要不要一起处理？这些才是 Inline Hook 的真正门槛。

### 7.4 PAC：ARM64e 给 Inline Hook 打上的死刑封印

#### 什么是 PAC

**PAC（Pointer Authentication Code）** 是 Apple 从 A12（iPhone XS/XR）和 iOS 12 开始引入的**硬件级指针完整性保护**。它的核心思想很简单：

> 每一个指针（函数地址、返回地址）在存储时，CPU 自动在指针的高位嵌入一个基于密钥生成的 **加密签名（PAC）**。当这个指针被用于跳转时，CPU 用同样的密钥重新计算签名并比对——不匹配就触发 `PAC/AUTH exception`，进程直接崩溃。

> **PAC 签名长度并不固定**：PAC 的可用位数依赖虚拟地址布局（VA_BITS）、TBI（Top Byte Ignore）配置以及具体 PAC 类型（IA/IB/DA/DB/GA），公开研究通常观察到 PAC 占用十几到二十余位高位空间，并非固定的 7 bit。

```
普通 ARM64 指针（64 位）：
+--------------------------------------------------+
|                 实际地址（64 位）                    |
+--------------------------------------------------+

ARM64e PAC 指针（64 位）：
+----------------------------+---------------------+
|    实际地址（含被忽略的 Top Byte）  |    PAC 签名（高位）   |
+----------------------------+---------------------+
              ↑                           ↑
       有效的虚拟地址            CPU 硬件级签名，外界无法伪造

注：具体地址和 PAC 各占多少位，依赖 VA_BITS、TCR_EL1 和 TBI 配置，
    不同芯片布局不同，Apple 未公开固定布局。上图为概念示意。
```

PAC 使用了 5 个硬件密钥（`IA Key`、`IB Key`、`DA Key`、`DB Key`、`GA Key`）。从外部行为观察，同一 Task 内的线程之间可以成功共享 PAC 签名指针——这意味着实际实现中跨线程 PAC 认证必然成立（否则 GCD 等多线程机制将崩溃），通常推测 XNU 在进程创建（`exec` / `spawn`）时初始化 PAC 密钥并在 Task 内所有线程间共享。线程上下文切换时，内核将 PAC 密钥重新加载到 `APIAKeyLo_EL1` 等系统寄存器中——**内核（EL1）本身就是密钥的管理者**。真正无法读取这些密钥的是**用户态程序（EL0）**，因为 PAC 寄存器是 EL1 特权资源，EL0 访问直接触发异常。注：Apple 未公开完整 PAC 密钥管理实现，以上基于外部行为推断。

> **为什么不能是线程级密钥？** 如果 PAC 密钥是线程专属的，线程 A 签名的函数或数据指针（例如通过 GCD 派发到子线程生成的对象回调）传递给线程 B 时，就会因签名密钥不匹配而直接触发 `PAC/AUTH exception`——大量跨线程传递的已签名指针将无法通过认证，这与现有系统行为（GCD、block 回调等正常运作）明显不符。

签名算法方面：ARM 架构定义了 PAC 密码学原语（如 QARMA-64），但 Apple 的具体实现细节（密钥派生、算法选择、是否使用自研算法）从未公开。关于"A12 用 QARMA、A14 起切换为自研算法"的说法在公开资料中缺乏直接证据，属于技术社区的推测。

#### PAC 对 Inline Hook 的致命打击

回顾 Inline Hook 的核心操作：在目标函数入口写入 `b replacement_addr`，把执行流引向自定义函数。在 ARM64 下，这只是一条 4 字节的 `b` 指令，地址是普通指针，随便写。

**但在 ARM64e（PAC 开启）下，问题来了：**

| Hook 操作 | ARM64（正常） | ARM64e（PAC 开启） |
| --- | --- | --- |
| 写入 `b replacement` | ✅ 直接跳转 | ✅ `b` 是 PC-relative 直接编码，不经过指针，PAC 不参与，近程跳转不受影响 |
| 构造 trampoline（间接跳转路径） | ✅ 复制指令 + `b orig` | ⚠️ 若 trampoline 涉及指针间接跳转（如 `blr x16`）且指向签名指针，则需 PAC；若走 `b` 直接跳转则不受影响 |
| 从 trampoline 跳回原函数 | ✅ 直接跳转 | ⚠️ 取决于跳转方式：PC-relative `b` 安全，通过签名指针间接跳转需要合法 PAC |

用一句话总结：**PAC 保护的是"指针"而非"指令"——`b`（PC-relative 直接编码）天然不受 PAC 影响；真正受 PAC 约束的是通过寄存器携带的间接跳转目标（如 `BRAA`、`BLRAA`、`RETAA`）。**

#### PAC 涉及的几条关键指令

```asm
; ===== ARM64（无 PAC）：普通跳转 =====
B    x0            ; 无条件跳转到 x0 的值 —— 无签名检查
BLR  x0            ; 调用 x0，保存 LR —— 无签名检查
BR   x0            ; 间接跳转到 x0 —— 无签名检查
RET                ; 返回 —— 从 LR 跳转，无签名检查

; ===== ARM64e（PAC 开启）：新增 PAC 认证跳转指令 =====
; 注意：ARM64e 并未修改 BLR / BR / RET 的语义，它们仍然不验证 PAC。
; PAC 验证仅发生在带 *AA / *AB 后缀的专用指令上：
BRAA  x0, x16      ; 跳转到 x0，用 x16 作为 context 验证 PAC 签名
BRAB  x0, x16      ; 同上，使用 IB Key
BLRAA x0, x16      ; 调用 x0，用 x16 验证签名，LR 自动签名
BLRAB x0, x16      ; 同上，使用 IB Key
RETAA              ; 返回 —— 验证 LR 的 PAC 签名（IA Key）
RETAB              ; 返回 —— 验证 LR 的 PAC 签名（IB Key）
AUTIA x0, x16      ; 单独验证 x0 的 PAC 签名（不跳转）
PACIA x0, x16      ; 为 x0 生成 PAC 签名（IA Key）
```

> **关键区分**：`BLR` / `BR` / `RET` 在 ARM64e 下**语义不变**，不验证 PAC。只有当编译器/链接器显式使用 `BLRAA` / `BRAA` / `RETAA` 等带认证后缀的指令时，CPU 才会执行 PAC 校验。Inline Hook 如果写入普通 `BLR`，在 ARM64e 上不会被 PAC 拦截。

#### 已有工具的 PAC 支持现状

| 工具 | PAC 支持 | 原理 |
| --- | --- | --- |
| **ElleKit** | ✅ 部分支持 | 近程 hook 仍然用 `b`（±128MB 范围），因为 `b` 是 PC-relative 直接编码，不经过指针，不受 PAC 影响。远程 hook（超出 ±128MB 范围）通常借助异常处理机制绕过 PAC 限制。 |
| **Dobby** | ⚠️ 有限支持 | 对 arm64e 目标的近程 hook 可用，远程 hook 未完整适配。部分 trampoline 实现可能涉及 PAC 返回链（取决于是否走 RETAA/编译器生成代码/LR 签名），需要额外处理。 |
| **litehook** | ⚠️ 支持有限 | 近程分支跳转在 arm64/arm64e 上可用，但对 ARM64e/PAC 场景支持有限，不同版本差异较大。 |
| **fishhook** | ⚠️ 需手动处理 PAC 签名 | 在 ARM64e + iOS 14+ 的 `__AUTH_CONST.__auth_got` 中，GOT 表项存储的**函数指针**可能受到 PAC 保护。是否需要重新签名取决于 bind 类型、discriminator、key 类型和 dyld 生成方式。一种常见做法是参照 dyld 的签名逻辑：`ptrauth_sign_unauthenticated()` 配合正确的 discriminator 对替换地址签名后再写入 GOT。但并非所有 `__auth_got` 条目都需要此操作。 |
| **hwbp hook** | ✅ 不受影响 | 硬件断点 Hook 利用 CPU 调试寄存器（`DBGBVR`/`DBGBCR`）在目标地址设置硬件指令断点，完全不修改内存，因此对 PAC、代码签名校验等对内存敏感的防护手段天然免疫。注意：这与软件断点（`brk` 指令 + Mach Exception）是两个不同机制。 |
| **Substrate / Substitute / libhooker** | ⚠️ 旧版不支持 | 这些框架诞生于 A11 时代，原生不支持 PAC。需要通过 ElleKit 这类新引擎间接获得 PAC 兼容性。 |

#### 为什么 `b` 指令不受 PAC 影响？

这是 ARM64e PAC 设计的关键细节：

```asm
; B 指令：PC-relative 直接跳转
; 目标地址 = PC + imm26 << 2，由指令本身编码，不经过寄存器
; → 没有"指针"可签名 → PAC 不介入
B _my_replacement ; 不受 PAC 影响（±128MB 范围）

; BRAA 指令：间接跳转 + PAC 认证
; 目标地址来自寄存器，是一个带 PAC 签名的指针
; → CPU 验证签名 → 不匹配就 crash
BRAA x16, x17           ; 验证 x16 中的 PAC 签名后跳转
```

PAC 保护的核心对象是**指针值**，而非跳转指令本身。`b` 指令的目标地址直接编码在指令字中（PC-relative immediate），不存在"指针"概念，因此 PAC 机制完全不参与。`BRAA` / `BLRAA` / `RETAA` 等带认证后缀的指令才是 PAC 的检查点。

---

## 8. 三个让你疯掉的 Hook 调试现场

### 8.1 Method Swizzling 的 load 竞态——哪个 tweak 先跑？

**现象**：越狱设备装了两个 tweak，都 hook 了 `-[UIApplication openURL:]`。一个 tweak 工作正常，另一个间歇性失效。两个单独用时都正常，一起装就崩。

**排查**：两个 tweak 都在 `+load` 方法里做 Method Swizzling。问题在于：**tweak A hook 后，把原始 IMP 保存到 `orig_openURL`。tweak B 也 hook，但 B 拿到的是 A 已经改过的 IMP**。当 A 调用 `orig_openURL` 时，实际执行的是 B 的 hook 层——如果 B 的实现不是"可重入"的（即不支持被链式调用），就 crash。

**修复**：ElleKit 在 API 层面做了链式调用兼容——每个 hook 返回的 `orig` 指针自动指向"前一层"，形成调用链。但如果 tweak 自己用 Runtime API 直接交换，链式不会自动成立。

**教训**：**Method Swizzling 的 `orig` 不是你自己的 `orig`，是你前面的 hook 者的 `orig`。**

**⚠️ 严禁在 Hook 方法内调用 `class_getMethodImplementation` 来获取"原始 IMP"**——因为交换后 Runtime 返回的正是当前已经被 Hook 的 IMP（即你自身或链顶层）。如果你在 Hook 内部调用它，它会再次跳入你的 Hook，瞬间触发无限递归栈溢出。正确的做法只有两种：

1. **静态保存原始 IMP**：在 Hook 初始化时（`+load` 或构造函数中）将原始 IMP 保存到一个全局/静态函数指针，调用时直接强转调用这个指针
2. **依赖底层框架的 Trampoline**：如 ElleKit / Substrate 在内存中构造的闭包，将真正的 `orig` 隔离出来，规避多重 Hook 引发的死循环竞态

### 8.2 fishhook 搞不定的静态符号——`ptrace` 到底藏在哪里？

**现象**：想用 fishhook hook `ptrace` 来防止 App 被调试，但 `rebind_symbols` 返回 0（成功），实际调用 `ptrace` 时却完全没有被拦截。

**排查**：`ptrace` 的实现在 `libsystem_kernel.dylib` 中。如果 App 显式声明并调用了 `int ptrace(int, pid_t, caddr_t, int)`，编译器和链接器会正常生成 GOT 表项——不存在"跨模块内联"的可能，因为编译器在编译 App 时根本没有 `libsystem_kernel` 的源码或中间码。

真正的原因是：安全开发者为了防 fishhook，**主动避开了 GOT**。最常用的两种手段：

1. **间接系统调用（部分失效）**：`syscall(SYS_ptrace, PT_DENY_ATTACH, 0, 0, 0)` — Apple 在较新的 iOS 版本中使 `SYS_ptrace` 等部分系统调用号在内核层面失效（返回 `ENOSYS`），导致通过 `syscall()` 间接调用这些功能无法生效。但 `syscall()` 函数本身至今（iOS 18）仍然存在于 `libsystem_kernel.dylib` 中，是一个导出符号，安全研究代码中仍广泛使用。真正被封锁的是特定 syscall number，而非 `syscall()` 函数本身。
2. **纯内联汇编**：`__asm__ volatile("mov x0, #31; mov x1, #0; mov x16, #26; svc #0x80")` — 直接向 XNU 内核发起 supervisor call，从指令到参数全部自包含，不碰 GOT、不碰符号表、不经过 dyld 的任何流程。**这是现代 iOS 反调试的硬核手段之一**，与 `ptrace(PT_DENY_ATTACH)`、`sysctl(P_TRACED)`、`csops`、AMFI 状态检测、dyld 环境检测、代码完整性校验等手段共同构成多层反调试体系。

**修复**：对这类"半内联"的符号，fishhook 无能为力。需要改用 Inline Hook（Dobby）直接 patch `ptrace` 的函数入口地址。

**教训**：**fishhook 只能 hook"老老实实走 GOT"的外部符号，而安全开发者会用 `syscall()` 和 `svc` 内联汇编主动绕开 GOT。** 对抗 fishhook 比对抗 Inline Hook 容易得多——换一个调用方式就够了。这也是为什么高级反 Hook 必须走到 Inline Hook 或硬件断点层级。

### 8.3 Dobby 的地址碰撞——hook 目标正好在页边界

**现象**：某 App 的私有 C++ 函数，用 Dobby hook 后 App 启动 crash。崩溃日志显示 `EXC_BAD_ACCESS`，地址落在一个奇怪的只读区域。

**排查**：> 以下为 Inline Hook 跨页边界问题的示意推演案例。被 hook 的函数入口地址是 `0x100013FF0`——距离代码段最后一页的边界只有 16 字节。iOS ARM64 的虚拟内存页大小通常为 **16KB (`0x4000`)**（但也有 4KB 的情况，应通过 `vm_page_size` 运行时查询），`mprotect` 作用于整页（`0x100010000`-`0x100013FFF`），但跳转指令（`adrp + add + br`）占 12 字节，剩余 4 字节不够写完。更致命的是，下一页面（`0x100014000`）属于 `__DATA` 段，权限本来就是 rw-——Inline Hook 框架的 `mprotect` 逻辑若假设目标函数始终落在连续的代码段页内，跨页边界的情况就需要特殊处理。

**修复**：用一个简单的页对齐前检查：如果函数尾部的所有 hook 指令能落在当前页内，正常 hook；如果跨页，则把 hook 指令写在 trampoline 里，目标函数入口改为 `b trampoline`。

**教训**：**写 Inline Hook 框架，最难的不是 ARM64 编码，而是把"你以为连续的东西"和"实际物理布局"之间的差异全部处理掉。**

---

## 9. 四种"非主流"但杀伤力极大的底层 Hook 手段

前面 8 节覆盖了主流的 OC Swizzling / GOT / Inline Hook 三条路线。但在极端的对抗场景下——尤其是深入C++ 引擎、Mach 异常调度、或内核级攻防时——还有四种相对小众但杀伤力极大的手段。

### 9.1 C++ 虚表 Hook（VTable Hooking）—— 绕过代码段校验的终极手段

在逆向以 C++ 为主的引擎（Unity IL2CPP、Unreal Engine，或系统底层的 WebKit / JavaScriptCore）时，常规的 fishhook 和 OC Swizzling 统统失效——因为它们面向的是 C 符号和 ObjC Runtime，而 C++ 的多态走的是完全不同的路径。

**原理**：包含虚函数的 C++ 对象，其内存布局的首 8 字节是一个指向**虚函数表（VTable）**的指针 `vptr`。VTable 是一块连续内存，按声明顺序存储各个虚函数的地址。调用 `obj->foo()` 的汇编等价于：

```asm
; 伪代码：C++ 虚函数调用的底层实现
LDR  x8, [x0]        ; 从 this 指针取 vptr（对象首 8 字节）
LDR  x8, [x8, #0x10] ; 从 VTable 取第 3 个虚函数的地址（假设 foo 是第 3 个虚函数）
BLR  x8              ; 间接调用
```

**攻击手段一：替换单个对象的 `vptr`**

```c
// 以下为伪代码，还原 C++ VTable Hook 的核心逻辑
// 仅影响单个实例，类似 ObjC 的 ISA Swizzling

struct VTableHook {
    void **original_vtable;   // 原虚函数表
    void **fake_vtable;       // 伪造的虚函数表
    size_t vtable_size;       // 虚函数表大小（函数个数 × 8 字节）
};

// 对单个 C++ 对象做 VTable Hook
void vtable_hook_instance(void *obj, int method_index, void *replacement) {
    // 1. 读取对象的 vptr（首 8 字节）
    void **vptr = *(void ***)obj;

// 2. 获取准确的 VTable 大小
    //    Itanium C++ ABI 布局：vptr[-2] = offset_to_top, vptr[-1] = RTTI 指针
    //    虚函数从 vptr[0] 开始。如果只从 vptr[0] 复制，伪造的 VTable 丢失 RTTI
    //    和 offset_to_top——dynamic_cast、异常展开时访问 fake[-1] 直接 crash
    size_t method_count = get_vtable_method_count_from_rtti(vptr);

// 3. 分配内存：虚函数 + 2 个头部元数据槽位
    //    从 vptr - 2 开始完整复制，保证负偏移访问安全
    void **fake_vtable = (void **)malloc((method_count + 2) * sizeof(void *));
    memcpy(fake_vtable, vptr - 2, (method_count + 2) * sizeof(void *));

// 4. 替换目标虚函数（注意索引偏移：fake_vtable[0]=offset_to_top, [1]=RTTI）
    fake_vtable[2 + method_index] = replacement;

// 5. ★ 核心操作：将对象 vptr 指向 fake_vtable + 2
    //    fake_vtable + 0 = offset_to_top, fake_vtable + 1 = RTTI（负偏移安全）
    //    fake_vtable + 2 = 第一个虚函数入口
    *(void ***)obj = (void **)(fake_vtable + 2);
}
```

**隐蔽性**：只修改堆内存（对象的 `vptr`）或数据段，完全不碰代码段（`__TEXT`）。传统的代码段哈希校验、`sys_icache_invalidate` 扫描对它毫无察觉——这是反外挂引擎的盲区。

**攻击手段二：直接修改 VTable 内存（影响该类的所有实例）**

如果能通过内核漏洞获得对 VTable 所在页的写权限，直接覆盖 VTable 中的函数指针，将对一个类的所有实例生效。这种方式更粗暴，但需要注意：在 ARM64e 二进制中，VTable 中的函数指针也可能启用 PAC 保护（取决于编译器、编译选项和函数类型），直接覆盖可能触发认证失败。

### 9.2 Mach 异常端口 Hook — 伪造成 Crash 的隐蔽拦截

硬件断点 Hook（hwbphook）利用 CPU 调试寄存器，而**软件异常同样可以作为无痕 Hook 引擎**。

**原理**：

1. 用 `task_set_exception_ports` 注册自定义 Mach 异常端口
2. 在目标函数入口写入非法指令（如 `brk #1` 或故意制造的内存违规）
3. 执行到此处 → XNU 传递 `EXC_BREAKPOINT` 异常到注册端口
4. 异常处理程序读取 `arm_thread_state64_t` 寄存器快照，修改参数/PC，完成逻辑替换后再恢复线程

```c
// 以下为伪代码，还原基于 Mach 异常端口的隐蔽 Hook 引擎
// 参考 osfmk/mach/exception_types.h 和 task_set_exception_ports 的实现

#include <mach/mach.h>

typedef struct {
    mach_port_t exception_port;      // 接收异常消息的端口
    void       *target_func;         // 被 hook 的函数地址
    uint32_t    saved_instr;         // 被覆盖的原始指令（备份）
    void       *replacement;         // 自定义替换函数
    thread_t    target_thread;       // 目标线程
} ExceptionHook;

// Step 1: 注册异常端口
kern_return_t setup_exception_hook(ExceptionHook *hook) {
    // 创建一个 Mach port 用于接收异常
    kern_return_t kr = mach_port_allocate(mach_task_self(),
                                          MACH_PORT_RIGHT_RECEIVE,
                                          &hook->exception_port);

// 为当前 task 注册异常端口
    // EXC_MASK_BREAKPOINT: 只拦截断点异常
    kr = task_set_exception_ports(
        mach_task_self(),
        EXC_MASK_BREAKPOINT,          // 只对断点异常感兴趣
        hook->exception_port,
        EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES,  // 64-bit 异常码
        ARM_THREAD_STATE64             // 获取 ARM64 线程状态
    );

return kr;
}

// Step 2: 在目标函数入口写入断点指令
void insert_breakpoint(ExceptionHook *hook) {
    // 备份原始指令（4 字节）
    hook->saved_instr = *(uint32_t *)hook->target_func;

// 写入 brk #1 指令（编码: 0xD4200020）
    // 注意：此处假设越狱环境或已获得适当权限（W^X 已 patch、CS_VALID 绕过）
    //    在严格 iOS 环境下，W^X / CS_VALID / JIT 限制会导致此操作失败
    uintptr_t page = (uintptr_t)hook->target_func & ~(PAGE_SIZE - 1);
    vm_prot_t cur_prot, max_prot;
    mach_vm_protect(mach_task_self(), (mach_vm_address_t)page, PAGE_SIZE,
                    0, VM_PROT_READ | VM_PROT_WRITE);       // r-x → rw-
    uint32_t brk_instr = 0xD4200020;
    mach_vm_write(mach_task_self(), (mach_vm_address_t)hook->target_func,
                  (vm_offset_t)&brk_instr, sizeof(brk_instr));
    mach_vm_protect(mach_task_self(), (mach_vm_address_t)page, PAGE_SIZE,
                    0, VM_PROT_READ | VM_PROT_EXEC);         // rw- → r-x
}

// Step 3: 异常处理循环（在独立线程中运行）
void *exception_handler_thread(void *arg) {
    ExceptionHook *hook = (ExceptionHook *)arg;

while (1) {
        // 等待 Mach 异常消息
        //    mach_msg_header_t 只有 24 字节，EXC_BREAKPOINT 包含 body 数据
        //    （thread port、task port 等），Buffer 过小 → MACH_RCV_TOO_LARGE
        uint8_t recv_buf[2048];
        mach_msg_header_t *msg = (mach_msg_header_t *)recv_buf;
        kern_return_t kr = mach_msg(msg, MACH_RCV_MSG, 0, sizeof(recv_buf),
                         hook->exception_port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
        if (kr != KERN_SUCCESS) continue;

// 从异常消息中提取目标线程端口（位于消息 Body 中）
        thread_t target_thread = extract_thread_from_exc_msg(msg);

// 解析线程状态 —— CPU 寄存器快照
        arm_thread_state64_t state;
        mach_msg_type_number_t state_count = ARM_THREAD_STATE64_COUNT;
        thread_get_state(target_thread,
                         ARM_THREAD_STATE64,
                         (thread_state_t)&state, &state_count);

// ★ 核心：修改 PC 和执行参数，实现逻辑替换
        //   替换函数的参数通过 x0-x7 传递
        state.__x[0] = state.__x[0];   // 保持原有参数
        state.__pc = (uint64_t)hook->replacement;  // 跳转到自定义函数

// 写回修改后的线程状态
        thread_set_state(target_thread,
                         ARM_THREAD_STATE64,
                         (thread_state_t)&state,
                         ARM_THREAD_STATE64_COUNT);

// ★ 向内核回复异常处理结果 —— Mach 异常是双向消息协议
        //    内核发送 EXC_BREAKPOINT 后阻塞线程，等待处理端口的回复
        //    只修改 state 而不回消息 → 内核认为异常未处理 → Kill 进程
        //    正常路径：修改 thread state → 构造 reply → 内核恢复线程从新 PC 继续执行
        mach_msg_header_t reply;
        reply.msgh_bits        = MACH_MSGH_BITS(MACH_MSG_TYPE_MOVE_SEND_ONCE, 0);
        reply.msgh_remote_port = msg.msgh_remote_port;  // 内核的回复端口
        reply.msgh_local_port  = MACH_PORT_NULL;
        reply.msgh_id          = 0;
        reply.msgh_size        = sizeof(reply);
        mach_msg(&reply, MACH_SEND_MSG, reply.msgh_size, 0,
                 MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);

// 注意：线程在异常发生时已处于挂起状态，收到 reply 后内核自动恢复。
        // 额外的 thread_resume() 可能导致引用计数不匹配，应避免。
    }
    return NULL;
}
```

**隐蔽性优势**：
- 不需要写 12 字节的跳板指令（`adrp + br`），只改 4 字节的 `brk`
- 可以伪装成普通的 Crash，对抗检测完整 Hook 指令序列的扫描器
- 异常处理程序运行在独立线程，不污染目标线程的调用栈

**代价**：每次拦截触发一次 Mach 消息往返（用户态 → 内核 → 用户态），性能开销远大于 Inline Hook。高频调用的函数不适合此方案。

### 9.3 `objc_msgSend` 汇编级全局拦截 — 每一行 OC 代码都逃不掉

如果想做全局行为打点——比如监控整个 App 内所有 OC 方法的调用，一个个 Swizzle 太慢且容易遗漏。最高效的方式是直接劫持消息发送的入口。

**原理**：Objective-C 的每一条 `[obj method]` 调用，编译器最终都会转化为对 `objc_msgSend` 的调用。`objc_msgSend` 是纯汇编写的（必须保护所有寄存器状态以平滑传递给实际 IMP）。用 Dobby 拦截 `objc_msgSend`，在替换函数中保存现场、记录调用、恢复现场后跳回原函数。

开源项目 **InspectiveC**（David Goldman, 7e6K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6V1j5i4k6A6k6r3N6G2L8r3c8E0j5h3&6Q4x3V1k6u0L8Y4y4H3k6h3y4@1K9i4k6W2b7#2!0q4c8W2!0n7b7#2)9^5z5g2!0q4y4g2!0n7x3q4!0n7x3g2!0q4y4W2)9&6z5q4!0m8c8W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4q4!0n7z5q4)9^5x3q4!0q4y4W2)9^5x3q4)9&6c8q4!0q4z5q4!0n7y4#2!0m8c8W2!0q4y4#2)9&6b7g2)9^5y4q4!0q4y4#2!0n7b7W2)9^5c8W2!0q4y4g2)9^5y4g2!0n7z5q4!0q4y4g2!0m8c8g2)9&6c8g2!0q4y4#2)9^5c8g2!0n7x3q4!0q4c8W2!0n7b7#2)9&6b7b7`.`.

```asm
; InspectiveC 的核心思路：在 objc_msgSend 入口处拦截
; 以下为简化版伪汇编，还原全局消息拦截的寄存器保存逻辑

_hooked_objc_msgSend:
    ; 1. 保存所有调用者寄存器（ARM64 调用约定 AAPCS64）
    ;    整数参数: x0-x7（x0=self, x1=SEL, x2-x7=参数 1-6）
    STP  x0, x1,   [sp, #-16]!
    STP  x2, x3,   [sp, #-16]!
    STP  x4, x5,   [sp, #-16]!
    STP  x6, x7,   [sp, #-16]!
    STP  x8, x9,   [sp, #-16]!     ; x8 = isa/返回临时存储

;    SIMD/浮点参数: q0-q7（8 个 128 位寄存器）
    ;    CGRect、CGSize、多个 double 参数都走这些寄存器
    ;    只保存 q0/q1 会污染 q2-q7 → UI 错乱、数据异常
    STP  q0, q1,   [sp, #-32]!
    STP  q2, q3,   [sp, #-32]!
    STP  q4, q5,   [sp, #-32]!
    STP  q6, q7,   [sp, #-32]!

; 2. 记录本次调用信息
    ;    x0 = self, x1 = SEL — 可以直接读取类名和方法名
    BL   _record_invocation

; 3. 恢复所有寄存器（与保存顺序相反，栈后进先出）
    LDP  q6, q7,   [sp], #32
    LDP  q4, q5,   [sp], #32
    LDP  q2, q3,   [sp], #32
    LDP  q0, q1,   [sp], #32
    LDP  x8, x9,   [sp], #16
    LDP  x6, x7,   [sp], #16
    LDP  x4, x5,   [sp], #16
    LDP  x2, x3,   [sp], #16
    LDP  x0, x1,   [sp], #16

; 4. 跳回原始 objc_msgSend
    B    _original_objc_msgSend
```

> **注意**：`objc_msgSend` 的 hook 性能开销极大（每条 OC 调用都经过拦截点），只适合离线分析、调试和打点，不适合线上持续运行。

### 9.4 内核级 Hook — 当攻击者拿到了 tfp0

当对抗级别上升到最高——攻击者掌握了 `tfp0`（Task For Pid 0，即内核任务端口）或 Kernel R/W 时，用户态的所有防御（PAC、代码段校验、App 层 syscall 拦截）全部失效。

**Syscall Table Patching**：直接修改内核的 `sysent`（系统调用入口表），将 `sys_open`、`sys_ptrace` 等条目的函数指针替换为内核模块中的自定义函数。此后**所有用户态进程**的对应系统调用都被拦截，甚至绕过了 `__RESTRICT` 段和 `DYLD_INSERT_LIBRARIES` 的所有限制。

**MACF（Mandatory Access Control Framework）Hook**：XNU 内核内置了 MAC 机制（源自 FreeBSD）。攻击者可以注册恶意的 MAC Policy，在 VFS 层（文件读写）、`proc_check` 层（进程创建/调试）、Socket 层实现比用户态彻底无数倍的拦截。MACF Hook 的一个关键特征是：它运行在 **内核上下文** 中，用户态的任何反 Hook 手段（代码段校验、Inspection、`sysctl` 扫描）都对它完全不可见。

> **内核级 Hook 需要 tfp0 或等效的 Kernel R/W 原语**，通常由越狱工具的内核漏洞利用提供。在非越狱设备上无法实现，但这不意味着它不重要——它定义了 Hook 技术的理论上限。

---

## 10. 社区工具生态数据：谁在用什么

| 工具 | 架构 | 代表使用者 |
| --- | --- | --- |
| **Cydia Substrate** | OC+C+Inline 统一 | Cydia 时代所有 tweak |
| **Substitute** | Substrate 的开源社区替代（Rootful 时代） | Electra / unc0ver / Chimera |
| **libhooker** | 双层 hook 引擎，Swift 基板 | Taurine / Odyssey / Odysseyra1n |
| **fishhook** | GOT 符号重绑定 | 非越狱 hook（MonkeyDev） |
| **Dobby** | 多平台 Inline Hook | 越狱/安全研究/脱壳 |
| **ElleKit** | SW JIT 汇编 + 远程 hook | **Dopamine / palera1n** |
| **litehook** | 分支跳转 + GOT 重绑定 | 轻量级场景 |

三个趋势信号：
- **ElleKit 成为 rootless 时代最主流的 Hook 引擎**：Dopamine 和 palera1n 都默认支持 ElleKit，因为它完整支持 Substrate API 和 libhooker API，同时适配 A12+ PAC/BTI
- **Simple is better**：litehook 只依赖 libsystem，不引入任何外部依赖，说明社区在追求"够用就好"而不是"大而全"
- **越狱检测的军备竞赛推动 hwbphook**：硬件断点 hook 因为不修改内存（靠 CPU 调试寄存器），传统 hook 检测手段完全失效——但它也受限于硬件断点寄存器数量（不同芯片的 BRP/WRP 数量可能不同，应通过读取 `ID_AA64DFR0_EL1` 寄存器确定；以常见 Apple Silicon 为例约 **6 个 BRP + 4 个 WRP**，hwbphook 使用指令断点，上限由实际 BRP 数量决定）

---

## 11. 每种 Hook 方案的边界：不该期望什么

### Method Swizzling 的边界
- ❌ **Hook 不了纯 C 函数**：没有 `SEL`，Runtime 无路可走
- ⚠️ **父类方法需要特殊处理**：`class_getInstanceMethod` 会沿继承链查找，hook 父类方法会影响所有子类
- ⚠️ **`+load` 的 hook 需要特殊入口**：在 `+load` 或更早阶段（如 dyld 回调）中 hook `+load` 本身是完全可行的，但需要合理的注入时机和工具链。`SubstrateAdapter` 提供了更可靠的初始化顺序保证；`__attribute__((constructor))` 也是被 Substrate、ElleKit、libhooker、Logos 等成熟框架广泛使用的初始化方式，两者各有适用场景

### fishhook 的边界
- ❌ **静态/内联函数无效**：无 GOT 条目
- ❌ **系统私有符号需要先找地址**：fishhook 按符号名匹配，但很多系统函数在公开头文件里没有声明
- ⚠️ **PAC 保护下的 GOT 可能需要手动 re-sign**：ARM64e 设备上，`__AUTH_CONST.__auth_got` 中的函数指针受 PAC 保护，写入前可能需要调用 `ptrauth_sign_unauthenticated()` 重新签名（具体取决于 bind 类型、discriminator 和 key 类型）
- ⚠️ **`__la_symbol_ptr` 在现代系统库中大幅缩水**：从 iOS 14/15 开始，大量外部函数调用迁移到受 PAC 保护的非懒加载绑定（`__AUTH_CONST.__auth_got` 等），传统的懒加载表不再是唯一的 hook 入口。现代 fishhook 已同时支持 `__la_symbol_ptr`、`__nl_symbol_ptr`、`__got`、`__auth_got` 等多个 section

### Inline Hook 的边界
- ❌ **PAC/BTI 保护**：ARM64e 的指针认证会让篡改后的跳转目标被 CPU 拒绝
- ❌ **代码完整性校验**：某些 App 在运行时校验代码段哈希，发现被改立即退出
- ⚠️ **线程安全性**：改代码段时如果另一个线程正在执行被改的函数，行为未定义

### 统一框架（Substrate/ElleKit）的边界
- ⚠️ **依赖越狱环境**：需要 dylib 注入 + 代码签名绕过
- ⚠️ **版本适配滞后**：新 iOS 大版本发布后，框架通常需要 1-3 个月才能稳定支持

---

## 12. Hook 的未来：从黑盒拦截到透明插桩

### 短期方向

1. **ARM64e PAC 的适配深化**：ElleKit 已在大量 A12+ 设备上稳定运行多年（Dopamine/palera1n 默认使用），但 ARM64e 的 PAC 机制仍然给 Inline Hook 带来额外复杂度——尤其是在涉及 PAC 返回链和远程跳转的场景下

2. **硬件断点成为必备武器**：hwbphook 的价值不在于日常 hook，而在于"最后一公里"——当 App 用了代码完整性校验 + PAC + BTI 三重防护，硬件断点仍然是可工作的手段之一（此外还有 Mach Exception Hook、VTable Hook、GOT Hook 等路径）

3. **无需传统越狱的注入能力崛起**：TrollStore + Bootstrap 的组合（依赖 CoreTrust 漏洞）让设备无需完整越狱即可获得类似 tweak 的 dylib 注入能力，hook 工具的战场从"越狱环境"扩展到了更广义的系统应用级权限环境

### 长期趋势

- **Swift 的 Hook 挑战**：Pure Swift 方法通常不经过 ObjC 运行时派发（标注 `@objc` 或 `dynamic` 的除外），传统的 Method Swizzling 对纯 Swift 方法无效。新的 hook 机制需要在 Swift 的 witness table / protocol conformance 层面做文章
- **Apple 的反制**：`dyld4` 引入了更严格的内存布局随机化，同时 Mach-O 二进制可通过 `__RESTRICT,__restrict` 段直接禁用 `DYLD_INSERT_LIBRARIES` 注入；配合大量私有符号的编译期剥离和 `__AUTH_CONST` PAC 保护——Apple 在 Segment 级、符号级、指令级三个层面同步封堵 hook 的入口

---

## 13. Hook 的本质不是改代码，是控制执行流

> 从 `method_exchangeImplementations` 到 `DobbyHook`，从 GOT 表到硬件断点（`DBGBVR`/`DBGBCR`）、Mach Exception Hook——iOS Hook 工具链演进了 15 年，不变的核心只有一句话：**改变原本的控制流目标，让它指向你指定的位置。** 理解了这一点，所有 Hook 框架都只是这条原理的不同实现。

---

## 参考资料

[1] fishhook — Facebook, 7d1K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6X3j5h3y4W2j5X3!0G2K9#2)9J5c8X3k6A6M7$3S2Z5L8$3!0C8
[2] Dobby — jmpews, f8cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6B7L8i4m8W2N6%4y4Q4x3V1k6p5L8$3u0T1P5b7`.`.
[3] ElleKit — tealbathingsuit, 6cfK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6@1k6h3q4D9j5X3q4@1K9r3W2F1k6%4y4#2K9i4c8Q4x3V1k6W2L8r3I4W2K9$3W2@1
[4] litehook — opa334, f4eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2M7r3p5K6x3K6c8Q4x3V1k6D9K9i4c8W2K9r3!0G2K9H3`.`.
[5] ElleKit — The Apple Wiki, 4c8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6@1K9r3g2S2M7s2m8D9k6i4N6A6K9$3W2Q4x3X3g2U0L8$3#2Q4x3V1k6%4K9h3E0A6i4K6u0r3c8h3I4D9k6f1E0A6N6l9`.`.
[6] Cydia Substrate — Saurik, 2d4K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3y4&6k6r3W2S2M7%4g2T1M7%4c8J5j5i4c8W2i4K6u0W2j5$3!0E0i4K6u0r3
[7] Objective-C Runtime Programming Guide — Apple, 598K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1k6i4k6W2L8r3!0H3k6i4u0Q4x3X3g2S2M7s2m8D9k6g2)9J5k6h3y4G2L8g2)9J5c8X3c8G2j5%4g2E0k6h3&6@1j5i4c8A6L8$3&6Q4x3V1k6G2j5X3A6W2j5%4c8A6N6X3g2U0i4K6u0r3L8$3u0B7k6h3y4@1K9i4k6W2i4K6u0V1j5#2)9#2k6Y4u0#2L8Y4c8A6L8h3f1`.
[8] Mach-O Programming Topics — Apple (Archived)
[9] ARM Architecture Reference Manual — ARM Ltd.
[10] iOS App Hook — Urinx, f5fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6g2M7X3W2F1P5q4)9J5c8X3W2a6f1@1q4H3M7p5S2G2L8$3D9`.
[11] fishhook 原理深度剖析 — 掘金, 8d8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6B7N6h3g2B7K9h3&6Q4x3X3g2U0L8W2)9J5c8Y4m8G2M7%4c8Q4x3V1j5%4y4e0V1$3z5e0M7#2x3o6x3#2y4o6x3^5y4K6V1J5y4K6p5K6
[12] Dobby 框架源码学习 — 看雪, https://bbs.kanxue.com/thread-280661.htm
[13] iOS Hook 框架终极对决 — CSDN, 3f5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6T1L8r3!0Y4i4K6u0W2j5%4y4V1L8W2)9J5k6h3&6W2N6q4)9J5c8X3N6A6N6r3u0D9L8$3N6Q4y4h3j5H3x3o6x3#2z5q4)9J5c8X3q4J5N6r3W2U0L8r3g2Q4x3V1k6V1k6i4c8S2K9h3I4K6i4K6u0r3x3e0f1J5y4e0l9J5x3U0f1^5

---

> **声明**：本文仅从技术角度分析 iOS Hook 工具的工作原理，旨在帮助安全研究人员和 iOS 开发者理解运行时修改与代码注入的安全机制。Hook 技术可能违反 App 的使用条款，请确保你的行为符合当地法律法规和软件许可协议。

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最新回复 (74) 1 2 3 ▶
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 693 粉丝 7 关注私信	mb_ldbucrik 2 楼感谢分享 2026-6-8 18:49 0
mb_aszywhsj 雪币： 9 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 28 粉丝 0 关注私信	mb_aszywhsj 3 楼 66666 2026-6-8 21:54 0
kingking888 雪币： 3174 活跃值： (6254) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 294 粉丝 6 关注私信	kingking888 4 楼 666 2026-6-8 22:13 0
tonykros 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 99 粉丝 0 关注私信	tonykros 5 楼 666 2026-6-9 02:23 0
mb_yaitzugg 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_yaitzugg 6 楼 6666 2026-6-9 05:49 0
XCicada 雪币： 3085 活跃值： (2680) 能力值： ( LV6，RANK：80 ) 在线值：发帖 3 回帖 323 粉丝 101 关注私信	XCicada 2 7 楼 666 2026-6-9 08:55 0
wx_插曲雪币： 411 活跃值： (896) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 318 粉丝 24 关注私信	wx_插曲 8 楼 6 2026-6-9 09:45 0
mb_qimctavn 雪币： 5254 活跃值： (6670) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 392 粉丝 1 关注私信	mb_qimctavn 9 楼 6 2026-6-9 09:51 0
guijingwen 雪币： 7342 活跃值： (7540) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 306 粉丝 0 关注私信	guijingwen 10 楼 66 2026-6-9 11:17 0
fengyunabc 雪币： 5386 活跃值： (6187) 能力值： ( LV4，RANK：50 ) 在线值：发帖 11 回帖 632 粉丝 27 关注私信	fengyunabc 1 11 楼感谢分享。 2026-6-9 11:24 0
YANG、雪币： 22 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 36 粉丝 0 关注私信	YANG、 12 楼感谢分享。 2026-6-9 12:20 0
墨穹呢雪币： 4730 活跃值： (8157) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 225 粉丝 18 关注私信	墨穹呢 13 楼感谢分享 2026-6-9 12:34 0
tubecityman 雪币： 344 活跃值： (2781) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 63 粉丝 0 关注私信	tubecityman 14 楼学习下 2026-6-9 15:44 0
Imxz 雪币： 112 活跃值： (9435) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 754 粉丝 9 关注私信	Imxz 15 楼 tql 2026-6-9 16:58 0
毛毛毛毛虫雪币： 2904 活跃值： (3380) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 73 粉丝 0 关注私信	毛毛毛毛虫 16 楼学习一下 2026-6-9 20:54 0
yuzhouheike 雪币： 638 活跃值： (3399) 能力值： ( LV5，RANK：60 ) 在线值：发帖 9 回帖 38 粉丝 25 关注私信	yuzhouheike 17 楼学习 2026-6-9 21:21 0
mb_dikxczkf 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	mb_dikxczkf 18 楼 666 2026-6-10 11:14 0
jasonxgw 雪币： 207 活跃值： (1846) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 52 粉丝 0 关注私信	jasonxgw 19 楼 tql 2026-6-10 16:43 0
Midsw 雪币： 29 活跃值： (1275) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 125 粉丝 1 关注私信	Midsw 20 楼 tql。 2026-6-11 21:51 0
MaYil 雪币： 9408 活跃值： (7977) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 478 粉丝 2 关注私信	MaYil 21 楼感谢分享 2026-6-11 23:00 0
mb_xjdhrmck 雪币： 276 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 146 粉丝 0 关注私信	mb_xjdhrmck 22 楼 tql 2026-6-12 10:20 0
ATrueMan 雪币： 1050 活跃值： (1645) 能力值： ( LV2，RANK：10 ) 在线值：发帖 11 回帖 87 粉丝 14 关注私信	ATrueMan 23 楼 study 2026-6-12 11:05 0
随风而行aa 雪币： 7767 活跃值： (25159) 能力值： ( LV12，RANK：550 ) 在线值：发帖 39 回帖 423 粉丝 1585 关注私信	随风而行aa 10 24 楼看看 2026-6-12 16:34 0
merryfish 雪币： 442 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 22 粉丝 0 关注私信	merryfish 25 楼 thanks 2026-6-12 20:11 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复