[原创]frida-gum 源码解读-逆向工程-看雪安全社区｜专业技术交流与安全研究论坛

[原创]frida-gum 源码解读

发表于: 2025-11-5 20:01 7570

[原创]frida-gum 源码解读

教教我吧~

2025-11-5 20:01

7570

# frida-gum 源码解读

学习 frida 源码，先从 test 案例入口开始分析，以 https://bbs.kanxue.com/thread-278423.htm 作为指导进行学习，有理解不对的地方欢迎指正，谢谢。

## `Interceptor` (拦截器) 的单元测试

测试文件 `frida\subprojects\frida-gum\tests\core\arch-arm64\interceptor-arm64.c`

### 宏观理解 - 这段代码在做什么？

你看到的这段代码是一个 **单元测试（Unit Test）**。

1. **目标模块：** `Interceptor` (拦截器)，这是 Frida 用来实现 <a href="elink@977K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6X3M7X3W2V1j5g2)9J5k6i4u0W2i4K6u0r3k6r3!0U0M7#2)9J5c8X3k6#2L8X3y4@1K9h3!0F1M7#2)9J5c8R3`.`.">Inline Hook</a> 的核心组件。
2. **目标架构：** `interceptor_arm64`，这特指是为 ARM64 架构（目前绝大多数 64 位智能手机的 CPU 架构）编写的测试。
3. **核心概念：`lr` 寄存器**
 - 在 ARM64 架构中，`lr` (Link Register，链接寄存器，也叫 `X30`) 扮演着至关重要的角色。
 - 当一个函数（比如 `A`）调用另一个函数（比如 `B`）时，CPU 会把 `A` 函数中“调用 B 之后的下一条指令地址”（即 **返回地址**）存放到 `lr` 寄存器中。
 - 当 `B` 函数执行完毕时，它会执行一条 `RET` 指令，这条指令的作用就是“跳转到 `lr` 寄存器里存储的地址去执行”。
 - **一句话总结：`lr` 寄存器存放着函数的返回地址。**
4. **测试的真正目的：一个棘手的边界情况**

- Frida 的 `Interceptor` 是如何工作的？它会直接修改目标函数（比如 `B`）开头的几条指令，替换成一条跳转指令（`BL` 或 `B`），跳转到 Frida 自己的代码（我们称之为“Trampoline”或“跳板机”）。
   - **问题来了：** 当 CPU 执行这条跳转指令（`BL`）时，它会 *覆盖* `lr` 寄存器，写入一个新的返回地址（即跳板机执行完后要返回的地址）。
   - **如果原函数 `B` 本身就需要读取 `lr` 寄存器怎么办？** 比如，有些函数（尤其是“thunk”或编译器生成的辅助函数）可能会依赖 `lr` 寄存器的值来计算地址。
   - 如果 Frida 不妥善处理，原函数 `B` 读到的 `lr` 就会是 *错误* 的（被 Frida 篡改过的），导致程序崩溃。
   - **所以，** 这两个测试（`..._reading_lr`）的 **核心目的** 就是：**验证 Frida 的 `Interceptor` 在 Hook 那些会读取 `lr` 寄存器的函数时，能否正确地“修复”或“模拟” `lr` 寄存器，保证原函数逻辑依然能正确执行。** 这展示了 Frida 为了保持稳定性和兼容性所做的底层努力。
     - **`attach_to_function_reading_lr`**：一个“标准函数”，Frida hook 它时 **会** 破坏 `LR`, 导致函数读取到 **错误** 的 `LR` 值。
     - **`attach_to_thunk_reading_lr`**：一个“Thunk 函数”（一种特殊的跳转函数），Frida hook 它时 **会启用特殊保护**，**不会** 破坏 `LR`。
 ![](upload/attach/202511/940077_2XDR34TJ6NMNSW7.webp)

------

### 代码列表 - 测试套件定义

```c
TESTLIST_BEGIN (interceptor_arm64)
  TESTENTRY (attach_to_thunk_reading_lr)
  TESTENTRY (attach_to_function_reading_lr)
TESTLIST_END ()
```

- `TESTLIST_BEGIN (interceptor_arm64)`：定义一个名为 `interceptor_arm64` 的测试列表（或称“测试套件”）。
- `TESTENTRY (...)`：在这个套件中注册两个单独的测试用例。
- `TESTLIST_END ()`：结束定义。

这部分很简单，只是一个目录，告诉测试框架：“嘿，我们要跑这两个测试。”

------

### 逐行精讲 - `TESTCASE (attach_to_function_reading_lr)`

这个测试用例测试的是：**Hook 一个“会读取 `lr` 寄存器”的\*普通函数\***。

```c
TESTCASE (attach_to_function_reading_lr)
{
  // 1. 准备工作：分配内存
  const gsize code_size_in_pages = 1;
  gsize code_size;
  GumEmitLrFuncContext ctx; // 'ctx' 是一个结构体，像个工具箱，存放这次测试需要的所有变量

code_size = code_size_in_pages * gum_query_page_size (); // 计算1个内存页到底是多少字节
  ctx.code = gum_alloc_n_pages (code_size_in_pages, GUM_PAGE_RW); // 分配1页可读(R)可写(W)的内存

// 2. 初始化工具箱
  ctx.run = NULL;     // C语言的函数指针，指向我们要测试的函数
  ctx.func = NULL;    // 原始函数指针
  ctx.caller_lr = 0;  // 用来存放“期望的”lr值

// 3. 动态生成测试函数（最关键的步骤之一）
  gum_memory_patch_code (ctx.code, code_size, gum_emit_lr_func, &ctx);
```

- **深入讲解 `gum_memory_patch_code`**:
  - 这个函数会调用 `gum_emit_lr_func` (这是一个辅助函数，我们看不到它的定义，但可以猜出它的功能)。
  - `gum_emit_lr_func` 的作用是：**动态地在 `ctx.code` 这块内存里写入几条 ARM64 汇编指令**。
  - 这些汇编指令构成了一个小函数，这个函数的功能很简单：**读取当前的 `lr` 寄存器，并将其作为返回值返回**。
  - 同时，`gum_emit_lr_func` 还会填充 `ctx` 这个“工具箱”：
    - `ctx.func` 会指向这个刚生成的函数的入口地址。
    - `ctx.run` 会被设置成一个可以直接在 C 代码里调用的函数指针。
    - `ctx.caller_lr` 会被设置成一个“预期值”，即在 *正常调用*（未被 Hook 时）这个函数时，它 *应该* 读到的 `lr` 值。

```c
  // 4. 【测试点A】: 验证函数在 Hook 前是否正常
  g_assert_cmphex (ctx.run (), ==, ctx.caller_lr);
```

- `ctx.run()`：执行我们刚生成的那个“返回 `lr` 值”的函数。
- `g_assert_cmphex (...)`：这是一个断言。它检查 `ctx.run()` 的返回值是否**等于 (==)** `ctx.caller_lr`（那个预期值）。
- **意义：** 这一步必须通过。它证明了我们的测试函数本身是编写正确的。

```c
 // 5. 【核心操作】: Attach！开始 Hook
 interceptor_fixture_attach (fixture, 0, ctx.func, '>', '<');
```

- 这行代码告诉 Frida 的 `Interceptor`：“请马上 Hook `ctx.func` 这个地址上的函数！”
- `fixture` 是测试框架提供的上下文。`'>'` 和 `'<'` 是 onEnter 和 onLeave 探针的标识，用来验证 Hook 是否真的执行了。

```c
 // 6. 【测试点B】: 验证 Hook 后的行为
 g_assert_cmphex (ctx.run (), !=, ctx.caller_lr);
 g_assert_cmpstr (fixture->result->str, ==, "><");
```

- `g_assert_cmphex (ctx.run (), !=, ctx.caller_lr);`
 - 我们 *再一次* 调用 `ctx.run()`。但这一次，它已经被 Hook 了！
 - 调用会先进入 Frida 的跳板机，这个过程会改变 `lr` 寄存器。
 - 这个测试断言：`ctx.run()` 的返回值 **不等于 (!=)** 原始的 `ctx.caller_lr`。
 - **意义：** 这说明 Hook 确实生效了，并且改变了函数的执行流程。对于这个 *简单* 的 `lr` 读取函数，Frida 似乎 *没有*（或 *不需要*）去恢复那个原始的 `lr` 值，返回的是一个 *新* 的 `lr` 值（比如跳板机里的某个返回地址）。这符合预期。
- `g_assert_cmpstr (fixture->result->str, ==, "><");`
 - 检查 `fixture->result->str`（一个日志字符串）是否等于 `"><"`。
 - **意义：** `>` 代表 onEnter 探针被执行，`<` 代表 onLeave 探针被执行。这证明了我们的 Hook 不仅改变了流程，而且 onEnter/onLeave 回调也成功触发了。

```c
  // 7. 清理工作
  interceptor_fixture_detach (fixture, 0); // 卸载 Hook
  gum_free_pages (ctx.code);               // 释放内存
}
```

### 逐行精讲 - `TESTCASE (attach_to_thunk_reading_lr)`

这个测试用例测试的是：**Hook 一个“会读取 `lr` 寄存器”的\*Thunk 函数\***。

- **什么是 Thunk (垫片/跳板)？**
  - Thunk 是一种非常小的函数，它通常不做别的，只做一件事：**跳转到另一个函数**。
  - `BL target_function` (跳转并链接到目标函数)
  - `B target_function` (直接跳转到目标函数)
  - Thunk 经常被编译器用来处理（比如）跨模块调用或虚函数表。
  - Hook Thunk 非常棘手，因为它们太短了，Frida 可能没有足够的空间来插入它的跳转指令。

```c
TESTCASE (attach_to_thunk_reading_lr)
{
  // 1. 准备工作 (和上一个测试完全一样)
  const gsize code_size_in_pages = 1;
  gsize code_size;
  GumEmitLrThunkContext ctx; // 这次用的是 Thunk 的“工具箱”

code_size = code_size_in_pages * gum_query_page_size ();
  ctx.code = gum_alloc_n_pages (code_size_in_pages, GUM_PAGE_RW);
  ctx.run = NULL;
  ctx.thunk = NULL;
  ctx.expected_lr = 0;

// 2. 动态生成 Thunk 函数
  gum_memory_patch_code (ctx.code, code_size, gum_emit_lr_thunk, &ctx);
```

- **深入讲解 `gum_memory_patch_code`**:
  - 这次它调用的是 `gum_emit_lr_thunk`。
  - 这个函数会在 `ctx.code` 里写入一个 *Thunk*。
  - 这个 Thunk 不仅会跳转，它在跳转前 *还会* 读取 `lr` 寄存器，并把它和 `ctx.expected_lr` (由 `gum_emit_lr_thunk` 设置的预期值) 进行比较。
  - 我们可以猜测，这个 Thunk 的返回值（通过 `ctx.run()`）很可能就是它读到的 `lr` 值（或者是一个比较结果）。
  - `ctx.thunk` 指向这个 Thunk 的入口地址。

```c
  // 3. 【测试点A】: 验证 Thunk 在 Hook 前是否正常
  g_assert_cmphex (ctx.run (), ==, ctx.expected_lr);
```

- 和上个测试一样，断言 `ctx.run()` 的返回值**等于 (==)** 预期值。
- **意义：** 证明我们动态生成的 Thunk 在未被 Hook 时工作正常。

```c
 // 4. 【核心操作】: Attach！Hook 这个 Thunk
 interceptor_fixture_attach (fixture, 0, ctx.thunk, '>', '<');
```

- 告诉 `Interceptor` 去 Hook 这个（可能非常短的）Thunk。

```c
 // 5. 【测试点B】: 验证 Hook 后的行为（这是最关键的区别！）
 g_assert_cmphex (ctx.run (), ==, ctx.expected_lr);
 g_assert_cmpstr (fixture->result->str, ==, "><");
```

- `g_assert_cmphex (ctx.run (), ==, ctx.expected_lr);`
 - 我们再次调用 `ctx.run()` (此时它已被 Hook)。
 - **注意！** 这里的断言是**等于 (==)**！
 - **这说明了什么？**
 - 这说明 **即使 Thunk 被 Hook 了**，Frida 的 `Interceptor` 也 **成功地** 让这个 Thunk 内部的 `lr` 读取逻辑拿到了 **和未 Hook 时完全一样** 的 `lr` 值 (`ctx.expected_lr`)！
 - 这就是我们之前说的“`lr` 修复”或“`lr` 模拟”。当 Frida 把原 Thunk 的代码“搬家”到别处（Relocation）时，它必须智能地分析 Thunk 的代码，如果发现它在读取 `lr`，Frida 必须把 *原始的、未被篡改的* `lr` 值保存下来，并“喂”给被搬家的 Thunk 代码。
 - 这个断言通过，意味着 Frida 成功做到了这一点。
- `g_assert_cmpstr (fixture->result->str, ==, "><");`
 - 和之前一样，这证明 onEnter/onLeave 探针确实执行了。

```c
  // 6. 清理工作
  interceptor_fixture_detach (fixture, 0);
  gum_free_pages (ctx.code);
}
```

------

### 阶段小结：两个测试的区别和意义

这两个测试非常精彩，它们共同验证了 `Interceptor` 的一个核心能力：

1. **`attach_to_function_reading_lr` (普通函数):**
 - **测试内容：** Hook 一个普通的、会返回 `lr` 值的函数。
 - **测试结果：** Hook 后，函数返回的 `lr` 值 **变了 (`!=`)**。
 - **结论：** 这 OK。Hook 改变了调用流程，`lr` 变了是正常的。同时，Hook 探针 (`><`) 也成功执行。这证明了 **基本的 Hook 功能** 是正常的。
2. **`attach_to_thunk_reading_lr` (Thunk 函数):**
 - **测试内容：** Hook 一个 *依赖* `lr` 值的 Thunk（它可能用 `lr` 来做计算或比较）。
 - **测试结果：** Hook 后，Thunk 内部逻辑拿到的 `lr` 值 **没变 (`==`)**。
 - **结论：** 这非常重要！这证明 Frida 的 `Interceptor` 足够智能，能够 **识别、保存和恢复** 原函数逻辑所依赖的 `lr` 值。即使函数被 Hook（`><` 探针证明了这一点），其原始逻辑也 **丝毫不受影响**。

这就是 Frida 强大的 **稳定性（Robustness）** 的体现。它不仅能 Hook 函数，还能在 Hook 的同时，保证原函数的（尤其是依赖 `lr` 这种易变状态的）逻辑不被破坏。

### ==== ==== ==== ==== ===

----

**下面从“它做了什么” (What it does) 转向了“它是怎么做的” (How it does it)。**

看上面两个 TESTCASE 中的公共函数 **interceptor_fixture_attach** 是 Frida 测试框架中用于“挂钩” (Hook) 的辅助函数 (Helper Functions)。让我们来解剖它们。

------

### 简单包装器 `interceptor_fixture_attach`

```c
static void
interceptor_fixture_attach (InterceptorFixture * h,
                            guint listener_index,
                            gpointer test_func,
                            gchar enter_char,
                            gchar leave_char)
{
  g_assert_cmpint (interceptor_fixture_try_attach (h, listener_index, test_func,
      enter_char, leave_char), ==, GUM_ATTACH_OK);
}
```

#### 逐行讲解：

1. `static void interceptor_fixture_attach(...)`
 - `static`: 这个函数只在当前这个 C 文件内可见。
 - `void`: 这个函数不返回任何值。
 - 它接收的参数和我们在 `TESTCASE` 中看到的一模一样：
 - `h`：测试“固定装置”(Fixture)，包含了像 `interceptor` 和 `result` 这样的全局测试状态。
 - `test_func`：我们要 Hook 的目标函数地址。
 - `enter_char` 和 `leave_char`：就是 `'>'` 和 `'<'`。
2. `g_assert_cmpint ( ... , ==, GUM_ATTACH_OK);`
 - `g_assert_cmpint` 是一个 **断言**。它的作用是：如果 `...` 的结果**不等于 (==)** `GUM_ATTACH_OK`，程序就 ** 立即崩溃 ** 并报告测试失败。
 - `GUM_ATTACH_OK` 是一个枚举值，代表“附加成功”。
 - `interceptor_fixture_try_attach(...)`：它调用了你给的第一个函数，也就是“真正干活”的函数。

`interceptor_fixture_attach` 是一个 **“必须成功”的包装器**。

它存在的意义就是为了让 `TESTCASE` 里的代码更简洁。在测试中，我们 *期望* Hook 总是成功的。所以我们用这个函数：它去尝试 Hook，如果失败了，就直接让测试失败。如果成功了，它就安静地返回。

------

#### 核心实现 `interceptor_fixture_try_attach`

这是真正的主菜。这个函数负责 **创建并注册一个监听器 (Listener)**，然后把它附加 (attach) 到目标函数上。

```C
static GumAttachReturn
interceptor_fixture_try_attach (InterceptorFixture * h,
                                guint listener_index,
                                gpointer test_func,
                                gchar enter_char,
                                gchar leave_char)
{
  GumAttachReturn result;
  Arm64ListenerContext * ctx;
```

- `GumAttachReturn`: 这个函数的返回值，它会告诉调用者是成功 (`GUM_ATTACH_OK`) 还是失败了。

```C
  // --- 步骤 1: 清理可能存在的旧监听器 ---
  ctx = h->listener_context[listener_index];
  if (ctx != NULL)
  {
    arm64_listener_context_free (ctx);
    h->listener_context[listener_index] = NULL;
  }
```

- `h->listener_context` 是一个数组，用来存放我们创建的监听器上下文。
- `listener_index` 告诉我们要操作这个数组中的第几个元素（在我们的测试中，它总是 `0`）。
- **逻辑：** 在附加一个新的监听器之前，先检查一下这个“槽位”上是不是已经有一个旧的了。如果 `ctx != NULL`（说明有旧的），就调用 `arm64_listener_context_free (ctx)` 把它释放掉，防止 **内存泄漏**。

```C
  // --- 步骤 2: 创建新的监听器上下文 (Context) ---
  ctx = g_slice_new0 (Arm64ListenerContext);
```

- `g_slice_new0`: 这是 GLib 库提供的内存分配函数，可以把它理解为 `malloc`。它分配了一块足够存放 `Arm64ListenerContext` 结构体的内存，并把内存清零。
- `ctx` 现在指向一个我们自己的“工具箱”结构体。

```C
  // --- 步骤 3: 配置监听器 (Listener) ---
  ctx->listener = test_callback_listener_new ();
  ctx->listener->on_enter =(TestCallbackListenerFunc) arm64_listener_context_on_enter;
  ctx->listener->on_leave =(TestCallbackListenerFunc) arm64_listener_context_on_leave;
  ctx->listener->user_data = ctx;
```

- 这是 **最核心的逻辑**。我们正在配置一个 `listener` 对象。
- `ctx->listener`: `ctx` 这个“工具箱”里有一个 `listener` 成员。
- `ctx->listener->on_enter = ... arm64_listener_context_on_enter;`
  - `on_enter` 是一个 **函数指针**。
  - 这行代码的意思是：“当 Hook 被触发（即目标函数刚要执行）时，请去调用 `arm64_listener_context_on_enter` 这个函数。”
- `ctx->listener->on_leave = ... arm64_listener_context_on_leave;`
  - 同理：“当目标函数执行完毕（即刚要返回）时，请去调用 `arm64_listener_context_on_leave` 这个函数。”
- `ctx->listener->user_data = ctx;`
  - **关键中的关键！** `user_data` 是一个“用户自定义数据”指针。
  - 我们把 `ctx`（我们刚创建的“工具箱”）的地址赋值给了它。
  - **为什么？** 因为当 Frida 调用 `...on_enter` 时，它会把 `user_data`（也就是 `ctx`，上下文信息）作为参数传给 `...on_enter`。这样，我们的回调函数就能拿到完整的“工具箱”（上下文信息），从而访问到 `fixture`、`enter_char` 等信息。

```C
  // --- 步骤 4: 填充我们自己的上下文信息 ---
  ctx->fixture = h;
  ctx->enter_char = enter_char;
  ctx->leave_char = leave_char;
```

- 我们把测试需要的数据存放到“工具箱” `ctx` 中。

- `ctx->fixture = h;`：把测试“固定装置”`h` 存进去。

- `ctx->enter_char = enter_char;`：把 `'>'` 存进去。

- `ctx->leave_char = leave_char;`：把 `'<'` 存进去。

- **回顾一下 ` Hooked 函数调用` 的工作流：**

1. 目标函数被调用，Hook 触发。

2. Frida 调用 `on_enter`（即 `arm64_listener_context_on_enter`）。

3. Frida 把 `user_data`（即 `ctx`）传给 `on_enter`。

4. `on_enter` 函数内部：

(1). 通过 `ctx` 拿到 `ctx->fixture`（即 `h`）。
     (2). 通过 `ctx` 拿到 `ctx->enter_char`（即 `'>'`）。
     (3). 把 `'>'` 追加到 `h->result->str` 字符串的末尾。

5. **Frida 调用原始的目标函数（`ctx.run()` 内部的原始逻辑）。**

6. 原始函数执行完毕，准备返回。Frida 在它真正返回 *之前*，调用 `on_leave` (即 `arm64_listener_context_on_leave`)。

7. `on_leave` 函数内部：

(1). 通过 `ctx` 拿到 `ctx->fixture`（即 `h`）。
 (2). 通过 `ctx` 拿到 `ctx->leave_char`（即 `'<'`）。
 (3) 把 `'<'` 追加到 `h->result->str` 字符串的末尾。

*(此时，`h->result->str` 的内容变成了 `"><"`)*

8. `on_leave` 返回，Frida 将原始函数的返回值（如果有的话）交还给调用者。

这就是 `fixture->result->str == "><"` 这个断言的由来！

```C
  // --- 步骤 5: 执行真正的附加 (Attach) 操作 ---
  result = gum_interceptor_attach (h->interceptor, test_func,
      GUM_INVOCATION_LISTENER (ctx->listener), NULL,
      GUM_ATTACH_FLAGS_NONE);
```

- 这行代码是 **对 Frida `Interceptor` 核心 API 的真正调用**。
- `gum_interceptor_attach`: 这是 Frida 的 C API。
- `h->interceptor`: 告诉 Frida 用哪个拦截器实例。
- `test_func`: 告诉 Frida 要 Hook 哪个函数。
- `GUM_INVOCATION_LISTENER (ctx->listener)`: 告诉 Frida，当 Hook 触发时，使用我们刚刚配置好的 `ctx->listener`（以及它包含的 `on_enter` 和 `on_leave` 指针）来处理回调。
- `result = ...`：`gum_interceptor_attach` 会执行所有复杂的汇编代码修改（比如重写函数开头、设置跳板机），然后返回一个状态码（比如 `GUM_ATTACH_OK`）。

```C
  // --- 步骤 6: 根据结果进行处理 ---
  if (result == GUM_ATTACH_OK)
  {
    h->listener_context[listener_index] = ctx;
  }
  else
  {
    arm64_listener_context_free (ctx);
  }

return result;
}
```

- **如果附加成功 (`result == GUM_ATTACH_OK`)：**
  - `h->listener_context[listener_index] = ctx;`：把我们新创建的“工具箱”`ctx` 存放到 fixture 的数组中。**为什么？** 这样在测试结束时（或者下次再调用 attach 时），我们可以找到它并正确地释放它（见步骤 1）。
- **如果附加失败 (`else`)：**
  - `arm64_listener_context_free (ctx);`：附加失败了，意味着这个 `ctx` 永远不会被使用。我们必须 **立即释放它**，否则就会 **内存泄漏**。
- `return result;`：把 `GUM_ATTACH_OK` 或错误码返回给上一层（也就是 `interceptor_fixture_attach`）。

### 阶段小结：Frida Hook 的标准流程

通过分析这两个函数，你实际上已经学通了 Frida `Interceptor` (C API 层面) 的标准工作流程：

1. **分配上下文 (Context)**：创建一个结构体（如 `Arm64ListenerContext`）来存放你需要的所有信息（回调函数、用户数据等）。

2. **创建监听器 (Listener)**：创建一个 `GumInvocationListener` 对象。

3. **配置回调 (Callbacks)**：设置 `listener->on_enter` 和 `listener->on_leave` 指向你自己的 C 函数。

4. **设置 `user_data`**：把你的 **上下文 (Context)** 地址赋值给 `listener->user_data`。这是连接回调函数和你的数据的桥梁。

5. **调用 `gum_interceptor_attach`**：传入目标函数和配置好的监听器，执行 Hook。

6. **处理结果**：
   
   - 成功：保存你的上下文，以便将来释放。
   - 失败：立即释放你的上下文，防止内存泄漏。
   
---

### ==== ==== ==== ==== ===

----

**可以注意到，其中 `on_enter` 和 `on_leave` 是可以由用户自行重载的。然后再从 `gum_interceptor_attach` 进入，该函数包括了布置 hook 并启动 hook 的任务：**

----

```c
//frida\subprojects\frida-gum\gum\guminterceptor.c
GumAttachReturn
gum_interceptor_attach (GumInterceptor * self,
                        gpointer function_address,
                        GumInvocationListener * listener,
                        gpointer listener_function_data,
                        GumAttachFlags flags)
{
  GumAttachReturn result = GUM_ATTACH_OK;
  GumFunctionContext * function_ctx;
  GumInstrumentationError error;

gum_interceptor_ignore_current_thread (self);
  GUM_INTERCEPTOR_LOCK (self);
  gum_interceptor_transaction_begin (&self->current_transaction);
  self->current_transaction.is_dirty = TRUE;

function_address = gum_interceptor_resolve (self, function_address);

function_ctx = gum_interceptor_instrument (self, GUM_INTERCEPTOR_TYPE_DEFAULT,
      function_address, &error);

if (function_ctx == NULL)
    goto instrumentation_error;

if (gum_function_context_has_listener (function_ctx, listener))
    goto already_attached;

gum_function_context_add_listener (function_ctx, listener,
      listener_function_data, (flags & GUM_ATTACH_FLAGS_UNIGNORABLE) != 0);

goto beach;

instrumentation_error:
  {
    switch (error)
    {
      case GUM_INSTRUMENTATION_ERROR_WRONG_SIGNATURE:
        result = GUM_ATTACH_WRONG_SIGNATURE;
        break;
      case GUM_INSTRUMENTATION_ERROR_POLICY_VIOLATION:
        result = GUM_ATTACH_POLICY_VIOLATION;
        break;
      case GUM_INSTRUMENTATION_ERROR_WRONG_TYPE:
        result = GUM_ATTACH_WRONG_TYPE;
        break;
      default:
        g_assert_not_reached ();
    }
    goto beach;
  }
already_attached:
  {
    result = GUM_ATTACH_ALREADY_ATTACHED;
    goto beach;
  }
beach:
  {
    gum_interceptor_transaction_end (&self->current_transaction);
    GUM_INTERCEPTOR_UNLOCK (self);
    gum_interceptor_unignore_current_thread (self);

return result;
  }
}
```

### C 代码 API 核心 `gum_interceptor_attach`

`interceptor_fixture_try_attach` 只是一个测试辅助函数，而你现在看到的 `gum_interceptor_attach` 则是 **Frida Interceptor 模块的公开 C API 核心**。所有语言（JavaScript, Python, Swift...）的 `Interceptor.attach()` 最终都会调用到这个 C 函数。

让我们来一步步解剖这个“引擎”。

#### 核心功能概览

这个函数的 **真正工作** 可以分为两个阶段：

1. **Instrumentation (插桩)：**
   - 这是“物理”上的修改。Frida 会分析目标函数的汇编代码（这就是我们最开始看 `lr` 分析的地方），然后用一条 `JUMP` 指令替换掉函数开头的几条指令。
   - 这个操作 **只需要做一次**（即使有 100 个 listener，也只 patch 一次）。
2. **Add Listener (添加监听器)：**
   - 这是“逻辑”上的注册。它把你传进来的 `listener`（包含 `onEnter`/`onLeave`）添加到一个列表中。
   - 当“插桩”被触发时，Frida 会遍历这个列表，调用所有注册过的 `listener`。

------

#### 逐段精讲 `gum_interceptor_attach`

```C
GumAttachReturn
gum_interceptor_attach (GumInterceptor * self,
                        gpointer function_address,
                        GumInvocationListener * listener,
                        gpointer listener_function_data, /* 注意这个参数 */
                        GumAttachFlags flags)
{
  GumAttachReturn result = GUM_ATTACH_OK; // 默认返回“成功”
  GumFunctionContext * function_ctx;
  GumInstrumentationError error;
```

- **`listener_function_data` 参数：**
  - 这是一个有趣的点。`GumInvocationListener` (我们传入的 `listener`) 内部已经有了一个 `user_data` 字段（我们用它来存 `ctx`）。
  - 这个 `listener_function_data` 是一个 *额外* 的数据指针，它会被传递给一个 *不同类型* 的 C 回调（如果你不使用 `GumInvocationListener` 对象，而是用一个原始的 C 函数指针作为 listener）。
  - 在我们的测试中，我们把数据打包在了 `listener->user_data` 里，所以上层调用处传了 `NULL`。

------

##### ????️ 阶段 1：准备 - 线程安全与事务

```C
  gum_interceptor_ignore_current_thread (self);
  GUM_INTERCEPTOR_LOCK (self);
  gum_interceptor_transaction_begin (&self->current_transaction);
  self->current_transaction.is_dirty = TRUE;
```

这是在执行“高危操作”（修改正在运行的程序的代码）之前的标准 **安全措施**。

- **`GUM_INTERCEPTOR_LOCK (self)`：**
  - **加锁！** `Interceptor` 是多线程共享的。这个锁（Mutex）确保了同一时间 **只有一个线程** 可以执行 `attach` 或 `detach` 操作。这防止了两个线程同时去 patch 同一个函数，导致灾难。
- **`gum_interceptor_ignore_current_thread (self)`：**
  - **精妙的技巧！** 这行代码告诉 `Interceptor`：“嘿，接下来我（指当前这个线程）要执行一些内部操作了。如果我不小心调用了 *其他* 已经被 Hook 的函数，**请不要** 触发它们的 `onEnter`/`onLeave` 回调。”
  - **为什么这么做？** 
  
    - 在 Frida Hook 框架中，当我们对一个函数（如 `open`, `recv`, `malloc`）安装拦截（intercept）后，**所有线程执行该函数时都会跳转到我们注入的 trampoline / replacement 函数**。但有时，**我们自己当前线程的代码** 也会调用被 Hook 的函数（比如 Hook `malloc` 时，我们自己的日志模块也会用到 `malloc`），
    - 这就可能导致：
  
      > 当前线程陷入递归 hook → 死循环 → 崩溃。
  
      为了避免这种情况，Frida 提供了：
  
    ```
    gum_interceptor_ignore_current_thread(self);
    ```
  
    	它的作用是：
    	 **让当前线程暂时被标记为“忽略拦截”**，
    	当被 hook 的函数在该线程中执行时，Frida 会自动跳过 hook 路径，直接执行原始函数。
- **`gum_interceptor_transaction_begin (...)`：**
  - 开启一个“事务”。Frida 会把这次 `attach` 期间发生的所有内存修改（比如 patch code）都记录在这个事务里。

------

#####  阶段 2：核心 - 插桩 (Instrument)

```C
  function_address = gum_interceptor_resolve (self, function_address);

function_ctx = gum_interceptor_instrument (self, GUM_INTERCEPTOR_TYPE_DEFAULT,
      function_address, &error);

if (function_ctx == NULL)
    goto instrumentation_error;
```

- **`gum_interceptor_resolve (self, function_address)`：**
  - **解析真实地址。** 你传入的 `function_address` 可能并不是函数 *真正的* 入口，它可能是一个 `PLT`（过程链接表）条目，或者一个跳转到别处的 `thunk`。
  - 这个函数会“跟随”这些跳转，直到找到函数 *真正* 的实现代码的地址。
- **`gum_interceptor_instrument (..., function_address, &error)`：**
  - **这就是奇迹发生的地方！** 这是 **整个 `Interceptor` 最核心的函数**。
  - 它接收“真正”的 `function_address`，然后：
    1. **反汇编** 函数开头的指令。
    2. **分析** 这些指令（比如，它是不是在 **读取 `lr`**？—— 这就是我们最初的测试点！）。
    3. **决定** 要 patch 多少字节的代码。
    4. **分配** 内存来创建“跳板机”（Trampoline，用于执行被覆盖的原始指令并跳回来）。
    5. **“JIT”**（即时编译）生成一个 `dispatcher`（分发器），这个分发器负责将来调用 `onEnter`/`onLeave`。
    6. **最后，** 用一条 `JUMP` 指令 **“热修补”** (Hot-patch) 原始函数！
  - 如果这一切都成功了，它会返回一个 `GumFunctionContext` 对象（`function_ctx`），这是一个“钩子管理对象”。
  - 如果失败了（比如代码太短无法 Hook，或遇到了无法识别的指令），它返回 `NULL`。
- **`if (function_ctx == NULL) goto instrumentation_error;`**
  - 如果 `instrument` 失败，就跳转到错误处理代码。

------

##### ✍️ 阶段 3：核心 - 注册 (Add Listener)

```C
  if (gum_function_context_has_listener (function_ctx, listener))
    goto already_attached;

gum_function_context_add_listener (function_ctx, listener,
      listener_function_data, (flags & GUM_ATTACH_FLAGS_UNIGNORABLE) != 0);

goto beach;
```

- **`if (gum_function_context_has_listener (...))`**
  - 检查这个 **一模一样** 的 `listener` 对象是不是已经注册过了？
  - 这说明了很重要的一点：**你可以对同一个函数 `attach` 多个不同的 `listener`**。`instrument`（阶段 2：插桩 ）只会在第一次 `attach` 时执行（插桩只执行一次）。后续的 `attach` 只会执行这个 `add_listener`（阶段 3：注册）。
- **`gum_function_context_add_listener (...)`：**
  - **这才是 `attach` 的第二步。** `instrument` 准备了“舞台”（`function_ctx`），而 `add_listener` 则是把我们的 `listener`（观众）带到这个舞台的观众席上。
  - 它简单地把 `listener` 添加到 `function_ctx` 内部的一个列表里。
- **`goto beach;`**
  - 一切顺利！跳转到最后的清理代码。

------

##### ???? 阶段 4：清理 - `goto` 与资源释放

最后，我们来看看那些 `goto` 语句。在 C 语言中，`goto` 经常被（正确地）用于 **集中的错误处理和资源释放**。这是一种非常标准的模式。

```C
instrumentation_error:
  {
    // ... 根据 'error' 类型设置 'result' 状态码 ...
    goto beach;
  }
already_attached:
  {
    result = GUM_ATTACH_ALREADY_ATTACHED;
    goto beach;
  }
beach:
  {
    gum_interceptor_transaction_end (&self->current_transaction);
    GUM_INTERCEPTOR_UNLOCK (self);
    gum_interceptor_unignore_current_thread (self);

return result;
  }
```

- **`goto beach;` 的含义：**
  - `beach` 是 C 程序员的一个俚语，意思是“去海滩”—— 工作完成了，去放松（清理）吧。
  - 你会发现，无论是 **成功** (`goto beach;`)、**插桩失败** (`goto instrumentation_error;` ... `goto beach;`) 还是 **重复添加** (`goto already_attached;` ... `goto beach;`)，**所有代码路径最后都会汇聚到 `beach:` 标签**。
- **`beach:` 标签下的代码：**
  - `gum_interceptor_transaction_end (...)`：提交事务（让代码 patch 生效）。
  - `GUM_INTERCEPTOR_UNLOCK (self)`：**释放锁！** 这是最关键的一步。无论成功还是失败，都必须释放锁，否则整个程序都会死锁。
  - `gum_interceptor_unignore_current_thread (self)`：恢复当前线程的 Hook 功能。
  - `return result;`：返回最终的状态码。

### gum_interceptor_attach 流程图
 ![](upload/attach/202511/940077_AVBQGTYSZ64YFN6.webp)

### 阶段小结

`gum_interceptor_attach` 是一个 **非常健壮** 的函数：

1. 它首先通过 **锁（Lock）** 和 **事务（Transaction）** 确保线程安全。
2. 它通过 `ignore_current_thread` 防止了 **递归**。
3. 它通过 `gum_interceptor_instrument` **执行** 了“修改代码”这一高危操作（这是你最初研究的 `lr` 问题的核心所在）。
4. 它通过 `gum_function_context_add_listener` **注册** 了我们的回调函数。
5. 它通过 `goto beach;` 模式，确保 **无论成功还是失败**，锁（Lock）和其它资源 **总能被正确释放**。

----

### ==== ==== ==== ==== ===

---

### Inline Hook 原理

Inline Hook（也称内联钩子）是一种低级的函数钩子技术，它通过直接修改目标函数的机器码（通常是函数开头的几条指令）来实现钩子。具体来说，它会用跳转指令（如 jmp）替换函数的起始代码，将执行流重定向到自定义的钩子函数中，执行完钩子后再跳回原函数继续运行。这种方式效率高，但实现复杂，需要处理架构差异（如 ARM、x86）和指令对齐问题。

Inline Hook 可以看作是 Frida 等工具可能采用的一种底层技术，但 Frida 提供了更全面的生态和易用性。如果你是在开发钩子工具，Frida 更推荐入门；如果追求低级控制，则需掌握 Inline Hook。

### frida hook 的执行流

当一个被 Hook 的函数（`TargetFunction`）被调用时，它首先会跳转（JUMP）到 Frida 的“总调度中心”（`Dispatcher`）。这个`Dispatcher`会先保存现场，然后循环调用所有已注册的 `onEnter` 监听器（`Listener`）。接着，它会通过“跳板机”（`Trampoline`）来执行被覆盖的几条原始指令，并跳回到原函数的“身体”部分继续执行。当原函数执行完毕返回时，`Dispatcher`会再次捕获返回，循环调用所有 `onLeave` 监听器，最后才恢复现场，将控制权和（可能被修改过的）返回值交还给最初的调用者。

![](upload/attach/202511/940077_ND572SQPWVNF72R.webp)

### Interceptor 的核心——`gum_interceptor_instrument`

关于 `lr` 寄存器、Thunk、Trampoline 的 **所有** 汇编层面的“脏活累活”，**几乎都发生在这个函数调用的深处**。

`gum_interceptor_attach` (我们上一步看的) 只是一个“前台接待”，它负责处理锁、事务和 Listener 列表。

`gum_interceptor_instrument` 则是“**后台的建筑工头**”。它的工作是：**“去，给我把 `function_address` 这个地方的‘舞台’（`function_ctx`）建好！”**

让我们逐段解剖这个“工头”的施工流程。

------

#### 第 1 阶段：【缓存检查】—— “这个舞台是不是已经建好了？”

```C
static GumFunctionContext *
gum_interceptor_instrument (/* ... */)
{
  GumFunctionContext * ctx;

*error = GUM_INSTRUMENTATION_ERROR_NONE;

ctx = (GumFunctionContext *) g_hash_table_lookup (self->function_by_address,function_address); //function_by_address“全局登记册”

if (ctx != NULL)
  {
    if (ctx->type != type)
    {
      *error = GUM_INSTRUMENTATION_ERROR_WRONG_TYPE;
      return NULL;
    }
    return ctx;
  }
```

- 这是 **整个 `Interceptor` 中最重要的优化**。

- `self->function_by_address` 是一个 **哈希表（HashTable）**，你可以把它想象成一个“全局登记册”。

- `g_hash_table_lookup(..., function_address)` 的意思是：“去登记册里查一下，我们是不是已经为 `function_address` 这个地址建过‘舞台’（`function_ctx`）了？”

- **`if (ctx != NULL)`：**

- **查到了！** 这意味着这是对该函数的 **第二次（或第 N 次）`attach`**。

- “工头”一看：“哦，舞台（`ctx`）已经在了。”

- 它什么也不用做，**直接返回之前建好的那个 `ctx`**。

- **这就是为什么我们说“插桩 (Instrument) 只会发生一次”！**

- `if (ctx->type != type)`

- `type` (类型) 这个参数，代表你 **这次** 想用 *哪种方式* 来 Hook 这个函数。

- Frida 的 `Interceptor` 不仅仅只有 `attach` (附加) 这一种操作，它至少还有（或者曾经有过）另一种操作，比如 `replace` (替换)。
        - `Interceptor.attach` (我们一直在分析的) 对应 `GUM_INTERCEPTOR_TYPE_DEFAULT` (默认类型)。它有 onEnter / onLeave 回调。
        - `Interceptor.replace` (一个不同的 API) 可能对应 `GUM_INTERCEPTOR_TYPE_REPLACE` (替换类型)。它会用一个全新的函数 **完全替换** 掉原函数。

- 这个 `if (ctx->type != type)` 检查就是在说：

“OK，我发现这个函数（`function_address`）**已经被 Hook 过了**（`ctx != NULL`）。

“我检查一下当初 Hook 它的类型（`ctx->type`），是不是和你 **这次** 想用的类型（`type`）一样？

“**如果不一样**（比如你之前用 `attach` Hook 了它，现在又想用 `replace` 去 Hook 它），那对不起，这两种操作是 **互斥** 的！我不能让你这么做。”

- 这是一个 **安全锁**，它确保你 **不能对同一个函数混用不同类型的 Hook**（比如在 `attach` 之后又去 `replace` 它）。如果 Frida 发现你试图这么做，它会返回 `GUM_INSTRUMENTATION_ERROR_WRONG_TYPE`（类型错误）来拒绝这次操作。

- **`if (ctx == NULL)`：**

- 没查到。这是 **第一次** 有人要 Hook 这个函数。
  - “工头”戴上安全帽：“OK，没有舞台，我们得 **从零开始建一个**。”

------

#### 第 2 阶段：【准备施工队】—— “我的汇编工具在哪？”

**_gum_interceptor_backend_create 关键函数**

```C
  if (self->backend == NULL)
  {
    self->backend = _gum_interceptor_backend_create(&self->mutex, &self->allocator); //平台相关(当前 CPU 架构)的具体函数
  }
```

- `self->backend` (后端) 就是“**施工队**”。
- 这个“施工队”是 **架构相关的**（比如 `interceptor-arm64.c`）。它知道如何反汇编 ARM64 指令、如何写 ARM64 的 `JUMP` 指令、如何分析 `lr` 寄存器的使用（**你最初的测试点！**）。
- `if (self->backend == NULL)`：这是 Interceptor 第一次工作，连“施工队”都还没有。`_gum_interceptor_backend_create` 会根据当前 CPU 架构（比如 ARM64）去“雇佣”一个正确的施工队。

------

#### 第 3 阶段：【施工！】—— “开工！建 Trampoline！”

```c
  ctx = gum_function_context_new (self, function_address, type);

if (gum_process_get_code_signing_policy () == GUM_CODE_SIGNING_REQUIRED)
  { //分支 A 
    if (!_gum_interceptor_backend_claim_grafted_trampoline (self->backend, ctx))
      goto policy_violation;  //违反政策 杀死APP
  }
  else
  { //分支 B
    if (!_gum_interceptor_backend_create_trampoline (self->backend, ctx)) //就是我们一直在找的那个函数
      goto wrong_signature;
  }
```

这是 **最核心的施工步骤**。

1. `ctx = gum_function_context_new (...)`：
   - 先创建一个“舞台”的“施工蓝图”（`GumFunctionContext`）。
2. `if (gum_process_get_code_signing_policy () == ...)`：
   - **关键的逻辑分叉！** “工头”在施工前必须检查 **“代码签名”** 策略。
   - **什么是代码签名？** 像 iOS (或 macOS) 这样的 系统 **禁止** 程序创建新的可执行内存 (W^X 策略)。如果你敢自己分配一块内存（`mmap`）并试图在里面写 `JUMP` 指令，系统会 **立刻杀死** 你的 App。
3. **分支 A (iOS / 高安全环境): `GUM_CODE_SIGNING_REQUIRED == true`**
   - `_gum_interceptor_backend_claim_grafted_trampoline (self->backend, ctx)`
   - **“Grafted” (嫁接)** 是这里的关键词。
   - Frida 不能 *创建* 新的可执行内存，但它可以利用一些系统已有的、合法的可执行内存。
   - 这个函数的作用是从一块 **预先准备好** 的、合法的“Trampoline 岛”上，**“认领”** 一块小区域给 `ctx` 用。这是 Frida 绕过代码签名的核心技巧之一。
   - 如果失败了（比如“岛”上没空间了），就 `goto policy_violation` (策略冲突)。
4. **分支 B (Android / Linux / 普通环境): `GUM_CODE_SIGNING_REQUIRED == false`**
   - `_gum_interceptor_backend_create_trampoline (self->backend, ctx)`，这是 **“常规”** 施工路径。
   - **就是它！** **`_gum_interceptor_backend_create_trampoline`** 就是我们一直在找的那个函数！
     - 它会派“施工队”(`backend`) 去 `function_address`：
       - **反汇编** 开头的指令。
       - **分析** 这些指令（比如：**“它是不是在读 `lr`？”**）。
       - **决定** 需要复制多少字节（比如 5 字节，或 12 字节）。
       - **分配** 一块新的可执行内存。
       - **创建** 我们之前在图里画的那个 `Trampoline`（包含“被偷走的指令”+ `JUMP` 回原函数）。
     - 如果这个过程失败了（比如函数太短、或者遇到了无法识别的汇编指令），它会返回 `false`，然后 `goto wrong_signature` (签名错误，这里指“函数特征”错误)。

------

#### 第 4 阶段：【竣工登记 & 提交】

```C
//登记到function_by_address“全局登记册”，实现“只插桩一次”的优化  
g_hash_table_insert (self->function_by_address, function_address, ctx);

//添加任务，设置回调函数 gum_interceptor_activate 用于激活跳板
//gum_interceptor_activate真正是去内存中写入那条 `JUMP` 指令
gum_interceptor_transaction_schedule_update (&self->current_transaction, ctx,gum_interceptor_activate);

return ctx;
```

- `g_hash_table_insert (...)`：
  - **“竣工登记！”** “工头”把新建好的“舞台”(`ctx`) **登记到** `function_by_address` 这个“全局登记册”里。
  - 这样，下一次 `attach` 同一个函数时，**第 1 阶段** 的 `g_hash_table_lookup` 就能 **直接查到它**，实现“只插桩一次”的优化。
- `gum_interceptor_transaction_schedule_update (...)`：
  - **极其精妙的一步！** “工头”建好了 Trampoline，但 **它还不能立刻去 Patch (修改) 原函数**。
  - 为什么？因为它还拿着“锁”（`GUM_INTERCEPTOR_LOCK`）。如果它现在去 Patch，而此时另一个线程正在执行这段代码，就会出大事。
  - 所以，它 **不会** 立刻执行 Patch。它只是 **“调度一个更新”**。
  - 它告诉“事务”（`current_transaction`）：“嘿，等一下你完工（`transaction_end`）的时候，记得帮我调用 `gum_interceptor_activate` 这个函数。”
  - 而 `gum_interceptor_activate` 这个函数的工作，才 **真正是去内存中写入那条 `JUMP` 指令**，让 Hook 正式生效。
- `return ctx;`：
  - “工头”的工作完成了。它返回这个新建好的“舞台”(`ctx`)。

------

#### 第 5 阶段：【错误处理】

```C
policy_violation:
  /* ... */
wrong_signature:
  /* ... */
propagate_error:
  {
    gum_function_context_finalize (ctx);
    return NULL;
  }
```

- 如果在第 3 阶段施工时出了任何问题（`goto policy_violation` 或 `goto wrong_signature`），所有代码都会跳转到 `propagate_error`。
- `gum_function_context_finalize (ctx)`：
  - “施工失败！拆掉刚建了一半的脚手架（`ctx`），别留垃圾。”
- `return NULL;`：
  - 返回 `NULL` 告诉上层（`gum_interceptor_attach`）：“插桩失败了！”
  - `gum_interceptor_attach` 随后就会把这个错误（比如 `GUM_ATTACH_WRONG_SIGNATURE`）返回给 **最上层** 的测试代码。

---

### 阶段小结：`gum_interceptor_instrument` 函數

`gum_interceptor_instrument` 是 Interceptor 的“**建築工頭**”，它是一個 **效率與安全並重** 的函數，其核心職責是 **“建造”**（插樁）一個函數的“舞台”（`ctx`），並確保這個建造過程只發生一次。

- 它首先通過 `g_hash_table_lookup`（哈希表）實現 **“只插樁一次”** 的核心優化。
- 如果函數已被插樁（`ctx != NULL`），它會 **立即執行 `if (ctx->type != type)` 檢查**。這是一個 **一致性安全鎖**，用於防止（例如）在一個已經 `attach` 的函數上再執行 `replace`，如果類型不匹配，它會返回 `GUM_INSTRUMENTATION_ERROR_WRONG_TYPE`。
- 如果緩存未命中（`ctx == NULL`），它會獲取特定於 CPU 架構的“施工隊”（`backend`），這個 `backend` 知道如何處理特定（例如 ARM64）的匯編。
- 它通過 `_gum_interceptor_backend_create_trampoline` 執行 **所有高危且複雜** 的匯編分析操作（包括分析 `lr` 寄存器使用、反匯編、JIT 編譯 Trampoline），並能智能處理高安全環境（如 iOS）。
- 施工成功後，它通過 `g_hash_table_insert` 將新建的 `ctx`（“舞台”）註冊到全局緩存中，供下次快速返回。
- 它通過 `gum_interceptor_transaction_schedule_update` **“調度”** Hook 的激活（即真正的內存 Patch），而不是立即執行，以避免在持有鎖時執行 Patch 帶來的線程安全問題。
- 它通過 `goto ... propagate_error` 模式，確保在施工失敗時，能正確清理掉半成品的 `ctx` 並返回 `NULL`。

### ==== ==== ==== ==== ===

先看【Interceptor的核心——`gum_interceptor_instrument` 】代码中的第 2 阶段：【准备施工队】—— “我的汇编工具在哪？”的`_gum_interceptor_backend_create` 函数

因此我们跟到 `_gum_interceptor_backend_create` 里看看它是如何实现的。该函数是平台相关的具体函数，由于打算分析 arm64 下的实现，因此这里的源代码应为 frida-gum/gum/backend-arm64/guminterceptor-arm64.c

你現在看到的 `_gum_interceptor_backend_create` 函數，就是 `gum_interceptor_instrument` (建築工頭) 在找不到“施工隊”(`self->backend == NULL`)時，調用的“**HR/工具房管理員**”。

它的職責是：**創建並初始化一個特定於 CPU 架構（在這裡是 ARM64）的 `backend`（“施工隊”），並為其配備所有必需的工具。**

------

###  HR/工具房管理员：`_gum_interceptor_backend_create`

#### **第 1 阶段：创建“施工队”并配备“共享工具”**

```c
GumInterceptorBackend *
_gum_interceptor_backend_create (GRecMutex * mutex,
                                 GumCodeAllocator * allocator)
{
  GumInterceptorBackend * backend;

backend = g_slice_new0 (GumInterceptorBackend); //為“施工隊”(`backend`)本身分配內存
  backend->mutex = mutex;
  backend->allocator = allocator;
```

- “工头” (建筑工头) 指的是 **`gum_interceptor_instrument`** 这个函数
- `backend = g_slice_new0 (...)`：為“施工隊”(`backend`)本身分配內存。
- `backend->mutex = mutex;`：把“工頭”（`Interceptor`）的 **全局鎖**（`mutex`）交給“施工隊”。這確保了“工頭”和“施工隊”在操作內存時使用的是 **同一把鎖**，防止了線程衝突。
- `backend->allocator = allocator;`：把“工头”的 **代碼分配器**（`allocator`）交給“施工隊”。`backend`（施工隊）的工作就是創建新的可執行代碼（比如 Trampoline），它需要使用這個分配器來獲取可執行內存。

------

#### **第 2 阶段：关键的环境检查**

```C
  if (gum_process_get_code_signing_policy () == GUM_CODE_SIGNING_OPTIONAL)
  {
```

- `if (gum_process_get_code_signing_policy () == GUM_CODE_SIGNING_OPTIONAL)`
- 這是在檢查：“我們是否处于一個 **允許** 我们 **JIT**（即時編譯）/創建新可執行代碼的環境中？”
- `GUM_CODE_SIGNING_OPTIONAL`（代碼簽名可選）是 **“簡單模式”**（例如 Android, Linux）。
- `GUM_CODE_SIGNING_REQUIRED`（代碼簽名必需）是 **“困難模式”**（例如 iOS）。
- **為什麼要檢查？**
  - 如果是“困難模式”（iOS），我們 **不允許** 自己創建 `writer` 或 `relocator` 來隨意寫代碼。這個 `if` 塊會被 **完全跳過**。`backend` 會以一個“空殼”狀態被返回，並在之後依賴我們之前看到的 `_gum_interceptor_backend_claim_grafted_trampoline`（“嫁接”/“認領”模式）來工作。
  - 如果是“簡單模式”（Android），`if` 塊會被執行。我們可以自由地初始化我們的工具箱。

------

#### **第 3 阶段：初始化“核心工具箱”（仅限“简单模式”, 例如 Android, Linux）**

```C
    gum_arm64_writer_init (&backend->writer, NULL);
    gum_arm64_relocator_init (&backend->relocator, NULL, &backend->writer);
```

- `gum_arm64_writer_init (&backend->writer, NULL);`
 - **初始化“汇编笔” (`writer`)**。`backend->writer` 是一個知道如何 **“写”** ARM64 匯編指令（如 `MOV`, `BLR`, `LDR`）的工具。Frida 會用它來動態生成 `Dispatcher`（總調度中心）的代碼。
- `gum_arm64_relocator_init (&backend->relocator, NULL, &backend->writer);`
 - **初始化“指令搬运工” (`relocator`)**。
 - 這是 **极其关键** 的工具，它直接關係到我們最初分析的 `lr` 寄存器問題。
 - 當 `backend`（施工隊）要去創建 `Trampoline`（跳板機）時，它需要把原函數開頭的幾條指令“偷走”（複製）到 Trampoline 裡。
 - **問題是：** 這些指令可能是“位置相關”的（比如 `ADR X0, ...` 或 `B <label>`）。如果只是簡單地 `memcpy`，這些指令在新的內存地址（Trampoline 裡）就會出錯。
 - `relocator` 的工作就是 **智能地“搬運”這些指令：它會讀取一條指令，分析它，如果它是一條位置相關的指令，`relocator` 會自動修復/重寫** 它，使其在新的位置也能正確工作。這就是“重定位”（Relocation）。
 - **這就是 Frida 如何解決（部分）`lr` 相關問題的答案：`relocator` 在搬運 `LDR Xn, [PC, #...]` 這樣的指令時，會把它們重寫為絕對地址讀取，從而保證其正確性。**

------

#### **第 4 阶段：預先建造“标准零件”（Thunks）**

```C
    gum_interceptor_backend_create_thunks (backend);
  }

return backend;
}
```

- `gum_interceptor_backend_create_thunks (backend);`
  - **“Thunks”（转换块/跳板块）** 是 Frida 需要反複使用的、非常小的、標準化的汇编代碼片段。
  - 比如：一个用于“从 `Dispatcher` 進入 `onEnter` C 回調”的 thunk，或者一個“處理 `leave`”的 thunk。
  - **性能優化：** Frida 不會在 *每次* `attach` 時都重新 JIT (即时编译)编译这些小片段，而是在“施工隊”被創建時，就 **一次性** 把它們全部造好，放在工具箱裡。
  - 當 `_gum_interceptor_backend_create_trampoline`（真正的施工函數）工作時，它會像“搭積木”一樣，把這些預製的 `thunks` 和動態生成的 `Trampoline` 拼接在一起，形成完整的 Hook 逻辑。
- `return backend;`
  - 返回這個裝備精良（或在 iOS 上是“空殼”）的“施工隊”。

------

### 阶段小结

`_gum_interceptor_backend_create` 是 Interceptor 的“**军械库/工具房**”。

- 它的職責是 **創建** 並 **初始化** 特定於 CPU 架構的 `backend`（“施工隊”）。
- 它將 **共享的** `mutex`（鎖）和 `allocator`（內存分配器）传送給 `backend`。
- 它會 **檢查代碼簽名策略**：
  - 在 **高安全環境**（如 iOS），它會跳過所有初始化，返回一個“空殼”`backend`，強制之後的邏輯使用“嫁接”（grafted）模式。
  - 在 **常規環境**（如 Android），它會執行完整的初始化。
- 它會初始化 `gum_arm64_writer`（“**汇编笔**”）和 `gum_arm64_relocator`（“**智能指令搬運工**”）。`relocator` 是保證 Trampoline 內“被偷走”的指令能正確執行的核心。
- 它會調用 `gum_interceptor_backend_create_thunks` **預先編譯** 所有 Hook 流程中需要用到的“標準匯編零件”，這是一個關鍵的性能優化。

### ==== ==== ==== ==== ===

`gum_interceptor_backend_create_thunks` 及其调用的所有函数，其**唯一目的**就是**预先 JIT(即时编译) （创建）两个可重用的汇编代码块**：`enter_thunk` 和 `leave_thunk`。

### 预先编译标准汇编零件：gum_interceptor_backend_create_thunks 函数

这正是我们之前所说的“**性能优化**”。Frida 无需在 *每次* `attach` 时都重新生成这些通用的“桥接”代码，而是在启动时就将它们一次性造好。

让我们像搭乐高一样，从最小的零件（`enter`/`leave` thunk）开始，逐步拼装出完整的逻辑。

从底层向上层看代码

```c
static void gum_interceptor_backend_create_thunks (GumInterceptorBackend * self) //第4部分：最上层
{
  gsize page_size, code_size;
  GumMemoryRange range;

page_size = gum_query_page_size ();
  code_size = page_size;

self->thunks = gum_memory_allocate (NULL, code_size, page_size, GUM_PAGE_RW);

range.base_address = GUM_ADDRESS (self->thunks);
  range.size = code_size;
  gum_cloak_add_range (&range);

gum_memory_patch_code (self->thunks, 1024,
      (GumMemoryPatchApplyFunc) gum_emit_thunks, self);
}

static void gum_interceptor_backend_destroy_thunks (GumInterceptorBackend * self) 
{
  gum_memory_free (self->thunks, gum_query_page_size ());
}

static void gum_emit_thunks (gpointer mem,GumInterceptorBackend * self)//第3部分：中间层
{
  GumArm64Writer * aw = &self->writer;

self->enter_thunk = self->thunks;
  gum_arm64_writer_reset (aw, mem);
  aw->pc = GUM_ADDRESS (self->enter_thunk);
  gum_emit_enter_thunk (aw);
  gum_arm64_writer_flush (aw);

self->leave_thunk = (guint8 *) self->enter_thunk + gum_arm64_writer_offset (aw);
  gum_emit_leave_thunk (aw);
  gum_arm64_writer_flush (aw);
}

static void
gum_emit_enter_thunk (GumArm64Writer * aw)  //第1部分：最底层
{
  gum_emit_prolog (aw);

gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X1, ARM64_REG_SP,
      GUM_FRAME_OFFSET_CPU_CONTEXT);
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X2, ARM64_REG_SP,
      GUM_FRAME_OFFSET_CPU_CONTEXT + G_STRUCT_OFFSET (GumCpuContext, lr));
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X3, ARM64_REG_SP,
      GUM_FRAME_OFFSET_NEXT_HOP);

gum_arm64_writer_put_call_address_with_arguments (aw,
      GUM_ADDRESS (_gum_function_context_begin_invocation), 4,
      GUM_ARG_REGISTER, ARM64_REG_X17,
      GUM_ARG_REGISTER, ARM64_REG_X1,
      GUM_ARG_REGISTER, ARM64_REG_X2,
      GUM_ARG_REGISTER, ARM64_REG_X3);

gum_emit_epilog (aw);
}

static void
gum_emit_leave_thunk (GumArm64Writer * aw) //第2部分：最底层
{
  gum_emit_prolog (aw);

gum_arm64_writer_put_call_address_with_arguments (aw,
      GUM_ADDRESS (_gum_function_context_end_invocation), 3,
      GUM_ARG_REGISTER, ARM64_REG_X17,
      GUM_ARG_REGISTER, ARM64_REG_X1,
      GUM_ARG_REGISTER, ARM64_REG_X2);

gum_emit_epilog (aw);
}
```

----

#### 第 1 部分（最底层）：`gum_emit_enter_thunk`

这是“**进入 Thunk**”（`enter_thunk`）的汇编代码 **生成器**。

`enter_thunk` 是一个标准化的汇编“零件”，它是在 `Dispatcher`（总调度中心）内部被调用的。它的工作是 **从纯汇编的世界“桥接”到 C 语言的世界**，去 **调用那个真正执行 `onEnter` 循环的 C 函数**。

```C
static void
gum_emit_enter_thunk (GumArm64Writer * aw)
{
  // 1. 发出“函数序言”（Prolog）
  //    这会 JIT 编译出保存所有 CPU 寄存器（X0-X28, FP, LR）到堆栈上的代码。
  //    这是“保护现场”。
  gum_emit_prolog (aw);

// 2. 准备 C 函数的参数 (X1, X2, X3)
  //    在 ARM64 C 语言调用约定中，参数通过 X0, X1, X2, X3... 传递。
  //    X0 稍后会设置（它来自 X17）。

//    ADD X1, SP, ...CPU_CONTEXT
  //    将“指向堆栈上 GumCpuContext（包含了所有寄存器值） 结构的指针”放入 X1（第二个参数）。
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X1, ARM64_REG_SP, GUM_FRAME_OFFSET_CPU_CONTEXT);
  //    ADD X2, SP, ...CpuContext.lr
  //    将“指向堆栈上 lr 寄存器保存位置的指针”放入 X2（第三个参数）。
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X2, ARM64_REG_SP, GUM_FRAME_OFFSET_CPU_CONTEXT + G_STRUCT_OFFSET (GumCpuContext, lr));
  //    ADD X3, SP, ...NEXT_HOP
  //    将“指向堆栈上 next_hop 字段的指针”放入 X3（第四个参数）。
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X3, ARM64_REG_SP,
      GUM_FRAME_OFFSET_NEXT_HOP);

// 3. JIT 编译一个 C 函数调用
  gum_arm64_writer_put_call_address_with_arguments (aw,
      GUM_ADDRESS (_gum_function_context_begin_invocation), 4, // 目标C函数
      // 这个 C 函数将接收 4 个参数:
      //   - Arg 1 (X0) = X17 (这是由 Dispatcher 提前设置好的 GumFunctionContext*,（包含了 `listener` 列表) )
      GUM_ARG_REGISTER, ARM64_REG_X17,
      //   - Arg 2 (X1) = X1 (我们刚设置的 GumCpuContext*,（包含了所有寄存器值）)
      GUM_ARG_REGISTER, ARM64_REG_X1,
      //   - Arg 3 (X2) = X2 (我们刚设置的 saved_lr*)
      GUM_ARG_REGISTER, ARM64_REG_X2,
      //   - Arg 4 (X3) = X3 (我们刚设置的 next_hop*)
      GUM_ARG_REGISTER, ARM64_REG_X3);

// 4. 发出“函数终言”（Epilog）
  //    这会 JIT 编译出从堆栈上恢复所有寄存器的代码，并执行 RET（返回）。
  gum_emit_epilog (aw);
}
```

- **`_gum_function_context_begin_invocation`**：
  - 这就是 **真正执行 `onEnter` 的 C 函数**。
  - 它会接收到 `GumFunctionContext*`（包含了 `listener` 列表）和 `GumCpuContext*`（包含了所有寄存器值），然后 **循环遍历** `listener` 列表，逐个调用它们的 `onEnter` 回调。
  - 这就是为什么 `onEnter` 回调可以读取和修改 `this.context.x0` 这样的寄存器！

```
; 步骤 C: 保存所有寄存器（包括 X17）到堆栈
; (gum_emit_prolog)

; 步骤 D: 准备 C 函数的第 2、3、4 个参数 (X1, X2, X3)
ADD X1, SP, ...  ; (GumCpuContext*)
ADD X2, SP, ...  ; (saved_lr*)
ADD X3, SP, ...  ; (next_hop*)

; 步骤 E: 准备 C 函数的第 1 个参数 (X0)
; 关键！把“中转”寄存器 X17 里的值，
; “正式”移动到第一个参数寄存器 X0 中！
MOV X0, X17

; 步骤 F: 调用 C 语言大脑
BL _gum_function_context_begin_invocation
```

------

#### 第 2 部分（最底层）：`gum_emit_leave_thunk`

这是“**离开 Thunk**”（`leave_thunk`）的汇编代码 **生成器**。

它几乎和 `enter_thunk` 一模一样，但它调用的是 **C 函数 `_gum_function_context_end_invocation`**。

```c
static void
gum_emit_leave_thunk (GumArm64Writer * aw)
{
  // 1. 发出“函数序言”（Prolog） - 保存所有寄存器
  gum_emit_prolog (aw);

// 2. 准备 C 函数的参数 (X1, X2)
  //    ADD X1, SP, ...CPU_CONTEXT
  //    将 GumCpuContext* 放入 X1（第二个参数）。
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X1, ARM64_REG_SP,
      GUM_FRAME_OFFSET_CPU_CONTEXT);
  //    ADD X2, SP, ...NEXT_HOP
  //    将 next_hop* 放入 X2（第三个参数）。
  gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X2, ARM64_REG_SP,
      GUM_FRAME_OFFSET_NEXT_HOP);

// 3. JIT 编译一个 C 函数调用
  gum_arm64_writer_put_call_address_with_arguments (aw,
      GUM_ADDRESS (_gum_function_context_end_invocation), 3, // 目标C函数
      // 这个 C 函数将接收 3 个参数:
      //   - Arg 1 (X0) = X17 (GumFunctionContext*)
      GUM_ARG_REGISTER, ARM64_REG_X17,
      //   - Arg 2 (X1) = X1 (GumCpuContext*)
      GUM_ARG_REGISTER, ARM64_REG_X1,
      //   - Arg 2 (X2) = X2 (next_hop*)
      GUM_ARG_REGISTER, ARM64_REG_X2);

// 4. 发出“函数终言”（Epilog） - 恢复所有寄存器并 RET
  gum_emit_epilog (aw);
}
```

- **`_gum_function_context_end_invocation`**：
  - 这就是 **真正执行 `onLeave` 的 C 函数**。
  - 它会循环遍历 `listener` 列表，逐个调用它们的 `onLeave` 回调。

------

#### 第 3 部分（中间层）：`gum_emit_thunks`

这是“**Thunk 布局引擎**”。它调用上面的两个“生成器”，把 `enter_thunk` 和 `leave_thunk` **一前一后** 地写（JIT, 即时编译）到一块内存里。

```c
static void
gum_emit_thunks (gpointer mem,         // 'mem' 是那块新分配的 RW 内存页
                 GumInterceptorBackend * self)
{
  GumArm64Writer * aw = &self->writer; // 拿起“汇编笔”

// 1. 记录 enter_thunk 的起始地址
  self->enter_thunk = self->thunks;
  
  // 2. 将“汇编笔”重置到这块内存的开头
  gum_arm64_writer_reset (aw, mem);
  aw->pc = GUM_ADDRESS (self->enter_thunk); // 告知“笔”当前的绝对地址

// 3. 在内存中 JIT 编译出 enter_thunk 的所有汇编代码
  gum_emit_enter_thunk (aw);
  gum_arm64_writer_flush (aw); // 提交写入

// 4. 记录 leave_thunk 的起始地址
  //    它紧跟在 enter_thunk 的末尾
  self->leave_thunk = (guint8 *) self->enter_thunk + gum_arm64_writer_offset (aw);
  
  // 5. 在内存中 JIT 编译出 leave_thunk 的所有汇编代码
  gum_emit_leave_thunk (aw);
  gum_arm64_writer_flush (aw); // 提交写入
}
```

我们来详细分解 `gum_emit_thunks` 这个“布局引擎”的工作流程：

```c
static void
gum_emit_thunks (gpointer mem,         // mem 是一块刚申请的“空白内存页”
                 GumInterceptorBackend * self)
{
  GumArm64Writer * aw = &self->writer; // 拿到“汇编笔”

/* --- 步骤 1: 写入“前面”的 enter_thunk --- */

// 1a. 把“笔尖”复位 (reset) 到“空白内存页”(mem) 的最开头
  gum_arm64_writer_reset (aw, mem);
  // 1b. 告诉“笔”它现在的绝对地址（用于计算跳转）
  aw->pc = GUM_ADDRESS (self->enter_thunk);

// 1c. 开始 JIT 编译！
  //     “笔”开始在内存上写入 enter_thunk 的所有汇编指令
  //     (比如写了 100 字节)
  gum_emit_enter_thunk (aw);
  
  // 1d. “笔”停在了 enter_thunk 的末尾（即 100 字节处）
  gum_arm64_writer_flush (aw);

/* --- 步骤 2: 写入“后面”的 leave_thunk --- */

// 2a. 记录 leave_thunk 的起始地址：
  //     gum_arm64_writer_offset(aw) 会返回“笔”现在的位置（即 100）
  //     所以 leave_thunk 的地址 = 内存页起始地址 + 100
  self->leave_thunk =
      (guint8 *) self->enter_thunk + gum_arm64_writer_offset (aw);

// 2b. 开始 JIT 编译！
  //     “笔”从它当前的位置（100 字节处）继续写入 leave_thunk 的指令
  gum_emit_leave_thunk (aw);
  
  // 2c. “笔”停在了 leave_thunk 的末尾
  gum_arm64_writer_flush (aw);
}
```

**总结一下：**

“一前一后”的实现非常简单：

1. Frida **首先** 调用 `gum_emit_enter_thunk(aw)`，让“汇编笔” (`aw`) 在空白内存上从头开始写入 `enter_thunk`。
2. 当 `enter_thunk` 写完后，“笔” (`aw`) **自动停在了 `enter_thunk` 的末尾**。
3. Frida **紧接着** 调用 `gum_emit_leave_thunk(aw)`，“笔” (`aw`) 就 **从它当前停止的位置继续**，写入 `leave_thunk` 的内容。

这就好像 **用笔在纸上写字，`enter_thunk` 写完了不换行，紧接着写 `leave_thunk`**。

----

#### 第 4 部分（最上层）：`gum_interceptor_backend_create_thunks`

这是“**Thunk 生产线经理**”。它负责申请内存、“隐藏”内存，并启动“布局引擎”（`gum_emit_thunks`）。

```c
static void
gum_interceptor_backend_create_thunks (GumInterceptorBackend * self)
{
  gsize page_size, code_size;
  GumMemoryRange range;

page_size = gum_query_page_size ();
  code_size = page_size;

// 1. 申请一页 RW（读写）内存
  self->thunks = gum_memory_allocate (NULL, code_size, page_size, GUM_PAGE_RW);

// 2. “隐藏” (Cloak) 这块内存
  //    这是为了防止 Frida 自己的 Stalker 等工具来跟踪 Frida 内部的
  //    thunk 代码，避免无限递归。
  range.base_address = GUM_ADDRESS (self->thunks);
  range.size = code_size;
  gum_cloak_add_range (&range);  //隐藏这块内存

// 3. 调用 gum_emit_thunks（作为回调），
  //    让它在这块内存里 JIT 编译出 enter 和 leave thunks。
  //    (gum_memory_patch_code 稍后会负责将这块内存变为 RX（读+执行）)
  gum_memory_patch_code (self->thunks, 1024, (GumMemoryPatchApplyFunc) gum_emit_thunks, self);
}
```

### 阶段小结

`gum_interceptor_backend_create_thunks` 是一个 **性能优化**。它在 Interceptor 启动时，**预先 JIT 编译** 了两个高度可重用的汇编“零件”：

1. **`enter_thunk`**：一个“汇编 -> C”的桥接器，它负责 **调用 C 函数 `_gum_function_context_begin_invocation`**（`onEnter` 循环）。
2. **`leave_thunk`**：一个“汇编 -> C”的桥接器，它负责 **调用 C 函数 `_gum_function_context_end_invocation`**（`onLeave` 循环）。

`Dispatcher`（总调度中心）在 JIT 编译时，就不再需要自己生成这些复杂的“调用 C”的代码了，它只需要 JIT 编译两条简单的 `BL`（跳转）指令，分别跳转到这两个 **已经预制好** 的 `thunk` 地址即可。这就是“搭积木”的原理。

### ==== ==== ==== ==== ===

我们先看 第1部分`gum_emit_enter_thunk`（我们上一步分析的）是一个汇编“桥梁”， 它**调用**的就是这个 `_gum_function_context_begin_invocation` C 函数。

这个函数是**真正执行 `onEnter` 逻辑的地方**。它在纯 C 语言环境中运行，负责处理所有复杂的逻辑：比如递归保护、线程过滤、调用 `onEnter` 循环，以及**决定下一步该做什么**（是去执行原函数？还是去执行替换函数？）。

让我们来详细拆解这个“大脑”的思维过程。

### `onEnter` 的“C 语言大脑”: `_gum_function_context_begin_invocation`

**`_gum_function_context_begin_invocation`**：

- 这就是 **真正执行 `onEnter` 的 C 函数**。
- 它会接收到 `GumFunctionContext*`（包含了 `listener` 列表）和 `GumCpuContext*`（包含了所有寄存器值），然后 **循环遍历** `listener` 列表，逐个调用它们的 `onEnter` 回调。
- 这就是为什么 `onEnter` 回调可以读取和修改 `this.context.x0` 这样的寄存器！

**`_gum_function_context_end_invocation`**：

- 这就是 **真正执行 `onLeave` 的 C 函数**。
- 它会循环遍历 `listener` 列表，逐个调用它们的 `onLeave` 回调。

#### 函数签名解析

```c
gboolean _gum_function_context_begin_invocation (GumFunctionContext * function_ctx,
                                        GumCpuContext * cpu_context,
                                        gpointer * caller_ret_addr,
                                        gpointer * next_hop)
```

在深入代码之前，我们必须先理解它的参数，尤其是最后两个，它们是 **“出参”**（out-parameters），这个函数通过 **修改它们** 来 *告诉* 外层（即 `enter_thunk` 汇编代码）接下来该跳到哪里去。

- `GumFunctionContext * function_ctx`：
  - “**舞台**”。代表被 Hook 的这个函数。它包含了 `listener` 列表、`trampoline` 地址等。
- `GumCpuContext * cpu_context`：
  - “**CPU 状态**”。这是一个指针，指向 **堆栈上** 保存的所有 CPU 寄存器（`X0-X28`, `LR`, `SP`...）。
  - **关键：** `onEnter` 回调中 `this.context.x0` 能读写寄存器，就是因为它在操作这个 `cpu_context` 结构体。
- `gpointer * caller_ret_addr`：
  - “**返回地址的指针**”。这是一个指向“堆栈上存储的 `LR`（返回地址）”的指针。
  - **关键：** 如果 Frida 需要 `onLeave`，它就会 **覆写** 这个指针指向的内存，把它改成 `on_leave_trampoline` 的地址。
- `gpointer * next_hop`：
  - “**下一跳的指针**”。这是一个指针，`enter_thunk` 汇编代码在 `RET` 之前，会 JUMP 到这个指针指向的地址。
  - **关键：** 这个函数会修改这个值，告诉 `enter_thunk`：“OK，C 语言的工作做完了，你现在 **应该 JUMP 到原函数（Trampoline）还是 JUMP 到替换函数（Replacement）**？”

------

#### 函数内部需要保护的对象

问题：之前的【第 4 部分（最上层）：`gum_interceptor_backend_create_thunks`】中的`gum_cloak_add_range` 已经“隐藏”了内存，避免无限递归，为什么还要做下面的保护措施呢？

`gum_cloak_add_range` 确实是“隐藏”了内存，但让我们搞清楚它们各自的 **保护对象** 是谁。

------

##### 1. `gum_cloak_add_range` (“隐身衣”)

- **保护谁？** 保护 Frida **免受 Frida 自己的干扰**（特别是 `Stalker`）。
- **做什么？** `Stalker` 是 Frida 的另一个强大工具，用于代码跟踪。它本身也是通过 *插桩* (Hooking) 来工作的。
- **问题场景：** 如果你不“隐藏”（Cloak）`thunk` 内存，`Stalker` 可能会试图去跟踪（Hook）Frida 自己的 `enter_thunk`。
- **灾难：**
  1. `Stalker` Hook 了 `enter_thunk`。
  2. `Stalker` 的 Hook 逻辑 **又调用了 `enter_thunk`**（因为 `Stalker` 的 Hook 也是 Interceptor 实现的）。
  3. 无限递归，程序崩溃。
- **总结：** `gum_cloak_add_range` 就像是给 `thunk` 穿上了一件“**隐身衣**”，它告诉 `Stalker`：“**这里什么都没有，走开，不要跟踪我！**”

------

##### 2. “保镖” (Bouncers)

`_gum_function_context_begin_invocation` 里面的两个“保镖”（`gum_tls_key_get_value` 和 `calling_replacement`）**不是** 用来防 `Stalker` 的。

- **保护谁？** 保护 Frida **免受你（用户）的代码的干扰**。
- **做什么？** 它们防止 **你的 `onEnter` 或 `replace` 逻辑** 导致无限递归。

你设想的场景（`onEnter(A)` 调用 `function_B`）还不是最直接的递归。

让我们用一个更常见、更危险的真实场景来解释：**`onEnter` 内部调用了 `console.log`**。

###### *真正的“灾难”* *场景* *（假设没有“守卫”）*

想象一下，`console.log` 最终会调用底层的 `write` 函数来向屏幕输出。

1. 你，作为用户，Hook 了底层的 `write` 函数：

JavaScript

```
   Interceptor.attach(ptr("write"), {
     onEnter: function(args) {
       // 你的目的是：打印所有被写入的内容
       console.log("WRITING: " + args[1].readCString());
     }
   });
   ```

2. 现在，你的程序调用了 `write`（比如，`printf("Hello")`）。

**下面是“无限递归”的开始（假设没有“守卫”）：**

1. `write("Hello")` 被调用。
2. 触发 Hook。
3. 进入 `_gum_function_context_begin_invocation` (为 `write` 函数)。
4. **(假设没有“守卫”检查)**
5. `gum_tls_key_set_value(...)` **设置了“守卫”**。（*注意：在“无守卫”的假设下，这一行是存在的，但“检查”它的 `if` 不存在*）
6. Frida 执行你的 `onEnter` 回调。
7. 你的 `onEnter` 开始执行 `console.log("WRITING: ...")`。
8. `console.log` 为了把 `"WRITING: ..."` 这个字符串显示出来，它 **也必须调用底层的 `write` 函数！**
9. `write("WRITING: ...")` 被调用。
10. **再次** 触发 Hook。
11. **再次** 进入 `_gum_function_context_begin_invocation` (为 `write` 函数)。
12. **(假设没有“守卫”检查)**
13. `gum_tls_key_set_value(...)` **再次设置了“守卫”**。
14. Frida **再次** 执行你的 `onEnter` 回调。
15. 你的 `onEnter` **再次** 执行 `console.log("WRITING: ...")`。
16. `console.log` **再次** 调用 `write`...
17. ... **程序陷入无限递归，直到堆栈溢出（Stack Overflow）而崩溃。**

------

###### *这就是为什么需要“守卫”*

现在，我们看看 **有了“守卫”**，Frida 是如何优雅地处理这个灾难的：

1. `write("Hello")` 被调用。
2. 触发 Hook。
3. 进入 `_gum_function_context_begin_invocation` (为 `write` 函数)。
4. **“守卫”检查 (A)：** `gum_tls_key_get_value` 返回 `NULL`。检查通过。
5. `gum_tls_key_set_value(...)` **设置了“守卫”**。
6. Frida 执行你的 `onEnter` 回调。
7. 你的 `onEnter` 开始执行 `console.log("WRITING: ...")`。
8. `console.log` **调用了底层的 `write` 函数**。
9. `write("WRITING: ...")` 被调用。
10. **再次** 触发 Hook。
11. **再次** 进入 `_gum_function_context_begin_invocation` (为 `write` 函数)。
12. **“守卫”检查 (B)：** `gum_tls_key_get_value` **返回了 `interceptor`**（在第 5 步设置的）！
13. **触发保护！** `if` 语句为 `true`，进入 `if` 块。
14. `*next_hop = function_ctx->on_invoke_trampoline;` （设置“下一跳”为 **原始的 `write`**）。
15. `goto bypass;` （**跳过** 所有的 `onEnter` 逻辑！）。
16. **（安全）** `write("WRITING: ...")` **的原始函数** 被执行。`console.log` 成功打印。
17. `write("WRITING: ...")` 调用结束，返回到 `onEnter` 回调中。
18. `onEnter` 回调执行完毕。
19. `_gum_function_context_begin_invocation`（第一次调用）继续执行。
20. `gum_tls_key_set_value(..., NULL);` **清除了“守卫”**。
21. 程序继续执行（去调用原始的 `write("Hello")`）。

---

“守卫”(`gum_tls_key_get_value`)的用途是：**防止一个 `onEnter` 回调（或 `replace` 实现）不小心调用了 另一个（甚至是 同一个 ）被 Hook 的函数，从而导致 Interceptor 逻辑“重入”（Re-entrancy）而引发无限递归。**

它就像一个“请勿打扰”的门牌：Frida 在进入 C 语言总控室时挂上门牌，如果它在挂着门牌时又有人来敲门（递归调用），它就知道这是“自己人”在办事，于是直接让他们“走旁门”（`goto bypass`）去执行原始函数，而不是再走一遍“总控室”逻辑。

###### “保镖” A：`gum_tls_key_get_value` (TLS 守卫)

- **问题场景：** 你，作为用户，做了以下操作：
  1. `Interceptor.attach(function_A, { onEnter: ... })`
  2. `Interceptor.attach(function_B, { onEnter: ... })`
  3. 在 `function_A` 的 `onEnter` 回调里，你 **又调用了 `function_B`**。
- **灾难：**
  1. `function_A` 被调用 -> 触发 Hook A。
  2. 进入 `_gum_function_context_begin_invocation` (函数 A)。
  3. Frida **设置 TLS 守卫**（`gum_tls_key_set_value`）。
  4. Frida 调用你的 `onEnter` (函数 A)。
  5. 你的 `onEnter` (函数 A) **调用了 `function_B`** -> 触发 Hook B。
  6. **再次** 进入 `_gum_function_context_begin_invocation` (函数 B)。
  7. **“保镖”A 检查：** `gum_tls_key_get_value` 发现“守卫”**已经被设置了**！
  8. **触发保护：** `goto bypass;`，**跳过** `function_B` 的 `onEnter`，直接去执行原函数。
- **总结：** 这个“保镖”防止的是 **“`onEnter` A -> 调用 -> Hooked B”** 这种 **用户层** 的递归。
-

---

###### “保镖” B：`calling_replacement` (Replace 守卫)

- **问题场景：** 你，作为用户，做了以下操作：
  1. `Interceptor.replace(function_A, function (arg) { ... this.original(arg); ... })`
- **灾难：**
  1. `function_A` 被调用 -> 触发 Hook A。
  2. 进入 `_gum_function_context_begin_invocation` (函数 A)。
  3. Frida 设置“下一跳” (`*next_hop`) 为你的 **替换函数** (`replacement_function`)。
  4. Frida 调用你的 **替换函数**。
  5. 你的替换函数调用了 `this.original(arg)`。
  6. `this.original` 会 **再次** 进入 `_gum_function_context_begin_invocation` (函数 A)。
  7. **“保镖”B 检查：** `stack_entry->calling_replacement` 标志位为 `true`！
  8. **触发保护：** `goto bypass;`，并且 **强制** 设置“下一跳” (`*next_hop`) 为 **真正的原始函数**（`on_invoke_trampoline`）。
- **总结：** 这个“保镖”防止的是 **“`replace` 实现 -> 调用 -> `this.original`”** 这种递归，确保 `this.original` 能正确地“穿透” Hook。

---

#### 逐段精讲：`onEnter` 的完整流程

##### 第 1 阶段：递归保护（“保镖”）

```c
  if (gum_tls_key_get_value (gum_interceptor_guard_key) == interceptor)
  {
    *next_hop = function_ctx->on_invoke_trampoline;
    goto bypass;
  }
  gum_tls_key_set_value (gum_interceptor_guard_key, interceptor);
```

- **这是什么？** 这是 `gum_interceptor_ignore_current_thread`（我们在 `gum_interceptor_attach` 中见过）的核心实现。
- **逻辑：**
  1. `gum_tls_key_get_value` 检查当前线程的“**线程局部存储**”（TLS）中是否已经设置了“守卫”（guard）标记。
  2. **如果已设置 (`== interceptor`)：** 这意味着本线程 **已经** 在 Frida 的 Interceptor 逻辑中了（例如，一个 `onEnter` 回调又调用了另一个被 Hook 的函数）。
  3. **处理：**
     - `*next_hop = ...on_invoke_trampoline;`：设置“下一跳”为 **原始函数**。
     - `goto bypass;`：**跳过所有 `onEnter` 逻辑**，直接去执行原始函数。这就防止了无限递归。
  4. **如果未设置：** `gum_tls_key_set_value(...)` **设置“守卫”**，表示“本线程现在进入 Frida 保护区”。

---

##### 第 2 阶段：`Interceptor.replace` 递归保护

```c
  stack_entry = gum_invocation_stack_peek_top (stack);
  if (stack_entry != NULL &&
      stack_entry->calling_replacement &&
      /* ... 检查函数地址是否匹配 ... */)
  {
    gum_tls_key_set_value (gum_interceptor_guard_key, NULL); // 清除守卫
    *next_hop = function_ctx->on_invoke_trampoline;
    goto bypass;
  }
```

- **这是什么？** 这是专门为 `Interceptor.replace(..., { implementation: ... })` 准备的第二道“保镖”。
- **场景：** 当你使用 `Interceptor.replace` 时，你可能会在你的 `implementation`（替换函数）中调用 `this.original()`。
- **问题：** `this.original()` 会 **再次** 触发同一个 Hook，使 hook 生效，从而导致又跑回 hook 核心函数 `_gum_function_context_begin_invocation` 中了。
- **逻辑：**
  1. `gum_invocation_stack_peek_top (stack)` 检查当前线程的“调用栈”顶部。
  2. `if (stack_entry->calling_replacement)`：如果栈顶标记为“正在调用替换函数”，并且函数地址也匹配...
  3. **处理：** 这说明这不是一个“外部调用”，而是 `this.original()` 导致的“内部调用”。
     - `*next_hop = ...on_invoke_trampoline;`：设置“下一跳”为 **原始函数**。
     - `goto bypass;`：**跳过所有 `onEnter` 逻辑**，直接去执行。

---

##### 第 3 阶段：状态保存

```c
#ifndef HAVE_WINDOWS
  system_error = gum_thread_get_system_error ();
#endif
```

- **逻辑：** 保存 `errno`（Linux/macOS）或 `GetLastError()`（Windows）的值。
- **为什么？** 因为你的 `onEnter` 回调（比如 JS 写的）可能会执行一些操作（比如 `console.log`），这些操作可能会 **改变** `errno`。这会干扰原始函数的正常执行（如果原始函数依赖于 `errno` 的话）。
- 这里 **先保存** 它，`onEnter` 执行完后，Frida 会 **恢复** 它。

我们来详细解释一下这个“干扰”是怎么发生的。

`errno` （在 Windows 上是 `GetLastError()`）并不是一个普通的变量，它是一个 **保存在线程局部存储（TLS）中的“最后错误码”**。

C 语言中很多函数的错误处理都依赖它。一个非常经典的“错误”流程是这样的：

1. 程序调用一个 C 函数，比如 `open("file_that_does_not_exist")`。
2. 这个 `open` 函数 **执行失败** 了。
3. `open` 函数会返回 `-1`，并且 **把 `errno` 这个全局变量设置为 `2`**（`ENOENT`，即“文件未找到”）。
4. 程序 **检查** 到返回值是 `-1`，于是它就去 **读取 `errno` 的值**，发现它是 `2`，就知道“哦，原来是文件没找到”。

###### “干扰”是这样发生的

现在，假设我们 Hook 了另一个函数，比如 `write`，而程序是这样执行的：

1. `open("file_that_does_not_exist")` 失败，**`errno` 被设置为 `2`**。
2. 程序 **紧接着** 调用 `write(...)`（我们 Hook 了这个函数）。此时程序 **期望 `errno` 的值仍然是 `2`**。
3. `write` 被调用，Frida 的 Hook 触发，进入 `_gum_function_context_begin_invocation` (C 语言总控室)。
4. `onEnter` (你的 JS) **开始执行**。
5. 你的 `onEnter` 里调用了 `console.log("Hook triggered")`。
6. `console.log` 为了把 `"Hook triggered"` 这个字符串显示到屏幕上，它 **内部也必须** 调用 C 函数，比如 `malloc` (分配内存) 和 `write` (把字符串写出去)。
7. 这些 `console.log` 内部的 `malloc` 和 `write` 调用 **成功** 了。
8. **关键点：** 很多 C 函数在 **执行成功** 时，有一个副作用：它们会 **把 `errno` 清除为 `0`**！
9. 所以，当 `console.log` 执行完毕时，**`errno` 已经被污染了**：它从 `2` 变成了 `0`。
10. `onEnter` 结束，Frida 继续执行原始的 `write` 函数（它也成功了）。
11. `write` 函数返回到原始程序中。
12. 原始程序现在去检查 `errno`（它期望 `errno` 还是 `2`，来自第 1 步的 `open` 失败），但它读到的却是 `0`！

**结果就是：** 你的 `onEnter` 回调（通过 `console.log`）意外地““治愈”了”原始程序的错误状态，导致原始程序的错误处理逻辑（`if (errno == 2) { ... }`）**失效** 了，从而引发了 Bug。

---

##### 第 4 阶段：决定是否调用 Listener（“检查访客名单”）

```c
  if (interceptor->selected_thread_id != 0)
  {
    invoke_listeners =
        gum_process_get_current_thread_id () == interceptor->selected_thread_id;
  }

if (invoke_listeners)
 {
 invoke_listeners = (interceptor_ctx->ignore_level <= 0);
 }

if (!invoke_listeners && function_ctx->has_unignorable_listener)
  {
    invoke_listeners = TRUE;
    only_invoke_unignorable_listeners = TRUE;
  }
```

- **逻辑：** 这一长串 `if` 语句在做一个决定：`gboolean invoke_listeners = ?`（我们到底要不要运行 `onEnter`？）

- **检查 1：** `selected_thread_id`。你是否 `attach` 时只指定了某个特定线程？如果是，我们现在是那个线程吗？

- **检查 2：** `ignore_level`。`gum_interceptor_ignore_current_thread()`（`attach` 里的那个）就是增加了这个 `ignore_level`。如果 `> 0`，就 `不` 调用。

- ### 详细分解：

1. **`invoke_listeners` 目前是 `true`**

- 在这行代码之前，`invoke_listeners` 要么是 `true`（默认），要么刚通过了“线程 ID 检查”（`selected_thread_id`）。总之，它现在代表“**准备调用**”。

2. **`interceptor_ctx->ignore_level` 是什么？**

- 这是一个 **“线程本地的忽略计数器”**，默认为 `0`。
     - 当你（或 Frida 内部，比如 `attach` 时）调用 `Interceptor.ignoreCurrentThread()` 或 `gum_interceptor_ignore_current_thread()` 时，这个计数器会 **`+1`**。
     - 当你调用 `Interceptor.revertCurrentThread()` 或 `gum_interceptor_unignore_current_thread()` 时，这个计数器会 **`-1`**。

3. **`(interceptor_ctx->ignore_level <= 0)` 的判断**

- **正常情况：** `ignore_level` 是 `0`。`0 <= 0` 为 `true`。`invoke_listeners` 保持 `true`。**`onEnter` 会被正常调用**。
 - **“忽略”情况：** 你调用了 `Interceptor.ignoreCurrentThread()`。`ignore_level` 变成了 `1`。
 - 此时，`1 <= 0` 为 `false`。
 - `invoke_listeners` 被 **“否决”**，**被赋值为 `false`**。

这行代码是 `ignoreCurrentThread()` 功能的“执行者”。它确保了：

1. 如果用户在当前线程 **主动** 调用了 `Interceptor.ignoreCurrentThread()`，那么这个计数器就会 `> 0`。
     2. 这个 `if` 检查就会失败，`invoke_listeners` 会变为 `false`。
     3. 最终，后面的 `onEnter` 循环（`if (invoke_listeners) { ...for... }`）会被 **完全跳过**。

这和我们之前讨论的 **“递归保镖”**（`gum_tls_key_get_value`）是两个 **不同** 的机制：

1. **“递归保镖”**（`gum_tls_key_get_value`）：是 **自动的**，防止 `onEnter` 调用 `console.log` 这种 **意外** 的无限递归。

2. **“忽略计数器”**（`ignore_level`）：是 **手动的**，让你（用户）可以 **主动地** 在一段时间内关闭当前线程的所有 Hook。

- **检查 3：** `unignorable_listener`（不可忽略的 Listener）。**这是一个例外**：即使上面两项检查都说“不要调用”，但如果存在一个“不可忽略”的 Listener，我们 **必须** 调用它。

---

##### 第 5 阶段：管理调用栈（“存包处”）

```c
  will_trap_on_leave = function_ctx->replacement_function != NULL || (invoke_listeners && function_ctx->has_on_leave_listener);

//Frida 是否需要在目标函数执行完毕、即将返回时，再次‘劫持’控制权？
  if (will_trap_on_leave)
  {
    stack_entry = gum_invocation_stack_push (stack, function_ctx, *caller_ret_addr, only_invoke_unignorable_listeners);
    invocation_ctx = &stack_entry->invocation_context;
  }
  else if (invoke_listeners)
  {
    /* ... 还是 push，但存入的是假返回地址 ... */
    invocation_ctx = &stack_entry->invocation_context;
  }
```

- **逻辑：** 这是在为 `onLeave` 做准备。

- **`will_trap_on_leave = ?`**（我们需要 `onLeave` 吗？）

- 如果这是一个 `replace` 操作（`replacement_function != NULL`），**是**。

- 如果我们要调用 Listener（`invoke_listeners`）**并且** 它们中有任何一个注册了 `onLeave`，**是**。

- 否则，**否**。

- **解释说明**：

这行代码是在决定：“**Frida 是否需要在目标函数执行完毕、即将返回时，再次‘劫持’控制权？**”

`will_trap_on_leave` 是一个布尔值（`true` 或 `false`），它的意思是“**是否要在离开时设置陷阱？**”

- **如果为 `true`（需要劫持）**：Frida 稍后会 **覆写（修改）堆栈上的返回地址**，将其指向 `on_leave_trampoline`。这样，当原函数执行 `RET`（返回）时，它会“掉入”Frida 的陷阱，Frida 就可以执行 `onLeave` 逻辑。
    - **如果为 `false`（不需要劫持）**：Frida **不会** 修改返回地址。`onEnter` 执行完毕后，原函数会正常执行，并 **直接返回给原始调用者**。Frida 不再介入，`onLeave` 也不会被执行。这是一种 **高性能** 模式。

所以，Frida 必须在 `onEnter` 阶段就决定是否需要 `onLeave`。它只在以下两种情况下才 **必须**（`||`，或）去劫持返回：

1. **`function_ctx->replacement_function != NULL`（这是一个 `Interceptor.replace` 操作）**
       - **含义**：用户调用的是 `Interceptor.replace`。
       - **为什么？** `replace` 操作（用一个新函数替换原函数）虽然（默认）跳过了原函数，但它 **仍然需要** 在最后执行 `onLeave` 阶段的逻辑（比如 `gum_invocation_stack_pop` 来清理 Frida 自己的调用栈）。为了能执行 `onLeave` 阶段的逻辑，就 **必须** 劫持返回。
    2. **`(invoke_listeners && function_ctx->has_on_leave_listener)`（这是一个 `attach`，且用户注册了 `onLeave`）**
       - **含义**：我们要调用 `listener`（`invoke_listeners`），并且 `listener` 列表中 **至少有一个** 注册了 `onLeave` 回调（`has_on_leave_listener`）。
       - **为什么？** 这是最直观的：用户 **明确要求** 在函数返回时执行 `onLeave` 代码。Frida 要想执行 `onLeave`，**唯一** 的办法就是设置陷阱（劫持返回）。

- **`if (will_trap_on_leave)`（如果需要 onLeave）：**

- `gum_invocation_stack_push`：把当前状态（比如 **真实的返回地址 `caller_ret_addr`**）“存”到 Frida 的调用栈上。
  - `invocation_ctx`：获取一个“存包小票”。这个 `invocation_ctx` 就是 JS 回调中的 `this` 对象！

- **`else if (invoke_listeners)`（如果只需要 onEnter，不需要 onLeave）：**

- 我们仍然需要 `push`，因为 `onEnter` 需要 `invocation_ctx`（那个 `this` 对象）。
  - 但我们存入一个“假”的返回地址，因为 `onLeave` 用不到它。

----

##### 第 6 阶段：执行 `onEnter` 循环（“主舞台”）

```c
  gum_function_context_fixup_cpu_context (function_ctx, cpu_context);

if (invoke_listeners)
  {
    /* ... */
    invocation_ctx->cpu_context = cpu_context;
    /* ... */
    listener_entries =
        (GPtrArray *) g_atomic_pointer_get (&function_ctx->listener_entries);
    for (i = 0; i != listener_entries->len; i++)
    {
      /* ... 过滤 unignorable ... */

if (listener_entry->listener_interface->on_enter != NULL)
      {
        listener_entry->listener_interface->on_enter (
            listener_entry->listener_instance, invocation_ctx);
      }
    }
  }
```

- **`gum_function_context_fixup_cpu_context(...)`**：

- **这又回到了我们最初的 `lr` 问题！** 如果 `backend`（施工队）在分析时发现这个函数需要修复 `lr`，这个函数就会在这里 **修正** `cpu_context->lr` 的值，*然后* `onEnter` 才能看到它。

- **`if (invoke_listeners)`：**

- `invocation_ctx->cpu_context = cpu_context;`

- **关键！** 这行代码把“存包小票”(`invocation_ctx`)和“CPU 状态”(`cpu_context`)**关联** 起来。

- `invocation_ctx` 的真正意思是“**调用上下文**”（**Invo** cation **C** on **t** e **x** t），它是一个 **“句柄” (Handle)**，代表了 **“这一次”** 函数调用。

- ### 为什么用“存包小票”来比喻？

想象一下你去一个需要“存包”和“取包”的地方（比如游乐园）：

1. **“存包” (Push Stack)**
           - 当 `onEnter` 触发时，Frida 需要为你保存一些状态，特别是当有 `onLeave` 时（比如 **真实的返回地址**）。
           - Frida 会调用 `gum_invocation_stack_push`，把这些状态“**存**”到它自己的一个内部堆栈（`GumInvocationStack`）上。
           - 这就好比你把你的“**包**”（真实返回地址等）交给了“存包处”。
        2. **“拿到小票” (Get `invocation_ctx`)**
           - “存包处”（`gum_invocation_stack_push`）会返回一个“**凭证**”，这就是 `invocation_ctx`。
           - 这张“**小票**”**唯一地代表** 了你刚刚存的那个“包”。
        3. **“使用小票” (Pass to JS)**
           - Frida 会把这张“小票” (`invocation_ctx`) 作为 `this` 传递给你的 `onEnter`（JS 回调）。
           - 你在 JS 里拿到的 `this`，就是这张“小票”。
           - “Frida 拿到了你刚拿到的那张‘小票’ (`invocation_ctx`)，然后又 **把一个指向‘CPU 状态’ (`cpu_context`) 的指针**，用订书机‘钉’在了这张‘小票’上。”
             - `cpu_context`：是堆栈上 **真实的 CPU 寄存器**（`X0`, `X1`, `LR`...）。
             - `invocation_ctx`：是你的“小票”（即 JS 里的 `this`）。
           - 在你的 JS 回调里，你只要一拿到“小票” (`this`)，就可以通过“钉”在它上面的那个指针（`this.context`），去 **直接读写** 堆栈上真实的 `cpu_context`！

- 现在，当 JS 回调中执行 `this.context.x0 = 0x123` 时，它修改的就是 `cpu_context->x0`，也就是 **堆栈上真实的 `X0`**！

---

- **`for (i = 0; ...)`：**

- 这就是 **循环**，遍历所有 `listener`。

- `listener_entry->listener_interface->on_enter(...)`：

- **执行！** 这就是调用 C 回调（`arm64_listener_context_on_enter`）的地方，C 回调再去调用 JS 的 `onEnter`。

- 我们最开始分析的测试代码 `interceptor_fixture_try_attach` ，在那里面做了这件事：

```C
      // 我们在“测试代码”里，把 arm64_listener_context_on_enter 这个 C 函数注册为了 on_enter 的回调。
      ctx->listener->on_enter = (TestCallbackListenerFunc) arm64_listener_context_on_enter;
      ```

现在，`for` 循环里的 `listener_entry->listener_interface->on_enter(...)` **调用的，正是我们当初注册的回调函数 `arm64_listener_context_on_enter`！**

从而达成 **完整的调用链**：

1. **`gum_emit_enter_thunk`** (汇编)：
         - 汇编代码（在内存中 JIT 编译出 enter_thunk 的所有汇编代码），负责“桥接”到 C 语言。
      2. **`_gum_function_context_begin_invocation`** (C 语言大脑)：
         - 执行各种检查（递归、线程等）。
         - 运行 `for (i = 0; ...)` 循环，开始遍历 `listener` 列表。
      3. **`listener_entry->...->on_enter(...)`** (C 语言回调)：
         - **就是这行代码！** 它调用了 `listener` 对应的 C 回调。
         - 在我们的 **测试** 中，它调用 `arm64_listener_context_on_enter`。这个 C 函数 **把 `>` 追加到了字符串上**。
         - 在 **真实** 的 Frida JS 脚本中，这里会调用一个 **不同的** C 回调（由 `frida-gum-js` 提供的），这个 C 回调的 **唯一工作** 就是 **进入 JavaScript 引擎**，去执行你写的 `onEnter: function () { ... }` 脚本。

----

##### 第 7 阶段：设置“下一步”和“返回劫持”（“出口”）

```c
  if (!will_trap_on_leave && invoke_listeners)
  {
    gum_invocation_stack_pop (interceptor_ctx->stack);
  }
  
  gum_tls_key_set_value (gum_interceptor_guard_key, NULL);

if (will_trap_on_leave)
  {
    *caller_ret_addr = function_ctx->on_leave_trampoline;
  }

if (function_ctx->replacement_function != NULL)  //使用了frida的  `Interceptor.replace`了
  {
    /* ... */
    *next_hop = function_ctx->replacement_function;//设置“下一跳”为 `Interceptor.replace` 的**替换函数**
  }
  else
  {
    *next_hop = function_ctx->on_invoke_trampoline;//设置“下一跳”为**原始函数**
  }
```

- **`if (!will_trap_on_leave ...)`：**
  - 如果我们不需要 `onLeave`，那么“存包小票”没用了，`gum_invocation_stack_pop` 将其 **丢弃**。
  - 如果 *需要* `onLeave`，我们会 **保留** 它，`onLeave` 逻辑稍后会用它来“取包”。
- `gum_tls_key_set_value (..., NULL)`：**解除“守卫”**。
- **`if (will_trap_on_leave)`：**
  - `*caller_ret_addr = function_ctx->on_leave_trampoline;`
  - **最关键的劫持！** 这行代码 **覆写了堆栈上的返回地址**！
  - 当原函数执行 `RET` 指令时，它不会返回给原调用者，而是会 **“返回”到 Frida 的 `on_leave_trampoline`**（离开跳板机）！
- **`if (function_ctx->replacement_function != NULL)`：**
  - `*next_hop = ...replacement_function;`
  - 设置“下一跳”为 `Interceptor.replace` 的 **替换函数**。`enter_thunk` 汇编代码稍后会 `JUMP` 到这里。
- **`else`：**
  - `*next_hop = ...on_invoke_trampoline;`
  - 设置“下一跳”为 **原始函数**。

------

### 阶段小结

`_gum_function_context_begin_invocation` 是 Interceptor 的 **“C 语言总控室”**。

它在 `enter_thunk`（汇编桥梁）之后、`onEnter`（JS 回调）之前运行。它负责：

1. 通过 `gum_tls_key_get_value` **防止无限递归**。

2. 通过 `selected_thread_id` 和 `ignore_level` **过滤** 掉不应触发的调用。

3. 通过 `gum_invocation_stack_push` **保存** `onLeave` 所需的状态（“存包”）。

4. 通过 `invocation_ctx->cpu_context = cpu_context` 将 JS 的 `this.context` **链接** 到真实的 CPU 寄存器，从而可以修改读取寄存器值。

5. **循环调用** 所有 `onEnter` 回调。

6. **决定** `enter_thunk` 的 **“下一跳”**（`*next_hop`）：是去原函数还是替换函数？

7. **劫持** CPU 的 **“返回地址”**（`*caller_ret_addr`）：是返回给原调用者，还是返回给 `on_leave_trampoline`？

1.  **返回给 `on_leave_trampoline`**

在以下两种情况下，`will_trap_on_leave` 会为 `true`，Frida **会** 覆写返回地址：

1. **这是一个 `Interceptor.replace` 操作。**
      2. **这是一个 `Interceptor.attach` 操作，且用户提供了 `onLeave` 回调。**

在这两种情况下，Frida 都 **必须** 在函数返回时重新获得控制权（去执行 `onLeave` 循环或清理堆栈），因此它 **必须** 劫持返回地址。

2. **返回给“原调用者”**

在以下情况下，`will_trap_on_leave` 会为 `false`，Frida **不会** 触碰返回地址：

1. **这是一个 `Interceptor.attach` 操作，且用户** 只 **提供了 `onEnter`，没有提供 `onLeave`。**

在这种情况下，Frida 知道 `onLeave` 阶段无事可做，它会选择性能最高的路径：在 `onEnter` 执行完毕后，让原函数直接 `RET`（返回）给它的“原调用者”，Frida 不再介入。

### ==== ==== ==== ==== ===

分析完onEnter，我们再看onLeave： 第2部分`gum_emit_leave_thunk`（我们之前分析的）， 它**调用**的是这个 `_gum_function_context_end_invocation` C 函数。

---

### `onLeave` 的 "C 语言大脑": `_gum_function_context_end_invocation`

`gum_emit_leave_thunk`（汇编桥梁）的工作就是调用这个 C 函数。

这个函数是 **“C 语言总控室”的下半场**。`onEnter` 阶段（`begin_invocation`）负责了 **“存包”、决策、和“劫持”返回地址**。而这个 `end_invocation` 函数（`onLeave` 阶段）则负责：**“取包”、执行 `onLeave` 循环、清理、并最终“放行”。**

#### 函数签名解析

```c
void _gum_function_context_end_invocation (GumFunctionContext * function_ctx,
                                      GumCpuContext * cpu_context,
                                      gpointer * next_hop)
```

- `GumFunctionContext * function_ctx`：**“舞台”**。
- `GumCpuContext * cpu_context`：“**CPU 状态**”。
  - **关键：** 这是在原函数 **已经执行完毕**、`RET`（返回）指令刚被 `on_leave_trampoline` 劫持 **之后** 的 CPU 状态！
  - 这意味着 `cpu_context->x0`（在 ARM64 上）**存放着原函数的真正返回值**。`onLeave` 回调能读写返回值，就是在这里。
- `gpointer * next_hop`：“**下一跳的指针**”（**出参**）。
  - 这是 `leave_thunk`（汇编）**最后** 要 `JUMP` 到的地方。
  - 这个函数 **必须** 修改它，告诉汇编代码：“`onLeave` 结束了，现在请 **JUMP 回原调用者**。”

------

#### 逐段精讲：`onLeave` 的完整流程

##### 第 1 阶段：设置“递归保镖”并保存 `errno`

```c
#ifdef HAVE_WINDOWS
  system_error = gum_thread_get_system_error ();
#endif

gum_tls_key_set_value (gum_interceptor_guard_key, function_ctx->interceptor);

#ifndef HAVE_WINDOWS
  system_error = gum_thread_get_system_error ();
#endif
```

- **`system_error = ...`**：和 `onEnter` 一样，**保存 `errno`**。
- **`gum_tls_key_set_value(...)`**：**设置“递归保镖”**。
- **为什么？** 因为 `onLeave` 回调（比如 JS 写的 `onLeave: function () { console.log(...) }`）**同样** 可能调用 `console.log`，而 `console.log` 又会调用被 Hook 的 `write`，这 **同样** 会造成无限递归。`onLeave` 逻辑和 `onEnter` 逻辑需要同等级别的递归保护。

---

##### 第 2 阶段：“取包”并设置“最终出口”

```c
  interceptor_ctx = get_interceptor_thread_context ();

stack_entry = gum_invocation_stack_peek_top (interceptor_ctx->stack);
  *next_hop = gum_sign_code_pointer (stack_entry->caller_ret_addr);
```

- **`stack_entry = gum_invocation_stack_peek_top(...)`**：
  - **“取包”！** `onEnter` 阶段（`begin_invocation`）调用了 `gum_invocation_stack_push` 把“包”（`stack_entry`）存了进去。现在我们把它从堆栈顶部“取”出来（`peek_top`）。
  - 这个 `stack_entry` 就是我们的“**存包小票**”，它包含了 `onEnter` 时保存的所有状态。
- **`next_hop = gum_sign_code_pointer (stack_entry->caller_ret_addr);`**
  - **这是 `onLeave` 阶段最核心的一行代码！**
  - `stack_entry->caller_ret_addr`：这就是 `onEnter` 阶段 **费尽心机保存下来** 的 **“原始调用者的真实返回地址”**。
  - `*next_hop = ...`：我们把这个“真实返回地址”设置为“下一跳”的目标。
  - **含义：** 这行代码告诉 `leave_thunk`（汇编）：“`onLeave` 的 C 语言工作完成了。当你（汇编）`RET` 时，请 **JUMP 到这个地址**。”
  - **至此，整个 Hook 劫持-返回的闭环完成了。**

----

##### 第 3 阶段：准备 `onLeave` 回调（“主舞台”）

```c
  invocation_ctx = &stack_entry->invocation_context;
  invocation_ctx->cpu_context = cpu_context;
  /* ... errno 相关的复杂处理 ... */
  invocation_ctx->backend = &interceptor_ctx->listener_backend;
```

- **`invocation_ctx = ...`**：拿到“存包小票” (`this` 对象)。
- **`invocation_ctx->cpu_context = cpu_context;`**
  - **关键！** 和 `onEnter` 一样，把“小票”和 **当前** 的 `cpu_context`（CPU 状态）“钉”在一起。
  - **区别在于：** 这里的 `cpu_context` 是经过 `onEnter`（修改、添加等）与原函数代码处理后 **返回** 的 `cpu_context`（所有寄存器值，上下文状态）。
  - **结果：** 当 JS 回调执行 `this.context.x0` 时，它读到的就是 **函数的返回值**。当它执行 `this.context.x0 = 0x456` 时，它就是在 **修改返回值**！

----

##### 第 4 阶段：执行 `onLeave` 循环

```c
  listener_entries = (GPtrArray *) g_atomic_pointer_get (&function_ctx->listener_entries);
  only_invoke_unignorable_listeners = stack_entry->only_invoke_unignorable_listeners;
  for (i = 0; i != listener_entries->len; i++)
  {
    /* ... 过滤 unignorable（不可忽视的） ... */

if (listener_entry->listener_interface->on_leave != NULL)
    {
      listener_entry->listener_interface->on_leave (
          listener_entry->listener_instance, invocation_ctx);
    }
  }
```

- **`for (i = 0; ...)`**：这就是 **“`onLeave` 广播员”**。
- **`if (...on_leave != NULL)`**：检查这个 `listener` 是否 **真的** 注册了 `onLeave`。
- **`listener_entry->...->on_leave(...)`**：
 - **执行！** 这就是调用 C 回调（在我们之前的分析中是 `arm64_listener_context_on_leave`，它负责追加 `<`），或者调用 JS 引擎去执行 `onLeave: function () { ... }` 的地方。

-----

##### 第 5 阶段：清理与“放行”

```c
  gum_thread_set_system_error (invocation_ctx->system_error);

gum_invocation_stack_pop (interceptor_ctx->stack);

gum_tls_key_set_value (gum_interceptor_guard_key, NULL);

g_atomic_int_dec_and_test (&function_ctx->trampoline_usage_counter);
}
```

- **`gum_thread_set_system_error(...)`**：**恢复 `errno`**。
- **`gum_invocation_stack_pop(...)`**：
  - **“撕掉小票”！** `onEnter` 存的“包”（`stack_entry`，这个 `stack_entry` 就是我们的“**存包小票**”，它包含了 `onEnter` 时保存的所有状态。）现在已经用完了，`pop` 将其 **彻底销毁**，清理堆栈。
- **`gum_tls_key_set_value (..., NULL)`**：
  - **解除“递归保镖”**。`onLeave` 逻辑已全部执行完毕。
- `g_atomic_int_dec_and_test(...)`：
  - 减少“使用计数器”。`onEnter` 时 `inc`（+1），`onLeave` 时 `dec`（-1），用于 `detach`（卸载）时的资源管理。

------

### 阶段小结

`_gum_function_context_end_invocation` 是 **Interceptor 的“C 语言收尾室”**。

它在 `on_leave_trampoline` 劫持了函数返回后被调用。它负责：

1. **设置“递归保镖”**（`gum_tls_key_set_value`）来保护 `onLeave` 逻辑本身。
2. 从 `GumInvocationStack`（调用栈）中 **“取出”** `onEnter` 时保存的 `stack_entry`（“存包小票”）。
3. **恢复“原始调用者的真实返回地址”**：从 `stack_entry` 中取出 `caller_ret_addr`，并将其设置为 `*next_hop`（“下一跳”），**这是完成“放行”的核心**。
4. 将 JS 的 `this` (`invocation_ctx`) **链接** 到 **包含函数返回值** 的 `cpu_context`。
5. **循环调用** 所有注册的 `onLeave` 回调。
6. **清理一切**：恢复 `errno`、`pop`（销毁）调用栈条目、解除“递归保镖”。

### ==== ==== ==== ==== ===

现在我在返回【Interceptor的核心——`gum_interceptor_instrument` 】的代码中去分析 第 3 阶段：【施工！】—— “开工！建 Trampoline！”中的 _gum_interceptor_backend_create_trampoline 函数

![](upload/attach/202511/940077_CGD5TQ2REWYQ48C.webp)

----

### 施工现场：`_gum_interceptor_backend_create_trampoline`

我们终于抵达了 Interceptor 的 **“施工现场”**！

`gum_interceptor_instrument`（“工头”）在检查了“缓存”后，如果发现是第一次 Hook，就会调用这个 `_gum_interceptor_backend_create_trampoline` 函数。

这就是 **“施工队” (`backend`) 实际在“建造” `Trampoline`（跳板机）和 `Dispatcher`（总调度中心）的地方**。

**我们最初关于 `lr` 寄存器的所有问题，都将在这个函数里找到最终的答案。**

让我们开始“施工”！

------

#### 函数签名与“工具”准备

```c
gboolean _gum_interceptor_backend_create_trampoline (GumInterceptorBackend * self,
                                        GumFunctionContext * ctx)
{
  GumArm64Writer * aw = &self->writer;
  GumArm64Relocator * ar = &self->relocator;
  gpointer function_address = ctx->function_address;
  // ...
```

- **返回值：`gboolean`**
  - **`gboolean`** 是 GLib 库中的布尔类型，等同于 `TRUE`（真）或 `FALSE`（假）。
  - **含义：** 这个返回值用来表示 **“施工是否成功”**。
    - **`TRUE`：** 表示“施工队”成功地 JIT 编译了 `Dispatcher`（总调度中心）和 `Trampoline`（跳板机），并且（在需要时）成功处理了 `lr` 寄存器等问题。`attach` 流程可以继续。
    - **`FALSE`：** 表示“施工”失败。这通常发生在 `gum_arm64_relocator`（“智能指令搬运工”）遇到了它无法理解的汇编指令（比如函数太短，或者是一个它无法修复的跳转），导致它无法“偷走”指令。`attach` 流程会因此中止，并向上层返回 `GUM_ATTACH_WRONG_SIGNATURE` 错误。

------

- **参数 1 (输入)：`GumInterceptorBackend * self`**
  - **`self`** 是 C 语言中模拟 C++ `this` 指针的常见做法。它指向“**施工队**” (`backend`) 实例本身。
  - **含义：** “施工队”需要它自己来访问自己的 **“工具箱”**。
  - **目的：** 这个函数需要通过 `self` 来获取 `_gum_interceptor_backend_create`（“HR/工具房管理员”）在启动时为它准备好的所有工具：
    - `self->writer`（“**汇编笔**”）：用来 JIT 编译 **新** 的代码（比如 `LDR` 和 `BR` 指令）。
    - `self->relocator`（“**智能指令搬运工**”）：用来 **“偷”** 和 **“修复”** 原函数的指令。**（这是解决 `lr` 问题的核心工具！）**
    - `self->enter_thunk` / `self->leave_thunk`（“**预制零件**”）：`Dispatcher` 需要 JUMP 到的目标地址。

------

- **参数 2 (输入与输出)：`GumFunctionContext * ctx`**
  - **`ctx`** 是“**舞台**” (`function_ctx`)，或者说是这次 Hook 任务的“**施工蓝图**”。
  - **含义：** 这个参数是 **这个函数最重要的部分**，它 **既是输入（Input）也是输出（Output）**。
  - **目的：**
    - **作为输入：** 函数通过 `ctx->function_address` 拿到“**施工地址**”（即原函数的地址）。
    - **作为输出（核心！）：** 这个函数的 **全部工作**，就是用“汇编笔” JIT 即时编译出各种代码块，然后 **把这些新代码块的内存地址，回填到 `ctx` 的各个字段中**，供“C 语言大脑”（`_gum_function_context_begin_invocation` 和 `_gum_function_context_end_invocation`）在运行时使用。
    - **它会填充以下字段：**
      - `ctx->on_enter_trampoline`：JIT 编译出的 `Dispatcher`（总调度中心）的入口地址。
      - `ctx->on_leave_trampoline`：JIT 编译出的 `onLeave` 陷阱的入口地址。
      - `ctx->on_invoke_trampoline`：JIT 编译出的 `Trampoline`（即“修复”过的原函数开头）的入口地址。
      - `ctx->overwritten_prologue`：**备份** 一份原始的函数开头指令，用于 `detach`（卸载）时“复原”现场。

------

#### 第 1 阶段：准备“施工地”和“入口”

```c
  if (!gum_interceptor_backend_prepare_trampoline (self, ctx, &need_deflector)) //预分析步骤
    return FALSE;

//把“汇编笔” (`aw`) 放在“施工地”的开头，准备 JIT(即时编译)。
  gum_arm64_writer_reset (aw, ctx->trampoline_slice->data);

if (ctx->type == GUM_INTERCEPTOR_TYPE_FAST)
  {
    deflector_target = ctx->replacement_function;
  }
  else
  {
      //JIT 编译出的 `Dispatcher`（总调度中心）的入口地址
      //gum_arm64_writer_cur (aw) 在这里返回的就是这块新内存(“施工地”)的“起始地址”
    ctx->on_enter_trampoline = gum_sign_code_pointer (gum_arm64_writer_cur (aw));
    deflector_target = ctx->on_enter_trampoline;
  }

if (need_deflector)
  {
    // ... (处理 B 指令跳转距离太远的情况) ...
  }
```

- **`gum_interceptor_backend_prepare_trampoline(...)`**：

- 这是一个 **预分析** 步骤。它会先去 **反汇编** `function_address` 的开头，**分析** 出“我们最少需要‘偷’多少字节？”（比如 4 字节或 8 字节或 16 字节）。
  - 它还会分配一块新的可执行内存（`ctx->trampoline_slice`），这就是我们的“**施工地**”。

- **`gum_arm64_writer_reset (aw, ctx->trampoline_slice->data);`**：

- 把“汇编笔” (`aw`) 放在“施工地”的开头，准备 JIT(即时编译)。

- **`ctx->on_enter_trampoline = gum_sign_code_pointer (gum_arm64_writer_cur (aw));`**：

- 这行代码的 **核心目的** 是：**JIT 编译（即时编译）`Dispatcher`（总调度中心）的入口点，对其进行“安全签名”，然后把这个入口地址“登记”到“施工蓝图” (`ctx`) 中。**

让我们从右到左，一步一步把它分解开：

- **`gum_arm64_writer_cur (aw)`**

- **`	aw`**：是 `GumArm64Writer`，我们的“**汇编笔**”。
    - **`_cur`**：是 "current"（当前）的缩写。
    - **含义：** 这个函数返回“汇编笔”**当前所在的内存地址**。
    - **在当前上下文中：**
      - 就在这行代码之前，我们调用了 `gum_arm64_writer_reset (aw, ctx->trampoline_slice->data);`。
      - `ctx->trampoline_slice` 是我们刚申请的“施工地”（一块全新的可执行内存）。
      - `reset` 把“汇编笔” (`aw`) 放在了这块“施工地”的 **最开头**。
      - **因此，** `gum_arm64_writer_cur (aw)` 在这里返回的就是 **这块新内存的“起始地址”**。这个地址，就是我们即将 JIT 编译的 `Dispatcher`（总调度中心）的 **入口地址**。

- **`gum_sign_code_pointer ( ... )`**
    - **含义：** 这个函数获取（来自第 1 步的）“入口地址”，并为它 **添加“指针认证”（PAC）签名**。
    - **目的：** 这是为了 **绕过** Apple 等高端 ARM64 芯片的硬件安全检查。它确保我们 JIT 编译出的这个新 `Dispatcher` 入口地址看起来是“合法的”，防止 CPU 在跳转到它时因“认证失败”而使程序崩溃。

- **`ctx->on_enter_trampoline = ...`**
    - **`ctx`**：是 `GumFunctionContext`，即本次 Hook 的“**施工蓝图**”。
    - **`on_enter_trampoline`**：是“蓝图”中的一个字段（一个指针）。
    - **含义：** 这是一个 **赋值操作**。
    - **总结：**
      1. 我们拿到了 `Dispatcher` 的入口地址（第 1 步）。
      2. 我们为这个地址进行了“安全签名”（第 2 步）。
      3. 我们把这个 **“签名后”的入口地址**，**保存（登记）** 到 `ctx->on_enter_trampoline` 字段中。

------

#### 第 2 阶段：JIT 编译 `Dispatcher`（总调度中心）

```C
  if (ctx->type != GUM_INTERCEPTOR_TYPE_FAST)
  {
    // JIT 编译“进入 onEnter 逻辑”的部分
    gum_arm64_writer_put_ldr_reg_address (aw, ARM64_REG_X17, GUM_ADDRESS (ctx));
    gum_arm64_writer_put_ldr_reg_address (aw, ARM64_REG_X16, GUM_ADDRESS (gum_sign_code_pointer (self->enter_thunk)));
    gum_arm64_writer_put_br_reg (aw, ARM64_REG_X16);

// JIT 编译“进入 onLeave 逻辑”的部分
    ctx->on_leave_trampoline = gum_arm64_writer_cur (aw);

gum_arm64_writer_put_ldr_reg_address (aw, ARM64_REG_X17, GUM_ADDRESS (ctx));
    gum_arm64_writer_put_ldr_reg_address (aw, ARM64_REG_X16, GUM_ADDRESS (gum_sign_code_pointer (self->leave_thunk)));
    gum_arm64_writer_put_br_reg (aw, ARM64_REG_X16);

gum_arm64_writer_flush (aw);
  }
```

- **这就是 `Dispatcher` 的“JIT 编译”过程！**

- **`onEnter` 部分：**

- `LDR X17, [ctx_addr]`：JIT 一条指令，把“舞台” (`ctx`) 的地址加载到 `X17` 寄存器。（然后回顾之前分析的 第 1 部分（最底层）：`gum_emit_enter_thunk`代码中 `X17` 在 `enter_thunk` 中被用作第一个参数）。

- `LDR X16, [enter_thunk_addr]`：JIT 一条指令，把我们 **预先造好** 的 `enter_thunk`（还记得吗？那个 C 语言桥梁）的地址加载到 `X16`。

- `BR X16`：JIT 一条指令，**JUMP** 到 `enter_thunk`。

```c
    //回顾之前分析的代码——第 1 部分（最底层）：`gum_emit_enter_thunk` 如下：
    
    static void
    gum_emit_enter_thunk (GumArm64Writer * aw)
    {
      // 1. 发出“函数序言”（Prolog）
      //    这会 JIT 编译出保存所有 CPU 寄存器（X0-X28, FP, LR）到堆栈上的代码。
      //    这是“保护现场”。
      gum_emit_prolog (aw);
    
      // 2. 准备 C 函数的参数 (X1, X2, X3)
      //    在 ARM64 C 语言调用约定中，参数通过 X0, X1, X2, X3... 传递。
      //    X0 稍后会设置（它来自 X17）。
    
      //    ADD X1, SP, ...CPU_CONTEXT
      //    将“指向堆栈上 GumCpuContext（包含了所有寄存器值） 结构的指针”放入 X1（第二个参数）。
      gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X1, ARM64_REG_SP, GUM_FRAME_OFFSET_CPU_CONTEXT);
      //    ADD X2, SP, ...CpuContext.lr
      //    将“指向堆栈上 lr 寄存器保存位置的指针”放入 X2（第三个参数）。
      gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X2, ARM64_REG_SP, GUM_FRAME_OFFSET_CPU_CONTEXT + G_STRUCT_OFFSET (GumCpuContext, lr));
      //    ADD X3, SP, ...NEXT_HOP
      //    将“指向堆栈上 next_hop 字段的指针”放入 X3（第四个参数）。
      gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X3, ARM64_REG_SP,
          GUM_FRAME_OFFSET_NEXT_HOP);
    
      // 3. JIT 编译一个 C 函数调用
      gum_arm64_writer_put_call_address_with_arguments (aw,
          GUM_ADDRESS (_gum_function_context_begin_invocation), 4, // 目标C函数
          // 这个 C 函数将接收 4 个参数:
          //   - Arg 1 (X0) = X17 (这是由 Dispatcher 提前设置好的 GumFunctionContext*,（包含了 `listener` 列表) )
          GUM_ARG_REGISTER, ARM64_REG_X17,
          //   - Arg 2 (X1) = X1 (我们刚设置的 GumCpuContext*,（包含了所有寄存器值）)
          GUM_ARG_REGISTER, ARM64_REG_X1,
          //   - Arg 3 (X2) = X2 (我们刚设置的 saved_lr*)
          GUM_ARG_REGISTER, ARM64_REG_X2,
          //   - Arg 4 (X3) = X3 (我们刚设置的 next_hop*)
          GUM_ARG_REGISTER, ARM64_REG_X3);
    
      // 4. 发出“函数终言”（Epilog）
      //    这会 JIT 编译出从堆栈上恢复所有寄存器的代码，并执行 RET（返回）。
      gum_emit_epilog (aw);
    }
    ```

![](upload/attach/202511/940077_GQ6EEGZVXJN7KS5.webp)

- **实际调试演示**：

- 下面是目标函数入口被覆写（动态调试发现16.4.18符合在此处覆写，但是16.7.19好像不是覆写，而且在其他内存中存放该指令？？）
 - ![](upload/attach/202511/940077_B2YEQ5PNMRPCZR9.webp)
 - 下面是Dispatcher（调度中心）
 - ![](upload/attach/202511/940077_EPECCBDVD6HBMM4.webp)
 - 下面是enter_thunk（C语言桥梁）
 - ![](upload/attach/202511/940077_3XHU64PBD9C8SVV.webp)

- **特征检测相关文章**：
        - [[原创]关于frida检测的一个新思路](https://bbs.kanxue.com/thread-268586.htm)
        - [从inlinehook角度检测frida](https://bbs.kanxue.com/thread-269862.htm)

- **`onLeave` 部分：**

- `ctx->on_leave_trampoline = ...`：**“标记 `onLeave` 的入口！”**

- 下面 JIT 了 **一模一样** 的代码，只是它加载的是 `leave_thunk` 的地址。（然后回顾之前分析的 第 2 部分（最底层）：`gum_emit_leave_thunk`代码中 `X17` 在 `leave_thunk` 中被用作第一个参数）。

- ```c
    //回顾之前分析的代码——第 2 部分（最底层）：`gum_emit_leave_thunk`如下：
    
    static void
    gum_emit_leave_thunk (GumArm64Writer * aw)
    {
      // 1. 发出“函数序言”（Prolog） - 保存所有寄存器
      gum_emit_prolog (aw);
    
      // 2. 准备 C 函数的参数 (X1, X2)
      //    ADD X1, SP, ...CPU_CONTEXT
      //    将 GumCpuContext* 放入 X1（第二个参数）。
      gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X1, ARM64_REG_SP,
          GUM_FRAME_OFFSET_CPU_CONTEXT);
      //    ADD X2, SP, ...NEXT_HOP
      //    将 next_hop* 放入 X2（第三个参数）。
      gum_arm64_writer_put_add_reg_reg_imm (aw, ARM64_REG_X2, ARM64_REG_SP,
          GUM_FRAME_OFFSET_NEXT_HOP);
    
      // 3. JIT 编译一个 C 函数调用
      gum_arm64_writer_put_call_address_with_arguments (aw,
          GUM_ADDRESS (_gum_function_context_end_invocation), 3, // 目标C函数
          // 这个 C 函数将接收 3 个参数:
          //   - Arg 1 (X0) = X17 (GumFunctionContext*)
          GUM_ARG_REGISTER, ARM64_REG_X17,
          //   - Arg 2 (X1) = X1 (GumCpuContext*)
          GUM_ARG_REGISTER, ARM64_REG_X1,
          //   - Arg 2 (X2) = X2 (next_hop*)
          GUM_ARG_REGISTER, ARM64_REG_X2);
    
      // 4. 发出“函数终言”（Epilog） - 恢复所有寄存器并 RET
      gum_emit_epilog (aw);
    }
    ```

- **至此，“总调度中心” (`Dispatcher`) 建造完毕。** 它包含两个部分，分别用于 `onEnter` 和 `onLeave`。

------

#### 第 3 阶段：JIT 编译 `Trampoline`（“被偷的”指令）

```c
  ctx->on_invoke_trampoline = gum_sign_code_pointer (gum_arm64_writer_cur (aw));

//开始 **读取** `function_address`（原函数）的指令，并把 **搬运/修复** 后的指令，用“汇编笔” (`aw`) JIT 到我们 **当前的位置**。
  gum_arm64_relocator_reset (ar, function_address, aw);

signature = g_string_sized_new (16);

//“偷”指令
  do
  {
    const cs_insn * insn;

reloc_bytes = gum_arm64_relocator_read_one (ar, &insn);//读取一条指令
 // ... 
 g_string_append (signature, insn->mnemonic);
 }
 while (reloc_bytes < data->redirect_code_size);
```

- **`ctx->on_invoke_trampoline = ...`**：
  - **“标记 `Trampoline` 的入口！”** 这就是 `onEnter` 的 C 语言大脑 (`_gum_function_context_begin_invocation`) 在决定“执行原函数”时，设置 `*next_hop` 的目标地址。
- **`gum_arm64_relocator_reset(...)`**：
  - 启动“智能指令搬运工” (`ar`)！
  - 告诉它：“开始 **读取** `function_address`（原函数）的指令，并把 **搬运/修复** 后的指令，用“汇编笔” (`aw`) JIT 到我们 **当前的位置**。”
- **`do...while` 循环：**
  - 这就是在“偷”指令。`gum_arm64_relocator_read_one` 会 **读取** 一条指令，并 **记录** 它（比如记录到 `signature` 里）。
  - 循环会一直“偷”，直到“偷”的字节数（`reloc_bytes`）**足够** 覆盖掉我们将要写入的 `JUMP` 指令（`data->redirect_code_size`）。

------

#### 第 4 阶段：【最终答案】—— 处理 `lr` 寄存器问题！

```c
  /*
   * 巨大的注释块，解释了 Android 上的 dlopen() 会读取 LR，
   * 而 Frida 劫持返回时会修改 LR，这导致了 dlopen() 崩溃。
   * 因此，Frida 必须在这里修复它。
   */
  is_eligible_for_lr_rewriting = strcmp (signature->str, "mov;b") == 0 ||
      g_str_has_prefix (signature->str, "stp;mov;mov;bl");

if (is_eligible_for_lr_rewriting)//是否启用“LR 修复扫描模式”：是否符合 lr 重写条件
  {
    const cs_insn * insn;

while ((insn = gum_arm64_relocator_peek_next_write_insn (ar)) != NULL) //是否真的执行修复：此为true时才会触发真正的修复行为
    {
      const cs_arm64_op * source_op = &insn->detail->arm64.operands[1];

if (insn->id == ARM64_INS_MOV &&
          source_op->type == ARM64_OP_REG &&
          source_op->reg == ARM64_REG_LR)
      {
        // ！！！侦测到：MOV Xn, LR！！！Xn是通用寄存器，其中n 是编号，范围 0 ~ 30，比如 X0, X1, X2...
        // 它在读取 LR！
        
        // JIT 一段代码，去调用 C 函数
        gum_arm64_writer_put_call_address_with_arguments (aw,
            GUM_ADDRESS (_gum_interceptor_translate_top_return_address), 1,
            GUM_ARG_REGISTER, ARM64_REG_LR);
        // ... (省略了复杂的 JIT 代码，用于把 X0 的结果存回 Xn) ...

// 跳过（不写入）这条原始的 'MOV Xn, LR'
        gum_arm64_relocator_skip_one (ar);
      }
      else
      {
        // 这条指令没问题，让 relocator 正常搬运并 JIT 它
        gum_arm64_relocator_write_one (ar);
      }
    }
  }
  else
  {
    // 函数不符合“重写”资格，正常搬运所有“偷来”的指令
    gum_arm64_relocator_write_all (ar);
  }
```

- **这就是我们所有分析的“风暴中心”！** 这就是对你最初 `lr` 测试用例的 **生产环境** 解决方案。

- **`is_eligible_for_lr_rewriting = ...`**：
  - **“启发式”检查**。Frida 不会对所有函数都执行这个昂贵的 `lr` 修复（太慢且有风险）。
  - 它只对那些 **“指令签名”**（`signature->str`）看起来像 `dlopen` Thunk（例如 `"mov;b"`）的函数才启用此功能。
  
- **`if (is_eligible_for_lr_rewriting)`（如果启用）：**
  - `while` 循环：检查“搬运工” (`ar`) **即将要 JIT** 的每一条“被偷的”指令。
  - **`if (insn->id == ARM64_INS_MOV && ... source_op->reg == ARM64_REG_LR)`**
    - **“抓到了！”** 施工队发现这条指令是 `MOV Xn, LR`。它 **正在读取 `LR`**！
  - **“修复” (The Fix)：**
    1. **它不会 JIT 这条 `MOV Xn, LR`**（因为此时 `LR` 已经被 Frida 污染了）。
    2. **取而代之**，它用“汇编笔” (`aw`) JIT 了一段 **全新的** 汇编代码。
    3. 这段新代码会 **调用一个 C 函数** (`_gum_interceptor_translate_top_return_address`)，这个 C 函数会去 `GumInvocationStack`（我们之前分析的“存包处”）**查到那个“真实的”、未被污染的 `LR`**。
    4. C 函数返回后（`X0` 寄存器里是“真实的” `LR`），JIT 代码会把 `X0` 里的值存入 `Xn`。
    5. `gum_arm64_relocator_skip_one (ar)`：**丢弃** 那条原始的 `MOV Xn, LR` 指令。

- 关于 `Interceptor` 如何（以及何时）决定修复 `LR`（链接寄存器）读取的核心逻辑。

```c
  is_eligible_for_lr_rewriting = strcmp (signature->str, "mov;b") == 0 ||
        g_str_has_prefix (signature->str, "stp;mov;mov;bl");
  ```

------

问题 1：“矛盾”：为什么比较的长度不同？（8 字节 vs 16 字节）

**答案：** 因为 Frida “偷”的字节数（`data->redirect_code_size`）是 **动态的**，而不是固定的 8 字节。
 
 在第 1 阶段：准备“施工地”和“入口”代码中的 `gum_interceptor_backend_prepare_trampoline`（“预分析”函数）会智能地分析目标函数，来决定“安全偷取”的最小字节数（决定是“偷”4 字节 or 8 字节 or 16 字节 等等）：
 
 - **对于 `"mov;b"` 场景：** “预分析”函数决定“偷” **8 字节** 就够了。`do...while` 循环正好偷了 8 字节，`signature->str` 变为 `"mov;b"`，`strcmp` 匹配成功。
 - **对于 `"stp;mov;mov;bl"` 场景：** “预分析”函数（为了安全）决定 **必须** 偷 **16 字节**。`do...while` 循环正好偷了 16 字节，`signature->str` 变为 `"stp;mov;mov;bl"`，`g_str_has_prefix` 匹配成功。

**结论：** 8 字节和 16 字节并不矛盾。它们是 Frida 为了 **两种不同情况** 而设置的 **两种不同长度** 的“高风险”签名。

------

问题 2：为什么是这两个“签名”？（目的）

**答案：** 这是一个 **“启发式检查”（Heuristic Check）**，是 Frida 最重要的 **性能优化** 之一。
  
  Frida **不会** 在 *每个* 函数上都执行昂贵的 `LR` 修复（即逐条检查指令的 `while` 循环），因为太慢了。相反，它使用这两个“签名”作为 **“高风险特征码”（Red Flags）** 来 **“快速筛选”**：
  
  - **`"mov;b"`**
    - **含义：** 这是一个“`dlopen` Thunk（垫片）”的“指纹”。
    - **风险：** 这种 Thunk **极有可能** 会读取 `LR` 寄存器来判断调用者。如果我们不启用“JIT 修复”，`dlopen` 就会读到 Frida 污染过的 `LR`，导致崩溃。
  - **`"stp;mov;mov;bl"`**
    - **含义：** 这是一个“复杂函数序言”的“指纹”，它在 16 字节内就同时操作了 `LR`（`STP`）并进行了函数调用（`BL`）。
    - **风险：** 这种“`LR` 敏感”的函数，**极有可能** 也包含了 `MOV Xn, LR` 这种需要“JIT 修复”的指令。

**总结：** 这行代码的 **唯一目的**，就是 **“解锁”** 那个昂贵的 `LR` 修复逻辑（`while` 循环），只对“高风险分子”进行逐条扫描。

------

问题 3：假如“被偷”的指令中没有读取 LR，但是后续（函数“身体”里）有读取 LR，还会修复吗？

**答案：会！但是通过\*另一种\*机制。**

Frida 有 **两套** `LR` 修复方案，互为补充：
  
  1. **“JIT 修复”（`create_trampoline`，我们正在分析的）：**
     - **目标：** 修复 `Trampoline` **内部**（即“被偷”的指令）的 `MOV Xn, LR`。
     - **方式：** **重写汇编代码**，把 `MOV Xn, LR` 替换成一个 `CALL C_function`。
     - **触发：** 由 `is_eligible_for_lr_rewriting = TRUE`（“启发式签名”）**解锁**。
  2. **“运行时修复”（`begin_invocation`，C 语言大脑）：**
     - **目标：** 修复在 `onEnter` 之后，函数 **“身体”**（Body）中对 `LR` 的读取。
     - **方式：** 通过调用 `gum_function_context_fixup_cpu_context`，在 **C 语言层面** 修改 `cpu_context->lr` 快照的值，把“被污染的” `on_leave_trampoline` 地址 **改回**“真实的” `caller_ret_addr`。
     - **触发：** **默认** 对 `attach_to_function_reading_lr` 类型的 Hook 生效（它在 `gum_function_context_new` 中设置）。

**结论：**
 
 - **“JIT 修复”**（我们正在看的）是一种 **特殊优化**，用于修复 **“被偷”的 Thunk**。
 - **“运行时修复”**（`fixup_cpu_context`）是一种 **通用机制**，用于修复 **函数“身体”** 中的 `LR` 读取。Frida 会同时使用它们来确保 `LR` 的正确性
 
 ---
 
 
 
 问题 4：开头‘长得’像 `"stp;mov;mov;bl"` 的函数，第二个 `mov` 是不是就是 `MOV Xn, LR`？
 
 **答案：不是的。**
 
 这是一个非常常见的、也是非常合理的推测，但答案是否定的。
 
 **“签名” (`signature->str`) 是一个“傻瓜式”检查。**
 
 1. `do...while` 循环（“偷”指令的循环）在构建 `signature->str` 时，它**只**关心指令的**“助记符”**（Mnemonic），比如 `stp`、`mov`、`bl`。
 2. 它**完全不关心**这些指令的**“操作数”**（Operands），比如 `X29`、`SP` 或者是 `LR`。
 3. 因此，`"stp;mov;mov;bl"` 签名中的那两个 `mov`，**在签名检查时**，Frida **并不知道**它们是 `MOV X29, SP` 还是 `MOV Xn, LR`。它们都只被当作一个“`mov`”。
 
 **这个“签名” (`"stp;mov;mov;bl"`) 只是一个“高风险特征码”。**
 
 **打个比方：**
 
 - “签名检查” (`g_str_has_prefix`) 就像一个保安，他**只**通过“外貌”（`"stp;mov;mov;bl"`）来判断一个人是不是“高风险分子”。
 - 这个“高风险分子”的“外貌”中包含 `mov`，但这并不意味着保安*知道*这个 `mov` 藏着一把“武器”（`LR` 读取）。
 - **只有当**保安（Frida）确认了这是个“高风险分子” (`is_eligible... = TRUE`)，他**才**“解锁”了权限，去执行**下一步**——那个**昂贵的 `while` 循环**。
 
 **`while` 循环**（`peek_next_write_insn`）才是**真正的“搜身”（Detailed Search）**。它**会**逐个检查那 4 条“被偷”的指令的**“操作数”**，去**真正地寻找**那把“武器”（`MOV Xn, LR`）。
 
 **总结：** `"stp;mov;mov;bl"` 里的 `mov` **不是** `MOV Xn, LR`。它只是一个“外貌特征”，这个“外貌”足以**“解锁”**那个真正会去检查 `LR` 的 `while` 循环。
 
 ---
 
 
 
 问题 5：“解锁”那个昂贵的 `while` 循环，去逐条扫描，扫描多少字节？
 
 **答案：它扫描的不是“字节”，而是“被偷走的指令列表”。**
 
 `while` 循环（`while ((insn = gum_arm64_relocator_peek_next_write_insn (ar)) != NULL)`）**不会**再去内存中读取新的字节。
 
 它扫描（遍历）的是**已经被 `do...while` 循环“偷走”并暂存在 `ar`（“搬运工”）对象中的那个指令列表**。
 
 所以，这个 `while` 循环的迭代次数是**固定**的，它**等于**“被偷走”的指令数量：
 
 - **如果签名是 `"mov;b"`：**
 - `do...while` 循环**偷了 2 条指令**（8 字节）。
 - `is_eligible...` 为 `TRUE`。
 - 昂贵的 `while` 循环**会执行 2 次**，逐条“搜身”这 2 条指令（`mov` 和 `b`），看它们是不是 `MOV Xn, LR`。
 - **如果签名是 `"stp;mov;mov;bl"`：**
 - `do...while` 循环**偷了 4 条指令**（16 字节）。
 - `is_eligible...` 为 `TRUE`。
 - 昂贵的 `while` 循环**会执行 4 次**，逐条“搜身”这 4 条指令（`stp`, `mov`, `mov`, `bl`），看它们是不是 `MOV Xn, LR`。
 
 **结论：** 这个昂贵的 `while` 循环，它的扫描范围**仅限于**被 `do...while` 循环（为了腾出空间而）“偷走”的那几条指令。它**不会**扫描函数“身体”的其余部分（**这就是为什么我们还需要“运行时修复”** `gum_function_context_fixup_cpu_context`）。

------

#### 第 5 阶段：JIT 编译“返回跳板”

```c
  if (!ar->eoi)
  {
    GumAddress resume_at;

resume_at = gum_sign_code_address (
        GUM_ADDRESS (function_address) + reloc_bytes);
    gum_arm64_writer_put_ldr_reg_address (aw, data->scratch_reg, resume_at);
    gum_arm64_writer_put_br_reg (aw, data->scratch_reg);
  }
```

- **`Trampoline`（跳板机）的最后一块积木。**
- **`resume_at = ...`**：计算出原函数中，**“被偷”指令之后** 的那条指令的地址。
- **`LDR ... BR ...`**：JIT 编译一个 **无条件 JUMP**，跳转到 `resume_at`。
- **含义：** 当 CPU 执行完 `Trampoline` 中所有（可能已被修复的）“被偷”的指令后，它会 **跳回到原函数的“身体”部分**，继续执行。

------

#### 第 6 阶段：收尾（保存原始指令用于 `detach`）

```c
  ctx->overwritten_prologue_len = reloc_bytes;
  gum_memcpy (ctx->overwritten_prologue, function_address, reloc_bytes);

return TRUE;
}
```

- `gum_memcpy(...)`：把原函数开头 **未经修复** 的、**原始的** `reloc_bytes` 字节，**备份** 到 `ctx->overwritten_prologue` 中。
- **为什么？** 当用户调用 `Interceptor.detach()`（卸载 Hook）时，Frida 需要 **把这些原始字节复制回去**，以实现“**反激活**”和“**复原**”函数。
- `return TRUE;`：“施工”完毕，一切顺利！

------

### 阶段小结

`_gum_interceptor_backend_create_trampoline` 是 Interceptor 中 **最复杂** 的 JIT 编译函数（“施工现场”）。

- 它负责 **JIT 编译 `Dispatcher`**（总调度中心），该中心由两个 stub（存根）组成，分别 JUMP 到预先造好的 `enter_thunk` 和 `leave_thunk`。
- 它负责 **JIT 编译 `Trampoline`**（跳板机），这个 `Trampoline` 由两部分组成：
  1. **“被偷的”指令：**
     - 使用 `gum_arm64_relocator`（“智能搬运工”）来“偷”原函数的开头指令。
     - **这就是 `lr` 问题的答案：** 它有一个 **启发式检测器**，如果发现函数“符合资格”（`is_eligible_for_lr_rewriting`），它会 **逐条检查**“被偷”的指令。
     - 如果检测到 `MOV Xn, LR`，它会 **丢弃** 这条指令，并 **JIT 生成一段全新的代码**，这段代码会调用 C 函数（`_gum_interceptor_translate_top_return_address`）去查找 **“真实的” `LR`**，并将其存入 `Xn`。
  2. **“返回跳板”：**
     - 一个 JUMP 指令，用于在 `Trampoline` 执行完毕后，跳回到原函数的“身体”部分。
- 它最后会 **备份** 原始的函数头（`overwritten_prologue`），以便将来 `detach`（卸载）时可以“复原”函数。

---

----

---

-----

## Stalker

Stalker 的主要目标是**跟踪一个线程的执行流**（Code Execution Tracing），而不是监控内存访问。

### 原理

它的大致原理是这样的：

1. **动态重新编译 (Dynamic Recompilation / Instrumentation):** Stalker 会接管目标线程的执行。它*不是*通过设置内存页权限，而是通过“JIT”（Just-In-Time）技术。
2. **基本块 (Basic Block) 粒度:** Stalker 以“基本块”（Basic Block - 即一段没有跳转的连续指令）为单位，在CPU即将执行某个基本块*之前*，Stalker 会：
   - 动态地生成（或从缓存中获取）一段新的代码。
   - 这段新代码 = **“桩代码” (Instrumentation)** + **原始的基本块指令**。
   - “桩代码”是 Stalker 插入的额外逻辑，用来记录“我即将执行这个基本块了”（例如，调用 `Stalker.queue_call` 或 `Stalker.trust`）。
3. **执行重定向:** Stalker 让 CPU 执行这个新生成的、包含“桩代码”的版本，而不是原始版本。
4. **循环往复:** 当这个基本块执行完毕（例如遇到 `ret` 或 `bl` 跳转），Stalker 会捕获这个跳转，并对*下一个*即将执行的基本块重复上述过程。

------

### 阶段小结

- **Stalker 的原理 (动态重新编译):**
  - **目的:** 跟踪**代码执行** (Code Execution)。
  - **触发:** 当线程 *即将执行* 某条（或某块）指令时，Stalker 介入并插入自己的代码。
  - **场景:** “我想知道这个线程执行了哪些指令。”

Stalker 是一种非常精细的执行跟踪技术，它让您几乎可以在每条指令（或每个基本块）执行前后“挂钩”(hook)，从而实现代码覆盖率分析、路径跟踪等高级功能。

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

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

最后于 2025-11-12 09:11 被教教我吧~编辑，原因：

#调试逆向 #系统底层 #其他内容

收藏・19

点赞・51

打赏

赞赏记录

参与人

雪币

留言

时间

git_51951meggadf3df

非常支持你的观点！

2026-9-11 13:30

mb_lthgjpwj

为你点赞！

2026-8-21 08:24

mb_wsoacceo

为你点赞！

2026-8-11 01:25

hexdump

感谢你分享这么好的资源！

2026-7-30 11:44

mb_cebxltxx

为你点赞！

2026-7-18 00:49

wx_晨梦

感谢你的积极参与，期待更多精彩内容！

2026-7-16 05:36

智童

这个讨论对我很有帮助，谢谢！

2026-7-1 14:17

juice4fun

感谢你的贡献，论坛因你而更加精彩！

2026-5-6 16:24

mb_cfjwplfo

感谢你的贡献，论坛因你而更加精彩！

2026-5-4 16:02

npc0vo

非常支持你的观点！

2026-4-25 21:52

gal2xy

非常支持你的观点！

2026-4-10 18:04

yaoguen

这个讨论对我很有帮助，谢谢！

2026-3-24 22:34

mb_eiufitqh

这个讨论对我很有帮助，谢谢！

2026-3-12 20:33

mb_dwxaumtm

你的分享对大家帮助很大，非常感谢！

2026-3-9 18:59

奋斗小菜鸟

你的帖子非常有用，感谢分享！

2026-3-5 14:27

岁月。

感谢你分享这么好的资源！

2026-3-5 10:55

Ms135

感谢你的贡献，论坛因你而更加精彩！

2026-2-24 20:44

季东

为你点赞！

2026-2-19 00:29

shutterbug

你的帖子非常有用，感谢分享！

2026-2-3 09:58

mb_vanjeoof

期待更多优质内容的分享，论坛有你更精彩！

2026-1-30 13:48

caozhzh

你的分享对大家帮助很大，非常感谢！

2026-1-28 11:17

卡卡骨

为你点赞！

2026-1-19 20:25

git_47499test-look

感谢你的积极参与，期待更多精彩内容！

2026-1-19 02:10

mb_pkrgdzpt

这个讨论对我很有帮助，谢谢！

2026-1-10 12:52

taeyeon_ss

感谢你分享这么好的资源！

2025-12-17 10:54

git_21210wzzzh2025

感谢你的贡献，论坛因你而更加精彩！

2025-12-12 09:48

New对象处

非常支持你的观点！

2025-12-12 09:32

梧桐生

感谢你的贡献，论坛因你而更加精彩！

2025-12-7 20:41

xianyuuuan

谢谢你的细致分析，受益匪浅！

2025-12-7 15:01

mb_ynpgeaep

你的帖子非常有用，感谢分享！

2025-12-5 17:28

烟花易冷丶

期待更多优质内容的分享，论坛有你更精彩！

2025-12-2 11:08

shanzj

期待更多优质内容的分享，论坛有你更精彩！

2025-11-27 23:43

灬哈密瓜

感谢你的积极参与，期待更多精彩内容！

2025-11-27 09:11

mb_kgfqphsx

为你点赞！

2025-11-25 09:47

git_86715adam019701

为你点赞！

2025-11-22 12:23

sinker_

期待更多优质内容的分享，论坛有你更精彩！

2025-11-22 03:02

快乐的小跳蛙

期待更多优质内容的分享，论坛有你更精彩！

2025-11-21 21:46

ldljlzw

感谢你的贡献，论坛因你而更加精彩！

2025-11-18 15:45

令狐双

你的分享对大家帮助很大，非常感谢！

2025-11-18 15:24

上网鱼

为你点赞！

2025-11-18 15:13

wx_0.0_522

感谢你的积极参与，期待更多精彩内容！

2025-11-17 17:36

cydian

这个讨论对我很有帮助，谢谢！

2025-11-17 15:03

冲冲冲

你的分享对大家帮助很大，非常感谢！

2025-11-12 09:36

NshIdE

谢谢你的细致分析，受益匪浅！

2025-11-10 11:52

东方玻璃

你的帖子非常有用，感谢分享！

2025-11-7 15:35

我的小拇指啊

感谢你的积极参与，期待更多精彩内容！

2025-11-7 14:54

ONewTach

这个讨论对我很有帮助，谢谢！

2025-11-7 08:54

蜕无痕

为你点赞！

2025-11-6 16:23

值得怀疑

+10

期待更多优质内容的分享，论坛有你更精彩！

2025-11-6 14:03

Ram98

非常支持你的观点！

2025-11-6 10:04

Imxz

感谢你的积极参与，期待更多精彩内容！

2025-11-6 09:21

最新回复 (24)
Imxz 雪币： 112 活跃值： (9420) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 752 粉丝 9 关注私信	Imxz 2 楼 tql 我反手就是一个三连 2025-11-6 09:20 0
值得怀疑雪币： 1605 活跃值： (9399) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 393 粉丝 1 关注私信	值得怀疑 3 楼用了ai吗？ 2025-11-6 14:15 0
教教我吧~ 雪币： 1979 活跃值： (3634) 能力值： ( LV6，RANK：80 ) 在线值：发帖 12 回帖 63 粉丝 68 关注私信	教教我吧~ 1 4 楼值得怀疑用了ai吗？用了，gemini，提升效率 2025-11-6 15:47 0
蜕无痕雪币： 2217 活跃值： (3327) 能力值： ( LV3，RANK：20 ) 在线值：发帖 4 回帖 25 粉丝 143 关注私信	蜕无痕 5 楼教教我吧~ 用了，gemini，提升效率强啊 ai写这么多给我网页都搞卡了 2025-11-6 16:23 0
huangjw 雪币： 6688 活跃值： (11872) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 511 粉丝 2 关注私信	huangjw 6 楼牛啊，感谢分享 2025-11-7 09:33 0
mb_qimctavn 雪币： 5228 活跃值： (6625) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 386 粉丝 1 关注私信	mb_qimctavn 7 楼 6 2025-11-18 14:35 0
haogl 雪币： 4593 活跃值： (5831) 能力值： ( LV3，RANK：30 ) 在线值：发帖 7 回帖 86 粉丝 16 关注私信	haogl 8 楼回复来看看，先谢过楼主！ 2025-11-18 15:07 0
mb_xxezghuh 雪币： 229 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 13 粉丝 0 关注私信	mb_xxezghuh 9 楼 tql 2025-11-23 23:52 0
focaccia 雪币： 323 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	focaccia 10 楼申请加精！ 2025-11-27 08:52 0
寻梦之璐雪币： 764 活跃值： (3827) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 170 粉丝 16 关注私信	寻梦之璐 11 楼 666 2025-11-30 16:10 0
wx_Dispa1r 雪币： 1939 活跃值： (4277) 能力值： ( LV4，RANK：55 ) 在线值：发帖 5 回帖 135 粉丝 4 关注私信	wx_Dispa1r 12 楼 mark 2025-11-30 16:53 0
夜惜风雨雪币： 95 活跃值： (3667) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 152 粉丝 0 关注私信	夜惜风雨 13 楼 6666 2025-12-2 18:25 0
mb_ynpgeaep 雪币： 203 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 25 粉丝 0 关注私信	mb_ynpgeaep 14 楼 1 2025-12-5 17:28 0
mb_euhyowpw 雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_euhyowpw 15 楼 666 2025-12-12 08:56 0
29o 雪币： 20 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 83 粉丝 0 关注私信	29o 16 楼看看 2025-12-30 14:12 0
mb_ykavguun 雪币： 1204 活跃值： (1725) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 164 粉丝 0 关注私信	mb_ykavguun 17 楼 111 2026-1-10 12:27 0
rhffvipbp 雪币： 1 活跃值： (65) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	rhffvipbp 18 楼 666 2026-1-11 14:44 0
mb_bhsrdtqf 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 36 粉丝 0 关注私信	mb_bhsrdtqf 19 楼 6666 2026-1-17 22:17 0
sorely 雪币： 862 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 28 粉丝 0 关注私信	sorely 20 楼 666 2026-1-31 12:34 0
qig 雪币： 47 活跃值： (755) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 55 粉丝 1 关注私信	qig 21 楼看看 2026-2-20 17:39 0
bigric三雪币： 1000 活跃值： (631) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	bigric三 22 楼学习 2026-3-5 10:44 0
小迷糊ddd 雪币： 268 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 152 粉丝 0 关注私信	小迷糊ddd 23 楼感谢分享，学习一下。 2026-4-8 11:56 0
mb_ehujhmht 雪币： 205 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_ehujhmht 24 楼学习 2026-4-13 09:35 0
wx_coddvccwyh 雪币： 4 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 128 粉丝 0 关注私信	wx_coddvccwyh 25 楼 66666 2026-5-4 04:41 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

教教我吧~

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (24)
Imxz 雪币： 112 活跃值： (9420) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 752 粉丝 9 关注私信	Imxz 2 楼 tql 我反手就是一个三连 2025-11-6 09:20 0
值得怀疑雪币： 1605 活跃值： (9399) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 393 粉丝 1 关注私信	值得怀疑 3 楼用了ai吗？ 2025-11-6 14:15 0
教教我吧~ 雪币： 1979 活跃值： (3634) 能力值： ( LV6，RANK：80 ) 在线值：发帖 12 回帖 63 粉丝 68 关注私信	教教我吧~ 1 4 楼值得怀疑用了ai吗？用了，gemini，提升效率 2025-11-6 15:47 0
蜕无痕雪币： 2217 活跃值： (3327) 能力值： ( LV3，RANK：20 ) 在线值：发帖 4 回帖 25 粉丝 143 关注私信	蜕无痕 5 楼教教我吧~ 用了，gemini，提升效率强啊 ai写这么多给我网页都搞卡了 2025-11-6 16:23 0
huangjw 雪币： 6688 活跃值： (11872) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 511 粉丝 2 关注私信	huangjw 6 楼牛啊，感谢分享 2025-11-7 09:33 0
mb_qimctavn 雪币： 5228 活跃值： (6625) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 386 粉丝 1 关注私信	mb_qimctavn 7 楼 6 2025-11-18 14:35 0
haogl 雪币： 4593 活跃值： (5831) 能力值： ( LV3，RANK：30 ) 在线值：发帖 7 回帖 86 粉丝 16 关注私信	haogl 8 楼回复来看看，先谢过楼主！ 2025-11-18 15:07 0
mb_xxezghuh 雪币： 229 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 13 粉丝 0 关注私信	mb_xxezghuh 9 楼 tql 2025-11-23 23:52 0
focaccia 雪币： 323 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	focaccia 10 楼申请加精！ 2025-11-27 08:52 0
寻梦之璐雪币： 764 活跃值： (3827) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 170 粉丝 16 关注私信	寻梦之璐 11 楼 666 2025-11-30 16:10 0
wx_Dispa1r 雪币： 1939 活跃值： (4277) 能力值： ( LV4，RANK：55 ) 在线值：发帖 5 回帖 135 粉丝 4 关注私信	wx_Dispa1r 12 楼 mark 2025-11-30 16:53 0
夜惜风雨雪币： 95 活跃值： (3667) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 152 粉丝 0 关注私信	夜惜风雨 13 楼 6666 2025-12-2 18:25 0
mb_ynpgeaep 雪币： 203 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 25 粉丝 0 关注私信	mb_ynpgeaep 14 楼 1 2025-12-5 17:28 0
mb_euhyowpw 雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_euhyowpw 15 楼 666 2025-12-12 08:56 0
29o 雪币： 20 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 83 粉丝 0 关注私信	29o 16 楼看看 2025-12-30 14:12 0
mb_ykavguun 雪币： 1204 活跃值： (1725) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 164 粉丝 0 关注私信	mb_ykavguun 17 楼 111 2026-1-10 12:27 0
rhffvipbp 雪币： 1 活跃值： (65) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	rhffvipbp 18 楼 666 2026-1-11 14:44 0
mb_bhsrdtqf 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 36 粉丝 0 关注私信	mb_bhsrdtqf 19 楼 6666 2026-1-17 22:17 0
sorely 雪币： 862 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 28 粉丝 0 关注私信	sorely 20 楼 666 2026-1-31 12:34 0
qig 雪币： 47 活跃值： (755) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 55 粉丝 1 关注私信	qig 21 楼看看 2026-2-20 17:39 0
bigric三雪币： 1000 活跃值： (631) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	bigric三 22 楼学习 2026-3-5 10:44 0
小迷糊ddd 雪币： 268 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 152 粉丝 0 关注私信	小迷糊ddd 23 楼感谢分享，学习一下。 2026-4-8 11:56 0
mb_ehujhmht 雪币： 205 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_ehujhmht 24 楼学习 2026-4-13 09:35 0
wx_coddvccwyh 雪币： 4 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 128 粉丝 0 关注私信	wx_coddvccwyh 25 楼 66666 2026-5-4 04:41 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复