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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

直接将提取的 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）：

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

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

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

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

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

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

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

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

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

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

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

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

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

每级对应的映射粒度：

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

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

insmod 后 dmesg 查看结果：

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

两个关键地址的来源：

init_mm 地址的定位方法：

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

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

在 IDA Pro 中的操作步骤：

页表级别判断逻辑：

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

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

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