尧图网页设计 
KernelSU 变砖自救指南Bootloop 救援的完整实操手册【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU刷机与模块玩法总是伴随着风险。无论是刷入 boot 分区时格式不匹配还是某个模块在开机阶段触发了死循环设备卡在开机动画、无法进入系统即俗称的变砖都是 KernelSU 用户最常遇到的故障场景。本文基于仓库官方救援文档rescue-from-bootloop.md展开系统梳理 boot 分区刷砖、模块导致的 bootloop 两类问题的成因并给出内核内置安全模式、ksud命令行、Recovery 手动清理三套由易到难的完整救援方案。读完本文你将能够根据设备状态判断故障类型按步骤恢复设备并理解 KernelSU 安全模式在底层是如何实现与触发的。故障成因分析KernelSU 为什么会把设备刷砖变砖在绝大多数情况下并非不可逆关键在于判断故障发生在哪一环节。KernelSU 的救援文档将故障归纳为两大来源boot 分区刷写问题与模块安装问题二者的成因、危害程度和救援手段完全不同。刷写 boot 分区导致的引导失败使用 fastboot 只刷 boot 分区本身风险相对可控但以下三种情况会导致设备无法启动刷入了错误格式的 boot 镜像。不同设备的 boot 分区压缩格式并不相同。例如若设备的启动格式是gzgzip 压缩却误刷入了lz4格式的镜像内核将无法解压引导设备自然无法开机。未关闭 AVB 校验。部分设备在修改 boot 分区后需要关闭 AVBAndroid Verified Boot验证才能正常引导而关闭 AVB 通常意味着需要清空设备全部数据。内核本身存在缺陷或不兼容。刷入的 KernelSU 内核若包含 bug或与设备硬件、固件版本不匹配同样会导致引导失败。无论具体是哪种情况刷回官方stockboot 镜像都是恢复设备的最可靠手段。正因为如此官方安装指南从一开始就强烈建议刷机前务必备份原始 boot 镜像。如果你没有备份可以从同型号设备的其他用户处获取原厂 boot或直接从官方固件中提取。模块导致的 bootloop最常见也最危险安装模块是导致变砖的更常见原因。模块运行在 root 权限之下能力与内核同级一旦出错可能造成不可逆的损害。因此官方文档给出了明确警告绝对不要安装来源不明的模块。不过模块导致的 bootloop 也需要区分两种情况正常模块模块本身来源可靠、行为安全只是恰好与设备环境不兼容导致无法开机。这类问题在 KernelSU 中几乎都可以轻松恢复。恶意或破坏性模块模块包含恶意操作如格式化数据、破坏分区或直接损坏了设备。这类问题只能通过清数据重刷官方系统或送修解决。判断模块属于哪一类决定了你该采用下面的哪种救援手段。内核级安全模式音量键三连击救援法对于来源可靠但导致无法开机的正常模块KernelSU 内置了**安全模式Safe Mode**救援机制。进入安全模式后所有模块都会被禁用系统得以正常启动之后再进入 KernelSU Manager 的模块页面就能卸载引发问题的模块。两种进入安全模式的途径利用系统自带的 Safe Mode部分 ROM 内置安全模式通常通过长按音量减键进入另一些系统如 MIUI/HyperOS可以在 Recovery 中开启。系统进入安全模式时KernelSU 也会同步进入该模式并自动禁用模块。在用户态侧utils.rs 会通过getprop(persist.sys.safemode)与getprop(ro.sys.safemode)检测系统级安全模式属性一旦命中即判定为安全模式。KernelSU 自带的安全模式在开机动画出现第一个开机画面之后连续快速按下音量减键 3 次以上。注意手法是按下-松开、按下-松开、按下-松开而不是长按不松。底层实现内核态的按键监听安全模式的检测并非由用户态完成而是实现在内核中。从源码看其核心逻辑位于 ksud_integration.c内核通过 kprobe 挂载input_event符号见 ksud_integration.c监听全局输入事件在ksu_handle_input_handle_event()中每当捕获到EV_KEYKEY_VOLUMEDOWN的按下事件就累加volumedown_pressed_count计数is_volumedown_enough()的判定阈值是count 3即至少按满 3 次计数达标后立即通过ksu_stop_input_hook_runtime()停止监听随后ksu_is_safe_mode()返回 true。之所以把实现放在内核而不是用户态正是为了避免按键事件被上层拦截而丢失——系统起不来时用户态服务可能根本没有机会运行而内核的 kprobe 钩子只要设备通电就能工作。不过需要注意对于非 GKI 内核可能需要手动集成这部分代码具体请参考官方集成文档how-to-integrate-for-non-gki.md。时序要求与两个限制官方文档对此机制有一个醒目的警告实操时务必留意内核模块在初始化阶段注册音量键监听LKM 模式下即内核执行 init 进程时加载并在on_post_fs_data阶段开机动画之前取消注册。查看 boot_event.c 可以看到on_post_fs_data中正是通过ksu_stop_input_hook_runtime()停止按键采样的。也就是说只有在开机画面出现后、on_post_fs_data之前的极短时间窗内连续按下 3 次音量减键才能触发安全模式。如果设备启动很快或操作不及时安全模式可能不会触发需要重试。如果模块在 init.rc 中写入了不合理的代码导致无法开机这些代码即使在安全模式下依然会执行——因为 init.rc 的注入发生在更早的内核引导阶段安全模式的禁用逻辑影响不到它。这类情况需要走下面的手动救援流程。手动救援方案一ADB 配合 ksud 命令行如果设备还能通过 ADB 获得 root shell就不需要动用 Recovery直接命令行操作即可。在 ADB shell 中依次执行adb shell su ksud module list # 列出所有模块 ksud module disable id # 禁用问题模块 ksud module uninstall id # 或直接卸载 rebootksud是 KernelSU 的用户态守护进程/命令行工具源码位于 userspace/ksud其模块子命令在 cli.rs 中定义list、disable、uninstall分别对应列出、禁用、卸载操作底层分别调用module::disable_module()与module::uninstall_module()见 cli.rs。一个实用的技巧在 Recovery 模式下也可以运行/data/adb/ksud。只要先挂载metadata和data分区就能在 Recovery 中管理模块。由于 GKI 设备共用initKernelSU 内核模块在 Recovery 模式下依然会被加载因此ksud的大多数功能例如设置 feature都能正常使用。手动救援方案二Recovery 手动清理如果设备完全进不了系统连 ADB 都连不上就需要借助第三方 Recovery如 TWRP。KernelSU 的模块加载链路依赖两个关键环节内核侧的 init.rc 注入文件与用户态的 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 Manager 即可处理模块问题。这一步的底层依据同样能在源码中找到模块的 init.rc 注入文件正是由 ksud 在 preinit 阶段生成的modules.rc常量定义见 defs.rs其中PREINIT_DIR_WATCHDOG指向/metadata/watchdog/ksu/内核通过挂钩 init 读取/system/etc/init/init.rc的过程将模块 rc 内容拼接注入见 ksud_integration.c 的ksu_install_rc_hook。删除ksud与两个位置的modules.rc等于同时切断注入源头和注入内容下次开机便不再有任何模块参与引导。另外注意init_event.rs 显示 ksud 每次正常启动还会重新生成 preinit rc 作为安全网因此手动清理后首次进入系统时不要再让旧的 ksud 残留重新执行。兜底方案格式化数据与送修如果以上所有手段都无法救回设备那么大概率是模块包含了恶意操作或已经以其他方式损坏了设备。此时只剩下两个选择清除数据并完整刷入官方系统wipe 后刷入官方固件相当于彻底重装。联系售后服务中心进行检修。救援决策速查设备状态推荐手段对应章节还能进入系统/Recovery但怀疑模块导致 bootloop安全模式音量减 ×3→ Manager 卸载模块安全模式救援法能通过 ADB 获取 root shellksud module disable/uninstall手动方案一完全无法开机但有第三方 Recovery删除/data/adb/ksud与modules.rc手动方案二模块疑似恶意/已损坏设备清数据重刷官方系统或送修兜底方案boot 分区刷坏格式错误/AVB/内核不兼容刷回官方 stock boot 镜像故障成因分析预防建议救援永远不如预防。结合官方文档的告诫建议在刷机前做好三件事一是始终备份原始 boot 镜像这是刷坏 boot 分区后最快恢复的前提二是只安装可信来源的模块对来源不明、评价存疑的模块保持警惕三是熟悉安全模式的触发时机在设备启动缓慢时可抓住开机画面出现后的短暂窗口完成三次按键为后续救援留出退路。理解 KernelSU 安全模式的内核实现与模块加载链路不仅能让你在故障发生时从容应对也能帮助你在集成 KernelSU 到非 GKI 设备时正确地保留和适配这套救援机制。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KernelSU 变砖自救指南：Bootloop 救援的完整实操手册
KernelSU 变砖自救指南Bootloop 救援的完整实操手册【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU刷机与模块玩法总是伴随着风险。无论是刷入 boot 分区时格式不匹配还是某个模块在开机阶段触发了死循环设备卡在开机动画、无法进入系统即俗称的变砖都是 KernelSU 用户最常遇到的故障场景。本文基于仓库官方救援文档rescue-from-bootloop.md展开系统梳理 boot 分区刷砖、模块导致的 bootloop 两类问题的成因并给出内核内置安全模式、ksud命令行、Recovery 手动清理三套由易到难的完整救援方案。读完本文你将能够根据设备状态判断故障类型按步骤恢复设备并理解 KernelSU 安全模式在底层是如何实现与触发的。故障成因分析KernelSU 为什么会把设备刷砖变砖在绝大多数情况下并非不可逆关键在于判断故障发生在哪一环节。KernelSU 的救援文档将故障归纳为两大来源boot 分区刷写问题与模块安装问题二者的成因、危害程度和救援手段完全不同。刷写 boot 分区导致的引导失败使用 fastboot 只刷 boot 分区本身风险相对可控但以下三种情况会导致设备无法启动刷入了错误格式的 boot 镜像。不同设备的 boot 分区压缩格式并不相同。例如若设备的启动格式是gzgzip 压缩却误刷入了lz4格式的镜像内核将无法解压引导设备自然无法开机。未关闭 AVB 校验。部分设备在修改 boot 分区后需要关闭 AVBAndroid Verified Boot验证才能正常引导而关闭 AVB 通常意味着需要清空设备全部数据。内核本身存在缺陷或不兼容。刷入的 KernelSU 内核若包含 bug或与设备硬件、固件版本不匹配同样会导致引导失败。无论具体是哪种情况刷回官方stockboot 镜像都是恢复设备的最可靠手段。正因为如此官方安装指南从一开始就强烈建议刷机前务必备份原始 boot 镜像。如果你没有备份可以从同型号设备的其他用户处获取原厂 boot或直接从官方固件中提取。模块导致的 bootloop最常见也最危险安装模块是导致变砖的更常见原因。模块运行在 root 权限之下能力与内核同级一旦出错可能造成不可逆的损害。因此官方文档给出了明确警告绝对不要安装来源不明的模块。不过模块导致的 bootloop 也需要区分两种情况正常模块模块本身来源可靠、行为安全只是恰好与设备环境不兼容导致无法开机。这类问题在 KernelSU 中几乎都可以轻松恢复。恶意或破坏性模块模块包含恶意操作如格式化数据、破坏分区或直接损坏了设备。这类问题只能通过清数据重刷官方系统或送修解决。判断模块属于哪一类决定了你该采用下面的哪种救援手段。内核级安全模式音量键三连击救援法对于来源可靠但导致无法开机的正常模块KernelSU 内置了**安全模式Safe Mode**救援机制。进入安全模式后所有模块都会被禁用系统得以正常启动之后再进入 KernelSU Manager 的模块页面就能卸载引发问题的模块。两种进入安全模式的途径利用系统自带的 Safe Mode部分 ROM 内置安全模式通常通过长按音量减键进入另一些系统如 MIUI/HyperOS可以在 Recovery 中开启。系统进入安全模式时KernelSU 也会同步进入该模式并自动禁用模块。在用户态侧utils.rs 会通过getprop(persist.sys.safemode)与getprop(ro.sys.safemode)检测系统级安全模式属性一旦命中即判定为安全模式。KernelSU 自带的安全模式在开机动画出现第一个开机画面之后连续快速按下音量减键 3 次以上。注意手法是按下-松开、按下-松开、按下-松开而不是长按不松。底层实现内核态的按键监听安全模式的检测并非由用户态完成而是实现在内核中。从源码看其核心逻辑位于 ksud_integration.c内核通过 kprobe 挂载input_event符号见 ksud_integration.c监听全局输入事件在ksu_handle_input_handle_event()中每当捕获到EV_KEYKEY_VOLUMEDOWN的按下事件就累加volumedown_pressed_count计数is_volumedown_enough()的判定阈值是count 3即至少按满 3 次计数达标后立即通过ksu_stop_input_hook_runtime()停止监听随后ksu_is_safe_mode()返回 true。之所以把实现放在内核而不是用户态正是为了避免按键事件被上层拦截而丢失——系统起不来时用户态服务可能根本没有机会运行而内核的 kprobe 钩子只要设备通电就能工作。不过需要注意对于非 GKI 内核可能需要手动集成这部分代码具体请参考官方集成文档how-to-integrate-for-non-gki.md。时序要求与两个限制官方文档对此机制有一个醒目的警告实操时务必留意内核模块在初始化阶段注册音量键监听LKM 模式下即内核执行 init 进程时加载并在on_post_fs_data阶段开机动画之前取消注册。查看 boot_event.c 可以看到on_post_fs_data中正是通过ksu_stop_input_hook_runtime()停止按键采样的。也就是说只有在开机画面出现后、on_post_fs_data之前的极短时间窗内连续按下 3 次音量减键才能触发安全模式。如果设备启动很快或操作不及时安全模式可能不会触发需要重试。如果模块在 init.rc 中写入了不合理的代码导致无法开机这些代码即使在安全模式下依然会执行——因为 init.rc 的注入发生在更早的内核引导阶段安全模式的禁用逻辑影响不到它。这类情况需要走下面的手动救援流程。手动救援方案一ADB 配合 ksud 命令行如果设备还能通过 ADB 获得 root shell就不需要动用 Recovery直接命令行操作即可。在 ADB shell 中依次执行adb shell su ksud module list # 列出所有模块 ksud module disable id # 禁用问题模块 ksud module uninstall id # 或直接卸载 rebootksud是 KernelSU 的用户态守护进程/命令行工具源码位于 userspace/ksud其模块子命令在 cli.rs 中定义list、disable、uninstall分别对应列出、禁用、卸载操作底层分别调用module::disable_module()与module::uninstall_module()见 cli.rs。一个实用的技巧在 Recovery 模式下也可以运行/data/adb/ksud。只要先挂载metadata和data分区就能在 Recovery 中管理模块。由于 GKI 设备共用initKernelSU 内核模块在 Recovery 模式下依然会被加载因此ksud的大多数功能例如设置 feature都能正常使用。手动救援方案二Recovery 手动清理如果设备完全进不了系统连 ADB 都连不上就需要借助第三方 Recovery如 TWRP。KernelSU 的模块加载链路依赖两个关键环节内核侧的 init.rc 注入文件与用户态的 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 Manager 即可处理模块问题。这一步的底层依据同样能在源码中找到模块的 init.rc 注入文件正是由 ksud 在 preinit 阶段生成的modules.rc常量定义见 defs.rs其中PREINIT_DIR_WATCHDOG指向/metadata/watchdog/ksu/内核通过挂钩 init 读取/system/etc/init/init.rc的过程将模块 rc 内容拼接注入见 ksud_integration.c 的ksu_install_rc_hook。删除ksud与两个位置的modules.rc等于同时切断注入源头和注入内容下次开机便不再有任何模块参与引导。另外注意init_event.rs 显示 ksud 每次正常启动还会重新生成 preinit rc 作为安全网因此手动清理后首次进入系统时不要再让旧的 ksud 残留重新执行。兜底方案格式化数据与送修如果以上所有手段都无法救回设备那么大概率是模块包含了恶意操作或已经以其他方式损坏了设备。此时只剩下两个选择清除数据并完整刷入官方系统wipe 后刷入官方固件相当于彻底重装。联系售后服务中心进行检修。救援决策速查设备状态推荐手段对应章节还能进入系统/Recovery但怀疑模块导致 bootloop安全模式音量减 ×3→ Manager 卸载模块安全模式救援法能通过 ADB 获取 root shellksud module disable/uninstall手动方案一完全无法开机但有第三方 Recovery删除/data/adb/ksud与modules.rc手动方案二模块疑似恶意/已损坏设备清数据重刷官方系统或送修兜底方案boot 分区刷坏格式错误/AVB/内核不兼容刷回官方 stock boot 镜像故障成因分析预防建议救援永远不如预防。结合官方文档的告诫建议在刷机前做好三件事一是始终备份原始 boot 镜像这是刷坏 boot 分区后最快恢复的前提二是只安装可信来源的模块对来源不明、评价存疑的模块保持警惕三是熟悉安全模式的触发时机在设备启动缓慢时可抓住开机画面出现后的短暂窗口完成三次按键为后续救援留出退路。理解 KernelSU 安全模式的内核实现与模块加载链路不仅能让你在故障发生时从容应对也能帮助你在集成 KernelSU 到非 GKI 设备时正确地保留和适配这套救援机制。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考