[原创]仅使用NDK构建内核模块的实验-Android安全-看雪安全社区

# 仅使用NDK构建Android内核模块的实践

原理分析见原创文章《把.o变为.ko》系列，以下是速通版：

## 一、insmod 的三扇门

知己知彼，方能百战不殆 —— 当我们使用insmod安装内核模块时，linux内核到底校验了什么？

这个问题只能从内核源码得到详细答案，由于分析过长，这里只给出摘要。

### 1. ELF格式 —— 你的文件"看起来像"一个内核模块吗？

内核到底期望什么二进制？可执行、动态库 or 对象文件？

这里让我们来看.ko加载时期待的section:

```
内核要求的 .ko
──────────────
.text 
.data 
.rodata 
.symtab 
.modinfo                    ← "这个模块叫啥名、什么license"
__versions                  ← "struct module 长什么样"
.gnu.linkonce.this_module   ← 模块结构体本体

```

毫无疑问，最接近这种格式要求的ELF文件格式就是.o对象文件，但是二者存在差异：

```
普通 .o              内核要求的 .ko
───────              ──────────────
.text ✓              .text ✓
.data ✓              .data ✓
.rodata ✓            .rodata ✓
.symtab ✓            .symtab ✓
❌ 没有 modinfo      .modinfo ✓        ← "这个模块叫啥名、什么license"
❌ 没有 __versions   __versions ✓      ← "struct module 长什么样"
❌ 没有 this_module  .gnu.linkonce.this_module ✓  ← 模块结构体本体
```

为了解决这个问题，我们引入一阶段修补工程 —— KPatcher，它负责（KPatcher.cpp:46-136）：

```
输入: loader_merged.o  (普通 ET_REL)
  ↓ LIEF 库解析 ELF
  ↓ ElfConverter 分析 section/符号/重定位
  ↓ KoWriter 写入 .ko — 补上 modinfo、__versions、this_module
输出: loader.ko  (内核认可的模块的模板)
```

1. 去除.o文件中的无用段（即不在内核加载器需要的段类型范围内的段）。
2. 补充.gnu.linkonce.this_module段，分配2048字节空白空间，在偏移24字节处写入name。
3. 补充.modinfo段，填充模块元数据，其中vermagic仅作占位，import_ns命名空间默认设置为VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver。
4. 补充__versions，预留64字节空间。
5. 补充三个12字节 SHT_NOBITS section：.plt、.init.plt、.text.ftrace_trampoline：内核要求这三个section存在，如果这三个 section 用 SHT_PROGBITS（有实际内容），内核会在模块旁边分配独立内存页，跟相邻 section 权限冲突，触发 Gunyah（type-2 虚拟化）的 stage-2 缺页异常。
6. 追加 build-id：MTK 特有的坑，MTK 的 mrdump（内核崩溃转储工具）和 module_sysfs 假设所有模块都有 SHF_ALLOC 的 NOTE section。没有的话空指针解引用，崩，故追加一个 .note.gnu.build-id section
7. 重新映射section索引：经过刚才的处理，section索引全变了，需要重新映射。
8. 注入this_module的重定位：struct module 里有两个函数指针字段：init_module的地址、cleanup_module的地址，他们需要在加载后被内核的加载器重定位为绝对地址，需要增加两项Relocation。
9. 最后写出.ko模板文件，等待fixup上机完成下一步修补。

注：namespace — Linux 把内核导出符号分了"房间"，普通驱动不能随便访问内部符号。-N VFS_internal_... 就是告诉内核"我获得了这个房间的访问授权"。

### 2. vermagic —— "你是我这个内核版本编译的吗？"

这是fixup需要填充的第一个地方，fixup根据真机上已经存在的.ko文件，提取vermagic，回填到KPatcher留下的位置（vermagic占位符）。

注：其实android内核不是很在意内核版本，比如`5.10.198-android12-9-g12345678 SMP preempt mod_unload aarch64`，android内核实际关注的是`SMP preempt mod_unload aarch64`，内核版本`5.10.198-android12-9-g12345678`则无所谓。猜测这与android的内核映像和设备高度绑定不能更新，但是系统可以更新有关。

### 3. module_layout CRC — "struct module 的结构体布局跟我一样吗？"

即使内核版本相同，编译选项不同也会导致 struct module 内部的字段偏移不同。内核用 __versions 里的 CRC 校验这个。fixup将从真机上的.ko提取其CRC值并填入__versions。

为了解决2、3，我们引入了fixup负责通过真机上的.ko文件修补KPatcher生成的模块.ko:

1. 修补vermagic：见上。
2. 修补CRC：见上。
3. 替换struct module：先保存模板.ko文件中.gnu.linkonce.this_module中的name。把真机.ko文件.gnu.linkonce.this_module的内容直接拷贝到模板预留的2048字节空位中，更新 section header 的 sh_size = 参考大小。动态定位 name 字段偏移，搜不到就用默认值（64-bit: 24, 32-bit: 16），重新把name改回模板中的name。
4. 修正重定位偏移：扫描真机.ko文件的.rela.gnu.linkonce.this_module里的所有重定位，只收集 STT_FUNC 类型的（函数指针），按 offset 排序，第一个 = init_module，第二个 = cleanup_module。如果参考 .ko 没有 exit 重定位，保留目标原有的 exit 偏移不动，不要清零，否则模块变为 [permanent] ， rmmod 返回 EBUSY。按照获得的偏移修正重定位偏移。
5. 注入 kallsyms 地址：程序里埋了一个 32 字节的魔术字符串，fixup_ko 在 .ko 文件里扫描这个 marker，把 kallsyms_lookup_name 的真实地址写进去。运行时向/proc/sys/kernel/kptr_restrict写入0，读取/proc/kallsyms，获取kallsyms_lookup_name地址。

## 二、运行时的安全特性CFI

### 1. 控制流完整性校验

Android 内核开启了 CFI（Control Flow Integrity，控制流完整性），在真的执行你的代码之前，验证你的函数指针没有被篡改。它的逻辑很简单：

```
正常调用：                          攻击者篡改后：
  func_ptr = &合法的函数            func_ptr = &恶意代码
  内核检查：这个地址是我认识的吗？   内核检查：不认识！→ 崩
```

但是5.x内核和6.x内核的具体检验策略是不同的，想象机场安检：

- 5.x（Shadow CFI）：安检员拿你的护照，去后台数据库查"这个人合法吗"
- 6.x（kCFI）：护照里嵌了芯片，读卡器一扫就知道真伪

技术上：

```
5.x Shadow CFI（clang 12-17）：                 6.x kCFI（clang 18+）：
                                             
  调用 func_ptr(x)                              调用 func_ptr(x)
    ↓                                            ↓
  __cfi_slowpath(id, ptr)  ← 拦截               ldr w16, [x16, #-4]  ← 读函数前4字节
    ↓                                            ↓
  查跳转表: {hash → stub → func}                cmp w16, #期望的hash  ← 芯片比对
    ↓                                            ↓
  匹配 → 执行  不匹配 → 崩                       匹配 → 执行  不匹配 → __kcfi_trap → 崩

```

关键区别：

- 5.x：检查靠外部跳转表，hash 存在另一个 section
- 6.x：检查靠嵌入在函数前面的 4 字节 hash，读取 func_addr - 4

### 2. 伪造的 __cfi_check 函数（cfi_entry_stubs.S:29-73）：

内核调用 init_module() 时会被拦下，然后调用模块注册的 __cfi_check 问"这个函数安全吗？"。这里我们手工构造函数：

```
__cfi_check:
    # 检查传入的 hash 是不是 init_module 或 cleanup_module 的
    cmp x0, #init_module的hash      # 调用者期望的类型对吗？
    b.eq check_which_target         # 对 → 继续检查目标地址
    cmp x0, #cleanup_module的hash
    b.eq check_which_target
    b   fail                        # 都不对 → 失败

check_which_target:
    # 目标地址是我们的 init_module / cleanup_module 吗？
    cmp x1, init_module_addr
    b.eq accept                     # 是 → 放行
    cmp x1, cleanup_module_addr  
    b.eq accept
    b   fail                        # 不是 → 失败

accept: ret                         # ✅ 放行
fail:   b   __cfi_check_fail        # ❌ 拒绝
```

翻译成人话："不管来什么 hash，只要目标地址是我认识的，就通过。"

### 3. 跳转表（cfi_entry_stubs.S:88-114）：

跳转表结构：

```
┌──────────────────────────┐
│ .word hash (4字节)       │ ← 跟调用者传来的 hash 比对
│ cleanup_module:          │ ← 内核可见的符号，真正的入口
│   b cleanup_module_impl  │ ← 跳到 loader.c 里真正干活的函数
└──────────────────────────┘
```

但跳转表结构不只是给 5.x 用的。那 4 字节 hash 同时服务了 6.x。

### 4. 为 6.x 注入 kCFI Hash：

6.x 不用跳转表了，它直接读函数地址前 4 字节。问题是：这 4 字节必须是 clang 亲自生成的，不能自己编。于是有了偷 hash 的流水线。

#### 第一步：让 clang 生成 hash

```
// kcfi_hash_probe.c — 用 -fsanitize=kcfi 编译
int init_module(void) { return 0; }
void cleanup_module(void) { }
```

#### 第二步：从编译产物里偷出来

```
# extract_kcfi_prefix.py
# 解析 kcfi_hash_probe.o 的 ELF 符号表
# 找到 init_module 的地址（比如 section 内偏移 0x10）
# kCFI hash 在函数代码前 4 字节（0x10 - 4 = 0x0C）
prefix = struct.unpack("<I", section_data[addr - 4 : addr])[0]
# cleanup_module: 0xa540670c
# init_module:    0x36b1c5a6
```

生成汇编文件：

```
// kcfi_prefix_gen.S（自动生成）
.section .kcfi_prefix.cleanup,"ax",@progbits
.word 0xa540670c

.section .kcfi_prefix.init,"ax",@progbits
.word 0x36b1c5a6
```

#### 第三步：链接脚本精确排列

linker_dual.lds 把前两步产物按精确顺序排进 .text section。内存布局最终变成：

```
0x2048: [4字节] 0xA540670C     ← .text..L.cfi.jumptable (跳转表里的 .word)
0x204C: cleanup_module:        ← 内核可见的符号
            b cleanup_module.cfi
0x2058: [4字节] 0x36B1C5A6     ← .text..L.cfi.jumptable.1
0x205C: init_module:           ← 内核可见的符号
            b init_module.cfi

0x2050: [4字节] 0xA540670C     ← .kcfi_prefix.cleanup (独立前缀)
0x2054: cleanup_module.cfi:    ← 中间 stub，只被 b 指令直接跳转
            b cleanup_module_impl
```

6.x 内核的 kCFI 检查读 cleanup_module - 4 = 跳转表 hash（0xA540670C），匹配，通过。

注：细看会发现 kcfi_prefix.cleanup 里的 hash 和跳转表里的 hash 完全一样。但内核只读跳转表 hash。原因是 kcfi_prefix.cleanup 紧贴在 cleanup_module.cfi 这个符号前面——而内核从不间接调用 cleanup_module.cfi，它只被 cleanup_module: 以 b 指令直接跳转。直接跳转不触发 kCFI。所以这个 hash 实际上从未被读取——它是第一版开发时留下的冗余保险，属于不影响功能的历史残留。

### 5. 运行时放行 KPM 函数指针

前面解决的只是 loader.ko 自身通过 insmod 时的 CFI 检查。但 loader 加载的 KPM（内核补丁模块）是用普通 clang 编译的，没有任何 CFI 保护。loader 通过函数指针调用 KPM 代码时，还是会撞 CFI。

于是 loader 在内核内部做了一次"安检豁免权申请"——hook 内核的 CFI 基础设施：

```
// loader.c
static void replace__cfi_slowpath(u64 id, void *ptr, void *diag)
{
    if (ptr 在 KPM 内存区域内)
        return;                              // 放行，不检查
    backup__cfi_slowpath(id, ptr, diag);     // 否则交给原始检查
}
```

同时把 CFI 失败的处理从 crash 降级为 warn：

```
do_hook(__cfi_slowpath, replace__cfi_slowpath, &backup);
do_hook(report_cfi_failure, replace_report_cfi_failure, &backup);
```

这样一来 loader.ko 自身的 insmod 走编译时伪造的跳转表 / kCFI hash，而它加载的 KPM 走运行时的 check 豁免，两套机制各司其职。

我也不知道这个技术有什么用，也许可以用于RootKit，目前只在5.10.198和6.13.4内核进行过测试。
下面介绍实践的成品：

## 1. KPatcher

项目地址：<a href="elink@304K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Y4k6$3N6Y4L8h3I4D9L8r3I4Q4x3V1k6w2f1r3q4@1j5$3S2W2M7R3`.`.">KPatcher</a>

他负责将NDK编译生成的.o文件修补为待填充的.ko文件。

## 2. NDK_Kernel_Module

项目地址：<a href="elink@407K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Y4k6$3N6Y4L8h3I4D9L8r3I4Q4x3V1k6z5c8p5E0Q4y4h3k6w2k6i4u0F1k6h3I4Q4y4h3k6y4L8$3c8#2L8r3f1`.">NDK_Kernel_Module</a>

相当于工程模板，很多构建配置已经设置了好了，也提供了有用的头文件，loader文件夹内是一个使用这套工程模板的实例。
在设备上使用时需要配合fixup_ko，用于获取设备上正常内核模块来完成对于待填充的.ko文件的最后修补（注：如果设备不支持kprobe，每次重启需要未修补的Loader.ko使用fixup_ko重新修补）。
loader本身是使用它构建的kpm加载器（但是兼容不全），依靠448号syscall与用户空间通信，且带有根据文件中配置的uid来关闭指定app的seccomp的功能（不然没办法用448号syscall）。

## 3. NDK_SIMPLE_KPM

项目地址：<a href="elink@e97K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Y4k6$3N6Y4L8h3I4D9L8r3I4Q4x3V1k6z5c8p5E0Q4y4h3k6e0d9f1#2b7e0p5g2Q4y4h3k6w2f1p5@1`.">NDK_SIMPLE_KPM</a>

loader支持的kpm构建模板，已装好构建配置和头文件。
目前src目录下是我修改的pte无痕hook实现作为使用示例，可以改成别的东西。

虽然理论上兼容很多设备，但暂时不能保证所有内核都可使用（悲）。
ptehook会莫名其妙崩溃，欢迎大佬提交修复！

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

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-6-25 01:33 被孤木落编辑，原因：

#基础理论 #NDK分析 #程序开发 #HOOK注入 #系统相关 #源码框架 #工具脚本

最新回复 (21)
温泉划水鱼雪币： 94 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 226 粉丝 28 关注私信	温泉划水鱼 2 楼都是熬夜大神 2026-6-25 02:15 0
mb_qimctavn 雪币： 5327 活跃值： (6780) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 401 粉丝 1 关注私信	mb_qimctavn 3 楼 6 2026-6-25 07:29 0
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 126 粉丝 0 关注私信	Gryffindoss 4 楼 66666 2026-6-25 09:41 0
Imxz 雪币： 110 活跃值： (9571) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 775 粉丝 9 关注私信	Imxz 5 楼 tql 2026-6-25 15:30 0
k4y0z 雪币： 325 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 144 粉丝 1 关注私信	k4y0z 6 楼 666 2026-6-25 15:33 0
mb_jnmxfjku 雪币： 109 活跃值： (820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_jnmxfjku 7 楼 111 2026-6-25 16:38 0
夜惜风雨雪币： 95 活跃值： (3767) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 155 粉丝 0 关注私信	夜惜风雨 8 楼 666666666666 2026-6-25 23:48 0
mb_urzqsoer 雪币： 206 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 121 粉丝 0 关注私信	mb_urzqsoer 9 楼 66666666666666 2026-6-26 00:40 0
mb_euhyowpw 雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 152 粉丝 0 关注私信	mb_euhyowpw 10 楼 666 2026-6-26 09:28 0
huangjw 雪币： 6747 活跃值： (11957) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 514 粉丝 2 关注私信	huangjw 11 楼 2026-6-26 09:31 0
wx_晚风_407 雪币： 19 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 24 粉丝 0 关注私信	wx_晚风_407 12 楼 666666666 2026-6-28 18:18 0
XCicada 雪币： 3103 活跃值： (2705) 能力值： ( LV6，RANK：80 ) 在线值：发帖 3 回帖 324 粉丝 101 关注私信	XCicada 2 13 楼 666666666 2026-6-28 18:26 0
mb_ajqftfbv 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 16 粉丝 0 关注私信	mb_ajqftfbv 14 楼 666666666 2026-6-29 02:23 0
4Chan 雪币： 375 活跃值： (4087) 能力值： ( LV3，RANK：30 ) 在线值：发帖 9 回帖 202 粉丝 12 关注私信	4Chan 15 楼 66666666666 2026-6-29 15:15 0
木魚· 雪币： 947 活跃值： (1021) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 34 粉丝 1 关注私信	木魚· 16 楼 666666666666 2026-6-30 15:27 0
zz胡雪币： 1049 活跃值： (1869) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 103 粉丝 1 关注私信	zz胡 17 楼 6666666666666 2026-7-1 15:52 0
iBa0 雪币： 1901 活跃值： (5928) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 490 粉丝 37 关注私信	iBa0 18 楼 111 2026-7-2 21:42 0
wx_kx92911 雪币： 0 活跃值： (370) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 63 粉丝 0 关注私信	wx_kx92911 19 楼感谢分析 2026-7-9 09:52 0
Thehepta 雪币： 3601 活跃值： (7420) 能力值： ( LV11，RANK：185 ) 在线值：发帖 23 回帖 240 粉丝 283 关注私信	Thehepta 3 20 楼 1 2026-7-15 10:01 0
simpleness 雪币： 6 活跃值： (802) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 34 粉丝 0 关注私信	simpleness 21 楼 6 2026-7-15 18:54 0
uni7corn 雪币： 0 活跃值： (2485) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 182 粉丝 0 关注私信	uni7corn 22 楼 6666 2026-7-20 17:53 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复