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.0 · Apache-2.0 仓库：https://github.com/hmascs/KSuRoot
⚠️ 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 里那两份更小（154872 B / 154856 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） | 写不了内核内存 —— 它没有那个原语 |
早先 Kotlin 侧曾有一套 VrKoBypass.plan()，规划"往哪几个内核地址写什么"。
那套代码已删除：它做的事没有任何人能执行，接上去只会得到一个
"看起来做了事、其实什么都没发生"的假动作。现在它的位置由 VrKoPayloadCheck 顶上。
归属：仅蓝厂方案。 通用方案不带、也不检查（VrKoPayloadGate 在
scheme != VIVO 时直接短路，连 ELF 都不解析）。vr.ko 是 vivo 的私有模块，
把它横切到所有方案等于让别的厂商也走一条没验证过的路径。
| 方案 | 载荷 | 实测 | 闸门 |
|---|---|---|---|
| 蓝厂 6.6 | libbs.so | 带 ✅ | 放行 |
| 蓝厂 6.1 | libbaseline_6_1.so | 重编后带 ✅ | 放行 |
| 蓝厂 6.12 | libbaseline_6_12.so | 重编后带 ✅ | 放行 |
| 蓝厂 · 两份无源码厂商载荷 | libksu_vivo_iqoo12_a15.so 等 | 不带 ❌ | 构建期拦住 + 列表里标红 + 选中时确认 |
| 通用 · 任意 | libionstack.so … | 不带（本就不该带） | 不触发 |
VrKoPayloadCheck，只读字节）两条，任一成立即判"带"：
"vr detag" —— patch_task_vr_tag() 打的两条日志里共有的那段；add xN, xM, #0x2c（算 tag B 地址）
与 AND 立即数、掩码 == ~0x400（清 VR_SYSCALL_TP_FLAG）。⚠️ 对早先一条建议的实测更正：曾建议"扫
movz/movk里的0x2c与0x400"。 实测不是这样 —— clang 把task + 0x2c折成add立即数、把& ~0x400折成AND逻辑立即数，两者都不是movz/movk。照movz扫会全量漏判。 为此在AArch64里补了decodeAddImmediate/decodeLogicalImmediate两个解码器。
实测区分度（jniLibs/arm64-v8a 全量 126 份 .so）：
| 份数 | 日志串 | 机器码特征 | |
|---|---|---|---|
| 带绕过 | 36 | 36 / 36 | 36 / 36 |
| 不带 | 89 | 0 / 89 | 0 / 89 |
两条判据在真实语料上完全一致、零假阳性；另 1 份 ELF 头损坏 → 判 UNPARSEABLE
（与 ABSENT 分开：闸门对两者都拦，但给的原因不同）。
BundledPayloadVrKoAuditTest 会把"展示用标注表"和磁盘上的真实字节逐条对一遍：
任何一份实测不带绕过却没标注的蓝厂载荷都会让用例变红 —— 不允许沉默的缺口。
libbaseline_6_1.so / libbaseline_6_12.so 本轮重编，修掉两个独立缺陷：
vr.ko 抹标记（vr detag 计数 0 → 2）；root.c / io_daemon.c，也没提供
wallpaper_blob.S 需要的素材，导致 install_android_root 等是指向 UND 的动态重定位，
dlopen 会直接失败。可重放配方在 载荷构建/README.md。
产物：175792 B / 175776 B（旧 135184 B）。
引入上游 GhostLock 源码登记的 50 个内核适配（每档 9 个符号地址 + 结构体族）， 让"通用方案"从 1 档扩到 51 档；蓝厂方案把这 51 档全部挂上 vr.ko 绕过，成为 52 档 （含手写实测的 PD2520）。
⚠️ 这 50 档一律标
UPSTREAM_TARGET_H+beta：数据是真的（来自上游源码）， 但我方未在真机上验证过。界面上与实测档分开显示，不谎报验证状态。
打补丁只能改写基线 .so 里本来就有的字面量。所以"基线有哪些键"和
"boot.img 解出哪些键"必须双向对齐，缺任何一边都会让产物里留下一批
"为别的内核烤死的旧值"—— 而那是静默的：不报错、也不表现为失败，装机后才炸。
原先的写法是 baseline.symbolOffsets[key] ?: continue（直接跳过），
于是"看起来支持、实际写错内存"。现在 SymbolAlignment 对不齐就阻断打包。
采用 GhostLock 的 offsets.json 作为互通格式（字段命名与结构已逐键核对，见下节），
实现读 / 写 / 合并（三种冲突策略），并且往返不丢未知键——
别人文件里我们不认识的键会原样保留，不会被静默丢掉。
把注册表的真实覆盖面摊开给用户看，而不是让人猜：
新增并入批次 83 份（Pixel 全系、三星全系、OPPO / realme / 一加 / 华硕等），
随包 .so 共 126 个。读不出内核版本的 77 份一律 kernelUnknown，
只允许手动选择、绝不参与自动匹配 —— 载荷靠编译期常量寻址内核符号，拿错一份就是提权失败。
用户实测 6.1.145 的 boot.img 时被拒，提示「基线 ABI 档位是 GKI 6.6，而 boot.img 是 6.1」。 根因有两层，都是"两套东西对不上"：
| 症状 | 根因 | 修法 | |
|---|---|---|---|
| 第 1 层 | 两张表 | 路由查 BaselineRegistry.allEntries（103 档），打包却查 BaselineProfiles.byId（只有 2 档 6.6）→ 查不到就兜底回落 PD2520 | 统一到 BaselineRegistry.byId / findByBytes |
| 第 2 层 | 两套词汇 | 上游档的 abi.kernelSeries 填的是三段小版本（6.6.118），闸门比的却是两段大系列（6.6）→ 50 档一档都构建不出来 | 拆开两个语义：路由键保留三段，ABI 比较键压成两段 |
顺带修掉同源的第 3 处：lookup() / coverageReport() / availableLabels() 也只查那 2 档，
导致报缺文案会在明明有档位时说"没有基线"。
并且不再兜底猜系列：认不出基础 .so 就如实报缺并停止打包，
而不是"取第一档顶上"—— 那等于拿 6.6 的旧值去打 6.1 的库。
libgl_universal.so（全工程 0 引用）与重复载荷 libksu_vivo_sixmodels_a.so上游仓库：YuKongA/ghostlock-app（Apache-2.0）。
本项目只取方法与数据，不复制其 C 代码；其许可证随包携带于
app/src/main/assets/GL_LICENSE_Apache2.txt。