本文是系列第二篇。第一篇讲述了如何通过 ELF 格式转换，将用户空间编译产物变成可被内核识别的 .ko 文件，并踩平了前 13 个坑。

本篇继续在 ARM64 Android GKI 设备上的实战 —— 当基础格式正确之后，真正的战斗才刚开始。

完成基础 ELF 转换后，我们得到了一份格式上合法的 .ko 文件，并在 x86 Kali 环境中成功实现加载。

信心满满地推送到目标设备：

结果 insmod 直接甩回来一个让人摸不着头脑的错误。

文件明明存在，且可读。ls -l 检查权限正常。dmesg 没有任何输出。strace insmod 到关键系统调用时直接返回：

这个问题与 ELF 格式无关，完全是 Android 安全机制在起作用。

Android 对 /data/local/tmp/ 目录应用了严格的 SELinux 文件上下文限制。

insmod 在执行 finit_module() 系统调用之前，需要访问 .ko 文件，而 SELinux 在这种情况下会拒绝访问。

为了不暴露攻击面信息，Android 的 SELinux 错误码映射策略将本该返回的 EACCESS 转换成了 EEXIST —— 一个经典的反侦察设计。

即使你已经 su 到 root，SELinux 仍会介入。因为 root 用户的行为也受安全策略约束。

临时关闭 SELinux 是验证阶段最快的途径：

之后 insmod 得以进入内核加载流程。

生产环境可考虑将模块放置于 SELinux 豁免路径，例如：

在 Kali Linux x86_64 上验证通过的 .ko，推送到 ARM64 Android 设备后：

dmesg 输出 vermagic 不匹配。

但我们明明已经从参考 .ko 中提取了 vermagic 并覆写，为什么还是不对？

内核的 vermagic 校验由 same_magic() 完成：

关键逻辑如下：

如果模块不包含 __versions 段，即 has_crcs == false→ 完整字符串比对，版本号和后缀都参与。

如果模块包含 __versions 段，即 has_crcs == true→ 跳过第一个空格前缀，也就是版本号，只比对后缀。

我们的 .ko 是带 __versions 段的，所以理论上版本号不同没关系。

但问题在于 Kali 和 Android 的后缀不同：

Android 多了 aarch64 架构标识。

后缀不匹配，strcmp 直接失败，内核返回 -ENOEXEC，用户空间显示：

至于为什么修补没生效 —— 那是开发流程问题：fixup_ko 的编译产物是旧的，还没包含 vermagic 覆写逻辑。重新编译即可。

带 __versions 的模块，内核不关心版本号前缀，但后缀必须精确匹配。

后缀由十几个 CONFIG_ 宏拼装而成，包含：

跨设备、跨架构时，必须从目标设备的参考 .ko 中完整提取后缀，不能复用开发机的值。

越过 SELinux 和 vermagic 之后，模块终于进入了内核加载器的内部路径。

但迎接它的是更底层的 ARM64 安全机制 —— 这些特性由 CPU 和编译器联合强制执行。

BTI 全称为 Branch Target Identification。

insmod 正常返回 0，但设备紧跟着直接重启。

从 pstore 中提取的崩溃日志显示，CPU 在 init_module 入口处触发了：

ARMv8.5 引入了 BTI 硬件强制保护。

当一个间接跳转发生时，例如：

CPU 会检查目标地址的第一条指令是否为合法的 BTI 着陆指令。

常见 BTI 着陆指令包括：

若目标地址没有合法 BTI 指令，CPU 会立即触发异常。

内核通过页表中的 GP，也就是 Guarded Page 位控制 BTI 的使能。

当开启：

module_enable_text_rox() 在设置模块 .text 段为可执行时，会顺便通过 PTE_MAYBE_GP 设置 GP 位：

这意味着一旦 GP 位置位，该段任何间接跳转的目标都必须经过 BTI 校验。

内核调用模块初始化函数是通过函数指针完成的：

这是一个间接调用。

我们的测试代码使用普通 NDK Clang 编译，默认不生成 BTI 着陆指令。

在 GP 位打开的情况下，CPU 发现 init_module 的头指令不是：

于是产生 Target Branch Exception，最终导致 kernel panic。

必须告诉编译器生成 BTI 兼容代码：

-mbranch-protection=standard 会在每个可被间接调用的函数开头生成：

同时它还会启用 PAC，也就是下一个坑的主角。

PAC 全称为 Pointer Authentication。

BTI 修复后，设备依然在加载模块时重启。

这次崩溃点发生在函数返回时，而非入口。

ARMv8.3 引入了 PAC，用于保护函数返回地址的完整性。

在函数入口，用栈指针 SP 作为 modifier 对返回地址 LR 进行签名：

在函数出口，再用：

验证签名。

若签名不通过，则触发 Authentication Fault，直接终止执行。

内核开启：

后，所有内核代码都使用 PAC。

模块代码如果不同步启用 PAC，就会出现这样的场景：

关键约束是：模块与内核的 PAC 密钥必须一致。

这个一致性通过都使用同一编译选项生成相同的指令序列来保证。

与 BTI 完全相同：

-mbranch-protection=standard 同时生成 BTI 和 PAC 指令，一根编译选项解决两者。

SCS 全称为 Shadow Call Stack。

当开启：

内核会启用影子调用栈。

SCS 使用 x18 寄存器保存一个独立于正常栈的返回地址链。

在静态 SCS 实现下，也就是：

所有内核代码都必须遵守 SCS 规约，即不能随意使用 x18 寄存器。

任何对 x18 的写操作都会破坏影子调用栈，导致诡异的返回地址错误。

由于 KPM 编译时使用了与内核兼容的 Clang，并传递了：

该选项会隐式启用 SCS 指令生成，因此这个坑被自动绕过。

但还需注意：

若以后使用手写汇编，必须保留 x18 作为 SCS 指针的约定，否则会一脚踩进去。

CFI 全称为 Control Flow Integrity。

BTI 和 PAC 两关打通后，模块加载仍导致重启。

pstore 日志显示：

我们终于触碰到了 Android GKI 最核心的安全机制：CFI。

内核 Makefile 中声明使用：

kCFI 的原理是：

每个可间接调用函数的入口前 4 字节保存一个类型哈希值。

调用方在进行间接调用前，会检查：

是否与期望的哈希值匹配。

不匹配则执行 BRK 指令陷入内核，最终导致 panic。

逻辑上，只要我们用同样的编译器、同样的标志编译模块，生成的哈希就能匹配。

但事实并非如此。

我们从目标设备提取了一个正常工作的参考模块 asix.ko，分析发现：

这印证了一个关键事实：

GKI 预编译模块实际使用的是 CFI_ICALL，也就是 UBSan 风格的 CFI，而非 kCFI。

Makefile 的声明与预编译模块的实际行为并不一致。

即使知道内核可能是 CFI_ICALL，我们仍先用标准编译试试水。

结果如前所述：

内核 panic。

改用：

编译后，错误变成：

我们生成的哈希值是：

但内核期望的是 AOSP 预编译模块所用的哈希。

不同版本的 Clang，对同一函数原型生成的 CFI 哈希不同。

开发机上的 Clang 与 AOSP 构建内核时的 Clang 版本不一致，哈希体系不兼容，因此 kCFI 这条路也走不通。

根据 asix.ko 的格式特征，我们转向 CFI_ICALL。

CFI_ICALL 是 Clang 的：

实现，依赖 LTO，也就是链接时优化，来生成跨编译单元的类型检查。

编译命令：

之后用 clang -r 将 LLVM bitcode 链接为 ELF relocatable 文件。

关键参数如下：

这样生成的模块内部结构包括：

__cfi_check 函数接收 (地址, 类型哈希)，验证该地址是否属于某个合法间接调用目标。

.cfi_jt 跳转表为每个地址可被间接调用的函数生成一个 8 字节 CFI 桩，例如：

此时 init_module 符号指向这个桩，真正的代码在：

这一次，模块加载成功：

注意：

其中 0x8 表示 init_module 的大小是 8 字节，而非实际代码大小。

这证实了它指向的是跳转表桩。

然而，胜利的喜悦只持续了几秒钟 —— 手机卡死了。

insmod 命令在内核中阻塞，手机完全无响应：

恢复后，dmesg 里出现了令人意外的崩溃：

崩溃不在我们的代码里，而在一个叫 mrdump 的驱动中。

梳理出来的调用链如下：

问题出在 CFI_ICALL 编译所产生的 ELF section 布局上。

clang -r 将 LLVM bitcode 转换为 ELF 时，生成了一堆非标准的 section 名称：

核心问题是：

.text 段大小为 0，所有实际代码分散在 .text.* 子段中。

MediaTek 的 mrdump 驱动注册了模块状态通知回调。

当模块变为：

时，blocking_notifier_call_chain() 会调用到：

后者再调用：

这个函数会遍历模块的 ELF section 表，遇到一个大小为 0 的 .text 段，以及大量非标准的 .text.* 子段。

其中一个查找操作返回 NULL 后未做空检查，直接解引用访问结构体成员，也就是偏移 0x8，导致空指针崩溃：

内核的模块加载器在处理 section 时，主要基于 ELF Flags 分类，而不是根据名称。

例如：

因此 .text.__cfi_check 虽然名字非标准，但因为其 Flags 包含：

内核仍能正确将其归入代码区域。

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