在 4.14 非 GKI 内核上跑通 KernelSU检测、集成与验证【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 低版本内核适配4.14 及以上、非 GKI 设备的结论先说自 v1.0 起官方不再支持非 GKI 设备见集成文档顶部的存档声明唯一路径是把 v0.9.5 的源码集成进自己的内核源码树并自行编译。集成方式只有两种kprobe 自动挂钩推荐或者手动修改内核里 4 个系统调用位置。本文按检测、集成、验证的顺序走完整个流程。判断设备是否适合自行编译先确认环境在适用范围之内避免白做。内核环境是否适用方式与前提GKI 设备能刷官方 boot不适用本文管理器直接安装见安装指南非 GKI、4.14kprobe 正常推荐kprobe 集成不改内核源码非 GKI、4.14kprobe 异常或版本过老适用手动改 4 个系统调用挂钩点拿不到内核源码不适用前提是你能从源码编出可开机的内核三个边界条件官方最低支持到 4.14该集成文档已存档、不再维护所以源码必须用 v0.9.5非 GKI 内核碎片化严重没有统一编译方法boot 镜像需要自己出。检查内核版本并备份 boot这一步解决两个问题版本是否落在支持区间刷机失败后能否回退。adb shell uname -r输出形如4.19.191-android11-8-gb2f41e6只看前面的内核主版本号Android 系统版本号与它无关。随后安装 KernelSU 管理器应用显示不支持说明设备是本文的目标显示未安装说明设备已受支持无需自行编译。动手前先备份原厂boot.img方法见安装文档的备份你的 boot.img一节。它是本文流程里唯一的可靠回退手段。把 KernelSU 源码集成进内核源码树这一步解决 KernelSU 代码如何进入你的编译体系。改动共四处一个软链接、drivers/Makefile和drivers/Kconfig各加一行。仓库自带的 kernel/setup.sh 干的就是这几件事克隆本仓库、检出指定 tag、建软链接drivers/kernelsu指向KernelSU/kernel/、往drivers/Makefile和drivers/Kconfig各加一行。网络受限时手动做等价操作先取 v0.9.5 标签的源码必须用 v0.9.5这是支持非 GKI 的最后一个版本git clone https://gitcode.com/GitHub_Trending/ke/KernelSU cd KernelSU git checkout v0.9.5再回到内核源码根目录建软链接并补上两行构建注册。追加的内容与 setup.sh 完全一致CONFIG_KSU是总开关ln -s /绝对路径/KernelSU/kernel drivers/kernelsu echo obj-$(CONFIG_KSU) kernelsu/ drivers/Makefile echo source drivers/kernelsu/Kconfig drivers/Kconfig加完之后内核构建系统就能识别CONFIG_KSU选项该选项定义见 kernel/Kconfig。v0.9.5 中把它设为y即启用设为n即禁用。在 defconfig 中启用 KernelSU 与 kprobekprobe 集成方式依赖内核的 kprobe 机制内核动态挂钩点来安装钩子前提是配置里开了相关选项缺一个钩子都装不上。找到你设备的 defconfig通常在arch/arm64/configs/设备代号_defconfig或arch/arm64/configs/vendor/设备代号_defconfig按集成文档添加# KernelSU CONFIG_KSUy CONFIG_KPROBESy CONFIG_HAVE_KPROBESy CONFIG_KPROBE_EVENTSy第一行启用 KernelSU后三行启用 kprobe。如果编译后 KPROBES 仍未生效多半是CONFIG_MODULES等依赖没开用make menuconfig搜 KPROBES 勾选依赖项即可。这一步做完就用你现有的编译流程重新编译内核不需要别的改动。如果刷入后无法开机直接跳到手动改内核源码集成一节。kprobe 不工作手动修改内核源码集成当 kprobe 因上游 bug 或内核版本过老无法工作时需要显式挂钩 4 个系统调用入口。四处改动模式相同extern声明 KernelSU 的处理函数在目标内核函数开头调用它。以fs/exec.c为例新增声明和函数体开头的调用完整 diff 在集成文档中#ifdef CONFIG_KSU extern bool ksu_execveat_hook __read_mostly; extern int ksu_handle_execveat(int *fd, struct filename **filename_ptr, void *argv, void *envp, int *flags); extern int ksu_handle_execveat_sucompat(int *fd, struct filename **filename_ptr, void *argv, void *envp, int *flags); #endif在do_execveat_common函数体开头用if (unlikely(ksu_execveat_hook))判断走ksu_handle_execveat还是ksu_handle_execveat_sucompat关掉钩子时直接走原逻辑__do_execve_file。其余三处与版本差异内核函数文件挂钩函数版本差异do_faccessatfs/open.cksu_handle_faccessat4.17 以前无此函数改faccessat系统调用定义do_execveat_commonfs/exec.cksu_handle_execveat—vfs_readfs/read_write.cksu_handle_vfs_read—vfs_statxfs/stat.cksu_handle_stat无vfs_statx时改用vfs_fstatat手动集成时务必在 defconfig 里关掉CONFIG_KPROBES否则开机后按音量下键会误触发 KernelSU 安全模式集成文档原文明确警告了这个坑。开启安全模式预留救砖通道安全模式是 KernelSU 的救砖入口开机后按音量下进入可以恢复原有 boot。启用它需要再改一处drivers/input/input.c在input_handle_event函数体开头插入对输入事件的挂钩ksu_input_hook关闭时这行不产生任何开销#ifdef CONFIG_KSU if (unlikely(ksu_input_hook)) ksu_handle_input_handle_event(type, code, value); #endif完整 diff 在集成文档的安全模式小节。文档强烈建议开启它是模块出问题后唯一的自救通道。编译刷机后验证 KernelSU 生效验证分三层内核能启动、管理器能识别、su输出 root。先用 fastboot 刷入编译出的 boot确认设备正常开机并用下面的命令确认内核版本无误adb shell uname -r再打开管理器应用状态不再显示不支持而是识别出内核里的 KernelSU 版本。最后确认提权链路真正打通adb shell su -c id # 预期输出 uid0(root) gid0(root) groups0(root)输出uid0即适配完成。处理四个高频故障现象刷入后无法开机卡在 logo。原因kprobe 在该内核上工作不正常挂钩安装直接导致内核异常。解法按集成文档的验证方法注释掉 v0.9.5 源码kernel/ksu.c中的ksu_sucompat_init()和ksu_ksud_init()再编译测试若恢复正常即可确认是 kprobe 问题——要么修 kprobe要么转手动改 4 个位置的方案。现象没有按音量下键却进了安全模式。原因手动集成时没有禁用CONFIG_KPROBES开机按键事件被误判。解法defconfig 设CONFIG_KPROBESn重新编译。现象pm命令执行失败。原因devpts 设备点处理未被挂钩。解法在fs/devpts/inode.c的devpts_get_priv开头加一行ksu_handle_devpts(dentry-d_inode);补丁见集成文档的pm 命令执行失败小节。现象开了 KPROBES 配置但仍未生效。原因缺依赖项最常见的是CONFIG_MODULES。解法make menuconfig搜 KPROBES逐项启用其依赖。收尾的四条可执行建议刷机前备份原厂boot.img全程保留 fastboot 连接这是唯一可靠的回退路径。优先走 kprobe 方案确认它不工作再动手改内核源码手动改 4 处的工作量明显更大。手动集成时关闭CONFIG_KPROBES并开启安全模式两处改动成本极低却能避免误入安全模式和救不了砖。官方自 v1.0 起不再维护非 GKI 支持后续想升级 KernelSU 需要自行向新版本移植否则停留在 v0.9.5。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 4.14+ 非 GKI 内核上跑通 KernelSU：检测、集成与验证
在 4.14 非 GKI 内核上跑通 KernelSU检测、集成与验证【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 低版本内核适配4.14 及以上、非 GKI 设备的结论先说自 v1.0 起官方不再支持非 GKI 设备见集成文档顶部的存档声明唯一路径是把 v0.9.5 的源码集成进自己的内核源码树并自行编译。集成方式只有两种kprobe 自动挂钩推荐或者手动修改内核里 4 个系统调用位置。本文按检测、集成、验证的顺序走完整个流程。判断设备是否适合自行编译先确认环境在适用范围之内避免白做。内核环境是否适用方式与前提GKI 设备能刷官方 boot不适用本文管理器直接安装见安装指南非 GKI、4.14kprobe 正常推荐kprobe 集成不改内核源码非 GKI、4.14kprobe 异常或版本过老适用手动改 4 个系统调用挂钩点拿不到内核源码不适用前提是你能从源码编出可开机的内核三个边界条件官方最低支持到 4.14该集成文档已存档、不再维护所以源码必须用 v0.9.5非 GKI 内核碎片化严重没有统一编译方法boot 镜像需要自己出。检查内核版本并备份 boot这一步解决两个问题版本是否落在支持区间刷机失败后能否回退。adb shell uname -r输出形如4.19.191-android11-8-gb2f41e6只看前面的内核主版本号Android 系统版本号与它无关。随后安装 KernelSU 管理器应用显示不支持说明设备是本文的目标显示未安装说明设备已受支持无需自行编译。动手前先备份原厂boot.img方法见安装文档的备份你的 boot.img一节。它是本文流程里唯一的可靠回退手段。把 KernelSU 源码集成进内核源码树这一步解决 KernelSU 代码如何进入你的编译体系。改动共四处一个软链接、drivers/Makefile和drivers/Kconfig各加一行。仓库自带的 kernel/setup.sh 干的就是这几件事克隆本仓库、检出指定 tag、建软链接drivers/kernelsu指向KernelSU/kernel/、往drivers/Makefile和drivers/Kconfig各加一行。网络受限时手动做等价操作先取 v0.9.5 标签的源码必须用 v0.9.5这是支持非 GKI 的最后一个版本git clone https://gitcode.com/GitHub_Trending/ke/KernelSU cd KernelSU git checkout v0.9.5再回到内核源码根目录建软链接并补上两行构建注册。追加的内容与 setup.sh 完全一致CONFIG_KSU是总开关ln -s /绝对路径/KernelSU/kernel drivers/kernelsu echo obj-$(CONFIG_KSU) kernelsu/ drivers/Makefile echo source drivers/kernelsu/Kconfig drivers/Kconfig加完之后内核构建系统就能识别CONFIG_KSU选项该选项定义见 kernel/Kconfig。v0.9.5 中把它设为y即启用设为n即禁用。在 defconfig 中启用 KernelSU 与 kprobekprobe 集成方式依赖内核的 kprobe 机制内核动态挂钩点来安装钩子前提是配置里开了相关选项缺一个钩子都装不上。找到你设备的 defconfig通常在arch/arm64/configs/设备代号_defconfig或arch/arm64/configs/vendor/设备代号_defconfig按集成文档添加# KernelSU CONFIG_KSUy CONFIG_KPROBESy CONFIG_HAVE_KPROBESy CONFIG_KPROBE_EVENTSy第一行启用 KernelSU后三行启用 kprobe。如果编译后 KPROBES 仍未生效多半是CONFIG_MODULES等依赖没开用make menuconfig搜 KPROBES 勾选依赖项即可。这一步做完就用你现有的编译流程重新编译内核不需要别的改动。如果刷入后无法开机直接跳到手动改内核源码集成一节。kprobe 不工作手动修改内核源码集成当 kprobe 因上游 bug 或内核版本过老无法工作时需要显式挂钩 4 个系统调用入口。四处改动模式相同extern声明 KernelSU 的处理函数在目标内核函数开头调用它。以fs/exec.c为例新增声明和函数体开头的调用完整 diff 在集成文档中#ifdef CONFIG_KSU extern bool ksu_execveat_hook __read_mostly; extern int ksu_handle_execveat(int *fd, struct filename **filename_ptr, void *argv, void *envp, int *flags); extern int ksu_handle_execveat_sucompat(int *fd, struct filename **filename_ptr, void *argv, void *envp, int *flags); #endif在do_execveat_common函数体开头用if (unlikely(ksu_execveat_hook))判断走ksu_handle_execveat还是ksu_handle_execveat_sucompat关掉钩子时直接走原逻辑__do_execve_file。其余三处与版本差异内核函数文件挂钩函数版本差异do_faccessatfs/open.cksu_handle_faccessat4.17 以前无此函数改faccessat系统调用定义do_execveat_commonfs/exec.cksu_handle_execveat—vfs_readfs/read_write.cksu_handle_vfs_read—vfs_statxfs/stat.cksu_handle_stat无vfs_statx时改用vfs_fstatat手动集成时务必在 defconfig 里关掉CONFIG_KPROBES否则开机后按音量下键会误触发 KernelSU 安全模式集成文档原文明确警告了这个坑。开启安全模式预留救砖通道安全模式是 KernelSU 的救砖入口开机后按音量下进入可以恢复原有 boot。启用它需要再改一处drivers/input/input.c在input_handle_event函数体开头插入对输入事件的挂钩ksu_input_hook关闭时这行不产生任何开销#ifdef CONFIG_KSU if (unlikely(ksu_input_hook)) ksu_handle_input_handle_event(type, code, value); #endif完整 diff 在集成文档的安全模式小节。文档强烈建议开启它是模块出问题后唯一的自救通道。编译刷机后验证 KernelSU 生效验证分三层内核能启动、管理器能识别、su输出 root。先用 fastboot 刷入编译出的 boot确认设备正常开机并用下面的命令确认内核版本无误adb shell uname -r再打开管理器应用状态不再显示不支持而是识别出内核里的 KernelSU 版本。最后确认提权链路真正打通adb shell su -c id # 预期输出 uid0(root) gid0(root) groups0(root)输出uid0即适配完成。处理四个高频故障现象刷入后无法开机卡在 logo。原因kprobe 在该内核上工作不正常挂钩安装直接导致内核异常。解法按集成文档的验证方法注释掉 v0.9.5 源码kernel/ksu.c中的ksu_sucompat_init()和ksu_ksud_init()再编译测试若恢复正常即可确认是 kprobe 问题——要么修 kprobe要么转手动改 4 个位置的方案。现象没有按音量下键却进了安全模式。原因手动集成时没有禁用CONFIG_KPROBES开机按键事件被误判。解法defconfig 设CONFIG_KPROBESn重新编译。现象pm命令执行失败。原因devpts 设备点处理未被挂钩。解法在fs/devpts/inode.c的devpts_get_priv开头加一行ksu_handle_devpts(dentry-d_inode);补丁见集成文档的pm 命令执行失败小节。现象开了 KPROBES 配置但仍未生效。原因缺依赖项最常见的是CONFIG_MODULES。解法make menuconfig搜 KPROBES逐项启用其依赖。收尾的四条可执行建议刷机前备份原厂boot.img全程保留 fastboot 连接这是唯一可靠的回退路径。优先走 kprobe 方案确认它不工作再动手改内核源码手动改 4 处的工作量明显更大。手动集成时关闭CONFIG_KPROBES并开启安全模式两处改动成本极低却能避免误入安全模式和救不了砖。官方自 v1.0 起不再维护非 GKI 支持后续想升级 KernelSU 需要自行向新版本移植否则停留在 v0.9.5。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考