GitHub
themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyتحليل ما بعد CVE-2024-7344 لـ Howyar SysReturn NetCopy - ملاحظات الهندسة العكسية، والملفات الثنائية القابلة للاستغلال، ومراسلات المورّد، وأدوات إثبات المفهوم الخاصة بـ CVE-2026-79298 (تجاوز Secure Boot على IA-32 عبر محمّل PE المخصص RxPE في BOOTia32.efi).
تحت عباءة Secure Boot، تغرق بعض البنى أعمق من الثغرات التي كشفتها. بعض الملفات التنفيذية يتم إبطالها. بعض التصحيحات يتم إصدارها. لكن في الأعماق تحت السطح، تترك العادات القديمة آثارها. هذا ما يتبقى عندما تُكشف ثغرة، وتُرقَّع، وتُنسى.
تم تعيين النتائج الموثقة في هذا المستودع CVE-2026-79298.
خلال عملية الإفصاح المنسق، أكد البائع أن المعالجة المرتبطة بـ CVE-2024-7344 عالجت مسار الإقلاع x64 فقط. مسار الإقلاع IA-32 - بما في ذلك BOOTia32.efi الموزع كجزء من ميزة SysReturn NetCopy - لم يُدرج أبداً في المعالجة الأصلية. ونتيجة لذلك، استمر توزيع المكوّن IA-32 المصاب تجارياً حتى الإصدار 11.3.034 (يوليو 2026).
يعود مستودع CVE المخصص إلى هنا للحصول على العمق التقني الكامل: الهندسة العكسية، تحليل الملفات التنفيذية، مراسلات البائع، أدوات إعادة الإنتاج، وأدوات إثبات المفهوم.
طوال عام 2026 كنت غارقاً في أمن UEFI - تطوير bootkits، تجاوز Secure Boot، استغلال البرامج الثابتة، تحليل CVE، تطوير أدوات هجومية، نشر الأبحاث. هذا هو المجال الذي اخترت التخصص فيه وكل أسبوع يجلب شيئاً جديداً. جزء من هذا العمل يتضمن استغلال ثغرات CVE المعروفة في مكونات UEFI. وجزء منه يتضمن البحث في برامج تُوزّع محمّلات إقلاع UEFI لكنها لم تحظَ إلا بتدقيق عام ضئيل. وجزء منه - الجزء الذي يوثقه هذا المستودع - يتضمن طرح سؤال أعتقد أنه يُغفل كثيراً:
كيف يبدو منتج ما بعد ثغرة CVE؟
ليس خلال اندفاع الترقيع. ليس في الأسبوع الذي يصدر فيه التحذير. بعد ثمانية عشر شهراً، عندما يزول الضغط، عندما ينتقل الباحثون إلى شيء آخر، عندما لا يراقب أحد بعد الآن.
هذا المستودع هو محاولتي للإجابة على ذلك السؤال لمنتج محدد: Howyar SysReturn NetCopy.
وأعتقد أن ما وجدته سيفاجئ الناس.
كل شيء في البحث الأمني يتصل بشيء آخر إذا تابعت الخيوط بما فيه الكفاية. بدأ هذا الخيط تحديداً في العمل. كُلّفنا بتحليل المخاطر الواقعية لهجمات UEFI و bootkit ضد فئة محددة من البيئات: المراكز التعليمية. يبدو الأمر متخصصاً. لكنه ليس كذلك.
إليك الواقع الذي لا يقدّره معظم الناس خارج هذا المجال تقديراً كاملاً. في مدينة متوسطة الحجم، يمكن بسهولة أن يكون هناك 70,000 جهاز مشترك أو أكثر موزعة عبر المدارس - حواسيب محمولة ومحطات عمل يستخدمها طلاب تتراوح أعمارهم بين ثمانية وخمسة عشر عاماً، تعمل بتوزيعات Linux لأن ترخيص Windows على هذا النطاق غالباً ما يكون باهظ التكلفة.
الآن اسأل نفسك: كم من تلك الأجهزة لديها Secure Boot مُفعّل بشكل صحيح؟ الإجابة الصادقة، في معظم الأماكن، هي عدد قليل جداً. والسبب ليس الإهمال. إنه الواقع التشغيلي.
تفعيل Secure Boot بشكل صحيح في بيئة Linux يعني توقيع كل نواة. كل تحديث للنواة - وثغرات نواة Linux كانت تتوالى بسرعة في السنوات الأخيرة - يتطلب صورة موقّعة جديدة تُنشر على كل جهاز. هذا يعني خطوط تحديث منسقة، بنية تحتية لإدارة المفاتيح، أفراداً مدربين، وصيانة مستمرة عبر آلاف نقاط النهاية الموزعة على عشرات المواقع.
بالنسبة للمؤسسات التي تملك تلك الموارد، الأمر قابل للإدارة. بالنسبة لمعظم المناطق التعليمية، ليس كذلك. ببساطة لا يوجد عدد كافٍ من الأشخاص، ولا ميزانية كافية، ولا أدوات كافية للقيام بذلك بشكل صحيح على هذا النطاق. لذا يبقى Secure Boot معطلاً.
كلمات مرور BIOS لا يتم تعيينها - لأن تدويرها عبر 70,000 جهاز بطاقم محدود غير عملي. وتلك الأجهزة تبقى هناك، مكشوفة بالكامل على مستوى البرامج الثابتة، يستخدمها مئات الطلاب كل يوم.
ما يعنيه ذلك فعلياً، من منظور أمني، هو أن المهاجم الذي يفهم استغلال UEFI يمكنه اختراق أحد تلك الأجهزة على طبقة البرامج الثابتة - قبل تحميل نظام التشغيل، قبل بدء أي برنامج أمني، قبل أن تتاح لأي آلية حماية فرصة التدخل. يمكن لـ bootkit أن يستمر عبر عمليات إعادة التشغيل، وعبر إعادة تثبيت نظام التشغيل، وعبر كل شيء. أعرف هذا لأنني أطوّر هذا النوع من الأدوات بنفسي. التقنيات موجودة. إنها ليست نظرية.
هذه مشكلة معروفة. معترف بها على نطاق واسع. ولن تختفي قريباً.
الاستجابة التشغيلية لتلك المشكلة - الشيء الذي تنشره المدارس فعلياً بدلاً من Secure Boot المناسب - هي برامج الاستعادة.
الفكرة مباشرة: أياً كان ما يفعله الطالب خلال الجلسة، يعود كل شيء إلى حالة نظيفة معروفة بعد إعادة التشغيل التالية. البرمجيات الخبيثة، تغييرات الإعدادات، ملفات النظام المعطوبة، البيانات المحذوفة عن قصد أو عن غير قصد - كلها تختفي. هذا يقلل تكاليف الصيانة بشكل كبير ويمنح المسؤولين طريقة لإدارة الأجهزة المشتركة دون الحاجة إلى ضوابط أمنية مثالية على مستوى البرامج الثابتة في كل جهاز.
عندما بدأنا تقييم المنتجات المستخدمة في هذه البيئات، ظهرت عدة أسماء. أحدها كان Howyar SysReturn - منتج تايواني مصمم تحديداً للنشر التعليمي، مع دعم صريح لمختبرات الحاسوب المدرسية، ومحطات العمل المشتركة، والبيئات المُدارة واسعة النطاق.
في اللحظة التي رأيت فيها ذلك الاسم، عرفت بالضبط ما أردت فعله.
في يناير 2025، نشرت ESET Research الإفصاح عن CVE-2024-7344 - تجاوز لـ Secure Boot يؤثر على SysReturn وعدة منتجات استعادة أخرى مبنية على نفس قاعدة الكود.
كانت الثغرة أنيقة بطريقة محبطة للغاية. تطبيق UEFI موقّع من Microsoft - موثوق من البرامج الثابتة، قادر على العمل حتى مع تفعيل Secure Boot - نفّذ محمّل PE مخصصاً بالكامل من الصفر. بدلاً من استخدام دوال UEFI القياسية LoadImage و StartImage، التي تفرض التحقق من توقيع Secure Boot، قام بتحليل وتنفيذ ملفات EFI التنفيذية يدوياً من ملف يُسمى cloak.dat. مشفّر بـ XOR بمفتاح من بايت واحد. لا فحص للتوقيع. كل ما كان داخل ذلك الملف كان يعمل بثقة كاملة على مستوى البرامج الثابتة.
أبطلت Microsoft الملفات التنفيذية المصابة في تحديث Patch Tuesday لشهر يناير 2025. انتقلت صناعة الأمن إلى الشيء التالي. لكنني ظللت أفكر في الأمر.
ليس لأن الثغرة نفسها لم تُحل - وثّقتها ESET بدقة وكان الإبطال واضحاً. ما ظل يجذبني هو سؤال مختلف. النوع من الأسئلة الذي لا يصبح قابلاً للإجابة إلا مع الوقت:
هل أصلحوها فعلاً؟ أم أنهم تجاوزوا الضغط فقط؟
هناك فرق. الإصلاح الحقيقي يعالج السبب الجذري - في هذه الحالة، استخدام محمّل PE مخصص يتجاوز Secure Boot. أما الالتفاف فيجعل المشكلة الفورية تختفي مع إبقاء البنية الأساسية سليمة.
أردت أن أعرف أيهما فعلته Howyar.
تواصلت مع Howyar Technologies مباشرة وطلبت نسخة تقييم من SysReturn لتقييم شراء احترافي - وهو، بالنظر إلى السياق المهني الذي أنشأ هذا البحث في المقام الأول، كان دقيقاً تماماً.
كان البائع متعاوناً وسريع الاستجابة. قدموا ترخيصاً تجريبياً كاملاً، وأدلة، ومقاطع فيديو تعليمية، وحزمة تقييم كاملة. كما أجابوا على أسئلة مفصلة حول توافق Secure Boot، والتي تبين أنها ذات صلة مباشرة بما وجدته لاحقاً.
كل تلك المراسلات مُدرجة في هذا المستودع، دون تحرير.
لن أُفسد التفاصيل التقنية هنا - فهذا هو الغرض من دليل Vulnerability Research، وأوصي بصدق بقراءته بالكامل. لكنني سأقول هذا القدر.
