hmascs/ksurootOne-click Android kernel rooting tool exploiting CVE-2026-43499 to install KernelSU, with official, bundled, and custom .so payload sources.
⚠️ 温馨提示：蓝厂机型调度策略较为严格，提权时子进程易被系统回收。请先在「开发者选项」中开启「停止限制子进程」后再执行提权，成功率更高。
基于 CVE-2026-43499（GhostLock） 内核漏洞的一键 KernelSU 提权工具。
本分支以 KSuRoot 为蓝本，完整同步 Root-My-Galaxy v0.2.6 主线更新，并在此基础上增加了载荷构建、厂商载荷内置与一整套液态玻璃 UI。
Mod by hmascs · 版本 4.1.2 · Apache-2.0 仓库：https://github.com/hmascs/KSuRoot
vr.ko 给来自 app 的 task 打标记，那个偏移有 0x04 / 0x06 两种，而且是编译期
烤进载荷、patch 不了的。更麻烦的是同一台设备的两份 vr.ko 就各一种
（Y300 Pro+ 的 vendor_boot 里就有两份，srcversion 完全相同）——
选错的表现是「清错字节、标记没抹掉、子进程照样被杀」，而日志里一切正常。
现在蓝厂方案会要求你给一份 vendor_boot.img：应用从里面那份实际加载的
lib/modules/vr.ko 读出本机真正的偏移，再改写载荷。四份自带/自编库
（libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack）都强制配自己的档位，
选岔了会被零命中闸门当场拦下，而不是给你一个原样拷贝的产物。
另外新增**「导入完整刷机包」**：直接选你下载的 OTA zip 或 fastboot tgz，
它自己把 boot 和 vendor_boot 取出来，不用你先解压、也不用手动提取。
⚠️ 完整包要整份拷进应用缓存才能随机读（ZIP 中央目录在包尾，而 SAF 的 uri 变不成 File）。空间不够会当场拒绝，抽完立刻删缓存。
4.1.2 = 4.1.0 + 19 个提交。 这些提交原本停在 fix/baseline-routing 分支上，
现已并入 main。已发布的 4.1.0 安装包不含它们 —— 下面每一条都是那之后才修掉的。
| # | 缺陷 | 后果 |
|---|---|---|
| 1 | 6.1 的 VR_TAG_A_OFF 填成 0x06（实测该是 0x04） | 蓝厂 6.1 机型上标记一个字节都没抹掉，而自检报成功。表现是"提权成功之后子进程立刻被杀"，看不出是这个原因 |
| 2 | kallsyms 偏移表定位用了负数取模（Python 语义直译） | 6.4+ 内核整档失败，基址取到一段 ASCII 文本 |
| 3 | 偏移表判据只看「前三项单调」 | 几乎零区分度（表内任意位置都单调）；已改成查表的形状 |
| 4 | BASELINE_6_12.imageBase 填成目标基址 | 绝对地址形式的构造点全部漏改（39 处 → 9 处） |
| 5 | 符号对不齐时只置空产物、gate 仍是 Proceed | blocked=false 且产物 0 B，UI 不弹阻断框 |
| 6 | FopsSlot 的 fallback 从来没被用上 | 表找不到就直接放弃，退不到备用符号 |
TARGET_ASHMEM_FOPS_UNSYMBOLED）07-文档/6.1-6.12-双方案清单.md0x04，6.6 / 6.12 = 0x06（三台真机厂商固件里的 vr.ko）载荷构建/）：此前仓库里有 15 处引用指向一个不存在的目录X100 Pro（6.1.145）跑构建的结果是：
偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移
这不是"没什么可改"，是"这两样东西不是一套"。 根因是两条独立的路选岔了：
| 选什么 | 按什么选 | 6.1.145 上选到 |
|---|---|---|
| 基础库 | 结构体族（F6_1） | libbaseline_6_1.so（旧值来自 baseline-6.1-tokay/target.h） |
| 档位 | 三级路由（内核串） | up-6-1-145-…（旧值来自 GhostLock 的 offsets.h） |
打补丁的方式是「拿档位里的旧值去 .so 里找字面量」。两套旧值毫无交集， 所以 26 项一处都匹配不上，产物等于把基础库原样拷贝了一份。
为什么原来的硬闸门没拦住：hasFailures 的判据是 changed && !ok && !absent ——
absent 被明确排除在外。那个理由（"老版本 .so 可能没有对应代码路径"）对个别键成立，
对"全部键都 absent"不成立。
修法两条：
libbaseline_6_1.so / libbaseline_6_12.so）
必须配它自己的档（baseline-6-1-tokay / baseline-6-12-honor），
上游 up-* 档只适用于上游那份 .so。新增 BaselineLibraries.profileIdForLibrary()。SpecOutcome 加了 kind 字段。回归用例在 BaselineLibraryPairingTest（4 条），其中一条直接断言两套旧值没有交集 ——
把"为什么必须配对"变成了可执行的事实。
| # | 缺陷 | 后果 |
|---|---|---|
| 1 | 「载荷构建 → 用作载荷」用的是内存里的产物，进程被回收后 outputLibrary 为 null，而旧代码是 ?: return | 点了什么都不会发生：没 Toast、没报错、按钮不变 —— 用户看到的就是"点了没用" |
| 2 | PayloadStaging 的缓存键是「同名 + 同长度」 | 自定义载荷在私有目录里固定叫 payload.so，换一份字节数恰好相同的载荷时会静默复用上一份 |
| 3 | shizukuStage 的缓存键只有长度 | 同一个坑在 Shizuku 路径上又踩一次 |
| 4 | 只能存一份自定义载荷 | 导入第二份就覆盖第一份，没有提示 |
| 5 | 文件全在应用私有目录 | 用户在文件管理器里看不到，也没法自己备份/整理 |
Download/动态库/<机型>/<文件名>.soDownload/动态库/<机型>/<文件名>.sofiles/active_payload/payload.so —— 见下面的"为什么必须是两份"为什么库房那份不能直接 dlopen：分区存储下应用只能读自己经 MediaStore 创建的那批文件； 而且
/storage是 FUSE（u:object_r:fuse:s0），非untrusted_app的域根本读不到 —— 这一条是pm install时被 SELinux 当场拦出来的（avc: denied { read } ... tclass=file）。 所以库房负责"让用户看得见、管得住"，私有副本负责"一定能被加载"。
⚠️ 搜寻能力的边界：库房不能自动扫描
Download/动态库/里用户自己丢进去的文件 —— 分区存储不允许应用读取别的应用（包括文件管理器）创建的下载文件。 条目只有两个来源：本应用写进去的、以及用户通过系统选择器显式授权的那一个。
:app:testDebugUnitTest —— 之前只证明"编得过"，不证明"测得对"BundledPayloadVrKoAuditTest：展示用标注表与磁盘真实字节逐条对一遍，不许有沉默的缺口偏移是实测的，「抹标记」这一步没在任何真机上跑过。 vr detag 只证明代码编进去了，
不证明它抹对了、更不证明抹完就不被杀 —— 所以三族基线一律仍标 beta。
⚠️ 4.0.0 的安装包早于下面这批改动（4.0.0 打包于 03:55，蓝厂那批改动在 04:32 之后）。 也就是说 4.1.0 才是第一个真正带上
vr.ko反 root 绕过的正式版本。
vr.ko 反 root：两份自编族基线终于带上了绕过4.0.0 里 libbaseline_6_1.so / libbaseline_6_12.so 的 vr detag 计数是 0 ——
它们不带任何 vr.ko 抹标记。蓝厂机型上选这两份基线，等于把 vr.ko 的反 root 直接留在原地。
4.1.0 重编了两份基线，并修掉两个独立缺陷：
vr.ko 抹标记（vr detag 计数 0 → 2）；root.c / io_daemon.c，也没提供
wallpaper_blob.S 需要的素材，导致 install_android_root 等是指向 UND 的动态重定位，
dlopen 会直接失败。这一条不在原任务书里，是重编过程中实测发现的。可重放配方在 载荷构建/README.md（含出处分级与已知限制）。
上面是源码树尺寸。APK 里那两份更小（154856 B / 154840 B）—— release 构建会做 native 符号剥离，与
vr detag无关（已从成品包取出复核，仍是 2）。
能力与闸门成对出现：com.kernelpack.vivo 下新增 VrKoPayloadCheck（只读字节判据）
与 VrKoPayloadGate（只对蓝厂方案生效，通用方案短路、不做任何检查）。
判据是「日志串 vr detag」+「机器码特征（add #0x2c 且 AND ~0x400）」两条组合 ——
全量 126 份载荷实测：36/36 正例命中、89 份负例零假阳性。
boot.img）载荷构建页多了第三条路：直接粘一个完整包（OTA ZIP）的直链。
完整包直链 ──► 只取需要的几块 ──► boot 镜像 ──► 已有的构建流程
它不是"下载整个包再解压" —— 完整包通常 4–8 GiB，手机上那是几十 GB 流量。 实际网络代价是：
| 取什么 | 大约 |
|---|---|
| 文件尾部（找 ZIP 中央目录） | 64 KiB |
| ZIP 中央目录本体 | 几百 KiB |
payload.bin 头 + 分区清单 | 24 B + 几百 KiB |
boot 分区真正用到的那几块 | ~64–96 MiB |
两种完整包形态都认：
payload.bin）：读 update_engine 清单，按 dst_extents 把块还原成镜像；
支持 REPLACE / REPLACE_XZ / ZERO / DISCARD；boot.img / init_boot.img（国内厂商常见），
支持 Stored 与 Deflate。能力边界（如实列出，不粉饰）：
Range。不支持时直接拒绝，不会在用户没同意的情况下下几个 GB；xz --block-size=16384）会在第 2 块发散；
遇到时会给出明确报错，而不是静默产出错误镜像。没有验证过真实 OTA 的
REPLACE_XZ 操作是单块还是多块 —— 这条是未验证的；REPLACE_BZ（bzip2）不支持：为它引 commons-compress 不值得，遇到时明确报错；content:// 与本地文件），
ViewModel 里两者互斥赋值，避免出现"界面写着 A、实际用的是 B"。3.2.0 的内核支持是 6.6 一条线（外加 6.12 的口径声明）。4.0.0 扩到三个结构体族， 并且不是靠"版本号外推"，而是每一族都有自己的基线库：
| 结构体族 | pi_lock | cred | tasks | 基线库 |
|---|---|---|---|---|
6_1 | 0x924 | 0x838 | 0x550 | libbaseline_6_1.so（自编） |
6_6 | 0x90C | 0x820 | 0x550 | libionstack.so / libbs.so（沿用） |
6_12 | 0x9EC | 0x900 | 0x638 | libbaseline_6_12.so（自编） |
为什么必须按族选库：结构体偏移是编译期烤死的，patch 改不了。
拿 6.6 的库去打 6.1 的内核，符号就算全部 patch 对，写进去的也是错位置的字段 ——
比"符号对不上"更隐蔽。所以 BaselineLibraries.resolve 先由内核串推出族，再选库。
6.1 的口径变更留档：6.1 曾在 2026-09-12 被移出主线，理由是"它是 flat 形态 （88 字节 / task@0x30），与 6.6/6.12 的 nested（112 字节 / task@0x50）不是一套"。 这个理由本身是对的；变的是我们后来为 6.1 编出了专属基线， 于是"拿 6.6 的偏移硬打 6.1"这个危险不再存在。 ⚠️ 两条要一起读：6.1 能进主线的唯一前提是它有自己的族基线 —— 那份基线若被拿掉，6.1 必须同时退回拒绝。
vr.ko 反 root：能力在载荷里，闸门在构建前vr.ko 是 vivo/iQOO 的私有反 root 模块：它给每个来自 app 的 task 打两个标记字节
（task+0x06 / task+0x2c），并在 thread_info.flags 里置 VR_SYSCALL_TP_FLAG (0x400)；
该 task 一旦持有 euid 0，sys_exit tracepoint 探针就会把它杀掉。
所以蓝厂机型上装一份不带抹标记的载荷，结果不是"提权失败"，而是
提权成功之后子进程立刻被杀 —— 表面上完全看不出是这个原因。
这件事有一条容易走错的分工：
| 层 | 能做什么 | 不能做什么 |
|---|---|---|
载荷（C，root.c 的 patch_task_vr_tag） | 真的抹标记：先清 0x400，再逐字节清 tag A / tag B，最后回读自证 | — |
| Kotlin | 判定（VrKoBypass）· 证明（VrKoPayloadCheck）· 拦（VrKoPayloadGate） | 写不了内核内存 —— 它没有那个原语 |