GIGABYTE H510M K V2 BIOS SMM — الهندسة العكسية وبحث CVE-2025-7026/7027/7028/7029

هندسة عكسية ثابتة لصورة BIOS الخاصة بـ GIGABYTE H510M K V2 (H510MKV2.F3): تحليل استخراج كامل لمجلدات البرنامج الثابت UEFI لموزّع ذاكرة SMM Core وفق مواصفات PI، وبحث موجّه عن ثغرات تلف الذاكرة الأربع في SMM التي كشفت عنها GIGABYTE/Binarly في 2025 (CVE-2025-7026 CVE-2025-7027 CVE-2025-7028 CVE-2025-7029).

الحالة: تم تأكيد وجود 1 من 4 CVEs (CVE-2025-7027). أما الثلاثة الأخرى فقد تم البحث عنها بنشاط عبر كامل البرنامج الثابت المتاح ولم يُعثر عليها — راجع CVEs غير مؤكدة لفهم المعنى الدقيق لذلك وما لا يعنيه.

جميع ملفات البحث: GOOGLE DRIVE DOWNLAOAD: SMM_ALL

جدول المحتويات

• إخلاء المسؤولية / النطاق
• الهدف
• TL;DR
• المنهجية والأدوات
• بنية البرنامج الثابت
• بنية المستودع
• الخلفية: CVEs المنشورة
• نتيجة إضافية: موزّع ذاكرة SMM (PiSmmCore)
• مؤكد: CVE-2025-7027
• CVEs غير مؤكدة — CVE-2025-7026 / 7028 / 7029
• المعالجة
• القيود
• المراجع

إخلاء المسؤولية / النطاق

هذا بحث من نوع n-day وليس إفصاحًا عن ثغرة 0-day. جميع CVEs الأربعة المشار إليها هنا كانت قد أُفصح عنها علنًا وعولجت بالفعل من قِبل GIGABYTE (بدأ شحن البرنامج الثابت المُعالَج في 2025-06-12) مع تخصيص CVEs لها وتوثيقها من قِبل Binarly وCERT/CC قبل بدء هذا البحث. لا يوجد في هذا المستودع أي اكتشاف ثغرات جديد — إنه تحقق مستقل عبر التحليل الثابت من وجود فئات الأخطاء التي سبق الإفصاح عنها ومعالجتها في إصدار BIOS واحد محدد قابل للتحميل العام.

• لا يتضمن أي استغلال (exploit) عملي أو PoC ولم يُبنَ أي منهما. هذا تحليل ثابت فقط (تفكيك/فك ترجمة لوحدات البرنامج الثابت المستخرجة)؛ لم يتم تنفيذ أي شيء، لا قراءة/كتابة لأي SMRAM، ولا لمس لأي عتاد.
• لا يُدّعى اكتشاف أي ثغرة جديدة. تأكيد وجود CVE-2025-7027 تم عبر مطابقة نمط الكود المعرض للخطر الذي وصفته Binarly علنًا بالفعل، وليس عبر اكتشافه بشكل مستقل.
• نُشر لأغراض تعليمية / أمن دفاعي: لفهم كيف تبدو أخطاء البرنامج الثابت من نوع n-day عمليًا، وتعزيز توصية GIGABYTE نفسها بالتحديث بأدلة ملموسة لهذه اللوحة/إصدار BIOS المحدد.
• إذا كنت تمتلك هذه اللوحة: حدّث BIOS الخاص بك. راجع المعالجة.

الهدف

TL;DR

• استخرجنا شجرة مجلدات البرنامج الثابت UEFI بالكامل من صورة BIOS (uefi_firmware / uefi-firmware-parser) — تم تعداد 356 ملف FFS عبر مجلد SMM/DXE، 302 منها بملف PE32/TE قابل للاستخراج.
• عزلنا PiSmmCore (نواة SMM وفق مواصفات PI) وقمنا بهندسته عكسيًا بالكامل، مؤكدين ومسمّين موزّع مجمع/صفحات SMM الحقيقي (داخليّات SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages) عبر تواقيع الحماية المضمّنة "sphd"/"tail" — وهي مطابقة تمامًا لتطبيق EDK2 مفتوح المصدر MdeModulePkg/Core/PiSmmCore/Pool.c.
• قمنا بفحص كل وحدة قابلة للاستخراج في كل مجلد برنامج ثابت موجود في ROM (أكثر من 325 وحدة إجمالًا) بحثًا عن علامات تعريف من تقارير Binarly العامة حول CVE-2025-7026/7027/7028/7029.
• CVE-2025-7027 — مؤكد. وجدنا وتتبعنا مسار الكود المعرض للخطر بالضبط في GenericComponentSmmEntry: متغير NVRAM (SetupXtuBufferAddress) يُجلب عبر دون أي تحقق ويُستخدم مباشرة كمؤشر كتابة يمكن الوصول إليه عبر SW SMI — وهذا يطابق وصف Binarly المنشور للسبب الجذري نقطة بنقطة.

المنهجية والأدوات

1. الاستخراج — uefi_firmware (uefi-firmware-parser -e) فكّك صورة BIOS بشكل متكرر: مناطق Intel Flash Descriptor ← مجلدات البرنامج الثابت ← ملفات FFS ← أقسام، مع فك ضغط كل مجلد برنامج ثابت مضغوط LZMA/Tiano عثر عليه.
2. عزل الوحدات — كل ملف FFS يحتوي على قسم .ui (اسم عرض السائق) وقسم صورة .pe/.te تم نسخه كملف ثنائي PE32+/TE مستقل باسم <DriverName>__<GUID8>.<pe32|te>.
3. التحليل الثابت — IDA Pro (عبر واجهة العامل headless ida-pro-mcp / idalib) مع مفكك Hex-Rays، بقاعدة بيانات واحدة لكل وحدة. تحليل تلقائي + Hex-Rays فقط — لم تتوفر تواقيع FLIRT أو مكتبات أنواع EDK2 في هذه البيئة (مذكور كقيد أدناه).
4. البحث عن العلامات — عمليات مسح بالبايت/السلاسل النصية عبر Python لكل وحدة مستخرجة (وصورة الـ 16 MB الخام) بحثًا عن المعرفات المذكورة في نشرات Binarly العامة (أسماء متغيرات، ثوابت سحرية، تسميات دوال).
5. التتبع اليدوي — لكل علامة تم العثور عليها، تم فك ترجمة الدالة المرجعية وتتبع مخطط استدعاءاتها (المستدعون/المستدعَون) يدويًا لإعادة بناء مسار الكود الفعلي، مع مطابقته مع وصف السبب الجذري المنشور.
6. إعادة التسمية — تمت إعادة تسمية الدوال المؤكدة في قاعدة بيانات IDA الخاصة بها لتوثيق النتيجة مباشرة في الأثر القابل للتحليل، وليس في النص فقط.

بنية البرنامج الثابت

تحتوي صورة BIOS على أربع مناطق Intel Flash Descriptor؛ فقط region-bios يحتوي على كود GIGABYTE/OEM (region-me.fd region-gbe.fd region-pdr.fd هي برنامج ثابت لـ Intel Management Engine / GbE / الواصف — مكونات منفصلة خارج النطاق ولم تُستكشف).

داخل region-bios تم العثور على أربعة مجلدات برنامج ثابت واستخراجها:

تم استخراج الأربعة جميعًا وفحص علاماتها (راجع CVEs غير مؤكدة).

بنية المستودع

SMM/
├── README.md                    this file
├── CVE_ANALYSIS.md              full technical deep-dive (code-level detail confidence notes)
├── flash.fd                     copy of the extracted 16MB BIOS image
├── regions/                     raw recursive extraction (every FV/FFS/section as produced by uefi_firmware)
├── smm_modules/                 PiSmmCore isolated + fully analyzed (.pe32 + Hex-Rays .i64 renames applied)
├── smm_modules_all/             all 51 `Smm*`-named drivers as standalone PE32/TE + manifest.txt
│                                 (4 extra ones  PiSmmCpuDxeSmm SmmAccess SmmControl SmmLockBox
│                                  FlashSmiSmm FlashDriverSmm  have auto-analyzed .i64 databases)
├── all_modules/                 every extractable module from the main DXE/SMM volume (302 not just Smm*-named)
├── extra_volumes_modules/       modules from the two smaller auxiliary firmware volumes
└── f641_pei_modules/            modules from the duplicate PEI-phase volume copy

الخلفية: CVEs المنشورة

الخيط المشترك بين الأربعة جميعًا: معالج SMI برمجي يثق في سجل أو قيمة مصدرها NVRAM كمؤشر إلى الذاكرة دون التحقق من أنها تقع فعليًا خارج SMRAM، مما يتيح لمهاجم ring-0 (مسؤول/جذر) تحويل تشغيل SW SMI عادي إلى قراءة/كتابة عشوائية بامتيازات SMM (ring -2) — اختراق كامل للبرنامج الثابت وتجاوز Secure-Boot واستمرارية تحت مستوى نظام التشغيل.

نتيجة إضافية: موزّع ذاكرة SMM (PiSmmCore)

ليست ثغرة — بل بحث خلفي أرسى أساس بقية العمل بإثبات أن سلسلة الأدوات (الاستخراج ← عزل PE ← IDA/Hex-Rays ← الهندسة العكسية اليدوية) تستعيد فعليًا دواخل EDK2 حقيقية قابلة للتحقق من المصدر، قبل توجيهها نحو الأخطاء الأمنية.

PiSmmCore (GUID e94f54cd-81eb-47ed-aec3-856f5dc157a9) هو نواة SMM وفق مواصفات PI: فهو يملك SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages وجدول توزيع معالجات SMI.

سلسلة الاستدعاءات (العناوين داخل smm_modules/PiSmmCore.pe32.i64):

_ModuleEntryPoint (0x1184)
  -> SmmCoreEntryPointHelper (0x14D4)        writes the "SMST" table signature
     -> SmmInternalAllocatePool_wrapper (0x95EC)
        -> InternalAllocPoolByIndex_sphd_tail (0x57A8)     <- the allocator
     -> SmmAllocateZeroedPool (0x961C)        alloc + zero wrapper

SmmFreePool_wrapper (0x9714)
  -> SmmIsBufferInsideSmram (0x95A8)          decides SMRAM-resident vs not
  -> SmmInternalFreePool_sphd_tail (0x591C)   validates sphd/tail frees
     -> InternalFreePages (0x6A2C)            page-granularity free + coalesce
InternalFindFreePages (0x6820)                page-granularity alloc (mirror of InternalFreePages)

تم تأكيد InternalAllocPoolByIndex_sphd_tail (0x57A8) باعتباره الموزّع الحقيقي المقابل لـ MdeModulePkg/Core/PiSmmCore/Pool.c في EDK2: فهو يضمّن حرفيًا تواقيع ASCII الحرفية "sphd" (SMM_POOL_HEAD_SIGNATURE) و"tail" (SMM_POOL_TAIL_SIGNATURE) — وهي بالضبط الثوابت السحرية من التطبيق مفتوح المصدر. الطلبات ≤ 0x800 بايت تمر عبر موزّع فرعي بقوائم حرة مصنفة حسب الحجم؛ أما الطلبات الأكبر فتتنقل عبر قائمة حرة للصفحات وتغلّف الكتلة المُعادة بتوقيعي حماية للرأس/الذيل. النظير في جانب التحرير (SmmInternalFreePool_sphd_tail) يتحقق من التوقيعات نفسها قبل إعادة الذاكرة إلى القائمة الحرة.

جميع إعادة التسمية مدمجة في smm_modules/PiSmmCore.pe32.i64 — افتحه في IDA مع Hex-Rays لفحصه مباشرة.

مؤكد: CVE-2025-7027

الوحدة: GenericComponentSmmEntry (GUID 9caa3071-3459-4c5b-bbf0-ee68fe4dd46d) الملف: smm_modules_all/GenericComponentSmmEntry__9caa3071.pe32 (+ ملف .i64 محلَّل)

كيف تم العثور عليها

تم فحص كل وحدة مستخرجة (51 وحدة باسم Smm* ثم جميع الـ 302 في المجلد الرئيسي ثم المجلدات المساعدة) على مستوى البايت/السلاسل النصية بحثًا عن SetupXtuBufferAddress — اسم متغير NVRAM الدقيق الذي يستشهد به تقرير Binarly عن CVE-2025-7027. ظهرت كتطابق كسلسلة UTF-16LE داخل GenericComponentSmmEntry (ونظيره في DXE GenericComponentDxeEntry الذي يُفترض أنه يعيّنها/يكشفها).

السلسلة المعرضة للخطر

1. GetXtuBufferAddress_FromNvram (0x1F270) — يستدعي gRT->GetVariable(L"SetupXtuBufferAddress" &Guid NULL &Size=8 &OutBuffer) (الإزاحة +72 في الجدول بنمط خدمات وقت التشغيل = GetVariable). يُرجع القيمة الخام ذات الـ 8 بايت المخزنة في متغير NVRAM هذا — دون أي تحقق من ماهية تلك القيمة فعلًا.

2. SUSPECTED_CVE_2025_7027_UnvalidatedXtuPtrWrite (0x18400) — يستدعي ما سبق للحصول على v3 («العنوان» القادم من NVRAM) ثم يحلّق (محدودًا بعدّاد مأخوذ من بنية الإدخال الخاصة به a1[3]) منفذًا:

*(WORD *)(v3 + 2 * v7 + 12) = v9;   // v3 = raw NVRAM value v9 = attacker-influenced data

لا يُتحقق أبدًا من أن v3 عنوان حقيقي داخل الحدود وخارج SMRAM قبل استخدامه هدفًا للكتابة. SetupXtuBufferAddress هو متغير NVRAM عادي (غير مقفل عبر SMM في هذا الإصدار) — يستطيع مهاجم ring-0 تعيينه عبر SetVariable() إلى أي عنوان يختاره (مثل عنوان SMRAM أو بنية حساسة في النواة/المُشغّل الفائق) قبل تشغيل SMI، مما ينتج write-what-where خاضعة للتحكم بامتيازات SMM.

3. ComponentDispatch_KeymapOrXtu (0x18590) — رد نداء التوزيع: يجلب بايت نوع المكوّن من قاعدة بيانات مكوّنات داخلية، وإذا كان النوع == 1 يستدعي الدالة المعرضة للخطر أعلاه. أما النوع 0 فيذهب إلى SetupVar_SafeKeymapWrite_bounded (0x18234) الذي — على النقيض — يقوم فعلًا بفحص حدودي سليم للحجم مقابل السعة ضد متغير Setup حقيقي في NVRAM. هذا التباين هو ما يجعل مسار XTU بارزًا باعتباره المسار الشاذ غير المُتحقق منه.

4. sub_18698 — يسجّل ComponentDispatch_KeymapOrXtu مقابل قيمة التوزيع 0xB2 (178 عشريًا) — وهي بالضبط SwSmiInputValue 0xB2 التي تذكرها نشرة Binarly لهذه الفئة من الأخطاء. يربط هذا منفذ تشغيل SMI البرمجي مباشرةً بمسار التوزيع المعرض للخطر.

الثقة: عالية

• تطابق تام لاسم متغير NVRAM (SetupXtuBufferAddress) — حرفيًا.
• تطابق تام لقيمة تشغيل SW SMI (0xB2).
• نمط الكود (جلب مؤشر غير موثوق والكتابة عبره دون أي فحص عضوية/حدود) يطابق السبب الجذري «إلغاء مرجعية مؤشر مزدوج … كتابة عشوائية في SMRAM» تمامًا.
• غير مؤكد بشكل مستقل: القفزة الأخيرة — كيف يغذي سجل RBX عند دخول SMI مدخلات اختيار المكوّن التي تصل إلى ComponentDispatch_KeymapOrXtu/a1[3] — لم تُتتبع بالكامل حتى قراءة حالة حفظ CPU الخام. سيتطلب ذلك تمريرة إضافية عبر ما يوزّع قيمة 0xB2 المسجلة قبل الاستدعاء إلى رد النداء المسجل في GenericComponentSmmEntry.

هذا تأكيد عبر التحليل الثابت على أن النمط المعرض للخطر الموصوف في CVE موجود في إصدار BIOS هذا — وليس استغلالًا عمليًا أو PoC. لم يتم التحقق من محتويات SMRAM أو تخطيط حالة الحفظ أو السلوك وقت التشغيل.

CVEs غير مؤكدة — CVE-2025-7026 / 7028 / 7029

ما تم البحث عنه

كل علامة مذكورة في تقارير Binarly العامة لهذه الـ CVEs الثلاثة — $DB$ 2DB$ SwSmi OcHeader FuncBlock CommandRcx0 ReadFlash WriteFlash EraseFlash GetFlashInfo — تم البحث عنها كتسلسل بايت حرفي و(حيثما ينطبق ذلك) كسلسلة UTF-16LE عبر:

• صورة الـ 16 MB الخام flash.fd.
• جميع الـ 302 وحدة قابلة للاستخراج في مجلد DXE/SMM الرئيسي (all_modules/).
• جميع الوحدات في مجلدي البرنامج الثابت المساعدين (extra_volumes_modules/).
• جميع الـ 22 وحدة في النسخة المكررة لمجلد مرحلة PEI (f641_pei_modules/).

لم يتم العثور على أي من هذه العلامات في أي مكان. فقط SetupXtuBufferAddress (CVE-2025-7027) وسلاسل نص واجهة المستخدم العامة OverClock (غير ذات صلة — تسميات قوائم BIOS Setup) ظهرت كتطابق.

لماذا هذه النتيجة غير حاسمة وليست شهادة سلامة

كان يجب أن يظهر SetupXtuBufferAddress كسلسلة حرفية لأنه اسم متغير NVRAM حقيقي يُمرَّر إلى GetVariable() — السلسلة مطلوبة وظيفيًا. أما CommandRcx0 وOcHeader وFuncBlock فتبدو على النقيض كتسميات داخلية خاصة بـ Binarly لدوال مجهولة/مجرّدة من الرموز قاموا بهندستها عكسيًا، وليست معرفات مضمّنة في الملف الثنائي. غيابها كسلاسل نصية لا يثبت شيئًا بشأن وجود الكود الأساسي من عدمه. أما الثوابت السحرية $DB$/2DB$ فكانت ستظهر كتطابق على مستوى البايت لو كانت موجودة (ستظهر كمعامل فوري في المقارنة المترجمة أو لا تظهر) — غيابها أكثر دلالة إلى حد ما لكنه ما زال غير حاسم (ترميز فوري مختلف، أو نسخة برنامج ثابت مختلفة حسب الطراز، أو ترتيب فحص مختلف قليلًا — كلها قد تتجنب فحص السلسلة الفرعية الخام).

خطوات تالية ملموسة لمواصلة هذا البحث

1. CVE-2025-7028 (عمليات الفلاش). FlashSmiSmm (GUID 6c289241-...) وFlashDriverSmm (GUID 0c375a90-...) هما أقوى المرشحين — فاسماهما يطابقان ReadFlash/WriteFlash/EraseFlash/GetFlashInfo بشكل شبه تام. تم استخراج كلاهما وتحليله تلقائيًا (قواعد بيانات .i64 في smm_modules_all/ جاهزة لـ Hex-Rays) لكن لم يُتتبَّعا يدويًا — 174 و243 دالة على التوالي دون علامات ثابتة مميزة، الأمر الذي يتطلب النوع نفسه من تتبع المُوزِّع اليدوي الذي أُنجز لـ CVE-2025-7027 (اعثر على التسجيل المكافئ لـ SW SMI 0xB2، وتبِعه إلى توزيع جدول مؤشرات الدوال، وتحقق مما إذا كان مؤشر الجدول مُتحققًا منه).
2. CVE-2025-7029 (الطاقة/الحرارة OcHeader). مرشحون جيدون: GenericComponentSmmEntry نفسه (مصدر مثبت بالفعل لخلل مؤشر غير مُتحقق منه في هذه الوحدة بالذات) و و و و — لم يُتتبع أي منها يدويًا بعد.

لم يكتمل أي من هذا في هذه الجولة — تمت الإشارة إليه هنا صراحةً لتكون الفجوة مرئية بدلًا من أن يُفهم ضمنيًا أنها «تم فحصها وهي نظيفة».

المعالجة

إذا كنت تمتلك هذه اللوحة (أو أيًا من أكثر من 240 طرازًا من GIGABYTE تشملها هذه النشرة): حدّث إلى BIOS الحالي من موقع دعم GIGABYTE. بدأت GIGABYTE شحن البرنامج الثابت المُعالَج في 2025-06-12؛ والإصدار المُحلَّل هنا (H510MKV2.F3 بتاريخ 2023-12-20) يسبق ذلك بنحو 18 شهرًا ويتوافق مع كونه غير مُعالَج. هذه ليست توصية نظرية — لقد وجد هذا البحث مسار الكود الفعلي المعرض للخطر الخاص بـ CVE-2025-7027 حاضرًا في هذا الإصدار المحدد.

القيود

• لم تتوفر مكتبة أنواع EDK2/UEFI (.til) في بيئة التحليل هذه، لذا لم تستطع Hex-Rays تعيين حقول جدول نظام SMM (gSmst)/بنية البيانات الخاصة تلقائيًا؛ بعض تفسيرات إزاحات البنى في التحليل تستند إلى التتبع اليدوي وليس إلى معلومات أنواع مطبقة.
• تحليل ثابت فقط. لا اختبار ديناميكي ولا محاكاة ولا وصول إلى عتاد — النتائج تصف قابلية الوصول وشكل الكود، وليس قابلية الاستغلال المؤكدة وقت التشغيل على عتاد حقيقي.
• لم تُستكشف region-me.fd وregion-gbe.fd وregion-pdr.fd (مناطق Intel ME / GbE / الواصف) — خارج النطاق (مكونات برنامج ثابت منفصلة وليست كود SMM خاص بـ GIGABYTE/OEM).
• تبقى ثلاث من الـ CVEs الأربع غير مؤكدة كما فُصّل أعلاه.

المراجع

• GIGABYTE Security Advisory 2302
• CERT/CC VU#746790
• Binarly BRLY-DVA-2025-008 (CVE-2025-7026)
• Binarly BRLY-DVA-2025-011 (CVE-2025-7029)
• NVD: CVE-2025-7026
• uefi_firmware / uefi-firmware-parser
• راجع CVE_ANALYSIS.md للاطلاع على الغوص الفني الكامل على مستوى الكود الذي يلخّصه ملف README هذا.