文章总结： 文档详细记录了在Linuxarm64设备上通过内核Hook绕过系统分区完整性校验的完整流程。作者首先通过内核日志定位到触发重启的filecheckthread线程，随后利用/proc/iomem和/proc/vmallocinfo获取内核物理与虚拟地址，使用IDAPro反编译定位校验函数，最终通过修改页表属性实现函数入口指令替换（改为RET指令）从而绕过校验。整个过程包含页表层级诊断、内存映射修改等关键技术细节，具有实战参考价值。 综合评分： 85 文章分类： 渗透测试,二进制安全,内核安全,逆向分析,漏洞分析
Linux arm64 内核Hook实现与校验绕过
LeoChen.. LeoChen..
看雪学苑
2026年4月13日 18:04 上海
在小说阅读器读本章
去阅读
我手头有一台基于 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 ✓
| 参数 | 含义 | 值 |
| — | — | — |
| 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 | 极少用于内核代码 |
| PMD | 2MB 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 RET
memcpy((void *)file_check_addr, retInstruction, sizeof(retInstruction));
return 0;
}
代码逐段解释
两个关键地址的来源：
| 地址 | 含义 | 如何获取 |
| — | — | — |
| 0xFFFFFF800841C020 | 校验函数入口地址 | IDA Pro 中通过字符串交叉引用定位 |
| 0xFFFFFF8008B04ED8 | init_mm （内核全局页表结构体） | IDA Pro 中搜索"swapper"字符串，交叉引用定位（详见下方） |
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 中的操作步骤：
- 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库深度解析
球分享
球点赞
球在看
点击阅读原文查看更多
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：看雪学苑 LeoChen.. LeoChen..《Linux arm64 内核Hook实现与校验绕过》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论