ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

KernelSU 项目概览与兼容性指南:基于 Android 内核的 Root 方案解析

KernelSU 项目概览与兼容性指南:基于 Android 内核的 Root 方案解析 KernelSU 项目概览与兼容性指南基于 Android 内核的 Root 方案解析【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU本文以 KernelSU 仓库中的意大利语 READMEdocs/README_IT.md为主体完整梳理 KernelSU 的核心功能、官方兼容性范围、安装与手动编译入口、翻译与安全的参与方式以及许可证边界并结合kernel/目录下的 Kconfig、UAPI 头文件与集成脚本补充各能力在内核侧的实际落点帮助你在部署、编译或二次开发前建立准确的项目认知。一、项目定位内核态的 Root 解决方案KernelSUKernel-based SuperUser是一个面向 Android 设备的基于内核的 root 方案原文“Una soluzione per il root basata sul kernel per i dispositivi Android”。与运行在用户空间的传统 root 工具不同KernelSU 将提权逻辑下沉到内核态通过kprobes挂钩系统关键调用点、在内核中管理 root 授权再由用户态的ksud守护进程和 Manager 应用与之协同工作。这一点在仓库结构上可以得到印证kernel/目录是内核侧全部代码挂钩、策略、SELinux、超调用通道等userspace/ksud/是 Rust 编写的用户态守护进程manager/是 Android 管理端应用三者通过 uapi/ksu.h 汇总的 UAPI 头文件supercall.h、app_profile.h、feature.h、selinux.h、sulog.h约定通信接口。二、核心功能README_IT 列出了三大功能特性下面逐项展开并指出其在仓库中的对应实现位置。1. 基于内核的su与 root 访问管理“sue accesso root basato sul kernel”——KernelSU 的 root 授权直接由内核完成内核维护各应用的允许/拒绝名单与 UID 级别的授权状态用户态进程通过内核超调用supercall通道向内核请求 root而不是依赖某个用户态二进制去修改自身权限。从源码结构看uapi/supercall.h 定义了整个内核/用户态接口的核心KERNEL_SU_UAPI_VERSION 3当前为 scoped su-session driver fd 协议版本KSU_IOCTL_GRANT_ROOTK, 1请求 rootKSU_IOCTL_GET_INFO查询内核版本号、UAPI 版本、支持的特性位以及KSU_GET_INFO_FLAG_LKM/KSU_GET_INFO_FLAG_MANAGER/KSU_GET_INFO_FLAG_LATE_LOAD/KSU_GET_INFO_FLAG_PR_BUILD等运行形态标志KSU_IOCTL_NEW_GET_ALLOW_LIST/KSU_IOCTL_NEW_GET_DENY_LIST分页查询允许/拒绝名单KSU_IOCTL_UID_GRANTED_ROOT、KSU_IOCTL_UID_SHOULD_UMOUNT按 UID 查询授权与模块挂载解除策略KSU_IOCTL_SET_SEPOLICY下发 sepolicy 规则配合KSU_SEPOLICY_CMD_*子命令序列。这些 ioctl 即 Manager 与ksud与内核交互的全部入口是理解 KernelSU 架构的关键文件。2. 基于 Metamodules 的模块系统“Sistema di moduli basato su metamodules: Infrastruttura modulare per modifiche systemless”——KernelSU 的模块系统建立在metamodules元模块之上提供面向 systemless 修改的可插拔基础设施。Metamodule 是一类特殊的模块普通模块负责修改系统文件而 metamodule 负责“普通模块如何被安装与挂载”这一基础设施层。仓库内置文档 website/docs/guide/metamodule.md 对其特性做了明确归纳基础设施角色metamodule 提供普通模块所依赖的服务单实例约束同一时间只能安装一个 metamodule优先执行metamodule 的脚本先于普通模块脚本运行三个钩子脚本分别覆盖安装、挂载与清理阶段。这种设计的直接收益是KernelSU 内核本体不执行挂载逻辑从而缩小检测面、保持核心稳定挂载策略overlayfs、兼容 Magic mount、完全不挂载等交由社区 metamodule如官方参考实现meta-overlayfs独立演进。文档同时强调一条关键限制若未安装任何 metamodule模块不会被挂载——全新安装的 KernelSU 必须先装入 metamodule 模块才能生效。内核侧对 metamodule 的识别与处理逻辑位于 kernel/metamodule.rs 所对应的用户态与 kernel/manager/ 相关模块中。3. App Profile把 root 能力关进笼子“App profile: Limita i poteri dellaccesso root a permessi specifici”——App Profile 允许按应用粒度收紧 root 权限把“root 权力”限制在特定 UID/GID、补充组、capabilities 与 SELinux 域之内。其内核/用户态共享的数据结构定义在 uapi/app_profile.h核心字段包括struct root_profile { __s32 uid; /* 目标 UID */ __s32 gid; /* 目标 GID */ __u32 groups_count; __s32 groups[KSU_MAX_GROUPS]; /* 最多 32 个补充组 */ struct { /* capabilities v3u32[2] */ __u64 effective; __u64 permitted; __u64 inheritable; } capabilities; char selinux_domain[KSU_SELINUX_DOMAIN]; /* 自定义 SELinux 域 */ __s32 namespaces; /* 命名空间标志 */ __u64 flags; /* 如 FLAG_KSU_NO_NEW_PRIVS */ }; struct app_profile { __u32 version; /* 当前 KSU_APP_PROFILE_VER 4 */ char key[KSU_MAX_PACKAGE_NAME]; /* 应用包名特殊应用可取其他值*/ __s32 curr_uid; bool allow_su; union { struct { bool use_default; char template_name[...]; struct root_profile profile; } rp_config; /* root 配置 */ struct { bool use_default; struct non_root_profile profile; } nrp_config; /* 非 root 配置 */ }; };也就是说App Profile 同时覆盖两种情形应用允许su 时的受限 root 画像UID、capabilities、SELinux 域、命名空间等以及应用拒绝root 时的non_root_profile如是否umount_modules解除模块挂载。内核侧对应的读写 ioctl 为KSU_IOCTL_GET_APP_PROFILE/KSU_IOCTL_SET_APP_PROFILE实现代码位于 kernel/policy/app_profile.c 与 kernel/policy/allowlist.c。三、兼容性状态CompatibilityREADME_IT 对兼容性的表述需要逐条掌握它直接决定了“你的设备能否直接刷 KernelSU 镜像”1. 内核版本要求官方支持Android GKI 2.0 设备即kernel 5.10 及以上。旧内核kernel 4.14 也兼容但必须手动编译内核见下文“手动编译”小节官方预编译镜像只覆盖 GKI 2.0。从内核配置看KernelSU 对自身运行环境有两项硬性依赖见 kernel/Kconfigconfig KSU tristate KernelSU function support depends on KPROBES EXT4_FS即CONFIG_KPROBES内核挂钩能力与CONFIG_EXT4_FS用于ext4_unregister_sysfs缺一不可KSU本身是tristate意味着既可以编入内核也可以编译为名为kernelsu的内核模块LKM 模式对应KSU_GET_INFO_FLAG_LKM标志。2. 覆盖的“Android 形态”得益于 GKI 2.0 的通用性README 指出WSAWindows Subsystem for Android、ChromeOS 以及所有基于容器/虚拟化运行的 Android 变体均在其支持范围内——只要其内核满足上述条件即可。3. 支持架构当前支持arm64-v8a与x86_64两种架构。这与仓库的构建配置一致justfile 中build_ksud目标以--target aarch64-linux-android交叉编译用户态组件内核侧挂钩实现也按架构分目录维护见 kernel/hook/arm64/syscall_hook.c 与 kernel/hook/x86_64/syscall_hook.c。4. x86_64 特别警告README 中有一条醒目的注意CAUTION近期内核版本引入的一项变更会导致 KernelSU 在x86_64上失败并可能触发内核恐慌kernel panic。请以官方站点信息为准。从内核配置看x86_64上确有特殊处理点kernel/Kconfig 提供了KSU_X86_PATCH_SYSCALL_DISPATCHER选项——config KSU_X86_PATCH_SYSCALL_DISPATCHER bool Dynamically patch x64s hardened syscall dispatcher to support syscall hooks depends on KSU X86_64 default n用于在 LKM 模式下动态修补 x64 的加固 syscall dispatcher 以支持 syscall 挂钩对应实现位于 kernel/hook/x86_64/patch_memory.c。因此 x86_64 环境WSA、x86 容器等在部署前应确认目标内核版本与该选项的组合是否受上述变更影响。5. 与 Manager 集成的可选裁剪除兼容性外Kconfig 还暴露了两个可裁剪开关对“非标准部署”场景如只要 root、不要 Manager有实际意义KSU_DISABLE_MANAGER禁用 Manager APK 的检测与 Manager 专属处理相关功能退化为纯 root 行为KSU_DISABLE_POLICY禁用按应用的 root/non-root 画像定制提权始终使用默认完整 root 画像非 root 处理仅遵循全局 umount 策略。四、使用方式安装与手动编译README 的 “Utilizzo” 一节指向三条路径安装说明、手动编译说明、官方网站。仓库内与这三条路径直接对应的资源如下。1. 安装GKI 2.0 设备官方安装流程在文档站上README 指向 installation 指南从 Release 下载与设备对应的kernelsu_xxx_xxxx.zip镜像刷入 boot 分区再安装 Manager 应用授权。仓库内的 Release 工件由 scripts/ksubot.py 等脚本流水线产出本文不展开细节操作以安装指南为准。2. 手动编译内核侧集成脚本对于 4.14 旧内核或需要自定义编译的场景KernelSU 提供了集成脚本 kernel/setup.sh它在你的 GKI 内核源码树中完成如下工作Usage: setup.sh [--cleanup | commit-or-tag] --cleanup: 清理脚本之前的改动。 commit-or-tag: 将 KernelSU 集成/更新到指定 tag 或 commit。 (无参数): 集成到最新 tag 版本。具体行为见脚本setup_kernelsu()在 GKI 根目录克隆 KernelSU 仓库并检出目标版本在drivers/下创建指向KernelSU/kernel的符号链接kernelsu向drivers/Makefile追加obj-$(CONFIG_KSU) kernelsu/向drivers/Kconfig插入source drivers/kernelsu/Kconfig。之后即可按常规内核流程编译config KSU在 menuconfig 的 “KernelSU” 菜单下启用。--cleanup会完整回滚上述改动删符号链接、还原 Makefile/Kconfig、删除 KernelSU 目录。3. 手动编译用户态组件用户态部分ksud守护进程与 Manager APK可用 justfile 提供的命令一键构建just build_ksud # cross build --target aarch64-linux-android --release just build_manager # 先 build_ksud复制产物为 libksud.so再 cd manager ./gradlew aDebug just clippy # cargo fmt cross clippy 检查注意build_manager依赖build_ksud的产物路径target/aarch64-linux-android/release/ksud二者必须同一仓库内顺序执行。4. 官方站点README 指向官方站点安装/编译/下载的权威入口遵循“以仓库实际内容为准”的原则本文不重复其站外内容。五、翻译TraduzioniREADME_IT 的翻译一节说明帮助翻译 KernelSU 或改进现有翻译请使用 Weblate由于会与 Weblate 冲突不再接受针对 manager 翻译的 Pull Request。需要提示读者注意仓库主 docs/README.md 的 Translation 一节当前表述为“所有翻译改由 LLM 处理不再通过 Weblate 接受翻译贡献新增语言欢迎提 PR”。两处表述存在时间差——意大利语文档保留了 Weblate 时代的旧说明。实际参与前应以主 README 的最新表述与官方渠道为准。六、安全Securezza安全漏洞报告流程由 SECURITY.md 定义KernelSU 团队认真对待安全缺陷负责任披露可经由 GitHub Security Advisory 的 “Report a Vulnerability” 入口或直接邮件联系维护者weishu。团队会在回复中说明后续处理步骤并在修复与公开公告过程中持续同步进展、必要时请求补充信息。涉及内核挂钩、supercall 鉴权如 uapi/supercall.h 中的KSU_INSTALL_MAGIC1/2魔数校验等内核侧代码的问题建议报告时附带设备内核版本、架构arm64/x86_64、是否 LKM 模式等复现上下文。七、许可证LicenzaREADME 明确给出了双许可证边界对二次开发者非常重要kernel/目录下的文件按GPL-2.0-only提供见 kernel/LICENSEkernel/之外的所有部分按GPL-3.0-or-later提供见根目录 LICENSE。因此在分发修改版内核模块时须遵守 GPL-2.0-only 义务而用户态ksud、Manager 等组件适用 GPL-3.0-or-later。八、致谢与来源RiconoscimentiREADME 列出了四个上游思想来源理解它们有助于把握 KernelSU 的技术基因kernel-assisted-superuserKernelSU 的原始构想来源内核辅助的超级用户机制Magisk强力的 root 工具其 systemless 模块生态是 KernelSU 模块与 metamodule 体系兼容的对象genuineAPK v2 签名校验对应仓库中 kernel/manager/apk_sign.c 与 userspace/ksud/src/apk_sign.rs 的 manager APK 签名验证逻辑KSU_GET_INFO_FLAG_PR_BUILD等标志也与此相关Diamorphine部分 rootkit 能力如内存修补、隐藏能力的先驱实现与 kernel/hook/*/patch_memory.c 一类的内核内存修补代码同属一脉。九、小结与快速核对清单部署或集成 KernelSU 前可用这份清单对照本文各节检查项依据设备是否为 GKI 2.0kernel 5.10旧内核4.14需手动编译docs/README_IT.md 兼容性节架构是否为arm64-v8a或x86_64x86_64 是否命中近期内核变更的警告同上 x86_64 CAUTION内核配置是否开启CONFIG_KPROBES、CONFIG_EXT4_FSkernel/Kconfig是否安装 metamodule否则模块不挂载website/docs/guide/metamodule.md需要裁剪 Manager/Policy 集成时是否了解KSU_DISABLE_MANAGER/KSU_DISABLE_POLICYkernel/Kconfig手动编译走kernel/setup.sh 常规内核编译用户态走just build_ksud/just build_managerkernel/setup.sh、justfile二次开发的许可证边界kernelGPL-2.0-only其余GPL-3.0-or-laterLICENSE、kernel/LICENSE按此完成核对后即可根据官方安装/编译指南完成部署并借助 uapi/supercall.h、uapi/app_profile.h 等 UAPI 定义深入内核交互细节。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表