unisoc-su

طريقة لـ CVE-2025-31710 والاتصال بمقبس cmd_skt المجرد للحصول على شل جذر على موديلات unisoc غير المصححة

قبل أن يصرخ الجميع، Unisoc نفسها سمحت لي بنشر هذا بعد نشرة CVE-2025-31710، لذا ابق هادئًا.

لنبدأ بمزحة

9u4d2i

نعم، أنت لا تحلم، اليوم أريد أن أقدم لك استغلالًا لشل النظام على تطبيق com.sprd.engineermode وبما أنه أحد العملاء الموثوقين لـ cmd_skt تمكنت أيضًا من الدخول إليه. هذا المقبس المجرد جزء من خدمة تعمل كجذر (cmd_services)، لذا نعم، أنا سعيد بتقديم unisoc-su. هنا يمكنك رؤية قائمة العملاء الموثوقين لـ cmd_skt المستخرجة من ثنائي cmd_services باستخدام ghidra والتي تظهر أن com.sprd.engineermode موجود:

تطبيقات cmd_services

لهذا الاستغلال يُستخدم تطبيق com.sammy.systools بواسطة pascua28 وcli-pie بواسطة TomKing062. هناك نسختان من هذا التطبيق، الأولى تحتوي على ثنائيات متنوعة لاستخدامها من شل النظام، والأخرى تحتوي فقط على cli-pie وبعض clis للاتصال بمقابس أخرى متنوعة (بالنسبة لـ engpc يمكنك الآن استيراد هذا من شل النظام، أقترح استيراد tools.sh أولاً)، ثم لكل منهما إصدار لأندرويد 9 (للأجهزة الأقدم، يمكنك إعادة حزم التطبيق باستخدام Apktool M واختيار الإصدار المطلوب).

كيف تعمل هذه الطريقة: قم أولاً بتنفيذ UnisocEngSyshell_Enabler_Script.sh باستخدام adb أو shizuku rish لتمكين تطبيق com.sprd.engineermode (مطلوب فقط على الموديلات الجديدة)، ثم اتبع التعليمات وشغّل على الاتصال *#*#83781#*#* لتشغيل النشاط الرئيسي، ثم من هنا ادخل إلى نشاط Adb shell. ثم أدخل في سطر واحد مسار cli-pie الكامل (بما في ذلك الأبليت)، وفي السطر الآخر "setprop persist.sys.cmdservice.enable enable"، ثم اضغط على start بأسرع ما يمكن على setprop أولاً ثم على سطر cli-pie، وفجأة سيظهر متصل. ثم اضغط على end في نشاط setprop واحذف نصه، وأدخل "nc -s 127.0.0.1 -p 1234 -L sh -l" أو ما تستخدمه لتشغيل الصدفة العكسية. ثم اذهب إلى الطرفية واتصل مرة أخرى باستخدام الثنائي المناسب، إذا لم يعمل قم باستيراد السكريبت المناسب أو ببساطة اتصل باستخدام "nc 127.0.0.1 1234"، بعد ذلك "source /sdcard/Documents/unisoc-su.sh" (أو حيث وضعت السكريبت، لكن يجب أن يكون قابلاً للوصول من شل النظام). هذا كل شيء، لقد حصلت على شل جذر إذا كان كل شيء صحيحًا.

الآن، لنتحدث عن هذا الاستغلال، السياق محمي بشدة بواسطة selinux، لدينا الجذر ولكن كل الحماية ما زالت قائمة. هذا الجذر ضخم لأننا لم نعطل أي شيء للحصول عليه مثل استغلالات مماثلة أخرى. لسوء الحظ، لا يمتلك هذا السياق القوة الكافية لتعطيل selinux ويبدو أن التنفيذ يعمل فقط على مسار النظام (PATH). بخصوص الخدمة نفسها، يبدو على أندرويد 9 (أي قبل تصحيح CVE-2022-47339) أنها لا تحتوي على مجموعات في ملف rc الخاص بها وبالتالي تكون افتراضية إلى root، لاحقًا تم إضافة مجموعات (وإزالة root كـ gid/groups) لذا من الواضح أن الخدمة أصبحت أكثر تقييدًا، ولكن مع تشغيل selinux فهو الحاكم على أي حال. حول كيفية تصرف الخدمة: على الأجهزة الأحدث، يبدو أن الخدمة تعمل حتى يستخدمها شيء أو يتصل بها، إذا لم يكن هناك عميل متصل أو أمر صادر إليها ستتوقف الخدمة وسيكون من الضروري استخدام خاصية setprop لتشغيلها مرة أخرى، تقوم الخدمة بذلك فورًا تقريبًا، ولهذا السبب في هذه الطريقة نقوم بتشغيل setprop والاتصال بسرعة، على أندرويد 9، يبدو أن الخدمة تنتظر أمرًا بعد إصدار setprop، يبدو أن هذا هو الفرق بين الأجهزة القديمة والجديدة، بعد التنفيذ تتوقف، بالطبع يمكن ببساطة الاتصال بها باستخدام socat أو cli-pie (أو تشغيل الجسر)، في هذه الحالة ستبقى الخدمة قائمة لأنها ستكون مشغولة بهذا الاتصال، إذا لم يتم توفير أمر، ستبقى الخدمة في انتظار غير محدد.

ملف cmd_services.rc من روم المستخدم لأندرويد 13 وروم eng لأندرويد 9 لإظهار الاختلافات ملف rc لـ cmd_services على أندرويد 13 (مستخدم)

CVEs التي ألهمت هذه الطريقة: CVE-2022-47339 (cmd_services) بواسطة Lewei Qu(曲乐炜) وCVE-2025-31710 (شل النظام لـ com.sprd.engineermode) بواسطتي، على الرغم من أن Lewei Qu(曲乐炜) كان لديه CVE مشابه على com.sprd.engineermode على ما يبدو ولكن اكتشفت ذلك بعد حصولي على ثغري.

أيضًا ثلاث حالات خاصة جاءت لاحقًا، ليست جزءًا من قائمة CVEs الملهمة، الأولى هي ثغرة معاد تقديمها، سأضيفها هنا لتوضيح الأمور: CVE-2025-67264 (تصحيح سيء لـ com.sprd.engineermode في موديلات unisoc الجديدة من Doogee، مغطى هنا) بواسطتي أيضًا، الحالة الثانية تتعلق بموديلات ZTE الجديدة، ليس من الواضح إذا كانت تنطبق على جميعها أم البعض فقط، تم الاحتفاظ بنشاط Adb shell لـ com.sprd.engineermode، على ZTE Blade V70 Vita يحدث نفس المشكلة كما في CVE-2025-67264 لكن لاحقًا قامت ZTE بتصحيحها بتقييد النشاط إلى userdebug/eng (بدون CVE حيث لاحظوا ذلك بأنفسهم) بدلاً من إزالته، ونتيجة لذلك يظهر النشاط في واجهة التطبيق ولكن يطالب بعدم القدرة على فتحه في إصدارات المستخدم (user builds)، الجهاز عرضة للخطر على (على الأرجح قبل هذا التغيير):ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys وتم تصحيحه على ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys، شيء مشابه يحدث على ZTE Blade A55، هذه الموديلات تعمل بنظام أندرويد 14، هناك تم إعادة كتابة cmd_services وتم تغيير اسمها إلى tool_service (وتم تقليص الخدمات التي يمكنها الوصول إليها: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools)، هذه النسخة الجديدة نشطة دائمًا ولا تتطلب أي setprop، الحالة الثالثة وهي ثغرة مشابهة لثغرة هذا المستودع تؤثر على موديلات unisoc القديمة تم تغطيتها هنا.

هنا يتم توفير نصوص برمجية متنوعة لـ unisoc-su، واحد بدون تعليمات: unisoc-su.sh، واحد يوجه لدخول شل الجذر باستخدام شل النظام فقط (هذه الطريقة أسهل، تعمل بدون اتصال بالإنترنت وبدون shizuku/adb): unisoc-su-syshell-only-tut.sh، واحد يوجه لدخول شل الجذر باستخدام shizuku/adb، يُستخدم فقط لتشغيل جزء setprop: unisoc-su-adb-shizuku-tut.sh، أيضًا إصدار للاتصال بمقابس متنوعة، قم باستيراد الذي تفضله من الطرفية، فقط unisoc-su.sh وهذا الأخير يتطلب استيراده من شل النظام. يتوفر أيضًا نص tools.sh في مجلد ghostroot لإضافة أدلة متنوعة إلى PATH وهو متوافق مع adb/النظام/الجذر، وأيضًا نص multi لتشغيل شل النظام إذا كنت لا تعرف ما هو nc الموجود على نظامك والذي سيحاول nc من ثنائيات محتملة متعددة حتى ينجح الاتصال.

تمت إضافة الآن أيضًا تطبيق poc صغير، إنه مجرد تطبيق بأربعة أزرار: واحد للاتصال بشل جذر cmd_services، وآخر للاتصال بشل النظام، زر تعليمات، زر لمسح المخرجات، وطرفية مصغرة. يجب إجراء التحضير يدويًا لذا فهو آمن للاستخدام.

حول GhostRoot (قناة جذر ما بعد الاستغلال) قناة أوامر خفية ما بعد الاستغلال تبقى في ذاكرة الوصول العشوائي وتقبل الإدخال من أي تطبيق غير مميز عبر الإدخال/الإخراج القائم على الملفات.

يعمل الاستغلال حتى أندرويد 13 حيث في الإصدارات الأحدث أزالت unisoc علامة sharedUserId من تطبيق EngineerMode وأصبح الآن تطبيق مستخدم عادي، وهذا يجعل selinux يمنع تنفيذ cli-pie على أندرويد 14 وما فوق.

مقارنة SharedUid و NormalUid - التصحيح الصورة مقدمة من TomKing062