系统编程移动开发【免费下载链接】APatchThe patching of Android kernel and Android system项目地址https://gitcode.com/gh_mirrors/ap/APatch点击查看免费下载APatch 是一个新的内核级 root 解决方案与 Magisk、KernelSU 并列但技术路线截然不同它直接补丁 Android 内核本身而非修改 ramdisk 中的 init 系统。本文基于docs/BG/faq_bg.md保加利亚语 FAQ 展开结合apd守护进程源码深入解析 APatch 的定位、SuperKey/SuperCall 鉴权体系、SELinux 处理方式、Kernel Patch ModuleKPM以及它与 KernelPatch 的继承关系帮助读者完整理解这套架构的底层原理与实现证据。APatch 是什么与 Magisk、KernelSU 的定位对比FAQ 开篇即给出 APatch 的定位它是一个类似于 Magisk 或 KernelSU 的 root 解决方案但“结合了两者的优点”——既具备 Magisk 通过boot.img便捷安装的易用性又拥有 KernelSU 那种直接补丁内核的强大能力。从 README.md 可以确认其更完整的定位项目描述为 The patching of Android kernel and Android system即补丁 Android 内核与 Android 系统本身它是一个新的**基于内核kernel-based**的 root 解决方案支持两类模块APMAPatch Module类似 Magisk 的模块体系KPMKernel Patch Module允许向内核注入任意代码的内核模块提供内核函数inline-hook与syscall-table-hook能力。同时 README 明确了 APatch 的依赖与血缘它依赖于 KernelPatch 项目其 UI 与 APModule 源码派生自 KernelSU。支持的版本与前置条件根据 README 的说明使用 APatch 需要关注以下前提条件这与 FAQ 中“仅需标准 boot.img”的描述相互印证仅支持 ARM64 架构仅支持 Android 内核版本 3.18 – 6.12内核需开启CONFIG_KALLSYMSy若同时开启CONFIG_KALLSYMS_ALLy则获得完整支持仅开启前者为初始支持状态对带安全保护的 Samsung 设备支持处于计划中。APatch 与 Magisk 的本质区别补丁位置不同FAQ 明确指出 APatch 与 Magisk 的核心差异在于补丁的落点Magisk 通过补丁 boot image 的 ramdisk 来修改 init 系统而 APatch 直接补丁内核kernel本身。这一区别决定了二者架构上的分水岭Magisk 是在用户空间userspace层面通过修改 init 流程实现 root而 APatch 将补丁注入到内核镜像中root 能力直接由内核提供。从仓库源码可以找到与之呼应的实现细节apd/src/insmod.rs 中的insmod命令展示了 APatch 在内核层面工作的方式——它通过init_module(2)系统调用加载内核模块.ko并且绕过了内核严格的版本/符号校验未定义符号通过/proc/kallsyms解析并手动重定位从而允许预编译的kernelpatch.ko在标准stock内核上加载用于 jailbreak越狱模式。APatch 与 KernelSU 的区别是否需要内核源码FAQ 对比了 APatch 与 KernelSU 的关键差异KernelSU 需要设备内核的源代码而厂商并不总是提供APatch 仅使用标准的boot.img即可工作。这是 APatch 在可及性上的核心优势KernelSU 的典型用法需要针对具体内核源码编译而 APatch 面向的是公开发布的boot.img镜像对普通用户更加友好同时保持了内核级 root 的能力。源码佐证late-load 的 jailbreak 流程apd/src/late_load.rs 展示了这种“仅凭 boot.img / 预编译模块即可工作”的具体实现路径apd late-load命令会在标准内核上加载对应 KMIKernel Module Interface如android14-5.15的kernelpatch.ko模块然后实时应用 Magisk SELinux 策略并重启管理器应用。若未显式指定模块路径它会通过uname解析内核版本自动探测 KMI并在/data/adb/ap/{kmi}_kernelpatch.ko查找模块——这正是 FAQ 所说“只需标准 boot.img”的工程化落地。可选不修改 SELinuxAPatch 相对 Magisk/KernelSU 的独特优势FAQ 用一个专门小节阐述了 APatch 在 SELinux 处理上的独特能力APatch 允许选择性地不修改 SELinux这意味着应用线程本身就可以被授予 root 权限而无需 libsu 和 IPC。这句话包含两层含义APatch 可以不修改 SELinux 策略。与 Magisk 通常需要打补丁 SELinux 策略不同APatch 的架构允许跳过这一步root 权限可以直接作用于应用线程自身。传统方案中应用进程要获取 root通常需要通过 libsu 启动一个新的进程并通过 IPC 与其通信而在 APatch 的模型下应用自身的线程即可被提权为 root无需进程间通信。这一特性在后续“SELinux 处理方式”小节会结合源码进一步展开它正是 SuperCall 架构带来的直接收益。Kernel Patch ModuleKPM在内核空间执行的模块FAQ 对 KPM 给出了定义某些代码在内核空间Kernel Space执行类似于可加载内核模块LKM。此外KPM 允许在内核空间进行 inline-hook 和 syscall-table-hook。KPM 是 APatch 体系中区别于 Magisk 模块纯用户空间的另一类模块它以类似 LKM 的方式在内核空间运行代码并提供两种内核层面的挂钩能力inline-hook在函数入口处直接改写指令流实现对内核函数调用的拦截syscall-table-hook修改系统调用表拦截或重定向系统调用。源码佐证KPM 模块的加载路径KPM 的加载由 apd 守护进程承载。apd/src/insmod.rs 的注释说明这是 KernelSUksuinit::load_module的直接移植——它让预构建的kernelpatch.ko能在标准内核上加载通过临时设置kptr_restrict读取/proc/kallsyms获得符号地址将模块中未定义的符号手动重定位为绝对地址SHN_ABS再通过init_module(2)系统调用加载从而同时绕过 per-symbol 的 modversionsCRC校验与 vermagic 校验。此外 apd/src/cli.rs 中定义了apd insmod module [params...]子命令参数支持keyval key2val2形式的模块加载参数并在成功后打印Loaded kernel module。APatch 与 KernelPatch 的关系继承与扩展FAQ 阐明了 APatch 与 KernelPatch 的依赖关系APatch 依赖于 KernelPatch继承了它的全部能力并进行了扩展。可以只安装 KernelPatch但那将无法使用 Magisk 模块。解读如下KernelPatch 是内核层的基础设施提供了内核补丁的核心能力APatch 构建在 KernelPatch 之上继承其全部内核能力并在此基础上扩展出 Magisk 模块兼容支持APM两者可以分离使用单独安装 KernelPatch 也能获得内核级能力但无法使用 Magisk 模块——因为 Magisk 模块支持属于 APatch 层的扩展功能。从代码结构上看这种“继承与扩展”体现为 apd 守护进程同时承载两类职责既有insmod/late-load这类与 KernelPatch 内核模块直接交互的命令apd/src/insmod.rs、apd/src/late_load.rs也有module install/uninstall/enable/disable这类 Magisk 风格模块管理命令apd/src/cli.rs。运行时路径布局apd/src/defs.rs 定义了这套体系在设备上的目录约定可作为理解“KernelPatch 层 APatch 扩展层”的参考常量路径用途WORKING_DIR/data/adb/ap/APatch 工作目录BINARY_DIR/data/adb/ap/bin/二进制与 su 命令路径DAEMON_PATH/data/adb/apdapd 守护进程路径MODULE_DIR/data/adb/modules/APMMagisk 风格模块目录MODULE_UPDATE_DIR/data/adb/modules_update/模块更新目录AP_RC_PATH/data/adb/ap/.aprcroot shell 的 ENV 初始化脚本SuperKey 与 SuperCall内核级鉴权的系统调用FAQ 对 SuperKey 给出了权威定义KernelPatch 添加了一个新的系统调用syscall为用户空间的应用程序与程序提供全部能力这个 syscall 被称为SuperCall。当应用/程序尝试调用 SuperCall 时必须提供一个名为SuperKey的标识密钥。只有 SuperKey 正确时 SuperCall 才能被成功调用否则调用方不受影响。源码佐证SuperCall 的调用实现apd/src/supercall.rs 是理解 SuperCall 的最好入口其中定义了与内核约定的关键常量const __NR_SUPERCALL: c_long 45; const SUPERCALL_SU: c_long 0x1010; const SUPERCALL_KSTORAGE_WRITE: c_long 0x1041; const SUPERCALL_SU_GRANT_UID: c_long 0x1100; const SUPERCALL_SU_REVOKE_UID: c_long 0x1101; const SUPERCALL_SU_NUMS: c_long 0x1102; const SUPERCALL_SU_LIST: c_long 0x1103; const SUPERCALL_SU_RESET_PATH: c_long 0x1111; const SUPERCALL_SU_GET_SAFEMODE: c_long 0x1112;可以看到 SuperCall 是一个带版本编码的命令系统ver_and_cmd()将 KernelPatch 版本号KP_MAJOR 16 KP_MINOR 8 KP_PATCH左移 32 位与命令号组合调用方式统一为syscall(__NR_SUPERCALL, key_ptr, ver_and_cmd(cmd), ...)。这印证了 FAQ 的两点描述必须携带 SuperKey所有sc_*函数的第一步都是检查key.to_bytes().is_empty()空密钥直接返回-EINVAL只有密钥正确内核才会执行对应操作失败调用方不受影响密钥错误时内核拒绝执行调用方保持原状态。源码中 SuperCall 的实际用途包括以SuProfile { uid, to_uid, scontext }为应用授权 rootSUPERCALL_SU_GRANT_UID、撤销授权、列出已授权 UID、设置 su 路径SUPERCALL_SU_RESET_PATH读取/data/adb/ap/su_path文件以及查询安全模式状态SUPERCALL_SU_GET_SAFEMODE。refresh_ap_package_list()展示了这套机制的管理闭环先枚举全部已授权 UID跳过0root与2000shell等关键 UID撤销其余授权后按包配置重新逐个授权并将exclude的应用通过 KStorage 写入排除列表。SuperKey 的安全警示README 针对 SuperKey 给出了明确的安全提示应作为使用本方案的重要前提SuperKey 的权限高于 root 访问权限。弱密钥或泄露的密钥可能导致设备被未授权控制。务必使用强密钥并妥善保管以维护设备安全。这解释了为什么 FAQ 强调“SuperCall 只有 SuperKey 正确时才能成功调用”——SuperKey 本质上是内核级能力的唯一门禁其安全等级高于普通 root 授权。SELinux 处理方式绕过而非修改FAQ 的“那 SELinux 怎么办”小节给出了核心结论KernelPatch 不修改 SELinux 上下文而是通过 hook 绕过它。这允许在应用自身上下文中为应用线程提供 root 访问而无需使用 libsu 启动新进程并做 IPC。这非常方便。这段描述与“可选不修改 SELinux”一节形成完整逻辑闭环KernelPatch 的策略是不触碰 SELinux 策略本身而是通过内核 hook 在访问控制层面直接绕过从而让应用线程无需切换到su域的独立进程即可获得 root 能力。源码佐证 1SuperCall 直接授予应用线程 root在 apd/src/supercall.rs 的privilege_apd_profile()中可以看到具体实践它构造SuProfile将scontext设置为u:r:magisk:s0to_uid为 0然后通过sc_su()调用 SuperCall 将调用线程直接提权为 root——全程没有启动新进程、没有 libsu、没有 IPC正是 FAQ 所描述的场景。源码佐证 2magiskpolicy 作为“额外支持”FAQ 还提到此外APatch 直接使用 magiskpolicy 来提供额外的 SELinux 支持。apd/src/sepolicy.rs 完整实现了这一工具其结构是 Magisk 的magiskpolicySELinux Policy Patch Tool移植主要选项包括选项含义--load FILE从 FILE 加载 monolithic sepolicy--load-split从预编译 sepolicy 加载或编译 split cil 策略--compile-split编译 split cil 策略--save FILE将 monolithic sepolicy 导出到 FILE--live立即将策略加载进内核写入/sys/fs/selinux/load--magisk应用内置的 Magisk sepolicy 规则--apply FILE逐行解析并应用规则文件可多次指定--print-rules打印已加载策略的全部规则apply_magisk_policy_live()函数等价于magiskpolicy --magisk --live即从/sys/fs/selinux/policy加载当前策略、套用 Magisk 内置规则、再写回/sys/fs/selinux/load实时生效。这套“默认通过 hook 绕过 SELinux 按需用 magiskpolicy 补充策略”的双轨设计正是 FAQ 所描述的 APatch 的 SELinux 策略全貌。apd 与 su 命令从内核提权到用户空间 shell虽然 FAQ 未直接提及但为了完整理解“应用线程被 root 后如何获得可用 shell”可以从 apd/src/apd.rs 的root_shell()看到该体系与 su 命令的衔接方式apd/src/cli.rs 中的注释说明——内核执行 su 时会把 argv[0] 设为/system/bin/kp或/system/bin/suapd 检测到argv[0]以kp或su结尾时进入root_shell()分支。root_shell()实现的 su 兼容层包含以下参数与 Magisk 行为保持一致代码注释明确参考了 Magisk 的su_daemon.cpp-c COMMAND向被调用的 shell 传递命令-l/--login以登录 shell 方式运行-p/--preserve-environment保留整个环境-s SHELL指定 shell默认/system/bin/sh-M/--mount-master强制在全局挂载命名空间运行-g GROUP/-G GROUP指定主组与附加组-Z/--context兼容旧版 root 应用的 SELinux 上下文参数当前实现不切换上下文仅告警忽略-mm、-cn、-z等旧参数会被映射到新参数以兼容 Magisk 调用约定。shell 启动时还会将/data/adb/ap/bin追加到 PATH、在存在/data/adb/ap/.aprc时将其作为ENV注入并根据/data/adb/.global_namespace_enable文件内容或-M参数决定是否切换到全局挂载命名空间。这些细节共同构成了从“SuperCall 授予线程 root”到“可用的 root shell”的完整链路。总结通过docs/BG/faq_bg.md与仓库源码的对照可以清晰勾勒出 APatch 的技术全貌定位一个介于 Magiskboot.img 便捷安装与 KernelSU内核级能力之间的新 root 方案核心卖点是直接补丁内核、仅需标准 boot.img架构以 KernelPatch 为内核基础设施SuperCall/ SuperKey 鉴权、KPM 内核模块、hook 绕过 SELinuxAPatch 在其上扩展出 Magisk 兼容模块APM与完整的管理工具链apd安全性SuperKey 是内核级能力的唯一门禁权限高于 root必须使用强密钥并妥善保管SELinux默认通过 hook 绕过而非修改因此应用线程可原地提权需要时可用 magiskpolicy 工具补充策略。如需进一步深入可继续阅读 README.md、apd/src/supercall.rs、apd/src/insmod.rs、apd/src/sepolicy.rs 以及 apd/src/cli.rs 中的对应实现。赞分享系统编程移动开发【免费下载链接】APatchThe patching of Android kernel and Android system项目地址https://gitcode.com/gh_mirrors/ap/APatch点击查看免费下载相关推荐APatch 技术指南基于 KernelPatch 的 Android 内核级 Root 方案深入解析APatch 技术指南基于 KernelPatch 的 Android 内核级 Root 方案深入解析 APatch 是一款面向 Android 设备的 内核系统编程移动开发APatch 内核级 Root 方案全解析APatch、KernelPatch、SuperKey 与 KPM 内核补丁模块一文读懂APatch 内核级 Root 方案全解析APatch、KernelPatch、SuperKey 与 KPM 内核补丁模块一文读懂 本篇技术指南以官方 FAQ系统编程移动开发APatch 深度解析内核级 Root 方案、KernelPatch 与 SuperKey 安全模型APatch 深度解析内核级 Root 方案、KernelPatch 与 SuperKey 安全模型 APatch 是一款面向 Android 设备的内核级系统编程移动开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考