smt878u-ionstack-poc

[!CAUTION] هذا المشروع غير مكتمل — فهو لا يعمل بعد. لا يوجد root عامل على أي جهاز حتى تاريخ 2026-10-06. لا تتوقع أن ينجح البدء السريع أدناه. اقرأ الحالة الحالية قبل بناء أو تشغيل أي شيء.

[!WARNING] الحالة: قيد العمل — الحلقة 1 لم تتحقق

• لم يتحقق: root دائم أو حتى لمرة واحدة على SM-T878U.
• آخر فشل موثّق: حمولة استعادة المكدس لا تصل أبدًا إلى مسار الكتابة في النواة. عبر ~470 تشغيلًا مزوّدًا بأدوات القياس، لم يُلاحظ قط أخذ القفل المزوّر عند rtmutex.c:585، لذا فإن عملية التخزين *(ASHMEM_MISC_FOPS) = fake_fops لا تُنفَّذ أبدًا.
• العائق السابق، وقد حُلّ الآن: لم تكن التحقيقات الجنائية للانهيارات متاحة لـ uid 2000 shell (/proc/kmsg، /proc/last_kmsg، /sys/fs/pstore، dmesg → كلها EACCES). الآن أصبح سجل مرآة دائم عبر write()+fsync() (IONSTACK_LOG_MIRROR) يبقى بعد CONFIG_PANIC_ON_OOPS=y، لذا فإن تشغيلًا انهار لا يزال يترك أثرًا كاملًا.
• راجع docs/RTMUTEX_WEAPONIZATION.md §15.16–§15.18 لمسار الأدلة الكامل.

إثبات مفهوم لإعادة الحصول على root بلغة C خالصة وبمساعدة المضيف لجهاز Samsung Galaxy Tab S7 (SM-T878U / gts7l) ضد CVE-2026-43499 (IonStack / GhostLock).

تستخدم سلسلة التشغيل مكوّنات C/ELF أصلية فقط. لا تتطلب Python أو Java أو DEX أو app_process أو JVM على هدف Android. يُستخدم ADB للنشر والتحقق.

---

الحالة الحالية (غير مكتمل)

لم يتم الحصول على root. هذا القسم هو السرد الموثوق والمحدّث لموضع السلسلة (آخر مراجعة 2026-10-06). كل ما أدناه مقيس على عتاد حقيقي (SM-T878U، T878USQS8DXE1، النواة 4.19.113-27114284)، وليس نظريًا.

ما ثبت أنه يعمل

المرحلة	الحالة	الدليل
هوية الهدف + تسريب KASLR	يعمل	[reroot] LEAK_OK kaslr_base=… task=… (قناة جانبية perf)
محفّز CVE: FUTEX_CMP_REQUEUE_PI → -EDEADLK	يعمل	[*] requeue ret=-1 errno=35 — EDEADLK == 35 على Linux
التراجع المعطوب يترك pi_blocked_on معلّقًا	يطابق إصلاح المنبع	إصلاح المنبع 3bfdc63936dd يغيّر current->pi_blocked_on → waiter->task->pi_blocked_on
تخطيط struct rt_mutex_waiter (4.19)	مُتحقَّق منه من المصدر	tree_entry@0x00 pi_tree_entry@0x18 task@0x30 lock@0x38 prio@0x40 deadline@0x48
هندسة المكدس paint == rt_waiter + 0x28	مُتحقَّق منه 4× بما في ذلك objdump	rt_waiter = do_futex_sp+0xC0; address = ___sys_sendmsg_sp+0xB8
التحقيقات الجنائية الدائمة للانهيارات	يعمل	أثر IONSTACK_LOG_MIRROR عبر write()+fsync() يبقى بعد إعادة تشغيل بسبب panic
وسم هوية صفحة frag لكل رسالة	يعمل	reclaim-scan tag=1 sent=8201 range=1..8201 ok=8192 bad=0 dup=0 undecoded=0 absent=9
مسح الطابور: النواة كتبت 0 بايت في 8192 صفحة frag مصفوفة	مُتحقَّق منه	مقارنة 256 MB بايتًا ببايت مع الحمولة، hits=0
rt_mutex_adjust_prio_chain يصل إلى مسار الكتابة	مُتحقَّق منه من التفكيك	top_waiter == NULL ⇒ يبقى requeue بقيمة true ⇒ 664/682/685/716-725 قابلة للوصول بنيويًا

ما لا يعمل

1. مسار الكتابة لا يُنفَّذ أبدًا. عبر ~470 تشغيلًا مُجهَّزًا بالأدوات، تُبلِّغ جميع المشاهدات الـ174 لـ page-dump والـ45 لـ ring1-page عن first_diff=8000 (pristine)، وowner_cpu=00000000، وcase1_gate=0، وlock_root/lock_leftmost مساوية تمامًا لقيمة الحمولة. لم يُلاحَظ قط أن المسار يأخذ fake_lock->wait_lock عند rtmutex.c:585، لذا فإن 664/682/685/716-725 — الفرع الوحيد القادر على الكتابة في *(ASHMEM_MISC_FOPS) — لم يُنفَّذ قط. لاحظ أن _raw_spin_trylock()/_raw_spin_unlock() تمر عبر مساعدات خارجية، وأن شجرة هذا المورّد لا تحتوي على تجاوز arm64 لـ queued_spin_unlock، لذا فإن wait_lock.val == 1 هو الشاهد الموثوق على 585، وowner_cpu != 0 شاهد ثانوي فقط.
2. المركبة المنشورة غير متاحة هنا. الاستغلال الناجح العلني الوحيد لهذه الثغرة (CVE) (NebuSec، IonStack part II) يستعيد الإطار باستخدام prctl(PR_SET_MM, PR_SET_MM_MAP, …). هذه النواة تُشحن مع # CONFIG_CHECKPOINT_RESTORE is not set، لذا فإن ذلك الاستدعاء النظامي مُستبعَد من الترجمة. كما أنه لا يستخدم sendmsg أبدًا — وهي مركبتنا — وهو على الأرجح السبب الجذري لـ (1).
3. لم يُنفَّذ ring1-read قط. القراءة العكسية الوحيدة من مساحة المستخدم للحلقة 1 (configfs_read_once(fd, data_addr(ASHMEM_MISC_FOPS), …)) تقع خلف بوابة مسح الطابور وخلف القيمة الافتراضية MARKER في أداة الاختبار، والتي تتوقف قبل 8 ثوانٍ عند ring1-page. كل تشغيل وصل إلى البوابة مات بين page-dump tag=pre-arm وpage-dump tag=post-arm.

الخطوات التالية الفورية (بترتيب الأولوية)

1. أعد تشغيل التهيئة الوحيدة التي يمكن فيها لـ 664/682/685 أن تكتمل داخل صفحتنا الخاصة — IONSTACK_FOPS_WAIT_LOCK_WORD=0 مع IONSTACK_PAINT_WAITER_TASK_MODE=fake-task — واقرأ page-dump tag=post-arm / ring1-lock585 بحثًا عن wait_lock=00000001.
2. اجعل ring1-read يُنفَّذ: شغِّل مع إلغاء تعيين IONSTACK_RECLAIM_SCAN_QUEUE وMARKER='ring1-read|…' حتى لا تتوقف أداة الاختبار عند ring1-page.
3. حدِّد الصفحة المحتجزة: شغِّل مع IONSTACK_RECLAIM_TAG=1 وقارن pipe_tag مع msg_tag في page-dump. جميع صفحات frag نسخ متطابقة بايتًا ببايت من الحمولة، لذا لا يمكن لـ first_diff وحده التمييز بينها.
4. أعد اختبار مسألة IONSTACK_FOPS_WAIT_LOCK_WORD على أساس مطروح بشكل صحيح — wlw=0 مقابل wlw=1 مع تثبيت IONSTACK_RECLAIM_TAG — فقد كان الارتباط السابق مشوبًا بسبب تحرك المتغيرين معًا.
5. انقل سطح الطلاء pselect6 الخاص بـ res_in/res_out من منفذ K40 4.19.
6. عندئذٍ فقط حوِّل بدائية الكتابة إلى تصعيد صلاحيات.

خطأ مفتوح غير ذي صلة

fops.c:3157 reason=selinux_write ret=-1 errno=22 EINVAL — لا يزال دون حل.

---

التوثيق

المستند	المحتوى
docs/RTMUTEX_WEAPONIZATION.md	مسار الأدلة الكامل لسلسلة rtmutex (أكبر مستند)
docs/ROOT_CHAIN_THEORY.md	تصميم سلسلة الجذر من الحلقة 0→4 من البداية إلى النهاية
docs/PAINT_ORACLE_ANALYSIS.md	لماذا يقرأ أوراكل طلاء المكدس بالطريقة التي يقرأ بها
docs/PSELECT_GEOMETRY_FINDINGS.md	pselect6 كمركبة طلاء بديلة
docs/RING1_RECLAIM_IDENTITY_2026-10-06.md	وسم هوية صفحة frag لكل رسالة؛ التحقق من مسح الطابور
docs/RING1_585_NEVER_SUCCEEDED_2026-10-06.md	إثبات أن rtmutex.c:585 لم ينجح قط
docs/RING1_ORACLE_FIX_2026-10-05.md	تصحيح الأوراكل
docs/RING1_ORACLE_WRONG_FRAGMENT_2026-10-06.md	لماذا أُسيء تحديد الجزء المحتجز

---

عناصر الهدف (للتحليل الخارجي)

target-artifacts/ يحمل كل ما يلزم لتحليل هذا الهدف دون الجهاز:

• نواة الهدف بصيغة ELF غير مجرّدة (60 ميغابايت، مستضافة كـأصل إصدار حتى تبقى خارج سجل git)،
• جميع الرموز البالغ عددها 152,788 رمزًا كنص قابل للبحث بـgrep،
• /proc/config.gz (خام + بعد فك الضغط)،
• تحقق آلي من كل ثابت يشبه العنوان في src/exploit/offset.h مقابل جدول رموز ELF نفسه،
• تفكيك للدوال الاثنتي عشرة التي تعتمد عليها السلسلة.