أداة root لنظام Android لهاتف Samsung Galaxy S25 Ultra (SM-S938B) تقوم بتسلسل DirtyFrag CVE-2026-43284 وCVE-2026-43499 للحصول على صلاحيات root تلقائيًا عند الإقلاع عبر KernelSU.
fork لـ diabl0w/DFRoot، معدّ خصيصًا لـ Samsung Galaxy S25 Ultra (SM-S938B / pa3q)، الواجهة ومخرجات التشغيل بالكامل بالصينية.
مسارَان، واجهة واحدة:
الطريقة الثغرة الميزة المسار السريع DirtyFrag (CVE-2026-43284) مسار DFRoot الأصلي، من ثوانٍ إلى عشرات الثواني اليدوي CVE-2026-43499 احتمالي، ثلاث مراحل متدرجة، حتى عشرات الدقائق الافتراضي «تلقائي»: يشغّل المسار السريع أولًا، وإن لم ينجح ينتقل تلقائيًا إلى الطريقة اليدوية.
باختصار: الحصول على root تلقائيًا عند الإقلاع. في كل إقلاع يُجرَّب المسار السريع لثوانٍ؛ وإن لم ينجح، يُنتقل تلقائيًا إلى المسار اليدوي، مع إعادة المحاولة على ثلاث مراحل وفق «سريع → ثابت → صبور».
بعد الحصول على root يُشغَّل تلقائيًا أمرا cmd connectivity (لإزالة إعلانات «مثبّت الحزم» من سامسونج)،
وتُطبع الأوامر والمخرجات ورموز الخروج في سجل الواجهة — انظر القسم الخامس «إعدادات إعلانات المثبّت».
بدءًا من v1.8 يُكتب هذان الأمران كـ سكربت إقلاع لـ KernelSU، وفي كل إقلاع لاحق ينفّذه KernelSU نفسه بصلاحيات root
دون فتح التطبيق ودون نافذة تفويض.
Cannot run program "su": error=2, No such file or directory:
في v1.8، ولتجنّب إعادة تشغيل إضافية، أُزيل تمرير --soft-reboot إلى ksud؛ لكن su في KernelSU
يُثبَّت على /system/bin/su بواسطة وحدة النواة في مرحلة post-fs-data فقط، و late-load في ksud
يشغّل فقط المراحل late-load / post-mount / service / boot-completed (مصدر KernelSU
userspace/ksud/src/late_load.rs) —— بدون إعادة تشغيل الإطار، لن تظهر نقطة التثبيت هذه في دورة الإقلاع الحالية أبدًا،
وسيفشل su -c … في التطبيق حتمًا بـ error=2. المشكلتان لهما السبب الجذري نفسه؛KsudChannel) —— يحتوي APK على نسخة إضافية من ksud
(libksud.so، موضوعة في jniLibs/arm64-v8a/، تُثبَّت في nativeLibraryDir، ويمكن للتطبيق تنفيذها مباشرة عبر execve)،
لفتح root shell عبر libksud.so debug su، وتُكتب الأوامر في stdin الخاص بها. يتم رفع الصلاحيات عبر
ioctl(KSU_IOCTL_GRANT_ROOT) في النواة، دون الاعتماد على /system/bin/su، ودون نافذة تفويض، ودون إعادة تشغيل إطار النظام؛* root 通道：helper=…，ksud=可用，su=…، ليظهر مكان التعطّل بنظرة واحدة؛su تُضاف /data/adb/ksu/bin و /debug_ramdisk و /data/adb/magisk و /data/adb/ap/bin
إلى PATH، ووُسِّعت SU_PATHS إلى 8 مسارات (بعض إصدارات KernelSU تضع su في هذه المجلدات فقط).--soft-reboot إلى ksud. سابقًا كان هذا المعامل يجعل ksud
يعيد تشغيل إطار النظام بعد التثبيت —— ما يراه المستخدم هو «إعادة تشغيل ذاتية بعد الإقلاع»؛ والأسوأ أن إعادة التشغيل هذه
تقطع عملية التطبيق مع «إعدادات إعلانات المثبّت» التي كانت تعمل؛su في لحظة الإقلاع
(حينها لا يكون KernelSU جاهزًا بعد، وكان يفشل في كل إقلاع على الأجهزة الفعلية، ويستلزم فتح KernelSU يدويًا ثم فتح التطبيق).
الآن يُكتب الأمران نفسهما في /data/adb/service.d/dfroot-ads.sh، وينفّذه KernelSU بصلاحيات root في كل إقلاع
—— دون المرور بالتطبيق، ودون المرور بـ su، ودون أي نافذة تفويض؛cmd connectivity تلقائيًا،
وتُطبع الأوامر والمخرجات ورموز الخروج كاملة في سجل الواجهة (التنفيذ الناجح له مخرجات دائمًا)؛المسار المضمّن في DFRoot الأصلي، وكل شيفرته في app/src/main/jni/ (exp.c + مقطعتا shellcode +
وحدة النواة في dirtyfrag-lkm/)، تُترجَم إلى libexp.so ويستدعيها التطبيق مباشرة:
splice()؛/vendor/lib64/libstagefrighthw.so ثم تحميلها بـ finit_module،
وضبط SELinux على permissive؛libc.so / libc++.so، واستغلال نطاق modprobe لتشغيل ksud المضمّن،
و late-load لـ KernelSU.سريع (ثوانٍ)، والثمن أنه يترك في /dev/df أثر «تم التحصين في هذه الدورة»،
كما أن مسار تثبيت ksud فيه يختلف عن المسار اليدوي (انظر القسم السابع).
الملفات الثنائية الثلاثة مترجَمة مسبقًا (دون أي تعديل بايت واحد):
| الملف | الموقع | الوظيفة |
|---|---|---|
libcve43499root.so | jniLibs/arm64-v8a/ | helper، ملف ELF قابل للتنفيذ، ينفّذه التطبيق مباشرة عبر execve، لا يحتاج Shizuku |
cve-2026-43499-app.so | assets/payloads/ | payload، يُحمَّل بـ dlopen من helper ثم ينفّذ الثغرة |
ksud-s25u-kdp | assets/payloads/ | KernelSU نفسه (ksud + kernelsu.ko مضمّن) |
1. helper --run-payload <payload> <helper> <log> الحصول على root (احتمالي)
2. helper -c "cp ksud …" إنزال ksud إلى /data/local/tmp
3. helper --late-load bind mount لـ /system/bin/logcat،
ثم exec "logcat late-load …" لتثبيت KernelSU
معيار النجاح: ظهور exploit completed و done=1 root=1 معًا في السجل.
الطريقة «اليدوي» في الواجهة تشغّل هذا المسار (والطريقة «التلقائي» تنتقل إليه أيضًا إذا لم ينجح المسار السريع).
الضغط اليدوي على الزر (في الواجهة)
└─ يعمل في العملية الحالية: الطريقة «تلقائي» = المسار السريع → اليدوي؛ الطريقة «يدوي» = اليدوي مباشرة
الإقلاع التلقائي (BootReceiver، يُنفَّذ مع كل من البثّين)
│
├─ هل تم الحصول على root في هذه الدورة (بيانات اعتماد مثبّتة، أو root آخر لا يزال موجودًا)؟
│ ├─ إعدادات إعلانات المثبّت لم تُنفَّذ بعد → تُنفَّذ مرة واحدة، انتهى
│ └─ نُفِّذت سابقًا → تُتخطّى
├─ هل الخدمة الأمامية تعمل / الدورة السابقة لم تنتهِ؟ → تُتخطّى
│
├─ الخطوة 1 · المسار السريع DirtyFrag (من ثوانٍ إلى عشرات الثواني، يعمل مباشرة داخل البث)
│ ├─ نجاح → الخطوة 3
│ ├─ فشل دون ترك أثر (/dev/df غير موجود) → المتابعة إلى الخطوة 2
│ └─ فشل مع تحصين مسبق (/dev/df موجود) → التوقف، مع تلميح لإعادة تشغيل الهاتف
│
├─ الخطوة 2 · الطريقة اليدوية CVE-2026-43499 (ثلاث مراحل متدرجة، تُوكَل إلى الخدمة الأمامية)
│ ├─ نجاح → الخطوة 3
│ └─ فشل المراحل الثلاث → لا مزيد من المحاولات في هذه الدورة، انتظار الإقلاع التالي
│
└─ الخطوة 3 · إعدادات إعلانات المثبّت (أمرا cmd connectivity، انظر القسم الخامس)
├─ نجاح → تُكتب كسكربت إقلاع لـ KernelSU (/data/adb/service.d/)، ويُنفَّذ تلقائيًا في كل إقلاع لاحق
└─ فشل (لم يُفتح القفل بعد / KernelSU ليس جاهزًا بعد) → الخدمة الأمامية تعيد المحاولة كل 30 ثانية، بحد أقصى 5 دقائق
بث «الإقلاع (دون فتح القفل)» يشغّل المسار السريع فقط: المسار اليدوي يتطلب إنزال ksud إلى
/data/local/tmp، وهو تخزين مشفّر ببيانات الاعتماد، ولا يمكن الكتابة فيه قبل فتح القفل، فتشغيله بلا جدوى. لذلك ينتظر المسار اليدوي بث «اكتمال الإقلاع» (بعد فتح المستخدم للقفل).