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

✨ 特性

🔓 免解锁 BL — 不触碰 bootloader / 分区 / dm-verity，全 RAM 态，重启即净
🧬 内核级真 root — CapEff: 000001ffffffffff（41 位全能力），非应用层伪装
🛡️ 绕过 vivo 反 root — euid=2000 保持，vr.ko 检测失效，设备零崩溃
⚙️ 常驻 daemon — 文件队列 + Base64 协议，命令执行零依赖、输出完整透传
🔌 兼容层 — su 包装器，MT 管理器 / Termux 可直接调用
📦 零持久化 — 所有 patch 在 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 管理器 / 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 方案等)

⚠️ 已知限制与注意事项

重启即失效：所有 patch 为 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的且系统为橘子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 整体 slide