EfiGuard
v1.4
EfiGuard is a portable x64 UEFI bootkit that patches the Windows boot manager, boot loader and kernel at boot time in order to disable PatchGuard and Driver Signature Enforcement (DSE).
If you're just looking to try EfiGuard, skip to Usage.
Currently supports all EFI-compatible versions of Windows x64 ever released, from Vista SP1 to Windows 11.
Easy to use: can be booted from a USB stick or the Windows EFI partition via a loader that automatically finds and boots Windows. The driver can also be loaded and configured manually using either the UEFI shell or the loader.
Makes extensive use of the Zydis disassembler library for fast runtime instruction decoding to support more robust analysis than what is possible with signature matching, which often requires changes with new OS updates.
Works passively: the driver does not load or start the Windows boot manager. Instead it acts on a load of bootmgfw.efi by the firmware boot manager via the boot selection menu or an EFI application such as the loader. If a non-Windows OS is booted, the driver will automatically unload itself.
Supports four-stage patching for when bootmgfw.efi starts bootmgr.efi rather than winload.efi. This is the case when a WIM file is loaded to boot WinPE, Windows Setup or Windows Recovery mode.
Graceful recovery: in case of patch failure, the driver will display error information and prompt to continue booting or to reboot by pressing ESC. This is true even up to the final kernel patch stage, because the last patch stage happens before ExitBootServices is called. Many UEFI Windows bootkits hook OslArchTransferToKernel which, while easy to find by pattern matching, is a function that executes in protected mode after ExitBootServices. This means no boot services are available to tell the user that something went wrong.
While EfiGuard is a UEFI bootkit, it did not start out as one. EfiGuard was originally an on-disk patcher running on NT (similar to UPGDSED), intended to test the viability of a disassembler-based aproach, as opposed to using PDB symbols and version-specific signatures. PatchNtoskrnl.c still looks very much like this original design. Only after this approach proved successful, with no modifications to code needed in over a year of Windows updates, did UEFI come into the picture as a way to further improve capabilities and ease of use.
Some of the benefits provided by a bootkit approach include:
bcdedit.ImgpValidateImageHash (although this is still optionally done).db store.The initial incarnation of EfiGuard as a bootkit was an attempt to get dude719's UEFI-Bootkit to work with recent versions of Windows 10, because it had become dated and no longer works on the latest versions (like UPGDSED, often caused by version-sensitive pattern scans). While I did eventually get this to work, I was unsatisfied with the result mostly due to the choice of hooking OslArchTransferToKernel, which as noted above executes in protected mode and after ExitBootServices has been called. Apart from this, I was not satisfied with only being able to patch some versions of Windows 10; I wanted the bootkit to work on every EFI-compatible version of Windows x64 released to date. Because of this, I rewrote the bootkit from scratch with the following aims:
A big picture overview of the final EfiGuard boot flow is shown in the diagram above. For the individual component-specific hooks and patches, see EfiGuardDxe/PatchXxx.c in the source files. For driver initialization/unloading and the EFI Boot and Runtime Services hooks, see EfiGuardDxe.c.
EfiGuard is licensed under the GPLv3. Files in the EfiGuardDxe/Zydis submodule are licensed under the MIT license.
