[原创]安卓APatch Root方案compat的nofault回退导致被检测-Android安全-看雪安全社区

[原创]安卓APatch Root方案compat的nofault回退导致被检测

发表于: 5天前 2656

[原创]安卓APatch Root方案compat的nofault回退导致被检测

Lun_OS

5天前

2656

## 主要被检测原因

这条侧信道之所以成立，**原因是 KernelPatch 的 `compat_strncpy_from_user()` 在不走 nofault 原语的内核上会回退（fallback）到普通 `strncpy_from_user()`**——一次会真正触发缺页的用户内存读。

KP 的 supercall 鉴权路径正是用这个函数去读「superkey 指针」所指向的内存
## 通过KPM模块解决-提供现成的解决方案
【KPM模块】解决“发现APatch的鉴权密钥”模块
<a href="elink@dd2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6x3N6h3&6Q4x3X3c8a6f1#2)9J5c8V1q4b7d9$3g2&6i4K6g2X3d9r3W2V1k6g2)9#2k6V1E0b7e0b7`.`.">【github】11aK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6x3N6h3&6Q4x3X3c8a6f1#2)9J5c8V1q4b7d9$3g2&6i4K6g2X3d9r3W2V1k6g2)9#2k6V1E0b7e0b7`.`.</a> 
---

## 一、检测原理

> APatch检测原理参考：春秋检测文档 <4b7K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6E0K9h3&6Y4P5Y4g2F1x3o6W2Q4x3X3g2Y4K9i4c8Z5N6h3u0Q4x3X3g2A6L8#2)9J5c8V1y4Z5N6h3&6I4K9i4g2Q4x3X3c8p5k6i4c8W2j5%4c8G2M7W2)9J5k6q4m8J5L8$3u0D9k6h3#2Q4x3X3c8K6L8$3I4#2N6r3W2G2L8W2)9J5c8W2)9J5x3#2)9J5c8V1k6A6L8r3g2Q4x3V1k6p5L8$3y4Q4x3V1k6C8M7%4g2Q4y4h3k6C8M7q4)9#2k6Y4y4A6k6r3g2U0K9r3q4F1L8X3g2D9i4K6g2X3P5X3R3`.>

APatch检测原理：
建议参照<a href="elink@e00K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3d9$3g2J5L8X3g2D9f1r3q4@1j5$3S2Q4x3V1k6T1L8r3!0T1i4K6u0r3x3K6f1J5k6r3f1K6y4K6b7%4y4U0V1K6k6o6b7H3x3$3g2T1x3h3p5@1j5X3b7J5j5K6V1^5k6r3x3H3y4r3q4W2j5U0l9I4z5e0f1#2j5g2)9J5c8X3E0W2M7X3&6W2L8q4)9J5c8Y4m8S2N6r3y4Z5i4K6u0r3j5$3!0E0L8h3!0F1i4K6u0r3M7%4g2H3k6i4u0U0j5h3I4D9i4K6u0W2j5H3`.`.">【此代码】e75K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3d9$3g2J5L8X3g2D9f1r3q4@1j5$3S2Q4x3V1k6T1L8r3!0T1i4K6u0r3x3K6f1J5k6r3f1K6y4K6b7%4y4U0V1K6k6o6b7H3x3$3g2T1x3h3p5@1j5X3b7J5j5K6V1^5k6r3x3H3y4r3q4W2j5U0l9I4z5e0f1#2j5g2)9J5c8X3E0W2M7X3&6W2L8q4)9J5c8Y4m8S2N6r3y4Z5i4K6u0r3j5$3!0E0L8h3!0F1i4K6u0r3M7%4g2H3k6i4u0U0j5h3I4D9i4K6u0W2j5H3`.`.</a>阅读
APatch管理器在向kernelpatch框架发起鉴权请求时，kernelpatch会读取APatch管理器所提供的superkey的所在地址（从before函数的udata参数传入）；kernelpatch在鉴权前会验证cmd值是否在范围内，在此范围内则允许鉴权，反之不允许。
检测方法：
1. “懒分配”页探测
检测器先向系统申请一个“懒分配”页，将此“懒分配”页的所在地址当作superkey所在地址向kernelpatch发起鉴权请求，kernelpatch会解引用此地址，尝试从中读取所谓的“superkey”，但实际上“懒分配”页中不存在于superkey，而由于kernelpatch尝试读取该页，系统会自动将“懒分配”页映射到一个物理内存块，此时检测器检查此页是否被映射到物理内存块，如果被映射即可判定存在kernelpatch，反之说明kernelpatch不存在。
2. 鉴权时延探测
kernelpatch在尝试读取superkey之前有一个检查cmd值的步骤，如果cmd值在范围内（SUPERCALL_HELLO和SUPERCALL_MAX之间）将会走向读取和验证superkey，反之会快速返回结束鉴权，这两种走向的花费时间是不同的，检测器可以提前拟定一个在范围内的cmd值和不在范围内的cmd值，分别向kernelpatch发起鉴权请求，同样的，多次测量范围内cmd和范围外cmd所花费的时间，取其总和来让比值趋于稳定，如果比值大于2，则判定kernelpatch存在。
懒分配：当用户态程序向操作系统请求分配页时，操作系统为了节省物理内存空间，会在虚拟内存分配该页，但不映射物理内存块，直到此页被真正访问后才会实质上分配内存块。
### 1.1 载体：KernelPatch 自建的 syscall 45

KernelPatch 注册了一个自己的系统调用 `__NR_supercall = 45`（arm64 上 45 恰好是 `truncate` 的编号，所以 magic 路径叫 `/system/bin/truncate`）。APatch 管理器就是通过它向 KernelPatch 发起鉴权请求、下发 `su` / KPM 装载等命令。

它的入口是 `supercall.c: before()`：

```c
static void before(hook_fargs6_t *args, void *udata)
{
 ...
 if (has_preset_superkey()) {
 const char __user *key_user = (const char __user)syscall_argn(args, 0); // x0 = superkey 指针
 char key[MAX_KEY_LEN]; // 128
 long len = compat_strncpy_from_user(key, key_user, MAX_KEY_LEN); // ← 先读 x0
 if (len <= 0) return;
 ...
 }
 if (is_trusted_manager_uid(uid)) { ... } else if (is_su_allow_uid(uid)) { ... }
 if (!is_trusted_caller) return;

long ver_xx_cmd = (long)syscall_argn(args, 1); // x1 低 16 位 = cmd
 long cmd = ver_xx_cmd & 0xFFFF;
 if (cmd < SUPERCALL_HELLO || cmd > SUPERCALL_MAX) return; // ← 后判 cmd
 ...
}
```

**两个条件决定了这条侧信道能不能成立**：

1. 鉴权请求天然带一个"由调用者给出的用户态指针"（x0 = superkey 指针），**内核会去解引用它**；
2. 这个解引用**发生在 cmd 范围判断之前**——`x1` 取什么值都拦不住它。

顺序换过代。0.10 / 0.12 一代是**反的**：先 `if (cmd < SUPERCALL_HELLO || cmd > SUPERCALL_MAX) return;`，再读密钥。那种顺序下 §1.3 的负 `x1` 会在门控处被挡掉，根本读不到 x0；本机这一代不存在这个挡板。

### 1.2 ★ 根因：compat 的 nofault 回退

`kernel/patch/common/utils.c`：

```c
long compat_strncpy_from_user(char *dest, const char __user *src, long count)
{
    if (kver > VERSION(6, 7, 0)) {
        kfunc_call(strncpy_from_user_nofault, dest, src, count);   // 6.8+ 才走这里
        kfunc_call(strncpy_from_unsafe_user, dest, src, count);
    }

if (kfunc(strncpy_from_user)) {                                // ★ 回退：会真正缺页
        long rc = kfunc(strncpy_from_user)(dest, src, count);
        if (rc >= count) { rc = count; dest[rc - 1] = '\0'; }
        else if (rc > 0) { rc++; }
        return rc;
    }

kfunc_call(strncpy_from_user_nofault, dest, src, count);
    kfunc_call(strncpy_from_unsafe_user, dest, src, count);
    return 0;
}
```

（`kfunc_call(f, ...)` 展开为 `if (kf_f) return kf_f(...);`，即"有则用并立刻返回"。）

关键就在 `kver > VERSION(6, 7, 0)` 这道**版本门**：在 ≤ 6.7.0 的内核上，KP **连试都不试** nofault，直接落到 `strncpy_from_user()`。挡在这一步的是 KP 自己的版本判断，不是原语缺失——`strncpy_from_user_nofault()` 在 6.1 的 `mm/maccess.c` 里就已经存在（6.8 同文件、同实现）。

两者的差别只有一行 `pagefault_disable()`：

```c
/* mm/maccess.c */
long strncpy_from_user_nofault(char *dst, const void __user *unsafe_addr, long count)
{
    pagefault_disable();                                   // ★ 缺页不再被"处理"
    ret = strncpy_from_user(dst, unsafe_addr, count);
    pagefault_enable();
    ...
}
```

于是同一次读，后果完全不同：

| 读法                                      | 遇到"未换入的匿名页"时                  | 副作用                                  |
| --------------------------------------- | ---------------------------- | ------------------------------------ |
| `strncpy_from_user`（**回退路径**）            | 正常走缺页处理 → 分配零页 → 读成功返回全 0    | 该页 **被换入**；`min_flt` +1；VMA `Referenced` 置位 |
| `strncpy_from_user_nofault`（6.8+）        | `pagefault_disable()` 下失败 → 返回 `-EFAULT` | 不分配页，页表/计数器**零变化**                    |

**⇒ 这条侧信道是"回退"制造出来的，不是 KernelPatch 的设计意图。** KP 在 > 6.7.0 的内核上走 nofault，就不再暴露它；本机 4.19 落在回退分支上，才有得测。KPM 改不了 KP 的这条路径，也无法让本机 KP 去试那个它主动跳过的 nofault，所以只能从**调用侧**介入（见 §二）。

### 1.3 靶点：为什么 `x1` 为负是唯一干净的判据

原生 `do_sys_truncate()`：

```c
static long do_sys_truncate(const char __user *pathname, loff_t length)
{
 if (length < 0) /* 长度检查在 user_path_at/getname **之前** */
 return -EINVAL; /* ⇒ 干净内核一个字节都不读 pathname */
 error = user_path_at(AT_FDCWD, pathname, ...);
```

同一个 `x1` 寄存器，在原生 truncate 里是 `length`，在 KP 里是 `cmd` 的低 16 位：

| 调用 | 干净内核 | 打了 KP（本机顺序） |
| ------------------------------------- | ---------------------- | ----------------------------------- |
| `syscall(45, x0=懒页, x1<0)` | 长度检查提前返回 `-EINVAL`，**不读 x0** | `before()` 读 x0（superkey 指针）⇒ 该页被换入 |
| `syscall(45, x0=懒页, x1≥0)` | `getname()` 会读 x0 | 同样会读 ⇒ **无差异** |
| `syscall(45, key串, x1=0x1010, x2=懒页)` | 只读 x0 | 鉴权通过后 `call_su` → `memdup_user` 读 x2 |

⇒ **侧信道只存在于 `x1 < 0` 这一种参数布局**：此时 x0 上发生的任何读取 / 换入都只可能来自 KP 的 superkey 读取（§1.1 的顺序是它的前提）。`x1 ≥ 0` 两边都读，检测器无法据此区分内核，因此那里必须**保持原生语义**（否则会破坏 `Read control` 对照）。

errno 本身就把"有没有读路径"区分开了：`x1 < 0` 走长度检查、返回 `-EINVAL`；`x1 ≥ 0` 才进 `user_path_at` / `getname`，路径读不到时返回 `-EFAULT`。同一个坏指针、两种 errno，正是"负 length 提前返回、压根没读 path"的体现。

### 1.4 三条判定通道

检测器（`com.chunqiunativecheck`，uid 10254）与公开文档涉及下面三条口径。它们针对同一个鉴权路径，可互相印证：

**① 懒分配页探测**

> 懒分配：用户态 `mmap` 一块匿名页后**从不触碰** → VMA 有了，PTE 还没有，物理页尚未分配。

把它的地址当作 superkey 指针放进 x0 发起鉴权请求，调用后看该页是否被映射到物理内存：

| 结果      | 含义          |
| ------- | ----------- |
| `0 → 0` | 内核没读过它      |
| `0 → 1` | 内核读了一次 ⇒ KP |

**② 鉴权时延探测**

检测器拟定一个**在范围内**的 cmd 与一个**不在范围内**的 cmd，分别发起多次、累加求和使比值稳定：

| 比值    | 判定   |
| ----- | ---- |
| `> 2` | KP 存在 |
| `≈ 1` | 无 KP |

这条口径成立的前提是"cmd 越界会提前返回"，即 §1.1 里**门控在密钥读取之前**的那一代 KP。本机走不到这个差异：密钥先读，且对非受信任调用者而言密钥不匹配就已经 `return`，cmd 取值影响不到执行路径 ⇒ 比值恒 `≈ 1`，该口径在本机不成立（见 §二 L4）。

**③ 系统调用参数页被额外读取（对照法）**

以"系统调用参数页被额外读取"为判据的侧信道。检测器把目标调用的参数/缓冲区放在一块受监控的用户页上，测量调用前后该页被内核读取的页数：

| 对照                              | 期望读数                           | 说明                          |
| ------------------------------- | ------------------------------ | --------------------------- |
| `No-read control`（内核按语义不应读该页） | `0 → 0 kB`                     | 基线                          |
| `Read control`（内核应当读该页）         | `0 → 4 kB`                     | 正对照，证明探针本身可用                |
| `Target call`（目标调用）             | 出现 `0 → 4 kB, unexpected read` | 内核在该 syscall 路径上**多读了一次用户内存** ⇒ 该路径被内核补丁额外处理 |

该条目同时会输出 `Argument layouts`（内核读取系统调用参数的寄存器布局探测）、多轮一致性 `Consistency: n/n`、`Page size`，以及 `Probe duration`（秒级，采样较重）。

> 与 `Abnormal Environment` 的关系：两者针对同一类"鉴权路径"侧信道。仓库里的 KSU/APatch 侧信道说明描述的是"**懒分配页是否被映射**"与"**鉴权时延比值**"两种口径；本条是按**页读取量做对照**的实现，属同一思路的不同变体，可互相印证。
>
> 口径换算：报告同时给出页数与 `Page size`（4096 B），所以 `0 → 4 kB` 就是 `0 → 1` 页。判据是"被监控页是否被换入 / 是否发生缺页"（等价 `min_flt` 增量），**不是 `smaps` 的 `Referenced` 口径**——被监控页是 `mmap` 后从未触碰的懒分配页，而 `Read control` 用一次"本来就该读该页"的调用作正对照。

---

## 二、对策

根因既然在"那次读会触发缺页"，对策就只有两条路：**(a) 让那次读不发生**，或 **(b) 把它换成不触发缺页的读**。(b) 需要改动 KP 自身（KPM 做不到，也无法让本机 KP 去试它主动跳过的 nofault），所以本模块走 (a)。

### L0｜槽位前置（必须最外层）

KP 的 supercall 钩子走 `hook_syscalln()` → `fp_wrap_syscalln()` → `fp_hook_wrap()`，在 hook 链的**槽 0**；链上的 before 回调按索引 `0→N` 顺序执行——晚装的挂钩只会落到槽 1，也就是**在 KP 之后**执行，等发现问题时页已经被读了。

因此本模块用框架 `fp_hook()` **直接接管 `sys_call_table[45]` 槽位**，把 KP 的链 transit 保存为 backup，正常路径原样调用（KP 功能零回归）。

### L1｜核心短路：让那次读根本不发生

```c
if (x1 < 0 && 调用者不在受信任白名单) return -EINVAL;
```

- **返回原生 errno**：干净内核对负 `length` 给的就是 `-EINVAL`，所以返回值**逐字节一致**，不会因"返回值不同"形成新指纹（返回 `-EFAULT` 反而是破绽）。
- **一个字节都不读 x0**：不建 PTE、不置 AF、不触发缺页，`min_flt` / `Referenced` 全无变化 ⇒ 通道 ① 与 ③ 同时失效。
- **不依赖线性映射标定、不依赖页表遍历**：`x1 < 0` 是纯寄存器判定，任何内核 / KP 变体上都成立，也不会因标定失败而静默失效。
- **零回归**：`x1 ≥ 0` 时完全不干预（原生 `getname` 本来就读 x0，KP 的读不增加任何新信号）⇒ `Read control` 对照不受影响；真实程序 `truncate(path, 负长度)` 在干净内核上同样是 `-EINVAL`，行为一致。

### L4｜时延均衡（对应通道 ②；默认关闭）

通道 ② 只在"cmd 越界会让 KP 提前返回"时才有信号。本机 KP 的 cmd 门控在密钥读取**之后**，且对非受信任调用者而言密钥不匹配就已在门控之前 `return`——cmd 取值影响不到执行路径，范围内 / 范围外两条路径同源 ⇒ **比值恒 `≈ 1`，本机该口径不成立**，故 L4 默认关闭（`eq=0`）。

它只为**门控在前**的那一代 KP 保留：那里越界分支会提前返回，与正常分支开销差明显。打开后只在越界分支补一次等长（`APK_EQ_LEN = 128`，等于 KP 的 `MAX_KEY_LEN`）的读取，让两条分支对齐。读取对象仍是 x0——该分支只在 `x1 ≥ 0` 时可达，而原生 `getname` 本来就会读 x0，所以这次读不产生任何新信号。

### 身份过滤：只对"该管的人"生效

| 门               | 依据                                                                | 作用                                                                    |
| --------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------- |
| **受信任 uid 白名单** | KP 导出的 `current_uid()`（KP 内部用运行时探测的 `task_struct→cred→uid` 偏移实现，模块侧无需硬编码偏移） | 默认 `{0}`；root / 管理器 / su 一律放行，普通应用 uid 才会被干预。`ctl0 allow=` 可调 |
| **管理器形态识别**     | 实测管理器 supercall 的 `x1 = 0xD0811581_XXXX`：**正数、高 32 位带自有非签名**，cmd 在低 16 位  | `x1` 高 32 位非 0 的调用**永不干预**，只做"读寄存器 + 原样转发"                             |
| **窗口 + 本任务绑定**  | 只有本模块负责的那次 syscall 正在执行、且就是当前任务时才成立                               | 让可选守卫（G1/G2/G3）的作用域严格受限                                               |

> 补充事实：`su` 走的是 execve 魔法路径，**根本不调用 `syscall(45)`**，因此与 `x1 < 0` 这条判定天然无关。

### 可选守卫 G1/G2/G3（默认全部关闭）

用于覆盖**其它**参数布局（x2 / x3 上的 `memdup_user`、KP 的字符串原语等）。每个都要求**四道门同时成立**：窗口内 + `apk_win_task == current` + 非受信任 uid + 遍历已被 oracle 证实。

- **G1**：`memdup_user` —— 源页不可无痕访问时返回**全 0 缓冲**（匿名懒页真实内容就是全 0，与真读该页逐字节等价，但不动页表、不产生缺页）；
- **G2**：`compat_strncpy_from_user` —— 源页不可无痕访问时返回 0（正是 KP `if (len <= 0) return;` 的"读不到"分支）；
- **G3**：`compat_copy_to_user` —— 写方向加固（默认关，误伤合法"尚未触碰的接收缓冲"有回归风险）。

**默认全部关闭**有两层原因：① 真实靶点（`x1 < 0`）已由 L1 覆盖，不需要它们；② 关掉后模块**不安装任何全局原语钩子**，系统级足迹只剩 `sys_call_table[45]` 一个槽位。需要覆盖别的布局时：先 `allow=0,<管理器uid>`，再 `g1=1` / `g2=1`。

---

### 春秋检测4.5.5检测到AP框架的词条
 ![图片描述](upload/attach/202609/1080117_6SEARQRPUGAPW6Q.webp)

## 通过KPM模块解决-提供现成的解决方案
【KPM模块】解决“发现APatch的鉴权密钥”模块
<a href="elink@7c4K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6x3N6h3&6Q4x3X3c8a6f1#2)9J5c8V1q4b7d9$3g2&6i4K6g2X3d9r3W2V1k6g2)9#2k6V1E0b7e0b7`.`.">【github开源仓库】030K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6x3N6h3&6Q4x3X3c8a6f1#2)9J5c8V1q4b7d9$3g2&6i4K6g2X3d9r3W2V1k6g2)9#2k6V1E0b7e0b7`.`.</a>

## 鸣谢
<a href="elink@34dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0K9h3&6Y4P5Y4g2F1x3o6W2Q4x3V1k6o6K9s2g2F1M7h3W2#2i4K6u0V1c8r3g2@1k6h3y4@1L8%4u0Q4x3X3c8b7M7X3!0T1L8r3g2E0i4K6u0V1M7$3!0D9N6i4c8A6L8$3&6Q4x3V1k6@1M7X3g2W2i4K6u0r3L8h3q4A6L8R3`.`.">【春秋NativeCheck】628K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0K9h3&6Y4P5Y4g2F1x3o6W2Q4x3V1k6o6K9s2g2F1M7h3W2#2i4K6u0V1c8r3g2@1k6h3y4@1L8%4u0Q4x3X3c8b7M7X3!0T1L8r3g2E0i4K6u0V1M7$3!0D9N6i4c8A6L8$3&6Q4x3V1k6@1M7X3g2W2i4K6u0r3L8h3q4A6L8R3`.`.</a>
<a href="elink@ba0K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3d9$3g2J5L8X3g2D9f1r3q4@1j5$3S2Q4x3V1k6@1M7X3g2W2i4K6u0r3x3K6f1J5k6r3f1K6y4K6b7%4y4U0V1K6k6o6b7H3x3$3g2T1x3h3p5@1j5X3b7J5j5K6V1^5k6r3x3H3y4r3q4W2j5U0l9I4z5e0f1#2j5b7`.`.">【KernelPatch】d1dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3d9$3g2J5L8X3g2D9f1r3q4@1j5$3S2Q4x3V1k6@1M7X3g2W2i4K6u0r3x3K6f1J5k6r3f1K6y4K6b7%4y4U0V1K6k6o6b7H3x3$3g2T1x3h3p5@1j5X3b7J5j5K6V1^5k6r3x3H3y4r3q4W2j5U0l9I4z5e0f1#2j5b7`.`.</a>
<a href="elink@45fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3b7g2m8S2N6r3y4Z5">【APatch及各分支版本】367K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3b7g2m8S2N6r3y4Z5</a>

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

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

最后于 3天前被Lun_OS编辑，原因：

#基础理论 #协议分析

收藏・6

点赞・58

打赏

赞赏记录

参与人

雪币

留言

时间

mb_qqlojqnm

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

10小时前

上网鱼

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

11小时前

dancheng

为你点赞！

13小时前

啦啦啦哈哈

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

2天前

nulles

为你点赞！

2天前

非法用户名

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

2天前

ChuXinﻬ.

为你点赞！

2天前

Sigil

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

2天前

MochaCo

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

2天前

bluegatar

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

2天前

疯子Tear

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

3天前

wx_Kiyose

为你点赞！

3天前

mb_rrvlrvbk

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

3天前

carlcurist

为你点赞！

3天前

Ms135

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

3天前

feng504x

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

4天前

Yves Luo

非常支持你的观点！

4天前

sfl4800

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

4天前

xjohjrdy

非常支持你的观点！

4天前

Je2em1ah

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

4天前

LLeaves

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

4天前

qianlan

非常支持你的观点！

4天前

孤独的街

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

4天前

ngiokweng

非常支持你的观点！

4天前

微笑:)

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

4天前

教教我吧~

为你点赞！

4天前

ONewTach

非常支持你的观点！

4天前

nonovo

为你点赞！

4天前

4ak5ra

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

4天前

Antigone

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

4天前

mb_liueenqt

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

4天前

cr_lgdx

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

4天前

mb_bvvcoitr

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

5天前

mb_rjdrqvpa

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

5天前

逆向小玖

为你点赞！

5天前

wx_妳还是不懂

为你点赞！

5天前

醉染

非常支持你的观点！

5天前

Kare-chen

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

5天前

熊猫人大A

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

5天前

Wika

非常支持你的观点！

5天前

mb_iesvmzqc

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

5天前

k423

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

5天前

欲拭泪

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

5天前

顽劣

非常支持你的观点！

5天前

mb_bppcorlj

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

5天前

寻影星尘

非常支持你的观点！

5天前

mb_yvuzbfvo

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

5天前

doduhuang

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

5天前

Yu4n

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

5天前

mb_cfjwplfo

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

5天前

git_21210wzzzh2025

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

5天前

梧桐生

为你点赞！

5天前

mb_oatdtlak

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

5天前

juice4fun

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

5天前

mb_qtvylfog

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

5天前

huangyalei

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

5天前

令狐双

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

5天前

git_51951meggadf3df

非常支持你的观点！

5天前

最新回复 (33) 1 2 ▶
git_21210wzzzh2025 雪币： 2464 活跃值： (3737) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 18 粉丝 23 关注私信	git_21210wzzzh2025 2 楼学习 5天前 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 3 楼 666 5天前 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 4 楼 666 5天前 0
寻梦之璐雪币： 764 活跃值： (3827) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 170 粉丝 16 关注私信	寻梦之璐 5 楼 66 5天前 0
k4y0z 雪币： 313 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 143 粉丝 1 关注私信	k4y0z 6 楼 666 5天前 0
万神fake 雪币： 48 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 73 粉丝 3 关注私信	万神fake 7 楼谢谢楼主分享 5天前 0
xingbing 雪币： 158 活跃值： (5651) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1373 粉丝 2 关注私信	xingbing 8 楼学习 5天前 0
夜惜风雨雪币： 95 活跃值： (3662) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 152 粉丝 0 关注私信	夜惜风雨 9 楼 666666666 5天前 0
Imxz 雪币： 112 活跃值： (9405) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 750 粉丝 9 关注私信	Imxz 10 楼 tql 5天前 0
xianhuimin 雪币： 9281 活跃值： (6143) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 226 粉丝 2 关注私信	xianhuimin 11 楼看看 5天前 0
lbunknow 雪币： 24 活跃值： (652) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 54 粉丝 0 关注私信	lbunknow 12 楼 666 5天前 0
简biu 雪币： 165 活跃值： (393) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 9 粉丝 1 关注私信	简biu 13 楼看看 5天前 0
mb_bvvcoitr 雪币： 30 活跃值： (1511) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 24 粉丝 6 关注私信	mb_bvvcoitr 14 楼 4.19-才有这个问题，此外这个是两年前的牛头检测发明的，不知道为啥现在还没修 5天前 0
mb_bvvcoitr 雪币： 30 活跃值： (1511) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 24 粉丝 6 关注私信	mb_bvvcoitr 15 楼看了看是这个提交的问题：bfbK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3d9$3g2J5L8X3g2D9f1r3q4@1j5$3S2Q4x3V1k6U0L8$3#2E0K9i4c8Q4x3V1k6W2k6U0b7K6y4h3x3@1k6U0W2W2y4e0x3%4k6U0j5H3x3K6c8T1j5U0c8S2x3e0x3^5y4e0V1H3x3o6t1H3x3o6x3#2k6e0b7K6y4U0b7J5i4K6t1$3L8X3u0K6M7q4)9K6b7W2!0q4y4q4!0n7z5g2)9^5b7W2!0q4y4g2)9^5z5g2)9^5c8q4!0q4y4W2)9&6z5q4!0m8c8W2!0q4y4g2!0m8y4g2!0n7c8q4!0q4y4#2)9&6b7g2)9^5y4q4!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5g2)9&6y4#2!0m8c8g2!0q4y4q4!0n7b7g2)9^5y4W2!0q4y4q4!0n7z5q4)9^5b7W2!0q4z5q4!0m8c8W2!0n7y4q4!0q4y4W2)9&6z5q4!0m8c8V1I4f1e0#2!0q4y4g2!0m8c8W2!0n7b7#2!0q4z5q4)9^5y4#2!0n7y4q4!0q4y4W2)9^5z5g2!0n7c8g2!0q4y4q4!0n7z5q4)9^5c8q4!0q4y4g2)9^5z5q4!0n7x3q4!0q4y4#2!0m8b7#2!0m8y4W2!0q4y4g2)9^5c8W2!0n7y4H3`.`. 最后于 4天前被mb_bvvcoitr编辑，原因： 4天前 0
kingking888 雪币： 3146 活跃值： (6197) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 288 粉丝 6 关注私信	kingking888 16 楼 666 4天前 0
九黎雪币： 51 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 92 粉丝 0 关注私信	九黎 17 楼 666 4天前 0
huangjw 雪币： 6679 活跃值： (11862) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 510 粉丝 2 关注私信	huangjw 18 楼研究的真好 4天前 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 137 粉丝 0 关注私信	Zepp7289 19 楼 tql 4天前 0
iBa0 雪币： 1560 活跃值： (5833) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 482 粉丝 37 关注私信	iBa0 20 楼 666 4天前 0
guijingwen 雪币： 7325 活跃值： (7510) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 304 粉丝 0 关注私信	guijingwen 21 楼 66 4天前 0
lrhtony 雪币： 1366 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 1 关注私信	lrhtony 22 楼 66 4天前 0
mb_dzcyptxm 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_dzcyptxm 23 楼刚刚好需要 4天前 0
liowmark 雪币： 161 活跃值： (1233) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 40 粉丝 5 关注私信	liowmark 24 楼 666 4天前 0
Lun_OS 雪币： 534 活跃值： (75) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 3 粉丝 8 关注私信	Lun_OS 25 楼 mb_bvvcoitr 4.19-才有这个问题，此外这个是两年前的牛头检测发明的，不知道为啥现在还没修实测6.12也会有，≤ 6.7.0基本都有 AP的ef435c4提交compat_strncpy_from_user() 函数中 if (kver > VERSION(6, 7, 0)) { kfunc_call(strncpy_from_user_nofault, dest, src, count); kfunc_call(strncpy_from_unsafe_user, dest, src, count); } 只有当内核版本高于 6.7.0 时，才会尝试 nofault 原语但也不是小于这个版本就一定会出现这个，还得其他相关因素最后于 4天前被Lun_OS编辑，原因： 4天前 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

Lun_OS

发帖

回帖

RANK

关注

私信

他的文章

[原创]安卓APatch Root方案compat的nofault回退导致被检测 2621

关于我们

联系我们

企业服务

看雪公众号

最新回复 (33) 1 2 ▶
git_21210wzzzh2025 雪币： 2464 活跃值： (3737) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 18 粉丝 23 关注私信	git_21210wzzzh2025 2 楼学习 5天前 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 3 楼 666 5天前 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 4 楼 666 5天前 0
寻梦之璐雪币： 764 活跃值： (3827) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 170 粉丝 16 关注私信	寻梦之璐 5 楼 66 5天前 0
k4y0z 雪币： 313 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 143 粉丝 1 关注私信	k4y0z 6 楼 666 5天前 0
万神fake 雪币： 48 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 73 粉丝 3 关注私信	万神fake 7 楼谢谢楼主分享 5天前 0
xingbing 雪币： 158 活跃值： (5651) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1373 粉丝 2 关注私信	xingbing 8 楼学习 5天前 0
夜惜风雨雪币： 95 活跃值： (3662) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 152 粉丝 0 关注私信	夜惜风雨 9 楼 666666666 5天前 0
Imxz 雪币： 112 活跃值： (9405) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 750 粉丝 9 关注私信	Imxz 10 楼 tql 5天前 0
xianhuimin 雪币： 9281 活跃值： (6143) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 226 粉丝 2 关注私信	xianhuimin 11 楼看看 5天前 0
lbunknow 雪币： 24 活跃值： (652) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 54 粉丝 0 关注私信	lbunknow 12 楼 666 5天前 0
简biu 雪币： 165 活跃值： (393) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 9 粉丝 1 关注私信	简biu 13 楼看看 5天前 0
mb_bvvcoitr 雪币： 30 活跃值： (1511) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 24 粉丝 6 关注私信	mb_bvvcoitr 14 楼 4.19-才有这个问题，此外这个是两年前的牛头检测发明的，不知道为啥现在还没修 5天前 0
mb_bvvcoitr 雪币： 30 活跃值： (1511) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 24 粉丝 6 关注私信	mb_bvvcoitr 15 楼看了看是这个提交的问题：bfbK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3d9$3g2J5L8X3g2D9f1r3q4@1j5$3S2Q4x3V1k6U0L8$3#2E0K9i4c8Q4x3V1k6W2k6U0b7K6y4h3x3@1k6U0W2W2y4e0x3%4k6U0j5H3x3K6c8T1j5U0c8S2x3e0x3^5y4e0V1H3x3o6t1H3x3o6x3#2k6e0b7K6y4U0b7J5i4K6t1$3L8X3u0K6M7q4)9K6b7W2!0q4y4q4!0n7z5g2)9^5b7W2!0q4y4g2)9^5z5g2)9^5c8q4!0q4y4W2)9&6z5q4!0m8c8W2!0q4y4g2!0m8y4g2!0n7c8q4!0q4y4#2)9&6b7g2)9^5y4q4!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5g2)9&6y4#2!0m8c8g2!0q4y4q4!0n7b7g2)9^5y4W2!0q4y4q4!0n7z5q4)9^5b7W2!0q4z5q4!0m8c8W2!0n7y4q4!0q4y4W2)9&6z5q4!0m8c8V1I4f1e0#2!0q4y4g2!0m8c8W2!0n7b7#2!0q4z5q4)9^5y4#2!0n7y4q4!0q4y4W2)9^5z5g2!0n7c8g2!0q4y4q4!0n7z5q4)9^5c8q4!0q4y4g2)9^5z5q4!0n7x3q4!0q4y4#2!0m8b7#2!0m8y4W2!0q4y4g2)9^5c8W2!0n7y4H3`.`. 最后于 4天前被mb_bvvcoitr编辑，原因： 4天前 0
kingking888 雪币： 3146 活跃值： (6197) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 288 粉丝 6 关注私信	kingking888 16 楼 666 4天前 0
九黎雪币： 51 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 92 粉丝 0 关注私信	九黎 17 楼 666 4天前 0
huangjw 雪币： 6679 活跃值： (11862) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 510 粉丝 2 关注私信	huangjw 18 楼研究的真好 4天前 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 137 粉丝 0 关注私信	Zepp7289 19 楼 tql 4天前 0
iBa0 雪币： 1560 活跃值： (5833) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 482 粉丝 37 关注私信	iBa0 20 楼 666 4天前 0
guijingwen 雪币： 7325 活跃值： (7510) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 304 粉丝 0 关注私信	guijingwen 21 楼 66 4天前 0
lrhtony 雪币： 1366 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 1 关注私信	lrhtony 22 楼 66 4天前 0
mb_dzcyptxm 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	mb_dzcyptxm 23 楼刚刚好需要 4天前 0
liowmark 雪币： 161 活跃值： (1233) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 40 粉丝 5 关注私信	liowmark 24 楼 666 4天前 0
Lun_OS 雪币： 534 活跃值： (75) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 3 粉丝 8 关注私信	Lun_OS 25 楼 mb_bvvcoitr 4.19-才有这个问题，此外这个是两年前的牛头检测发明的，不知道为啥现在还没修实测6.12也会有，≤ 6.7.0基本都有 AP的ef435c4提交compat_strncpy_from_user() 函数中 if (kver > VERSION(6, 7, 0)) { kfunc_call(strncpy_from_user_nofault, dest, src, count); kfunc_call(strncpy_from_unsafe_user, dest, src, count); } 只有当内核版本高于 6.7.0 时，才会尝试 nofault 原语但也不是小于这个版本就一定会出现这个，还得其他相关因素最后于 4天前被Lun_OS编辑，原因： 4天前 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复