# 独家速琪临时 Root · 通俗说明（v1.0）

> 一句话：**其他工具让你自己选一个引擎去试；「独家速琪临时 Root」把 4 条漏洞链按最可能成功的顺序自动试一遍，成功就停，并顺手做 KernelSU 交接。**

---

## 一、入口与改名

| 位置 | 怎么进 |
|---|---|
| 首页 | 快捷入口第 1 格 **独家速琪临时 Root** |
| 提权页 | 「获取 Root」首卡 **独家速琪临时 Root**（推荐） |

v1.8 改名与合并说明：

- v1.7 的「一键临时 Root」→ 现在叫 **独家速琪临时 Root**；
- 旧的「独家临时 Root」独立入口**已删除**，它的 DiceRace pkj110 能力合并成这里的第 ② 条链；
- 功能没减少，只是不再让你二选一。

---

## 二、4 条链，各自什么时候能用

| 顺序 | 链 | 漏洞 / CVE | 需要什么 | 不需要什么 |
|---|---|---|---|---|
| ① | **DirtyFrag VR** | 未标注（BTF 自动偏移） | 设备 arm64、内置补丁库、IpSecManager，内核存在对应漏洞 | **不需要 Root / ADB / Shizuku** |
| ② | **DiceRace pkj110** | CVE-2026-64560 | Root / ADB / Shizuku 通道；内核指纹命中内置索引，payload 已内置 | 不需要 GhostLock 配置 |
| ③ | **GhostLock** | CVE-2026-43499 | 精确匹配的 profile + 预计算 blob + libghostlock + **Shizuku** | ADB 不能替代 Shizuku |
| ④ | **机型载荷** | 64560 / 98260 / 43499 等（按载荷标注） | 任一通道；189 条索引里有本机高分且资产已打包的载荷 | 不需要你手动选载荷 |

### ① DirtyFrag VR：最通用，先试它

- 原理：应用进程内跑 `libdfroot`，用 IpSec UDP 封装做堆喷，`--vr-auto` 从运行内核 BTF 自动算偏移；
- 什么时候能用：设备支持 + 内核没修这个洞；`/dev/df` 不存在（未 Hook）也能跑；
- 失败长什么样：`不支持`、`BTF 不可读`、`未 hook`、`exit=…`、bootstrap.log 报错；
- 注意：**这台机（6.1.57）没真机验证**，可能无效或重启。

### ② DiceRace pkj110：命中索引才会跑

- 原理：DiceRace 同款 pkj110 链，经 Root/ADB/Shizuku 通道推送 payload 执行；
- 什么时候能用：设备内核在 DiceRace 指纹索引里、对应 payload 已内置、有通道；
- 失败长什么样：`内核未命中 DiceRace 索引`、`payload 缺失`、`无执行通道`；
- 说明：它内部还带 GhostLock 回退；如果回退了，独立的第 ③ 链会自动跳过，避免重复跑内核利用。

### ③ GhostLock：配置要严丝合缝

- 原理：把与内核精确匹配的 offsets profile 编成 blob，喂给 `libghostlock.so`；
- 什么时候能用：profile 精确匹配 + blob 就绪 + 引擎存在 + Shizuku 已授权；
- 失败长什么样：`无匹配 profile`、`blob 缺失`、`需 Shizuku`；
- v1.8 新能力：完整 `.conf` 可在运行时编成 blob（79/79 与构建期一致），不再强制预计算；但界面还没把「解析→直接提权」串起来。

### ④ 机型载荷：索引里有没有你这台机

- 原理：从 189 条载荷索引按机型（+120）/ 内核（+60）/ 厂商（+30）打分，取最高分且资产已打包的载荷，经通道推送执行；
- 什么时候能用：`matchScore>0`、资产已打包、有通道；
- 成功判据：执行后 `id -u` 得到 0，或出现临时 `su`；
- 失败长什么样：`未匹配到本机机型载荷（索引 189 条）`、`资产未打包`、`无通道`；
- 注意：索引里很多条目没写机型/内核，得分可能是 0，这时该链直接跳过，不是坏了。

---

## 三、漏洞矩阵怎么看（5 条路径）

打开页面后，「自动匹配计划」下面是「漏洞矩阵（5 条路径）」：

| # | 行 | CVE | 看什么 |
|---|---|---|---|
| 1 | DirtyFrag VR | 未标注 | 是否「支持 / 已 Hook」；BTF 是否可读 |
| 2 | DiceRace pkj110 | CVE-2026-64560 | 索引是否命中、payload 是否内置、有无通道 |
| 3 | GhostLock 预置配置 | CVE-2026-43499 | profile / blob / 引擎 / Shizuku 四件套 |
| 4 | GhostLock 内置载荷（98260） | CVE-2026-98260 | 资产是否已打包（2 个）；这不是独立按钮 |
| 5 | 机型载荷 | 按载荷标注 | `matchScore`、候选数、资产是否打包、通道 |

三个要点：

1. **「可用」只代表现在能尝试，不代表一定成功**；内核修没修、payload 对不对，要看运行结果。
2. 第 4 行是**内置资产**（`ghostlock_cve2026_98260_android` / `_uid0`），需要 GhostLock 或载荷工具调用；所以即使已有 Root，它也可能显示可用。
3. 每行详情会直接写原因，比如「无与本机内核精确匹配的 profile」「未匹配到本机机型载荷（索引 189 条）」。

---

## 四、自动匹配结论与执行顺序

计划文本会写：

- **机型 / model / 内核 release / ABI / KMI**；
- **BTF 可读性**（DirtyFrag 自动偏移的前提）；
- **DiceRace 索引**：命中哪个内核、tier、payload 是否内置；
- **GhostLock**：profile release、blob、引擎、Shizuku；
- **DirtyFrag**：支持 / 已 Hook / 摘要；
- **机型载荷**：显示名、厂商、匹配分、资产状态；
- **KernelSU**：是否启用交接、已装管理器数；
- **资产结论**：匹配到的资产集合（DirtyFrag / pkj110 payload / GhostLock profile+blob / 机型载荷）；
- **执行顺序**：①~④ 的「尝试 / 跳过」与原因，以及一句「预计」。

执行规则：

- 固定顺序 ① → ② → ③ → ④，每条链只跑一次；
- 任一链成功即停止后续链；
- pkj110 内部回退 GhostLock 后，第 ③ 链跳过（去重）；
- 链超时 → 停止后续链并提示重启（避免两个内核利用并发）；
- 成功后进入 KernelSU 交接（幂等：未启用 / 已加载 / 无管理器都会明确跳过）。

---

## 五、运行中看什么

- **阶段**：检测 → 计划 → DirtyFrag → pkj110 → GhostLock → 机型载荷 → KernelSU 交接 → 完成；
- **链路进度**：等待 / 进行中 / 成功 / 失败 / 跳过；
- **日志前缀**：
  - `[dirtyfrag]`：IpSec、native 输出、`/dev/df`、bootstrap.log、ksud；
  - `[pkj110]`：指纹、preflight、payload 轮次、内部 GhostLock 回退；
  - `[ghostlock]`：profile/blob、libghostlock 输出、ACK；
  - `[payload]`：机型载荷匹配、推送、执行、uid0 校验；
  - `[ksu]`：KernelSU late-load 结果。

---

## 六、失败了怎么办

| 你看到的 | 含义 | 需要补什么 |
|---|---|---|
| DirtyFrag 不支持 / BTF 不可读 | 设备或内核不在引擎支持范围 | 换设备/等上游；可试独立 App |
| DirtyFrag 未 hook / `exit≠0` | 内核利用没成功（可能已修复） | 保留日志反馈；重启后再试 |
| pkj110 索引未命中 | 内核不在 DiceRace 索引 | 该内核的指纹/payload（boot.img/OTA 生成） |
| pkj110 payload 缺失 | 索引命中但资产没打包 | 补 payload 资产 |
| GhostLock 无匹配 profile | 没有该内核 offsets 配置 | 本机 boot.img/OTA → 解析 `.conf` + blob |
| GhostLock blob 缺失 | 有 profile 但没预计算 blob | v1.8 可用完整 `.conf` 运行时编码，或补 blob |
| 机型载荷未匹配 | 189 条里没有本机高分条目 | 提供该机型载荷，或等索引更新 |
| 无执行通道 | Root/ADB/Shizuku 都没连 | 连一个通道（DirtyFrag 链除外） |
| 无 KernelSU 管理器 | 提权成功但无法 late-load | 工具箱安装 KernelSU/SukiSU 等 |
| 超时 / 预算不足 | 链路卡住或总预算用完 | 重启 App/设备后重试 |

结束弹窗会给「需要补充的材料」；把日志最后 20~50 行发回，比截图更有用。

---

## 七、PLZ110 的实话

> 你的截图内核：`6.1.57-android14-11-o-gc323aa4de64f`
>
> RomCloud / romprovider 把 PLZ110 标为「一加 15T」，官方固件是 ColorOS 16/17（内核 6.12.x）。

- **型号/内核对不上，未确认**；旧文档写的「一加 Ace 5 Pro」现在只作低置信别名；
- 内置没有 6.1.57 的指纹 / profile / payload；
- DirtyFrag 没在这台机上真机验证；
- 机型载荷索引里没有 PLZ110 高分条目。

所以：**v1.0 仍不能确认能 Root 这台机**。4 条链大概率会依次失败，这是「缺内核数据」，不是按钮坏了。

要推进，提供任一：

1. 本机 `boot.img` / `init_boot.img`（或完整 OTA；高通可能还要 `xbl_config.img`、`uefi.img`）；
2. 该内核的提权 payload（`preload.so` 等）；
3. 现成的 `.conf` + 预计算 blob。

当前进展（2026-11-01 16:48）：**5 个官方 OTA 整包全部下载并 MD5 校验通过**（45.9 GB），
并已用工具内置 `libextract` 逐个解析：

- **16.0.7.201 / 16.0.8.300 / 16.0.9.400 / 16.0.10.500** → 内核
  `6.12.38-android16-5-g844001fb8721-ab14552068-4k`，**CVE-2026-43499 漏洞存在**，
  GhostLock 可用；四份 `offsets.conf` 逐字节相同；App v1.8.0 起已内置该内核 profile+blob，
  **v1.0 起自动匹配**（计划卡顶部 pill「内核实测可用」）；
- **17.0.0.107** → 内核 `6.12.69-android16-6-g242e1a07f878-ab15865446-4k`，
  rtmutex UAF 修复已进内核，**GhostLock 不可用**（pill「内核已修复」）。

也就是说：**如果你的设备内核对得上 6.12.38-g844，现在装 v1.0 就能自动匹配去试 GhostLock**；
如果内核是截图里的 6.1.57，仍缺该内核配置（矩阵显示「未收录」）。

---

## 八、风险

1. 内核利用可能导致**重启、panic、数据丢失**；先备份、保证电量；
2. DirtyFrag 在 6.1.57 上未验证，可能无效或重启；
3. GhostLock 运行时编解码只在 JVM 验证，真机 libextract 输出形态未知；
4. 补丁库依赖 init 上下文 staging，SELinux 拒绝会失败（有提示，不崩溃）；
5. 失败一般不影响设备（除可能重启）；重试前建议重启恢复干净状态；
6. 本工具仅供学习研究/设备维护/安全测试，风险自负，勿用于非法用途。

---

## 九、你该做什么

1. 装上 v1.0，打开「独家速琪临时 Root」，先看计划与漏洞矩阵；
2. 跑一次，把结果/日志发回（链路名、exit code、`/dev/df`、bootstrap.log、ksud 行）；
3. 想真正 Root PLZ110：等 9.55 GB 整包下载完 → 解析 `.conf` → 发回或等后续版本补 blob/payload；
4. 也可以先试 DirtyFrag 本地运行页，但请接受重启风险。

> 更完整的功能说明见 `速琪工具箱-使用说明.md`，逐条变更见 `更新日志-v1.0.md`。

---

## 十、v1.9 内核自动匹配矩阵（怎么用）

v1.0 起，打开「独家速琪临时 Root」先看**计划卡右上角的 pill**：

| pill | 含义 | 你要做什么 |
|---|---|---|
| **内核实测可用** | 官方 OTA 实测该内核 CVE-2026-43499 存在，GhostLock profile+blob 已内置并精确匹配 | 直接点「开始自动提权」，让 4 条链按序跑（GhostLock 是第 ③ 条） |
| **内核已修复** | 官方 OTA 实测该内核已打进 rtmutex UAF 补丁，GhostLock/pkj110 都不可用 | 别在 GhostLock 上耗时间；试 DirtyFrag（第 ① 条，免通道）或机型载荷（第 ④ 条） |
| **无 pill** | 矩阵未收录该内核 | 计划卡会写「未收录该内核，不会自动放行」；需要该内核的 boot.img/OTA 或 payload |

计划卡正文新增一段「内核自动匹配（官方 OTA 实测矩阵）」，会写清：

- 状态（✅ 官方 OTA 实测可用 / ⛔ 已修复）；
- 内核 release 与**对应官方固件版本**；
- GhostLock / DiceRace 两条路各自能不能走；
- **关键 offsets**（pselect / futex / buffer / waiter / shift / mm_struct / init_task / kernel_phys_load）；
- 依据（哪个整包、用什么工具、什么时候测的）。

匹配规则：完全一致（exact）→ 全量结论；只差 `-4k`（normalized）→ 同结论；
同家族但 commit 不同（family）→ 只提示「配置仍需实测校验，不会自动放行」；
未收录 → 明确提示。

「OTA 固件库」里每个固件也会标出对应内核与结论，方便你确认下载的整包属于哪个内核。

## 十一、v2.0 的变化

- 计划卡文字变短：只显示设备、内核、内核匹配结论、4 条链是「可试」还是「跳过（原因）」。
- 没有的内核配置，用新加的「提取」自己解：提权页 → 提取 → 选全量包或 boot.img → 解出 boot.img 和内核配置。
- 提取不需要 Root、ADB、Shizuku，也不需要服务器。