Übersicht

EfiGuard ist ein portables x64-UEFI-Bootkit, das den Windows-Boot-Manager, den Boot-Loader und den Kernel zur Bootzeit patcht, um PatchGuard und die Treibersignaturprüfung (DSE) zu deaktivieren.

Wenn Sie EfiGuard nur ausprobieren möchten, springen Sie zu Verwendung.

Funktionen

• Unterstützt derzeit alle jemals veröffentlichten EFI-kompatiblen Versionen von Windows x64, von Vista SP1 bis Windows 11.

• Einfach zu bedienen: Kann von einem USB-Stick oder der Windows-EFI-Partition über einen Lader gebootet werden, der Windows automatisch findet und startet. Der Treiber kann auch manuell über die UEFI-Shell oder den Lader geladen und konfiguriert werden.

• Nutzt umfangreich die Zydis-Disassembler-Bibliothek für schnelle Laufzeit-Dekodierung von Anweisungen, um eine robustere Analyse zu unterstützen, als dies mit Signatur-Matching möglich ist, das oft Änderungen bei neuen OS-Updates erfordert.

• Arbeitet passiv: Der Treiber lädt oder startet den Windows-Boot-Manager nicht. Stattdessen reagiert er auf ein Laden von bootmgfw.efi durch den Firmware-Boot-Manager über das Boot-Auswahlmenü oder eine EFI-Anwendung wie den Lader. Wenn ein Nicht-Windows-Betriebssystem gebootet wird, entlädt sich der Treiber automatisch.

• Unterstützt vierstufiges Patchen für den Fall, dass bootmgfw.efi bootmgr.efi statt winload.efi startet. Dies ist der Fall, wenn eine WIM-Datei geladen wird, um WinPE, Windows-Setup oder Windows-Wiederherstellungsmodus zu booten.

• Sanfte Wiederherstellung: Bei einem Patch-Fehler zeigt der Treiber Fehlerinformationen an und fordert auf, mit ESC den Bootvorgang fortzusetzen oder neu zu starten. Dies gilt sogar bis zur letzten Kernel-Patch-Stufe, da die letzte Patch-Stufe vor dem Aufruf von ExitBootServices stattfindet. Viele UEFI-Windows-Bootkits hooken OslArchTransferToKernel, das zwar leicht durch Pattern-Matching zu finden ist, aber eine Funktion ist, die im geschützten Modus nach ExitBootServices ausgeführt wird. Das bedeutet, dass keine Boot-Dienste verfügbar sind, um dem Benutzer mitzuteilen, dass etwas schiefgelaufen ist.

  Simulierter Patch-Fehler mit Fehlerinformationen

• Debug-fähig: Kann während der Kernel-Patching-Phase Nachrichten an einen Kernel-Debugger und an den Bildschirm (wenn auch gepuffert) ausgeben und während der Phasen des Boot-Managers und Boot-Loaders an eine serielle Schnittstelle oder ungepuffert an den Bildschirm. Wenn der Treiber mit PDB-Debug-Informationen kompiliert wird, können die Debug-Symbole zu jedem Zeitpunkt nach der HAL-Initialisierung geladen werden, indem die virtuelle DXE-Treiberbasis angegeben und der Treiber wie ein normaler NT-Treiber debuggt wird.

• DSE-Bypässe: Verfügbar entweder als einfache UPGDSED-artige DSE-Deaktivierung zur Bootzeit oder als Hook auf den EFI-Laufzeitdienst SetVariable(). Letzteres dient als Hintertür für beliebiges Kernel-Mode-Lesen/Schreiben, die von Windows aus mit NtSetSystemEnvironmentValueEx aufgerufen werden kann und das Setzen von g_CiEnabled/g_CiOptions auf den gewünschten Wert erlaubt. Eine kleine DSEFix-ähnliche Anwendung namens EfiDSEFix.exe wird bereitgestellt, um dies zu tun. Es ist auch möglich, DSE aktiviert zu lassen und nur PatchGuard zu deaktivieren. Der Lader verwendet standardmäßig die SetVariable-Hook-Methode, da einige Anti-Cheat- und Anti-Viren-Programme den Unterschied zwischen Cheats oder Malware und selbstsignierten Treibern im Allgemeinen nicht verstehen und den UPGDSED-Fix ins Visier nehmen.

• Unterstützt modifizierte Kernel und Boot-Loader auf der Festplatte, indem ImgpValidateImageHash auf jeder Stufe sowie ImgpFilterValidationFailure gepatcht wird, das möglicherweise stillschweigend bestimmte Verstöße an ein TPM oder die SI-Protokolldatei meldet.

• Ermöglicht Secure Boot unter Windows 7 (kein Witz!). Windows 7 selbst ist sich Secure Boot nicht bewusst, da es es nicht unterstützt oder (offiziell) sogar das Booten ohne CSM. Dies ist nützlich für Personen, die Windows 7 auf einem gesperrten Gerät verwenden möchten, das WHQL Secure Boot erfordert. Wiki-Eintrag zur Funktionsweise hier.

  WinObjEx64 unter Windows 7 mit aktiviertem Secure Boot

Probleme und Einschränkungen

• EfiGuard kann Hypervisor-erzwungene Code-Integrität (HVCI oder HyperGuard) nicht deaktivieren, da HVCI auf einer höheren Privilegstufe läuft. EfiGuard kann mit HVCI koexistieren und PatchGuard im normalen Kernel sogar erfolgreich deaktivieren, aber dies ist in der Praxis nicht nützlich, da HVCI abfängt, was PatchGuard zuvor getan hat. Beide Arten von DSE-Bypass werden durch HVCI nutzlos: Der Bootzeit-Patch hat keine Wirkung, da der Kernel für Integritätsprüfungen an den Secure Kernel delegiert, und der SetVariable-Hook verursacht einen SECURE_KERNEL_ERROR-Bugcheck, wenn er zum Schreiben auf g_CiOptions verwendet wird.
• Geprüfte Kernel werden nicht unterstützt, da die Unterschiede im PatchGuard- und DSE-Initialisierungscode aufgrund deaktivierter Optimierungen und hinzugefügter Asserts sowie zusätzlicher Änderungen an PatchGuard in geprüften Kerneln. Dies sollte kein Problem darstellen, da geprüfte Kernel ohne angeschlossenen Kernel-Debugger, der PatchGuard deaktiviert, im Allgemeinen nicht nützlich sind.

Verwendung

Es gibt zwei Möglichkeiten, EfiGuard zu verwenden: Booten der Lader-Anwendung, die den Treiber lädt und Windows für Sie startet, oder Installieren des Treibers als UEFI-Treibereintrag, damit er automatisch von der Firmware geladen wird.

Die Installation des Treibers kann in einigen fortgeschrittenen Konfigurationen wie beim Multi-Boot vorzuziehen sein, aber der Lader ist am einfachsten zu verwenden und sollte in allen Konfigurationen gut funktionieren. Siehe die Tabelle unten für die wichtigsten Unterschiede zwischen den beiden Methoden. Wenn Sie unsicher sind, wählen Sie die Lader-Anwendung.

Vergleich Lader vs. UEFI-Treibereintrag

Den Lader booten

1. Laden Sie EfiGuard herunter und benennen Sie EFI/Boot/Loader.efi in bootx64.efi um.
2. Legen Sie die Dateien auf einem Boot-Laufwerk ab, z. B. einem FAT32-formatierten USB-Stick (für physische Maschinen) oder einer ISO/virtuellen Festplatte (für VMs). Angenommen Laufwerk X:, sollten die Pfade für die beiden Dateien nun X:/EFI/Boot/{bootx64|EfiGuardDxe}.efi sein.
3. Booten Sie die Maschine von dem in Schritt 2 verwendeten Laufwerk. Die meisten Firmwares bieten ein Boot-Menü, um dies über F8/F10/F11/F12 zu tun. Wenn nicht, müssen Sie das BIOS so konfigurieren, dass es vom neuen Laufwerk bootet.
4. Windows sollte nun booten, und Sie sollten während des Bootens EfiGuard-Meldungen sehen.
5. Wenn Sie mit dem SetVariable-Hook (Standard) gebootet haben, führen Sie nach dem Booten EfiDSEFix.exe -d in einer Administratoreingabeaufforderung aus, um DSE zu deaktivieren, oder führen Sie EfiDSEFix.exe aus, um die vollständige Liste der Optionen zu sehen.

Beachten Sie, dass Sie kein separates Laufwerk für den Lader verwenden müssen. Falls gewünscht, können Sie EfiGuard auf der ESP installieren, auf der Windows bereits installiert ist. Dies ist jedoch etwas komplizierter, da Sie einen UEFI-Boot-Eintrag für den Lader hinzufügen müssen.

Mounten Sie dazu die ESP unter X: mit mountvol X: /S und folgen Sie den obigen Schritten, benennen Sie den Lader jedoch nicht um und kopieren Sie einfach beide Dateien nach X:/EFI/Boot. Danach müssen Sie manuell einen UEFI-Boot-Eintrag von der UEFI-Shell mit bcfg boot addp 0 Loader.efi "EfiGuard" oder alternativ mit efibootmgr (Linux), EasyUEFI (Windows) oder ähnlichem hinzufügen.

Installieren des Treibers

1. Mounten Sie die ESP unter X: mit mountvol X: /S.
2. Kopieren Sie EfiGuardDxe.efi nach X:/EFI/Boot/EfiGuardDxe.efi.
3. Booten Sie in die UEFI-Shell und fügen Sie einen UEFI-Treibereintrag hinzu: bcfg driver add 0 EfiGuardDxe.efi "EfiGuardDxe".
4. Windows sollte nun booten, und Sie sollten während des Bootens EfiGuard-Meldungen sehen.
5. Wenn Sie mit dem SetVariable-Hook (Standard) gebootet haben, führen Sie nach dem Booten EfiDSEFix.exe -d in einer Administratoreingabeaufforderung aus, um DSE zu deaktivieren, oder führen Sie EfiDSEFix.exe aus, um die vollständige Liste der Optionen zu sehen.

Hinweis: Abhängig von Ihrer Firmware müssen Sie möglicherweise in Schritt 3 "addp" anstelle von "add" verwenden. VirtualBox ist dafür bekannt, dies zu erfordern, und möglicherweise tun dies auch einige Mainboard-Firmwares.

Hinweis: Einige sehr alte oder nicht konforme Firmwares unterstützen diese Installationsmethode möglicherweise überhaupt nicht. Auf diesen Systemen haben Sie keine andere Wahl, als stattdessen den Lader zu verwenden.

Kompilierung

Kompilieren von EfiGuardDxe und dem Lader

EfiGuard benötigt EDK2 zum Bauen. Wenn Sie EDK2 nicht installiert haben, folgen Sie zuerst den Schritten unter Erste Schritte mit EDK2, da das EDK2-Buildsystem recht komplex einzurichten ist. Dieser Abschnitt geht davon aus, dass Sie ein workspace-Verzeichnis haben, auf das Ihre WORKSPACE-Umgebungsvariable zeigt, mit einem Checkout von EDK2 in workspace/edk2. Unterstützte Compiler sind MSVC, Clang, GCC und ICC.

1. Klonen Sie das EfiGuard-Repository in workspace/edk2/EfiGuardPkg.
2. Öffnen Sie eine Eingabeaufforderung oder Shell, die die Umgebungsvariablen für EDK2 einrichtet.
3. Führen Sie build -a X64 -t VS2019 -p EfiGuardPkg/EfiGuardPkg.dsc -b RELEASE aus und ersetzen Sie VS2019 durch Ihre Toolchain.

Dies erzeugt EfiGuardDxe.efi und Loader.efi in workspace/Build/EfiGuard/RELEASE_VS2019/X64.

Kompilieren von EfiDSEFix

EfiDSEFix benötigt Visual Studio zum Bauen.

1. Öffnen Sie EfiGuard.sln und erstellen Sie die Projektmappe.

Die Ausgabebinärdatei EfiDSEFix.exe befindet sich in Application/EfiDSEFix/bin.

Die Visual Studio-Projektmappe enthält auch Projekte für EfiGuardDxe.efi und Loader.efi, die mit VisualUefi verwendet werden können, aber diese Projekte werden standardmäßig nicht erstellt, da sie ohne zusätzlichen Code nicht linken, und die Build-Ausgabe ist schlechter (größer) als das, was EDK2 produziert. Loader.efi wird aufgrund der fehlenden UefiBootManagerLib in VisualUefi überhaupt nicht linken. Diese Projektdateien sind daher nur als Entwicklungshilfe gedacht, und die EFI-Dateien sollten weiterhin mit EDK2 kompiliert werden. Um VisualUefi für diesen Zweck einzurichten, klonen Sie das Repository in workspace/VisualUefi und öffnen Sie EfiGuard.sln.

Architektur

Obwohl EfiGuard ein UEFI-Bootkit ist, begann es nicht als solches. EfiGuard war ursprünglich ein auf NT laufender On-Disk-Patcher (ähnlich UPGDSED), der dazu diente, die Machbarkeit eines disassemblerbasierten Ansatzes zu testen, im Gegensatz zur Verwendung von PDB-Symbolen und versionsspezifischen Signaturen. PatchNtoskrnl.c sieht diesem ursprünglichen Design noch sehr ähnlich. Erst nachdem sich dieser Ansatz als erfolgreich erwies, ohne dass über ein Jahr Windows-Updates hinweg Codeänderungen erforderlich waren, kam UEFI ins Spiel, um die Fähigkeiten und die Benutzerfreundlichkeit weiter zu verbessern.

Einige der Vorteile eines Bootkit-Ansatzes sind:

• Keine On-Disk-Änderungen an Kerneln oder Bootloadern erforderlich.
• Keine Notwendigkeit, den Boot-Konfigurationsspeicher mit bcdedit zu ändern.
• Keine Notwendigkeit, ImgpValidateImageHash zu patchen (obwohl dies noch optional geschieht).
• Ironischerweise ermöglicht die Verwendung eines Bootkits die Aktivierung von Secure Boot, vorausgesetzt, Sie besitzen den Platform Key und können Ihr persönliches Zertifikat zum db-Store hinzufügen.

Die erste Inkarnation von EfiGuard als Bootkit war ein Versuch, dude719's UEFI-Bootkit mit aktuellen Versionen von Windows 10 zum Laufen zu bringen, da es veraltet war und auf den neuesten Versionen nicht mehr funktionierte (wie UPGDSED, oft verursacht durch versionsempfindliche Pattern-Scans). Während ich es schließlich zum Laufen brachte, war ich mit dem Ergebnis unzufrieden, hauptsächlich aufgrund der Wahl, OslArchTransferToKernel zu hooken, das wie oben erwähnt im geschützten Modus und nach Aufruf von ExitBootServices ausgeführt wird. Abgesehen davon war ich nicht zufrieden damit, nur einige Versionen von Windows 10 patchen zu können; ich wollte, dass das Bootkit auf jeder bisher veröffentlichten EFI-kompatiblen Version von Windows x64 funktioniert. Aus diesem Grund habe ich das Bootkit von Grund auf neu geschrieben mit den folgenden Zielen:

• Patch-Informationen auf jeder Boot-Stufe bereitzustellen, einschließlich des Kernel-Patches selbst.
• Alle EFI-kompatiblen Versionen von Windows-Versionen (zum Zeitpunkt des Schreibens) zu unterstützen.
• Lazy Instantierung des Bootkits und optional eine Kernel-Hintertür zu ermöglichen, erreicht durch EFI System Table Hooks.

Eine große Übersicht über den endgültigen EfiGuard-Bootablauf ist im obigen Diagramm dargestellt. Für die einzelnen komponentenspezifischen Hooks und Patches siehe EfiGuardDxe/PatchXxx.c in den Quelldateien. Für Treiberinitialisierung/-entladung und die EFI Boot- und Runtime-Services-Hooks siehe EfiGuardDxe.c.

Danksagungen

• UPGDSED von hfiref0x und Fyyre
• Zydis von zyantific
• Uninformed-Artikel über PatchGuard v1, v2 und v3 von Skywing
• UEFI-Bootkit von dude719
• ReactOS

Lizenz

EfiGuard ist unter der GPLv3 lizenziert. Dateien im Untermodul EfiGuardDxe/Zydis sind unter der MIT-Lizenz lizenziert.