旧内核也能刷 KernelSU4.14–5.3 设备从判断到开机的 5 步手动适配【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU用了五六年、还跑着 Linux 4.19 的老旗舰装上 KernelSU 管理器第一屏就提示不支持。其实只要这块旧内核的版本在 4.14 及以上、内核源码是开放的这台设备完全可以手动适配。下面是具体走法。 先判断你的设备要不要自己编译内核结论先行内核版本决定路线GKI 设备根本不用碰源码。先跑一条命令拿内核版本号adb shell uname -r # 输出示例4.19.191-android11-8-gb2f41e6再对照管理器的支持提示你属于三种情况之一GKI 内核5.4 / 5.10 / 6.x管理器直接可用刷官方预编译 boot 就行后面这些内容你可以关掉了。4.14–5.3 且内核源码开放手动适配的目标人群。路线只有两条——kprobe 自动集成或者手改内核源码kprobe 能用就走第一条不能用才动刀。源码不开放 / 编译不出能开机的 boot / 版本低于 4.14不建议折腾。以下全部内容属于非官方支持风险自担。还有一个硬事实要记住KernelSU 自 v1.0 起放弃非 GKI 支持最后一个支持旧内核的 tag 是v0.9.5后面所有操作都用这个版本。 原理 30 秒KernelSU 为什么非要改内核KernelSU 运行在内核层权限判定和隐藏逻辑必须在系统调用返回用户空间之前生效所以它必须存在于内核里。GKI 内核上它以可加载模块身份挂入靠 kprobe 动态 hook 目标函数而很多 4.x 老内核的 kprobe 机制本身是坏的模块一挂就死机。这就是适配时的分叉点要么验证 kprobe 能不能用要么手动在 4 个系统调用入口处各插一句 hook 调用——exec、access 检查、read、stat 四条路正好覆盖 su 和隐藏逻辑的全部路径。️ 适配时间线从源码到刷 boot 的 5 步1. 准备源码先确认能编出能开机的 boot用你设备对应的内核源码厂商源码优先。在集成任何东西之前先按原厂流程编出一张能正常开机的 boot 镜像如果连这一步都做不到说明内核闭源或工具链不全直接停手别往下走。2. 集成 KernelSU 源码先克隆仓库并切到 v0.9.5 这个 taggit clone https://gitcode.com/GitHub_Trending/ke/KernelSU cd KernelSU git checkout v0.9.5然后把 KernelSU 目录放在内核源码树的同级位置在内核根目录执行下面三行。它们等价于kernel/setup.sh做的事把内核代码挂进drivers/再登记到构建系统里。ln -s ../KernelSU/kernel drivers/kernelsu echo obj-$(CONFIG_KSU) kernelsu/ drivers/Makefile sed -i /endmenu/i source drivers/kernelsu/Kconfig drivers/Kconfig构建系统只多了两行登记万一出问题把这三处直接还原即可改动面很小。3. 打开 Kconfig 配置在你的设备 defconfig 里追加以下内容位置通常在arch/arm64/configs/设备代号_defconfig也可能是arch/arm64/configs/vendor/设备代号_defconfigCONFIG_KSUy CONFIG_KPROBESy CONFIG_HAVE_KPROBESy CONFIG_KPROBE_EVENTSy如果你判断 kprobe 大概率是坏的、准备一上来就走手改源码路线就把CONFIG_KPROBES直接设为n原因见后面的踩坑清单第 2 条。4. 选钩子路线kprobe 优先手改兜底路线 A推荐kprobe 在你内核里能正常工作就到此为止直接编译KernelSU 运行时自己完成 hook不改任何其他源码。路线 B刷入后开不了机优先怀疑 kprobe 失效。改用手改在 4 个函数入口各加一次 hook 调用。最核心的fs/exec.c中do_execveat_common长这样static int do_execveat_common(int fd, struct filename *filename, struct user_arg_ptr argv, struct user_arg_ptr envp, int flags) { #ifdef CONFIG_KSU if (unlikely(ksu_execveat_hook)) ksu_handle_execveat(fd, filename, argv, envp, flags); else ksu_handle_execveat_sucompat(fd, filename, argv, envp, flags); #endif return __do_execve_file(fd, filename, argv, envp, flags, NULL); }其余三处是同样的模式在函数入口前加对应的extern声明再插一行调用。分别是fs/open.c的do_faccessat4.17 以下的老内核没有这个函数直接改SYSCALL_DEFINE3(faccessat, ...)定义处、fs/read_write.c的vfs_read、fs/stat.c的vfs_statx没有 statx 就用vfs_fstatat顶替。想保留安全模式还要在drivers/input/input.c的input_handle_event里加一个输入 hook这一步强烈建议做救砖时靠它进安全模式。5. 编译并用 fastboot 验证开机先确认配置真的生效再编译命令以你设备厂商的构建方式为准这里给 arm64 通用示例grep -E ^CONFIG_KSU .config # 应输出 CONFIG_KSUy make -j$(nproc)在永久写入之前务必用 fastboot 临时启动来验证——这一步不写设备重启就回到原内核把风险全部消化在这里fastboot boot boot-ksu.img adb shell su -c id # 输出 uid0(root) 即成功连续正常开机 5 次以上再做永久刷写。⚠️ 适配踩坑四种几乎必碰的情况1. 卡在 logo 开不了机原因这个内核里 kprobe 工作不正常模块挂入即死机。 处理fastboot flash boot刷回备份恢复把CONFIG_KPROBES改为n改走路线 B 手改源码。2. 莫名其妙进了安全模式su 和模块全没了原因手改源码集成但CONFIG_KPROBES没关kprobe 的输入 hook 残留开机时按音量下就触发了安全模式。 处理关闭CONFIG_KPROBES重新编译。3. 开机正常但pm命令执行失败原因devpts 路径没有被 hook。 处理在fs/devpts/inode.c的devpts_get_priv函数开头加一行ksu_handle_devpts(dentry-d_inode);并在函数前声明extern int ksu_handle_devpts(struct inode *);。4. 编译报vfs_statx或do_faccessat未定义原因内核太老这两个函数还没从老函数里拆出来。 处理stat 用vfs_fstatat顶替access 直接挂在faccessat系统调用定义上改法见时间线第 4 步。 收尾必须记住的四件事在动任何东西之前先备份原始 boot管理器内置备份或fastboot flash boot 备份镜像.img随时能刷回。永久刷写之前务必先用fastboot boot临时启动验证正常开机 5 次再写入。整个流程是非官方支持风险自担卡住先对照非 GKI 内核集成文档文档已标注存档、不再更新完全开不了机时看bootloop 救援指南。旧内核只认 v0.9.5别拿 1.x 的 tag 往下走编译都过不了。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
