KernelSU 救砖完全指南从 boot 刷入失败到模块变砖的安全恢复方案【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU刷机变砖是每个玩机用户都可能遇到的场景KernelSU 为此提供了从内核级安全模式到手动清理的多层级恢复手段。本文以 website/docs/zh_CN/guide/rescue-from-bootloop.md 为骨架结合仓库源码深入讲解每种救砖方案的适用场景、操作细节与底层原理让你在设备无法启动时也能从容恢复。变砖的本质为什么 KernelSU 刷机会失败在开始救砖之前需要先理解变砖这个现象的本质。所谓变砖指的是设备无法正常进入系统无法开机、卡开机画面或无限重启但这通常不等于硬件损坏。只要设备还能进入 fastboot 或 Recovery就有恢复的可能。在 KernelSU 的刷机流程中核心操作就是把已经集成 KernelSU 的 boot 镜像刷入设备。这一步一旦出错设备就会在开机阶段失败。从源码结构看KernelSU 的内核侧实现位于 kernel/它通过 kernel/runtime/ksud_integration.c 等文件在内核初始化阶段挂载钩子如果内核本身无法启动那么系统自然无法引导。因此备份原厂 boot 是刷机前必须完成的第一件事——它是你在绝大多数场景下的最终兜底方案。刷入 boot 变砖三种典型原因与恢复思路根据官方文档刷入 boot 导致变砖主要有三种可能它们的成因和应对方式各不相同。原因一刷入了错误格式的 boot 镜像Android 的 boot 镜像有多种压缩格式常见的有gz、lz4、xz等。如果你的设备 boot 分区原本是gz格式却刷入了lz4格式的镜像内核在引导阶段无法解压设备自然无法启动。恢复方式重新刷入与你设备 boot 格式一致的原厂镜像即可无需清除数据。原因二设备要求关闭 AVB 验证AVBAndroid Verified Boot是 Android 的启动完整性验证机制。某些设备在刷入非官方 boot 镜像后会因验证失败而拒绝启动此时需要关闭 AVB 验证。注意关闭 AVB 验证通常意味着需要清除手机所有数据请提前备份重要内容。原因三内核与设备不匹配如果你的内核存在 bug或者编译的内核与你的设备型号不匹配也可能导致无法启动。通用恢复方案刷回原厂 boot无论属于上述哪种情况刷入原厂 boot都是最直接有效的恢复手段。这也是官方文档在安装教程中反复强调刷机前务必备份原厂 boot的原因。如果你没有提前备份可以通过以下途径获取向使用同款设备的其他用户求助获取其备份的原厂 boot从官方固件包ROM中提取原厂 boot 镜像。拿到原厂 boot 后进入 fastboot 模式执行刷入即可fastboot flash boot boot.img fastboot reboot刷入模块变砖KernelSU 内置安全模式的原理与使用相比 boot 刷入失败刷入模块导致变砖是更常见的情况。这里必须强调官方文档的郑重警告请勿刷入来路不明的模块模块拥有 root 权限恶意模块完全可能导致设备发生不可逆的损坏例如格机、损坏分区等。只有来自开源社区且被证明安全的模块才值得信任。对于普通模块导致的变砖即模块本身没有恶意行为只是写入了不兼容的配置或脚本KernelSU 提供了非常轻松的恢复路径——安全模式。安全模式的内核级实现KernelSU 的安全模式与系统自带安全模式不同它是在内核里面实现的因此不会出现按键事件被应用层拦截导致捕获不到的情况。从源码可以看到完整实现链。内核侧在 kernel/runtime/ksud_integration.c 中维护一个按键计数器static unsigned int volumedown_pressed_count 0; static bool is_volumedown_enough(unsigned int count) { return count 3; } int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value) { if (*type EV_KEY *code KEY_VOLUMEDOWN) { int val *value; if (val) { // key pressed, count it volumedown_pressed_count 1; if (is_volumedown_enough(volumedown_pressed_count)) { ksu_stop_input_hook_runtime(); } } } return 0; } bool ksu_is_safe_mode() { static bool safe_mode false; ... if (is_volumedown_enough(volumedown_pressed_count)) { // pressed over 3 times safe_mode true; return true; } return false; }用户态侧ksud 通过系统调用读取内核安全模式状态userspace/ksud/src/ksucalls.rs 调用ksu_check_safemode_cmd其对应的内核命令定义在 kernel/include/uapi/supercall.hKSU_IOCTL_CHECK_SAFEMODE最终由 kernel/supercall/dispatch.c 中的do_check_safemode处理并返回结果。值得注意的是内核侧还合并了系统属性的判断。在 userspace/ksud/src/utils.rs 中is_safe_mode()会依次检查persist.sys.safemode、ro.sys.safemode两个系统属性是否为1再检查内核侧的安全模式标志。这就是系统安全模式与 KernelSU 安全模式联动的机制来源。进入安全模式的两种方法官方文档给出了两种进入安全模式的方式方法一利用系统自带的安全模式有些系统是长按音量下键进入安全模式有些系统比如 MIUI可以在 Recovery 中开启安全模式。进入系统的安全模式后由于 ksud 检测到ro.sys.safemode/persist.sys.safemode属性为1KernelSU 也会自动进入安全模式并禁用所有模块。方法二使用 KernelSU 内置安全模式开机第一屏品牌 Logo出现后连续按音量下键超过三次。注意操作要领是按下-松开、按下-松开、按下-松开而不是长按不放。内核侧的ksu_handle_input_handle_event只统计KEY_VOLUMEDOWN的按下事件value非 0每按下一次计数加一达到 3 次即判定安全模式。::: warning 时序要求 KernelSU 在内核模块初始化时注册音量键监听LKM 模式下在内核执行 init 进程的时候加载到on_post_fs_data阶段开机动画前注销。你需要把握好时机在开机第一屏后快速按下音量下键三次。如果设备启动速度快或操作不及时可能无法触发安全模式。另外如果模块在 initrc 中编写了不合理的代码导致设备无法启动即使在安全模式下这些代码仍然会执行——因为 initrc 注入发生在安全模式判定之前的内核引导阶段。 :::进入安全模式后会发生什么从 userspace/ksud/src/init_event.rs 的源码可以确认安全模式下 ksud 会跳过大量模块相关的初始化逻辑跳过post-fs-data.d公共脚本与模块的post-fs-data脚本执行第 44-46、58-62 行调用disable_all_modules()禁用所有模块第 60-63 行——对应 userspace/ksud/src/module.rs 中的实现它会为每个模块写入 disable 标记文件并重新生成预初始化 rc 文件跳过 feature 配置加载与各 stage 脚本执行第 96-97、138-139 行。进入安全模式后打开 KernelSU 管理器的模块页面你会看到所有模块都被禁用。此时可以对有问题的模块执行卸载操作然后正常重启即可。手动救砖安全模式失效时的第二道防线如果安全模式无法解决问题例如设备根本进不了系统、安全模式未能触发可以尝试手动救砖。官方文档根据设备状态给出了两种方法。方法一通过 ADB 使用 ksud 管理模块前提条件设备能通过 ADB 获取 root shell。此时可以直接使用ksud命令行工具禁用或卸载问题模块adb shell su ksud module list # 列出所有模块 ksud module disable id # 禁用问题模块 ksud module uninstall id # 或直接卸载 reboot::: tip 在 Recovery 中操作 挂载metadata和data分区后你可以在 Recovery 模式下直接运行/data/adb/ksud命令来管理模块。由于 GKI 设备共用initRecovery 模式下仍会加载 KernelSU 内核模块因此你可以正常使用ksud的大部分功能如设置 feature。 :::这些子命令在 userspace/ksud/src/cli.rs 中完成分发最终对应 userspace/ksud/src/module.rs 中的具体实现list_modules()module.rs列出所有模块及其状态disable_module(id)module.rs在模块目录创建disable标记文件使模块在下一次启动时被跳过同时调用regenerate_preinit_rc()重新生成模块注入的 init.rcuninstall_module(id)module.rs写入 remove 标记文件将模块标记为待删除。理解这两个命令的区别很重要disable 是临时禁用可随时重新启用uninstall 是标记卸载下次启动时真正移除。在排查变砖问题时建议先用disable快速验证是否为该模块导致的问题确认后再决定是否卸载。方法二通过 Recovery 手动清理如果设备连 ADB 都无法连接系统完全无法进入则需要借助第三方 Recovery如 TWRP。KernelSU 的模块加载依赖两条链路内核侧的 init.rc 注入文件由 kernel/runtime/ksud_integration.c 的load_module_rc_once()读取并注入和用户态的 ksud 进程。删除这些文件后重新启动KernelSU 将不再加载任何模块。操作步骤进入 Recovery如 TWRP。挂载 data 分区mount /data你可能需要先解密 data 分区具体操作取决于设备型号和解密方式。删除 ksud阻止模块加载rm -f /data/adb/ksud可选挂载 metadata 分区并删除模块生成的 init.rc 注入文件mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc重启设备reboot重启后 KernelSU 将跳过所有模块的加载。进入系统后即可重新打开 KernelSU 管理器处理模块的问题。从源码可以印证这些路径的用途userspace/ksud/src/init_event.rs 中的注释明确说明/metadata/watchdog/ksu/modules.rc是下一次启动时内核钩子看到的当前模块集合——它充当模块状态变更的安全网文件。删除ksud与这些 rc 文件后内核侧的 init.rc 注入钩子没有可加载的内容模块自然全部失效。格机或恶意模块变砖最后的建议如果上述所有方法都无法拯救设备那么很可能你安装的模块包含恶意操作或者以其他方式损坏了设备例如格式化分区、破坏系统文件。这种情况下官方文档给出的建议只有两条清除数据后刷入完整的官方系统全量刷机还原到出厂状态咨询官方售后服务。这也再次印证了文档开头的警告模块拥有完整的 root 权限来路不明的模块可能造成不可逆的损坏。预防永远比救砖更重要——只安装开源、可信、有维护的模块并在刷机前做好原厂 boot 备份。总结救砖决策路径综合官方文档与源码实现KernelSU 变砖场景的恢复优先级可以归纳如下变砖场景首选方案备选方案关键前提刷入错误 boot / AVB 未关闭 / 内核不匹配刷回原厂 boot获取同型号固件提取 bootfastboot 可用普通模块变砖安全模式音量下键 ×3 或系统安全模式ksud 命令行 / Recovery 手动清理能进第一屏或 Recovery恶意模块 / 格机全量刷官方系统送售后无KernelSU 将安全模式实现在内核层配合用户态 ksud 的模块管理能力构建了一条内核判定 → 用户态禁用 → 手动兜底的完整救砖链路。只要设备还能进入 fastboot 或 Recovery绝大多数变砖都可以自行恢复而真正需要警惕的是那些可能造成不可逆损坏的恶意模块——这份指南的最终目的是让你在安全玩机的同时永远保留全身而退的余地。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 17:43:39 · 阅读 1.2k KernelSU 救砖完全指南：从 boot 刷入失败到模块变砖的安全恢复方案
KernelSU 救砖完全指南从 boot 刷入失败到模块变砖的安全恢复方案【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU刷机变砖是每个玩机用户都可能遇到的场景KernelSU 为此提供了从内核级安全模式到手动清理的多层级恢复手段。本文以 website/docs/zh_CN/guide/rescue-from-bootloop.md 为骨架结合仓库源码深入讲解每种救砖方案的适用场景、操作细节与底层原理让你在设备无法启动时也能从容恢复。变砖的本质为什么 KernelSU 刷机会失败在开始救砖之前需要先理解变砖这个现象的本质。所谓变砖指的是设备无法正常进入系统无法开机、卡开机画面或无限重启但这通常不等于硬件损坏。只要设备还能进入 fastboot 或 Recovery就有恢复的可能。在 KernelSU 的刷机流程中核心操作就是把已经集成 KernelSU 的 boot 镜像刷入设备。这一步一旦出错设备就会在开机阶段失败。从源码结构看KernelSU 的内核侧实现位于 kernel/它通过 kernel/runtime/ksud_integration.c 等文件在内核初始化阶段挂载钩子如果内核本身无法启动那么系统自然无法引导。因此备份原厂 boot 是刷机前必须完成的第一件事——它是你在绝大多数场景下的最终兜底方案。刷入 boot 变砖三种典型原因与恢复思路根据官方文档刷入 boot 导致变砖主要有三种可能它们的成因和应对方式各不相同。原因一刷入了错误格式的 boot 镜像Android 的 boot 镜像有多种压缩格式常见的有gz、lz4、xz等。如果你的设备 boot 分区原本是gz格式却刷入了lz4格式的镜像内核在引导阶段无法解压设备自然无法启动。恢复方式重新刷入与你设备 boot 格式一致的原厂镜像即可无需清除数据。原因二设备要求关闭 AVB 验证AVBAndroid Verified Boot是 Android 的启动完整性验证机制。某些设备在刷入非官方 boot 镜像后会因验证失败而拒绝启动此时需要关闭 AVB 验证。注意关闭 AVB 验证通常意味着需要清除手机所有数据请提前备份重要内容。原因三内核与设备不匹配如果你的内核存在 bug或者编译的内核与你的设备型号不匹配也可能导致无法启动。通用恢复方案刷回原厂 boot无论属于上述哪种情况刷入原厂 boot都是最直接有效的恢复手段。这也是官方文档在安装教程中反复强调刷机前务必备份原厂 boot的原因。如果你没有提前备份可以通过以下途径获取向使用同款设备的其他用户求助获取其备份的原厂 boot从官方固件包ROM中提取原厂 boot 镜像。拿到原厂 boot 后进入 fastboot 模式执行刷入即可fastboot flash boot boot.img fastboot reboot刷入模块变砖KernelSU 内置安全模式的原理与使用相比 boot 刷入失败刷入模块导致变砖是更常见的情况。这里必须强调官方文档的郑重警告请勿刷入来路不明的模块模块拥有 root 权限恶意模块完全可能导致设备发生不可逆的损坏例如格机、损坏分区等。只有来自开源社区且被证明安全的模块才值得信任。对于普通模块导致的变砖即模块本身没有恶意行为只是写入了不兼容的配置或脚本KernelSU 提供了非常轻松的恢复路径——安全模式。安全模式的内核级实现KernelSU 的安全模式与系统自带安全模式不同它是在内核里面实现的因此不会出现按键事件被应用层拦截导致捕获不到的情况。从源码可以看到完整实现链。内核侧在 kernel/runtime/ksud_integration.c 中维护一个按键计数器static unsigned int volumedown_pressed_count 0; static bool is_volumedown_enough(unsigned int count) { return count 3; } int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value) { if (*type EV_KEY *code KEY_VOLUMEDOWN) { int val *value; if (val) { // key pressed, count it volumedown_pressed_count 1; if (is_volumedown_enough(volumedown_pressed_count)) { ksu_stop_input_hook_runtime(); } } } return 0; } bool ksu_is_safe_mode() { static bool safe_mode false; ... if (is_volumedown_enough(volumedown_pressed_count)) { // pressed over 3 times safe_mode true; return true; } return false; }用户态侧ksud 通过系统调用读取内核安全模式状态userspace/ksud/src/ksucalls.rs 调用ksu_check_safemode_cmd其对应的内核命令定义在 kernel/include/uapi/supercall.hKSU_IOCTL_CHECK_SAFEMODE最终由 kernel/supercall/dispatch.c 中的do_check_safemode处理并返回结果。值得注意的是内核侧还合并了系统属性的判断。在 userspace/ksud/src/utils.rs 中is_safe_mode()会依次检查persist.sys.safemode、ro.sys.safemode两个系统属性是否为1再检查内核侧的安全模式标志。这就是系统安全模式与 KernelSU 安全模式联动的机制来源。进入安全模式的两种方法官方文档给出了两种进入安全模式的方式方法一利用系统自带的安全模式有些系统是长按音量下键进入安全模式有些系统比如 MIUI可以在 Recovery 中开启安全模式。进入系统的安全模式后由于 ksud 检测到ro.sys.safemode/persist.sys.safemode属性为1KernelSU 也会自动进入安全模式并禁用所有模块。方法二使用 KernelSU 内置安全模式开机第一屏品牌 Logo出现后连续按音量下键超过三次。注意操作要领是按下-松开、按下-松开、按下-松开而不是长按不放。内核侧的ksu_handle_input_handle_event只统计KEY_VOLUMEDOWN的按下事件value非 0每按下一次计数加一达到 3 次即判定安全模式。::: warning 时序要求 KernelSU 在内核模块初始化时注册音量键监听LKM 模式下在内核执行 init 进程的时候加载到on_post_fs_data阶段开机动画前注销。你需要把握好时机在开机第一屏后快速按下音量下键三次。如果设备启动速度快或操作不及时可能无法触发安全模式。另外如果模块在 initrc 中编写了不合理的代码导致设备无法启动即使在安全模式下这些代码仍然会执行——因为 initrc 注入发生在安全模式判定之前的内核引导阶段。 :::进入安全模式后会发生什么从 userspace/ksud/src/init_event.rs 的源码可以确认安全模式下 ksud 会跳过大量模块相关的初始化逻辑跳过post-fs-data.d公共脚本与模块的post-fs-data脚本执行第 44-46、58-62 行调用disable_all_modules()禁用所有模块第 60-63 行——对应 userspace/ksud/src/module.rs 中的实现它会为每个模块写入 disable 标记文件并重新生成预初始化 rc 文件跳过 feature 配置加载与各 stage 脚本执行第 96-97、138-139 行。进入安全模式后打开 KernelSU 管理器的模块页面你会看到所有模块都被禁用。此时可以对有问题的模块执行卸载操作然后正常重启即可。手动救砖安全模式失效时的第二道防线如果安全模式无法解决问题例如设备根本进不了系统、安全模式未能触发可以尝试手动救砖。官方文档根据设备状态给出了两种方法。方法一通过 ADB 使用 ksud 管理模块前提条件设备能通过 ADB 获取 root shell。此时可以直接使用ksud命令行工具禁用或卸载问题模块adb shell su ksud module list # 列出所有模块 ksud module disable id # 禁用问题模块 ksud module uninstall id # 或直接卸载 reboot::: tip 在 Recovery 中操作 挂载metadata和data分区后你可以在 Recovery 模式下直接运行/data/adb/ksud命令来管理模块。由于 GKI 设备共用initRecovery 模式下仍会加载 KernelSU 内核模块因此你可以正常使用ksud的大部分功能如设置 feature。 :::这些子命令在 userspace/ksud/src/cli.rs 中完成分发最终对应 userspace/ksud/src/module.rs 中的具体实现list_modules()module.rs列出所有模块及其状态disable_module(id)module.rs在模块目录创建disable标记文件使模块在下一次启动时被跳过同时调用regenerate_preinit_rc()重新生成模块注入的 init.rcuninstall_module(id)module.rs写入 remove 标记文件将模块标记为待删除。理解这两个命令的区别很重要disable 是临时禁用可随时重新启用uninstall 是标记卸载下次启动时真正移除。在排查变砖问题时建议先用disable快速验证是否为该模块导致的问题确认后再决定是否卸载。方法二通过 Recovery 手动清理如果设备连 ADB 都无法连接系统完全无法进入则需要借助第三方 Recovery如 TWRP。KernelSU 的模块加载依赖两条链路内核侧的 init.rc 注入文件由 kernel/runtime/ksud_integration.c 的load_module_rc_once()读取并注入和用户态的 ksud 进程。删除这些文件后重新启动KernelSU 将不再加载任何模块。操作步骤进入 Recovery如 TWRP。挂载 data 分区mount /data你可能需要先解密 data 分区具体操作取决于设备型号和解密方式。删除 ksud阻止模块加载rm -f /data/adb/ksud可选挂载 metadata 分区并删除模块生成的 init.rc 注入文件mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc重启设备reboot重启后 KernelSU 将跳过所有模块的加载。进入系统后即可重新打开 KernelSU 管理器处理模块的问题。从源码可以印证这些路径的用途userspace/ksud/src/init_event.rs 中的注释明确说明/metadata/watchdog/ksu/modules.rc是下一次启动时内核钩子看到的当前模块集合——它充当模块状态变更的安全网文件。删除ksud与这些 rc 文件后内核侧的 init.rc 注入钩子没有可加载的内容模块自然全部失效。格机或恶意模块变砖最后的建议如果上述所有方法都无法拯救设备那么很可能你安装的模块包含恶意操作或者以其他方式损坏了设备例如格式化分区、破坏系统文件。这种情况下官方文档给出的建议只有两条清除数据后刷入完整的官方系统全量刷机还原到出厂状态咨询官方售后服务。这也再次印证了文档开头的警告模块拥有完整的 root 权限来路不明的模块可能造成不可逆的损坏。预防永远比救砖更重要——只安装开源、可信、有维护的模块并在刷机前做好原厂 boot 备份。总结救砖决策路径综合官方文档与源码实现KernelSU 变砖场景的恢复优先级可以归纳如下变砖场景首选方案备选方案关键前提刷入错误 boot / AVB 未关闭 / 内核不匹配刷回原厂 boot获取同型号固件提取 bootfastboot 可用普通模块变砖安全模式音量下键 ×3 或系统安全模式ksud 命令行 / Recovery 手动清理能进第一屏或 Recovery恶意模块 / 格机全量刷官方系统送售后无KernelSU 将安全模式实现在内核层配合用户态 ksud 的模块管理能力构建了一条内核判定 → 用户态禁用 → 手动兜底的完整救砖链路。只要设备还能进入 fastboot 或 Recovery绝大多数变砖都可以自行恢复而真正需要警惕的是那些可能造成不可逆损坏的恶意模块——这份指南的最终目的是让你在安全玩机的同时永远保留全身而退的余地。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考