KSuRoot

⚠️ ملاحظة تنبيهية: سياسات الجدولة في أجهزة العلامة الزرقاء صارمة نسبيًا، وعند رفع الصلاحيات يسهل على النظام استرجاع العمليات الفرعية. يُرجى أولًا تفعيل «إيقاف تقييد العمليات الفرعية» في «خيارات المطوّر» قبل تنفيذ رفع الصلاحيات، لتحقيق معدل نجاح أعلى.

أداة رفع صلاحيات KernelSU بنقرة واحدة تعتمد على ثغرة النواة CVE-2026-43499 (GhostLock).

يعتمد هذا الفرع على KSuRoot كنموذج، ويزامن بالكامل تحديثات الفرع الرئيسي Root-My-Galaxy v0.2.6، ويضيف فوق ذلك بناء الحمولة وتضمين حمولات الشركات المصنّعة ومجموعة كاملة من واجهة المستخدم الزجاجية السائلة.

Mod by hmascs · الإصدار 4.1.2 · Apache-2.0 المستودع: https://github.com/hmascs/KSuRoot

---

ما الجديد في 4.1.2

الجديد في هذه الجولة (4.1.2): قراءة إزاحة علامة vr.ko من الصورة

يضع vr.ko علامة على المهام القادمة من التطبيقات، وتلك الإزاحة لها قيمتان 0x04 / 0x06، وهي مُدمجة في الحمولة وقت الترجمة ولا يمكن ترقيعها. والأكثر إزعاجًا أن نسختَي vr.ko على الجهاز نفسه تحملان كلٌّ منهما قيمة مختلفة (في vendor_boot الخاص بـ Y300 Pro+ توجد نسختان، وsrcversion متطابق تمامًا) —— واختيار القيمة الخاطئة يظهر على شكل «مسح بايتات خاطئة، والعلامة لم تُمحَ، والعمليات الفرعية تُقتل كما هي»، بينما السجلّات تبدو سليمة تمامًا.

الآن يتطلّب حل العلامة الزرقاء منك تزويده بـ vendor_boot.img: يقرأ التطبيق من نسخة lib/modules/vr.ko المحمّلة فعليًا الإزاحة الحقيقية لهذا الجهاز، ثم يعيد كتابة الحمولة. المكتبات الأربع المضمّنة/المُجمّعة ذاتيًا (libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) تُلزَم كلٌّ منها بفئتها الخاصة، وإذا اختُير الخطأ فسيُوقفك بوابة عدم التطابق الصفري في الحال، بدلًا من تسليمك ناتجًا منسوخًا كما هو.

كما أُضيف «استيراد حزمة الفلاش الكاملة»: اختر مباشرة ملف OTA zip أو fastboot tgz الذي حمّلته، فيتولّى هو استخراج boot وvendor_boot بنفسه، دون حاجة إلى فكّ الضغط أولًا أو الاستخراج اليدوي.

⚠️ يجب نسخ الحزمة الكاملة إلى ذاكرة التطبيق المؤقتة ليتمكن من القراءة العشوائية (الفهرس المركزي لـ ZIP في نهاية الحزمة، وuri الخاص بـ SAF لا يمكن تحويله إلى File). إذا لم تكفِ المساحة سيُرفض الطلب في الحال، وتُحذف الذاكرة المؤقتة فورًا بعد الاستخراج.

4.1.2 = 4.1.0 + 19 إيداعًا. كانت هذه الإيداعات متوقفة على فرع fix/baseline-routing، وقد دُمجت الآن في main. حزمة التثبيت 4.1.0 المُصدَرة لا تتضمّنها —— كل بند أدناه لم يُصلَح إلا بعد ذلك.

حالات الفشل الصامت التي أُصلحت

#	العيب	النتيجة
1	VR_TAG_A_OFF في 6.1 مُعبّأ بـ 0x06 (القياس الفعلي يقول 0x04)	على أجهزة العلامة الزرقاء بنواة 6.1 لم تُمحَ العلامة ولا بايت واحد، بينما يبلّغ الفحص الذاتي بالنجاح. المظهر هو «بعد نجاح رفع الصلاحيات تُقتل العمليات الفرعية فورًا»، دون أي إشارة إلى هذا السبب
2	تحديد جدول إزاحات kallsyms استخدم باقي القسمة على عدد سالب (ترجمة حرفية لدلالات Python)	فشل كامل الفئة على نوى 6.4+، واقتُبس العنوان الأساسي من نص ASCII
3	معيار جدول الإزاحات اكتفى بـ «تتالي العناصر الثلاثة الأولى»	تمييز شبه معدوم (أي موضع في الجدول يكون متتاليًا)؛ وقد غُيّر إلى فحص شكل الجدول
4	BASELINE_6_12.imageBase مُعبّأ بالعنوان الأساسي الهدف	جميع نقاط البناء بصيغة العنوان المطلق فاتها التعديل (39 موضعًا → 9 مواضع)
5	عند عدم تطابق الرموز يُفرَّغ الناتج فقط، وgate يبقى Proceed	blocked=false والناتج 0 B، فلا تُظهر الواجهة صندوق الحجب
6	احتياطي FopsSlot لم يُستخدم قط	إذا لم يُعثر على الجدول يُستسلم فورًا، دون الرجوع إلى الرموز البديلة

استكمال الميزات

• 6.12 يعمل فعليًا: أصبح ashmem في 6.12 تنفيذًا بـ Rust، وأسماء الرموز كلها mangled → غُيّر إلى القراءة وقت التشغيل من خانة fops الخاصة بـ miscdevice (TARGET_ASHMEM_FOPS_UNSYMBOLED)
• 6.1 / 6.12 متاحان تحت الحلّين العام / العلامة الزرقاء (أربع تشكيلات بـ 16 / 16 / 13 / 13 فئة لكل منها)، والقائمة في الأرشيف 07-文档/6.1-6.12-双方案清单.md
• قياس إزاحة علامة vr.ko جهازًا بجهاز: 6.1 = 0x04، 6.6 / 6.12 = 0x06 (من vr.ko في البرامج الثابتة للشركة المصنّعة على ثلاثة أجهزة حقيقية)
• وصفات بناء الحمولة مرفقة بالمستودع (载荷构建/): سابقًا كان في المستودع 15 موضعًا تشير إلى دليل غير موجود

★ ما التُقط على جهاز حقيقي: على 6.1 لم يُعدَّل أيٌّ من الإزاحات الـ 26، ومع ذلك يُنتَج الناتج

نتيجة تشغيل البناء على X100 Pro (6.1.145) هي:

偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移

هذا ليس "لا شيء يمكن تغييره"، بل "هذان الشيئان ليسا من نفس المجموعة". السبب الجذري هو أن مسارين مستقلين اختارا فرعين مختلفين:

ما تختاره	وفقًا لماذا تختاره	ما تم اختياره على 6.1.145
المكتبة الأساسية	عائلة البنية (F6_1)	libbaseline_6_1.so (القيمة القديمة من baseline-6.1-tokay/target.h)
الفئة	التوجيه الثلاثي (سلسلة النواة)	up-6-1-145-… (القيمة القديمة من offsets.h الخاصة بـ GhostLock)

طريقة الترقيع هي «أخذ القيمة القديمة من الفئة والبحث عن الحرفي في ملف .so». مجموعتا القيم القديمة لا تتقاطعان إطلاقًا، لذلك لم تتطابق أي واحدة من البنود الـ 26، والناتج كان بمثابة نسخ المكتبة الأساسية كما هي.

لماذا لم توقف البوابة الصلبة الأصلية ذلك: معيار hasFailures هو changed && !ok && !absent —— absent مستبعد صراحةً. ذلك التبرير ("قد لا تحتوي نسخة .so القديمة على مسار الكود المقابل") يصح لمفاتيح فردية، لكنه لا يصح عندما تكون "جميع المفاتيح absent".

طريقتا الإصلاح:

1. إلزام تطابق المصدر بين المكتبة والفئة: البنية الأساسية المُجمَّعة ذاتيًا (libbaseline_6_1.so / libbaseline_6_12.so) يجب أن تُقرن بفئتها الخاصة (baseline-6-1-tokay / baseline-6-12-honor)، وفئات up-* الأصلية تنطبق فقط على ملف .so الأصلي. أُضيف BaselineLibraries.profileIdForLibrary().
2. بوابة صلبة عند صفر إصابة: بمجرد ألا يقع أي بند من مواصفات الإزاحة على الموقع، يتوقف التغليف (بند العنوان الأساسي لا يُحتسب —— فهو غالبًا يتغير حتى لو لم يتطابق أي شيء، وسيخفي حقيقة "لم تتغير أي إزاحة"). لهذا أُضيف حقل kind إلى SpecOutcome.

حالات الانحدار في BaselineLibraryPairingTest (4 حالات)، إحداها تؤكد مباشرةً عدم تقاطع مجموعتي القيم القديمة —— مما يحوّل "لماذا يجب الاقتران" إلى حقيقة قابلة للتنفيذ.

المكتبات الديناميكية: فئة المشاكل التي "لا يحدث شيء عند النقر" بعد الاستيراد

#	العيب	النتيجة
1	«بناء الحمولة → استخدامها كحمولة» يستخدم الناتج في الذاكرة، وعند إعادة تدوير العملية يصبح outputLibrary فارغًا، بينما الكود القديم كان ?: return	لن يحدث أي شيء عند النقر: لا Toast، لا خطأ، لا تغيير في الزر —— ما يراه المستخدم هو "لا يحدث شيء عند النقر"
2	مفتاح التخزين المؤقت في PayloadStaging هو «نفس الاسم + نفس الطول»	الحمولة المخصصة تُسمى دائمًا payload.so في الدليل الخاص، وعند استبدالها بحمولة بنفس عدد البايتات بالضبط تُعاد بصمت استخدام الحمولة السابقة
3	مفتاح التخزين المؤقت في shizukuStage هو الطول فقط	نفس الحفرة تكررت في مسار Shizuku
4	يمكن تخزين حمولة مخصصة واحدة فقط	استيراد حمولة ثانية يستبدل الأولى، دون أي تنبيه
5	الملفات كلها في الدليل الخاص بالتطبيق	لا يراها المستخدم في مدير الملفات، ولا يمكنه نسخها احتياطيًا أو تنظيمها بنفسه

مستودع المكتبات الديناميكية: Download/动态库/<机型>/<文件名>.so

• المستودع (مرئي للمستخدم، يمكنه تنظيمه بنفسه): Download/动态库/<机型>/<文件名>.so
• النسخة النشطة (التي تُحمَّل فعليًا): files/active_payload/payload.so —— انظر "لماذا يجب أن تكون نسختين" أدناه
• أُضيفت إلى الواجهة قائمة مستودع مجمَّعة حسب الطراز، وكل نسخة يمكن تعيينها مباشرةً كـ«استخدام» لتصبح الحالية
• نسختان بنفس الاسم لكن بمحتوى مختلف لا تستبدلان بعضهما (تُضاف لاحقة تجزئة تلقائيًا)

لماذا لا يمكن dlopen مباشرةً للنسخة الموجودة في المستودع: في ظل التخزين المُقسَّم، لا يستطيع التطبيق قراءة إلا الملفات التي أنشأها بنفسه عبر MediaStore؛ كما أن /storage هو FUSE (u:object_r:fuse:s0)، وأي نطاق غير untrusted_app لا يمكنه القراءة إطلاقًا —— وهذا البند أوقفه SELinux في مكانه أثناء pm install (avc: denied { read } ... tclass=file). لذلك المستودع مسؤول عن "جعل المستخدم يرى ويتحكم"، والنسخة الخاصة مسؤولة عن "ضمان إمكانية التحميل".