当前位置：首页>Linux>Linux arm64 内核Hook实现与校验绕过

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

  • 2026-09-23 12:09:12
Linux arm64 内核Hook实现与校验绕过

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

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

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

为什么

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

执行

adb shell cat /dev/kmsg

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

发现

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

file_check_threadmonitor_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 RAM80080000-8098ffff :Kernel code80b10000-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 ✓
参数
含义
值
PHYS_OFFSET
System RAM 物理起始地址，由硬件决定
0x80000000
TEXT_OFFSET
ARM64 内核固定偏移（512KB），定义在内核 Image 头部
0x80000

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

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 用这个）→│        │← 物理地址 →│
看phys=后面的值 →0x80080000，和第二步 iomem 的 Kernel code 起始地址一致，确认这行就是内核代码段的映射
行首的虚拟地址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处为 magicARM\x64）。而这个固件在真正的 Image 头部前面塞了一段私有数据，导致 IDA 无法识别。

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

操作

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

  • 选中0x000~0x9F0范围
  • 删除选中区域
  • 另存为新文件

至此我们得到了标准的 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              │         │                 │└─────────────────┘         └─────────────────┘

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

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

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

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

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

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

bit[1:0]
类型
含义
0b01
Block entry
块映射，到此为止，改这级
0b11
Table entry
表描述符，指向下一级，继续往下走
0b00
Invalid
无效，地址未映射

每级对应的映射粒度：

级别
映射粒度
说明
PUD
1GB block
极少用于内核代码
PMD2MB block内核.text通常使用这级（section mapping）
PTE
4KB page
用户空间 / 特殊映射

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

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

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

staticint __init diag_init(void){unsignedlong 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（2MBsection 映射）← 改 PMD# 结果 B（少数内核）：[hook]0xffffff800841c020: PTE 级（4KBpage 映射）← 改 PTE

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

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

staticint __init lkm_init(void){// 目标函数虚拟地址（IDA Pro 中定位到的 file_check 函数入口）unsignedlong 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 指令 =====unsignedchar retInstruction[] = {0xC0, 0x03, 0x5F, 0xD6};  // ARM64 RETmemcpy((void *)file_check_addr, retInstruction, sizeof(retInstruction));return 0;}

代码逐段解释

两个关键地址的来源：

地址
含义
如何获取
0xFFFFFF800841C020
校验函数入口地址
IDA Pro 中通过字符串交叉引用定位
0xFFFFFF8008B04ED8init_mm
（内核全局页表结构体）
IDA Pro 中搜索"swapper"字符串，交叉引用定位（详见下方）

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

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

arch/arm64/mm/fault.c:168位置（具体位置需要根据你的内核源码进行定位）

内核在处理页表异常时，用"swapper"字符串来标识内核空间（init_mm），用"user"标识用户空间。这段逻辑在所有 ARM64 内核中都存在。

在 IDA Pro 中的操作步骤：

  • Shift+F12打开字符串窗口，搜索swapper
  • 找到后按X查看交叉引用，跳转到引用函数
  • 在反编译结果中可以看到类似：
    if ( a1 <= 0xFFFFFF7FFFFFFFFFLL )return sub_FFFFFF80080F5238(byte_FFFFFF80088702D0, a1); v4 = &unk_FFFFFF8008B04ED8;// ← mm == &init_mm swapper = "swapper";
  • unk_FFFFFF8008B04ED8就是init_mm的虚拟地址
对照关系：
IDA 反编译
内核源码（fault.c）
unk_FFFFFF8008B04ED8&init_mm
"swapper"
/"user"
mm == &init_mm ? "swapper" : "user"
后续的pgd_offset→pud_offset
页表遍历打印逻辑

页表级别判断逻辑：

逐级遍历页表，每级读出来用 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 修改页表项属性：https://blog.csdn.net/weixin_45030965/article/details/132764364

看雪ID：LeoChen..

https://bbs.kanxue.com/user-home-1069137.htm

*本文为看雪论坛精华文章，由 LeoChen..原创，转载请注明来自看雪社区

# 往期推荐

安卓逆向基础知识之frida Hook

2025 强网杯和强网拟态部分题解

在逆向分析方面-unidbg真的适合 MCP 吗？

AI静态分析，内核模块隐藏 Frida 特征，绕过linker私有结构遍历崩溃链

某安全so库深度解析

球分享

球点赞

球在看

点击阅读原文查看更多

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：596563534@qq.com 。

这个网站让我对Python兴趣达到了10000%

Python Web开发:系统设计模式实战

最新文章

随机文章