# EfiGuard: Disabling PatchGuard and Driver Signature Enforcement at Boot

> EfiGuard is a portable x64 UEFI bootkit that patches the Windows boot manager, boot loader and kernel before the OS starts. It is aimed at kernel developers and researchers, and its own README is explicit about what it cannot do.

**Mattiwatti/EfiGuard** — Disable PatchGuard and Driver Signature Enforcement at boot time

- Repository: https://github.com/Mattiwatti/EfiGuard
- Stars: 2,547 · Forks: 412
- Language: C++
- License: GPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/mattiwatti-efiguard

## What EfiGuard disables and who needs that

Two Windows mechanisms stand between a developer and a driver that was not signed by Microsoft. PatchGuard periodically checks critical kernel structures and bugchecks the machine when they change. Driver Signature Enforcement refuses to load a kernel driver whose signature does not chain to a trusted certificate. EfiGuard targets both, and it does so before Windows runs any of its own code.

The intended user is not a typical Windows administrator. It is someone writing or studying kernel-mode code who needs to load a self-signed driver on their own hardware, or who wants to inspect kernel structures that PatchGuard would otherwise protect. The README also lists a less obvious use: making Secure Boot work with Windows 7, which has no Secure Boot support of its own, on a device that requires WHQL Secure Boot. That is a narrow configuration, and the project points to a wiki entry rather than describing the procedure in the README.

The project is written in C++, licensed under GPL-3.0, and the repository's last push was on 2026-06-16. The most recent tagged release is v1.4 from 2023-10-15, so the release history is much older than the commit history.

## How the load-time patching actually works

EfiGuard is a DXE driver, not a Windows service. It works passively. The README states that the driver does not load or start the Windows boot manager itself; instead it acts when the firmware boot manager loads `bootmgfw.efi`, whether that happens from the boot selection menu or from an EFI application such as the bundled loader. If a non-Windows OS is booted, the driver unloads itself.

The patching is staged. The normal path covers the boot manager and the boot loader, and a four-stage path handles the case where `bootmgfw.efi` starts `bootmgr.efi` instead of `winload.efi`, which is what happens when a WIM file is loaded for WinPE, Windows Setup or Windows Recovery. The kernel patch is the last stage, and it happens before `ExitBootServices` is called. That ordering is the design point the README argues for: many UEFI Windows bootkits hook `OslArchTransferToKernel`, which runs in protected mode after `ExitBootServices`, so no boot services remain to report a failure to the user. EfiGuard can still show error information and prompt to continue or press ESC to reboot.

For analysis, EfiGuard uses the Zydis disassembler library to decode instructions at runtime rather than matching byte signatures, which the README says is more robust and needs fewer changes when Windows updates. It also patches `ImgpValidateImageHash` at every stage and `ImgpFilterValidationFailure`, which the README notes may silently report some classes of violations to a TPM or the SI log.

## Installing EfiGuard from a USB stick and running it

The README gives two deployment methods and recommends the loader for anyone unsure. The loader lives anywhere and needs no installation; the UEFI driver entry must sit on the EFI System Partition and is installed through the UEFI shell, but it cannot be skipped once installed and always boots the same OS as before.

The loader route starts with a rename and a copy. The README says to rename `EFI/Boot/Loader.efi` to `bootx64.efi`, then place the files on a FAT32 USB stick for a physical machine, or an ISO or virtual disk for a VM. Assuming drive `X:`, the two files end up as `X:/EFI/Boot/bootx64.efi` and `X:/EFI/Boot/EfiGuardDxe.efi`. Boot the machine from that drive, using the firmware boot menu (F8, F10, F11 or F12 on most firmware) or by changing the BIOS boot order. Windows should then boot, and EfiGuard messages appear during boot.

The default configuration uses the `SetVariable` hook method rather than the UPGDSED-style boot-time DSE disable. With that default, DSE is not yet off after boot. You run the bundled application from an Administrator command prompt:

```bash
EfiDSEFix.exe -d
```

The README states that `-d` disables DSE, and that running `EfiDSEFix.exe` with no arguments prints the full option list. The README does not document a rollback command for undoing the boot-time patch, and it does not document uninstalling the UEFI driver entry; the loader, by contrast, is skippable because you choose whether to boot from it.

## HVCI and checked kernels are hard stops

The README's limitations section is unusually direct, and it is the part worth reading before anything else. EfiGuard cannot disable Hypervisor-enforced Code Integrity, also called HVCI or HyperGuard, because HVCI runs at a greater privilege level. EfiGuard can coexist with HVCI and can disable PatchGuard in the normal kernel, but the README says this is not useful in practice because HVCI catches what PatchGuard did. Both DSE bypass methods fail under HVCI: the boot-time patch has no effect because the kernel defers integrity checks to the secure kernel, and using the `SetVariable` hook to write to `g_CiOptions` causes a `SECURE_KERNEL_ERROR` bugcheck.

Checked kernels are also unsupported. The README gives the reason: disabled optimizations and added asserts change the PatchGuard and DSE initialization code, and PatchGuard itself differs in checked kernels. It adds that this should not matter much, since checked kernels are not generally useful without a kernel debugger attached, and attaching one disables PatchGuard anyway.

The practical consequence is that EfiGuard is the wrong tool on any machine where you cannot turn HVCI off, and it is the wrong tool if you need a guarantee rather than a best-effort patch. The README's own recovery story is a prompt to continue or reboot, which is a graceful failure, not a successful patch.

## EfiGuard against UPGDSED and DSEFix

The closest comparison is in the README itself. EfiGuard offers a UPGDSED-style DSE disable at boot time as one option, and the `SetVariable` hook as the default. The difference is not cosmetic. The boot-time disable replicates what UPGDSED does: it turns DSE off before Windows finishes starting. The `SetVariable` hook instead exposes an arbitrary kernel-mode read/write path that can be called from Windows through `NtSetSystemEnvironmentValueEx`, letting you set `g_CiEnabled` or `g_CiOptions` whenever you want. EfiDSEFix.exe is the DSEFix-style client for that path.

The README gives a concrete reason for preferring the hook: some anti-cheat and anti-virus programs do not distinguish between cheats or malware and self-signed drivers in general, and target the UPGDSED fix specifically. That is a detection-surface argument, not a performance one. It also means the default is the more capable option, and the boot-time disable is the compatibility fallback.

A second axis is PatchGuard alone. EfiGuard can leave DSE enabled and disable only PatchGuard, which matters if you want signed drivers to keep loading normally while you work on kernel structures. Neither UPGDSED nor DSEFix offers that split, because both exist to turn DSE off.

## Building it, licence terms and upgrade cost

The repository ships an EDK2-style package: `EfiGuardPkg.dec` and `EfiGuardPkg.dsc` at the top level, `EfiGuardDxe/` for the driver, `Application/` for the Windows-side tool, and `Include/` for shared headers, with `EfiGuard.sln` and `EfiGuard.props` for the Visual Studio side. Zydis is pulled in as a git submodule, which is why `.gitmodules` is present. The README does not give build instructions in the text available here, so the package files are the place to start.

EfiGuard is GPL-3.0. That matters more than usual for this kind of project, because the driver is loaded into firmware and the Windows-side tool is a separate executable. If you plan to link the driver code into a product you distribute, the licence obligations travel with it. This is a description of the licence identifier, not legal advice; read the LICENSE file and get your own counsel.

Upgrade cost is the real ongoing expense. The project decodes instructions at runtime with Zydis instead of matching signatures, which the README presents as reducing the changes needed when Windows updates. That is a design claim, not a guarantee, and the README still documents four-stage patching for the WIM boot path and specific functions such as `ImgpValidateImageHash` and `ImgpFilterValidationFailure` that must be patched at every stage. Any Windows release that reworks those paths is a candidate for a new analysis pass. The gap between the v1.4 release in 2023 and the 2026-06-16 push suggests changes land in the repository without a matching tag, so pinning to a release tag and pinning to a commit are different decisions.

## Conclusion

EfiGuard is for kernel developers, driver authors and researchers who need a self-signed or modified driver to load on a machine they control, and who accept that HVCI and checked kernels are out of reach. It is not for anyone trying to run it on a managed or locked-down production machine, and not for a system where the secure kernel is active. Before relying on it, verify three things on your own hardware: that the firmware boots the loader from your USB stick, that EfiDSEFix.exe reports the DSE state you expect after boot, and that HVCI is off, because the README states both DSE bypass methods are useless when it is on.

## FAQ

### How do I install EfiGuard?

The README's loader method needs no installation: rename EFI/Boot/Loader.efi to bootx64.efi, place it and EfiGuardDxe.efi on a FAT32 USB stick or an ISO or virtual disk, and boot the machine from that drive. The alternative is installing the driver as a UEFI driver entry on the EFI System Partition via the UEFI shell.

### How do I use EfiGuard?

Boot from the loader drive so Windows starts with EfiGuard active, then run EfiDSEFix.exe -d from an Administrator command prompt to disable DSE, because the default SetVariable hook method does not disable it at boot. Running EfiDSEFix.exe with no arguments prints the full option list.

### What does EfiGuard do?

It is a portable x64 UEFI bootkit that patches the Windows boot manager, boot loader and kernel at boot time to disable PatchGuard and Driver Signature Enforcement. It can also disable only PatchGuard while leaving DSE enabled.

### Is EfiGuard safe?

The README does not make a safety claim, and it documents a real failure mode: EfiGuard cannot disable HVCI, and using the SetVariable hook to write to g_CiOptions under HVCI causes a SECURE_KERNEL_ERROR bugcheck. On patch failure the driver shows error information and prompts to continue booting or press ESC to reboot.

### What is EfiGuard?

The README describes it as 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. It supports all EFI-compatible Windows x64 versions from Vista SP1 to Windows 11.

## Sources

- [Issues](https://github.com/Mattiwatti/EfiGuard/issues)
- [License: GPL-3.0](https://github.com/Mattiwatti/EfiGuard/blob/master/LICENSE)
- [Mattiwatti/EfiGuard on GitHub](https://github.com/Mattiwatti/EfiGuard)
- [README](https://github.com/Mattiwatti/EfiGuard/blob/master/README.md)
- [Releases](https://github.com/Mattiwatti/EfiGuard/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mattiwatti-efiguard