Neo9Root

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 等价但进程身份安全。

✨ Caractéristiques

• 🔓 Déverrouillage BL non requis — ne touche ni au bootloader, ni aux partitions, ni à dm-verity ; tout est en RAM, un redémarrage nettoie tout
• 🧬 Vrai root au niveau noyau — CapEff: 000001ffffffffff (41 bits de capacités), pas une imitation au niveau applicatif
• 🛡️ Contournement de l'anti-root vivo — euid=2000 conservé, la détection vr.ko est neutralisée, zéro crash de l'appareil
• ⚙️ Démon résident — file d'attente de fichiers + protocole Base64, exécution de commandes sans dépendance, sortie intégralement relayée
• 🔌 Couche de compatibilité — wrapper su, directement utilisable depuis MT Manager / Termux
• 📦 Zéro persistance — tous les patches sont en RAM, redémarrage et l'état propre est restauré automatiquement

📱 Appareils pris en charge

⚠️ L'exploit dépend de la disposition spécifique de ce noyau (offsets de symboles, fonctionnalité VIVO_VMET_BREAK_KMI, comportement de vr.ko) ; tout autre appareil/noyau nécessite une réadaptation.

🚀 Démarrage rapide

Prérequis

• Windows + adb (ou adb sur n'importe quelle plateforme ; les scripts sont en PowerShell)
• Débogage USB activé sur le téléphone

Déploiement en une commande (recommandé)

# 克隆后运行 (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.

Déploiement manuel

# 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" 即成功

🛠️ Utilisation

rootc — exécuter n'importe quelle commande root

# 简单命令
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 — compatible MT Manager / Termux

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

u0 — opérations en vrai root (euid=0)

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 会话

• Sécurité confirmée par les tests : 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)
• Limitation confirmée : /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)
• Voir docs\u0_说明.md pour la méthode de compilation

Accès de /data/local/tmp par les utilisateurs normaux (app / avec des privilèges inférieurs à shell)

/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 能力

• L'app peut exécuter rootc (répertoire 1777 + fichier 755) → l'utilisateur normal obtient toutes les capacités root
• Limite : après redémarrage, le mode permissive n'est plus actif → l'accès des utilisateurs normaux redevient restreint (shell_data_file accessible uniquement au domaine shell) ; restauré après un nouveau déploiement
• Pour simplement lire un fichier : passer par su -c "cat /data/local/tmp/xxx > /sdcard/xxx" (l'app accède à /sdcard sans problème)

Vérifications courantes

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 私有数据

🔬 Principe

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)

Pourquoi euid=2000 ? Le noyau vivo intègre le module anti-root vr.ko : dès qu'un processus du domaine autre que vrp a cred->euid==0, il déclenche un fatal (redémarrage de l'appareil). L'élévation MODE=10 ne modifie volontairement pas l'euid, elle ne fait qu'écrire fsuid/fsgid + caps — vr.ko ne peut pas se déclencher, mais toutes les vérifications capable() du noyau passent (véritables capacités root).

📂 Structure du projet

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 方案等)

⚠️ Limites connues et précautions

• Perdu au redémarrage : tous les patches sont en RAM, un redémarrage nécessite un nouveau déploiement
• Fenêtre froide : le succès de l'exploit dépend d'une exécution <3 min après le reboot ; dans la boucle de candidats du processus, les ~28 premiers candidats correspondent à la fenêtre GPU normale, ensuite le GPU peut se figer → utiliser run_rootc_loop.ps1 pour réessayer en plusieurs boucles
• Déconnexion adb ≠ crash : sous forte charge GPU, adbd peut ne plus répondre et provoquer une déconnexion adb ; vérifier avec cat /proc/uptime (uptime qui continue d'augmenter et écran normal = l'appareil n'a pas crashé)
• id affiche uid=2000 : voir le chapitre Principe ; c'est un comportement voulu, les capacités sont équivalentes à root
• mount / est limité par fstab ; /system est en lecture seule (erofs + dm-verity), aucune modification persistante possible
• Permissions de /data/local/tmp : pour Termux/utilisateurs normaux, chmod 1777 est nécessaire (voir la section « Accès des utilisateurs normaux ») ; SELinux doit rester permissive (définie lors du déploiement de l'exploit), ne pas utiliser setenforce 0 (détection par vr.ko)

❓ FAQ

Q : Est-ce un vrai root ? R : Oui. Toutes les vérifications capable() du noyau (CapEff complètement ouvert, chown 0:0, lecture de /proc/iomem, lecture des données de n'importe quelle app) passent — le noyau reconnaît que vous avez les capacités root, seul l'uid numérique est 2000.

Q : L'appareil peut-il être brické ? R : Non. Aucune écriture de partition, aucune modification persistante ; au pire, le GPU se fige et un redémarrage restaure tout.

Q : D'autres appareils sont-ils pris en charge ? R : Une réadaptation est nécessaire (la disposition du noyau, les offsets de symboles et le comportement de vr.ko sont spécifiques au PD2338C ; si l'appareil est un vivo iQOO Neo9 sous OriginOS 5, vous pouvez tenter).

📜 Avertissement

Ce projet est uniquement à des fins de recherche en sécurité et d'utilisation sur vos propres appareils. Toute conséquence résultant de l'utilisation de cet outil (y compris, sans s'y limiter, les dommages matériels, la perte de données, la perte de garantie) est à la charge de l'utilisateur. Veuillez respecter les lois et réglementations locales et ne pas l'utiliser à des fins illégales.

🙏 Remerciements

• zhuowei/cheese — cadre original de l'exploit GPU
• sarabpal-dev/cheese-cake — implémentation étendue
• Type010 / CyberMeowfia et d'autres recherches publiques — référence pour l'approche

📄 Licence

MIT