Linux arm64 内核Hook实现与校验绕过

ARM64 Linux 内核 Hook 实战：绕过 system 分区完整性校验

背景

我手头有一台基于 Linux 的精简系统设备（BusyBox），在提取并修改 system 分区后，设备会出现开机约 5 分钟自动重启的问题。

对 system 分区进行了全面排查，始终无法定位原因。经过多轮测试验证，最终确认问题出在内核层面的完整性校验机制。于是决定通过内核 Hook 的方式，对校验逻辑进行修改与绕过。

第一步：通过内核日志定位问题

为什么

设备反复重启，首先要搞清楚是谁触发的重启。Linux 内核日志会记录重启前最后的活动，这是排查的第一入口。

执行

adb shell cat /dev/kmsg

/dev/kmsg 是内核日志的实时输出接口，比 dmesg 更适合抓取重启前的最后时刻日志。 在设备重启前持续观察输出，重点关注重启前最后几行。

发现

重启前最后时刻，日志中反复出现两个线程名：

file_check_thread
monitor_thread

这两个名字明显是文件完整性校验相关的内核线程 —— 内核在后台持续检测 system 分区是否被篡改，一旦发现不一致就触发重启。

结论：重启原因 = 内核级 system 分区完整性校验，需要从内核层面 Hook 绕过。

第二步：找到内核物理加载地址

要 Hook 内核函数，首先需要知道内核加载在内存的什么位置。

为什么

ARM64 架构下，内核被加载到物理内存的固定位置。/proc/iomem 是内核导出的物理地址空间布局图，直接标注了 Kernel code 和 Kernel data 的地址范围。

执行

adb shell "cat /proc/iomem | grep -i 'system ram\|kernel'"

输出

80000000-9fffffff : System RAM
  80080000-8098ffff : Kernel code
  80b10000-80c1efff : Kernel data

怎么读

• System RAM — 物理内存起始地址 0x80000000
• Kernel code — 内核代码段物理地址范围（我们要 Hook 的目标就在这里）
• Kernel data — 内核数据段物理地址范围
• 缩进表示包含关系：Kernel code 是 System RAM 的子区域

结论：内核物理加载地址 = 0x80080000

原理

ARM64 Linux 内核加载遵循固定公式：

内核物理加载地址 = PHYS_OFFSET + TEXT_OFFSET
                 = 0x80000000  + 0x80000
                 = 0x80080000 ✓

第三步：通过物理地址反查虚拟地址

IDA Pro 反编译内核需要使用虚拟地址作为 base address，而不是物理地址。所以我们需要用上一步拿到的物理地址，反查出对应的虚拟地址。

为什么用 vmallocinfo

精简系统（BusyBox）通常没有 /proc/kallsyms（内核符号表被裁剪），但 /proc/vmallocinfo 几乎一定存在。它记录了所有虚拟地址到物理地址的映射关系，其中 phys= 字段就是物理地址。

执行

用第二步拿到的物理地址 80080000 作为过滤条件：

adb shell "cat /proc/vmallocinfo | grep phys=.*80080000"

输出

0xffffff8008080000-0xffffff8008830000 8060928 0xffffff800899511c phys=0x0000000080080000 vmap

怎么读

0xffffff8008080000 - 0xffffff8008830000   phys=0x0000000080080000   vmap
│← 虚拟地址范围（IDA Pro 用这个）→│        │← 物理地址 →│

1. 看 phys= 后面的值 → 0x80080000，和第二步 iomem 的 Kernel code 起始地址一致，确认这行就是内核代码段的映射
2. 行首的虚拟地址 0xffffff8008080000 就是 IDA Pro 要填的 base address

结论：IDA Pro 加载内核 Image 时，base address = 0xffffff8008080000

原理

/proc/vmallocinfo 记录了内核所有 vmalloc / vmap / ioremap 映射区域。内核启动时会把自身代码段从物理地址 vmap 到虚拟地址空间，phys= 是物理地址，行首是虚拟地址。用物理地址 grep 就能直接过滤出虚拟地址。

第四步：还原魔改 Boot 镜像

问题

直接将提取的 boot 镜像拖入 IDA Pro，发现反编译报错 —— 这个内核镜像被厂商魔改过，头部格式不是标准的 ARM64 Image。

分析过程

用 Hex 编辑器打开 boot 镜像，对比标准 ARM64 内核 Image 的魔数（magic）：

标准 ARM64 Image 头部以固定格式开头（偏移 0x38 处为 magic ARM\x64）。而这个固件在真正的 Image 头部前面塞了一段私有数据，导致 IDA 无法识别。

经验判断：删除 0x0 ~ 0x9F0 的 Hex 数据，剩下的就是标准内核 Image。

操作

用 Hex 编辑器（如 010 Editor / HxD）：

1. 选中 0x000 ~ 0x9F0 范围
2. 删除选中区域
3. 另存为新文件

至此我们得到了标准的 ARM64 内核 Image，可以正常加载到 IDA Pro。

第五步：IDA Pro 反编译定位校验函数

加载内核

将还原后的 Image 拖入 IDA Pro，在加载选项中：

• Processor type：ARM Little-endian [ARM]
• Base address 填入第三步拿到的虚拟地址：0xffffff8008080000

搜索字符串

加载完成后，通过字符串搜索定位第一步发现的关键线程名：

Shift+F12 打开字符串窗口 → 搜索 file_check_thread

找到字符串后，通过交叉引用（快捷键 X）定位到引用该字符串的函数：

发现

该函数就是 system 分区的完整性校验逻辑 —— 内核启动后由 file_check_thread 线程周期性调用，检测 system 分区文件是否被修改，一旦校验失败就触发重启。

目标确定：Hook 这个函数，让它什么都不做直接返回。

第六步：编写内核模块实现 Hook

思路：为什么只需要写入一条 RET 指令

ARM64 的函数调用约定中，返回值通过 X0 寄存器传递。我们的目标不是让校验函数「返回成功」，而是让它根本不执行任何校验逻辑。

直接把函数入口的第一条指令改成 RET，函数被调用时立刻返回，X0 保留调用前的值（通常为 0）。对于校验线程来说，函数「正常返回」就意味着「没有异常」，不会触发重启。

原始函数:                    Hook 后:
┌─────────────────┐         ┌─────────────────┐
│ STP X29, X30... │         │ RET             │ ← 直接返回，后面全部跳过
│ 校验逻辑...      │         │ (dead code...)  │
│ 发现异常→重启    │         │                 │
│ RET              │         │                 │
└─────────────────┘         └─────────────────┘

ARM64 RET 指令的机器码：0xC0, 0x03, 0x5F, 0xD6（固定 4 字节）

核心问题：内核代码段是只读的

内核 .text 段的页表属性为只读 + 可执行，直接 memcpy 写入会触发内存保护异常。所以在写入前，必须先通过修改页表项属性，将目标地址所在的页临时改为可写。

但改哪一级页表？这不能靠猜，必须先判断目标地址的映射粒度。

前置知识：ARM64 页表层级与映射粒度

ARM64 使用多级页表管理虚拟地址到物理地址的映射，每级页表项（entry）有两种类型：

每级对应的映射粒度：

内核 .text 段通常使用 2MB section mapping（PMD 级别），这是为了减少 TLB miss、提高性能。但不能假设一定如此，必须用代码实际判断。

第一步：诊断目标地址在几级页表

先写一个诊断模块，insmod 后通过 dmesg 查看输出，确认该改哪级：

static int __init diag_init(void)
{
    unsigned long addr = 0xFFFFFF800841C020;
    struct mm_struct *mm = (struct mm_struct *)0xFFFFFF8008B04ED8;

    pgd_t *pgdp = pgd_offset(mm, addr);
    if (pgd_none(READ_ONCE(*pgdp))) {
        printk("[hook] 0x%lx: PGD 无效，未映射\n", addr);
        return 0;
    }

    pud_t *pudp = pud_offset(pgdp, addr);
    if (pud_none(READ_ONCE(*pudp))) {
        printk("[hook] 0x%lx: PUD 无效\n", addr);
        return 0;
    }
    if (pud_sect(*pudp)) {
        printk("[hook] 0x%lx: PUD 级 block（1GB 映射）\n", addr);
        return 0;
    }

    pmd_t *pmdp = pmd_offset(pudp, addr);
    if (pmd_none(READ_ONCE(*pmdp))) {
        printk("[hook] 0x%lx: PMD 无效\n", addr);
        return 0;
    }
    if (pmd_sect(*pmdp)) {
        printk("[hook] 0x%lx: PMD 级 block（2MB section 映射）← 改 PMD\n", addr);
        return 0;
    }

    pte_t *ptep = pte_offset_kernel(pmdp, addr);
    if (pte_none(READ_ONCE(*ptep))) {
        printk("[hook] 0x%lx: PTE 无效\n", addr);
        return 0;
    }
    printk("[hook] 0x%lx: PTE 级（4KB page 映射）← 改 PTE\n", addr);
    return 0;
}

insmod 后 dmesg 查看结果：

adb shell dmesg | grep hook

# 结果 A（大多数内核）：
[hook] 0xffffff800841c020: PMD 级 block（2MB section 映射）← 改 PMD

# 结果 B（少数内核）：
[hook] 0xffffff800841c020: PTE 级（4KB page 映射）← 改 PTE

第二步：根据诊断结果编写 Hook 代码

确认了页表级别后，编写对应的 Hook 模块：

static int __init lkm_init(void)
{
    // 目标函数虚拟地址（IDA Pro 中定位到的 file_check 函数入口）
    unsigned long file_check_addr = 0xFFFFFF800841C020;

    // init_mm 的地址（内核全局页表，需从内核源码或符号表获取）
    struct mm_struct *mm = (struct mm_struct *)0xFFFFFF8008B04ED8;

    pgd_t *pgdp;
    pud_t *pudp;
    pmd_t *pmdp;

    // ===== 第一阶段：逐级遍历页表，找到目标地址的 PMD 页表项 =====

    // PGD → PUD → PMD 三级页表逐级查找
    pgdp = pgd_offset(mm, file_check_addr);
    if (pgd_none(READ_ONCE(*pgdp)))
        return 0;

    pudp = pud_offset(pgdp, file_check_addr);
    if (pud_none(READ_ONCE(*pudp)))
        return 0;

    pmdp = pmd_offset(pudp, file_check_addr);
    if (pmd_none(READ_ONCE(*pmdp)))
        return 0;

    // ===== 第二阶段：修改页表属性，解除写保护 =====

    pmd_t pmd_value = READ_ONCE(*pmdp);
    pmd_value = pmd_mkwrite(pmd_value);          // 添加可写权限
    set_pmd(pmdp, pmd_value);                     // 写回页表
    __flush_tlb_kernel_pgtable(file_check_addr);  // 刷新 TLB 使修改生效

    // ===== 第三阶段：写入 RET 指令 =====

    unsigned char retInstruction[] = {0xC0, 0x03, 0x5F, 0xD6};  // ARM64 RET
    memcpy((void *)file_check_addr, retInstruction, sizeof(retInstruction));

    return 0;
}

代码逐段解释

两个关键地址的来源：

init_mm 地址的定位方法：

精简系统没有 /proc/kallsyms，无法直接查到 init_mm 的地址。但内核源码中有一个固定的引用模式可以利用：

// arch/arm64/mm/fault.c:168
mm == &init_mm ? "swapper" : "user"

arch/arm64/mm/fault.c:168位置（具体位置需要根据你的内核源码进行定位） 内核在处理页表异常时，用 "swapper" 字符串来标识内核空间（init_mm），用 "user" 标识用户空间。这段逻辑在所有 ARM64 内核中都存在。

在 IDA Pro 中的操作步骤：

1. Shift+F12 打开字符串窗口，搜索 swapper
2. 找到后按 X 查看交叉引用，跳转到引用函数
3. 在反编译结果中可以看到类似： c if ( a1 <= 0xFFFFFF7FFFFFFFFFLL ) return sub_FFFFFF80080F5238(byte_FFFFFF80088702D0, a1); v4 = &unk_FFFFFF8008B04ED8;// ← mm == &init_mm swapper = "swapper";
4. unk_FFFFFF8008B04ED8 就是 init_mm 的虚拟地址 对照关系：

页表级别判断逻辑：

逐级遍历页表，每级读出来用 pud_sect() / pmd_sect() 判断：

PGD  → 读出 table entry (0b11)  → 继续
 PUD → 读出 table entry (0b11)  → 继续
  PMD → 读出 block entry (0b01) → 到此为止，改 PMD（2MB section）✓
       读出 table entry (0b11) → 还有下一级，继续到 PTE（4KB page）

解除写保护 → 写入 → 刷新 TLB：

pmd_mkwrite() / pte_mkwrite()   → 把页表项的「只读」改为「可写」
set_pmd() / set_pte()           → 写回修改后的页表项
__flush_tlb_kernel_pgtable()    → 刷新 TLB 缓存，让 CPU 感知到权限变更
memcpy(addr, RET, 4)            → 写入 RET 指令，Hook 完成

编译与加载

编写内核模块需要对应设备的内核源码和编译工具链，不同设备配置方法不同，这里只提供思路框架。编译完成后在设备重启前通过 insmod 加载即可触发 Hook：

adb shell insmod /path/to/hook.ko

加载成功后，校验函数被 RET 覆盖，file_check_thread 每次调用都会直接返回，不再触发重启。

注意：此方法仅适用于没有开启内核保护机制的内核。 如果内核启用了 CONFIG_STRICT_MODULE_RWX、模块签名校验（CONFIG_MODULE_SIG_FORCE）或 SELinux 强制模式等保护，insmod 加载未签名模块会被拒绝，页表修改也可能被阻止。

参考

页表修改的核心原理参考了这篇文章，给了我很大启发：

Linux Arm64 修改页表项属性 - CSDN