HackBGRT: replacing the Windows UEFI boot logo without touching firmware

The logo lives in firmware, and HackBGRT does not touch firmware

On a UEFI machine, Windows can display a vendor logo that the firmware stores in a section called the Boot Graphics Resource Table (BGRT). Changing it permanently means rewriting firmware, which is risky and vendor-specific. HackBGRT takes the other route: a custom UEFI application runs before Windows and overwrites the logo in memory during the boot. The firmware image itself is never modified, so the change survives only as long as HackBGRT runs on every boot. That is the whole design, and it explains both the appeal and the friction. The README states plainly that the original logo is often visible for a moment before HackBGRT starts, and asks users not to report that as a bug. It cannot be fixed without modifying computer firmware, which the project says it will not do. So the realistic outcome is a split-second flash of the vendor logo, then your image. If you need the vendor logo gone from the very first frame, this tool does not do that. It is aimed at people who want a custom splash on a personal Windows machine and are willing to accept that boundary.

How the boot chain is rearranged, and what shim is doing there

HackBGRT is not a Windows program that runs after login. It is an EFI executable that has to start before Windows so it can overwrite the BGRT contents. The installer offers several ways to arrange that: a new EFI boot entry created with bcdedit, a new EFI boot entry written to NVRAM, or overwriting the Microsoft boot loader. Each has a different failure mode, which is why the batch interface exposes them separately as enable-bcdedit, enable-entry and enable-overwrite. The project is built with clang against gnu-efi, producing freestanding EFI binaries for x64, ia32, aa64 and arm, and the C side lives in src/main.c, src/util.c, src/types.c, src/config.c, src/sbat.c and src/efi.c. The C# side (src/Setup.cs, src/Esp.cs, src/Efi.cs, src/EfiBootEntries.cs) is the installer. Secure Boot is the awkward part. Microsoft has not approved HackBGRT, so the project ships the shim boot loader, maintained by Red Hat and extracted from various Linux distributions, which lets you manually select HackBGRT as a trusted program. The README is explicit that these steps cannot be automated, because that is the point of Secure Boot, and that enrolling foreign certificates directly into firmware is not advisable. The shim files carry their own copyright notice in shim-signed/COPYRIGHT.

Installing HackBGRT and changing the logo on a first run

The README's Windows path assumes one bootable hard drive; with more than one, the automatic setup may fail. Get the latest release from the Releases page, then run setup.exe and follow the prompts. The installer launches Paint for editing the image, or you can supply your own. For a quiet install, edit config.txt and splash.bmp first, then run setup.exe batch as administrator. The example given in the README disables any previous installation, copies the files, and creates the EFI boot entry with bcdedit:

setup.exe batch disable install enable-bcdedit

If you want a different image, copy it next to setup.exe and point config.txt at it before installing. The README gives this example for a file named my.jpg:

path=my.jpg

If you copy an image to the EFI System Partition by hand instead, it must be a 24-bit BMP with a 54-byte header, described in the README as TrueColor BMP3 in ImageMagick or 24-bit BMP/DIB in Microsoft Paint. After installing, read shim.md and follow its instructions on the first reboot. The README warns that the first boot can be very slow, sometimes several minutes, for an unknown reason, and suggests waiting and rebooting a few times before concluding something is wrong. If Windows later restores the original boot loader, the README says to just reinstall. To change the image or configuration afterwards, choose the option to install files only.

TPM, BitLocker and anti-cheat are the real cost of admission

This is the part that decides whether HackBGRT is appropriate for a given machine. A TPM watches how the computer boots, and inserting HackBGRT into the boot process changes that measurement. The README lists what may stop working: BitLocker or similar disk encryption, anti-cheat software, the Windows PIN unlock method, and other security features that mention TPM. It advises disabling these before using HackBGRT, and notes that some can be re-enabled afterwards while some cannot. For TPM problems it recommends either uninstalling HackBGRT or giving up the problematic feature. That is a blunt trade, and it is stated as such rather than softened. The README also floats a technical workaround, installing HackBGRT before Windows so that Windows is always booted through it, and immediately admits it is easier said than done. There is no documented rollback for a TPM state that has already changed, and the README does not describe how to reconfigure the TPM; it asks users who find an easy way to document and share it. On a personal desktop with no BitLocker and no anti-cheat, none of this matters. On a managed laptop, it is disqualifying.

The unbootable-system risk is not hypothetical hedging

The README opens its usage section with a warning that a messed-up installation may leave the system unbootable, and tells you to create a rescue disk first. That is not boilerplate. The installer can overwrite the Microsoft boot loader, which is why the batch interface has a separate disable-overwrite command to restore it, and why enable-overwrite exists as a distinct choice rather than the default. The troubleshooting section is written for people who are already stuck: if bcdedit fails, try the other installation option in the menu, and if that fails too, open Command Prompt and work out why bcdedit /enum firmware is failing. Suggestions include disabling antivirus, checking the hard disk, and searching for how to fix error 0x800703EE. A "Verification failed, Security violation" message is described as part of the first-boot setup, not a defect, and points back to shim.md. If the boot hangs on a spinner, the README says to wait, then reboot a few times. Notice what is missing: there is no documented one-command recovery from a machine that will not boot at all. The rescue disk is the recovery plan.

Multi-boot and Linux: where HackBGRT fits alongside other loaders

HackBGRT is not only for Windows-only machines, but the configurations differ. If you only need it for Windows, install the files without enabling, then point your existing boot loader at \EFI\HackBGRT\loader.efi. If you need it to start another system as well, you can configure HackBGRT to chain to that loader. The README gives the example boot=\EFI\systemd\systemd-bootx64.efi, then install as a new EFI boot entry. On a pure Linux install, the documented path is to run setup.exe dry-run and manually copy the files from dry-run/EFI to [EFI System Partition]/EFI, then consult your own distribution's documentation. Compared with editing firmware with a vendor tool, this is a lighter-touch approach: the change lives in the EFI System Partition and in NVRAM entries, both of which are reversible with the disable commands. Compared with a boot loader such as systemd-boot or GRUB, the difference is scope. Those manage which operating system starts; HackBGRT only paints a logo on the way to Windows and can hand control onward. If what you actually want is a custom boot menu, HackBGRT is not that tool, and the README treats it as a guest in someone else's boot chain rather than a replacement for it.

Licence, maintenance and what an upgrade actually costs

HackBGRT is MIT licensed, which places few restrictions on reuse and modification of the project's own code. Two caveats sit outside that licence. The bundled shim binaries are signed copies extracted from Linux distributions and maintained by Red Hat, with copyright information in shim-signed/COPYRIGHT, so their terms are not the project's MIT terms. And signing is not the same as approval: the README states that Microsoft has not approved HackBGRT, and that although it is self-signed with a certificate, enrolling foreign certificates directly into firmware is not advisable. On maintenance, the last push to the repository was on 2026-04-02, and v2.6.0 was released the same day, following v2.5.2 in April 2025 and v2.5.1 in August 2024. That is a slow release cadence, roughly annual, which is reasonable for a tool whose target is a firmware table that changes rarely, but it means a fix for a new Windows or firmware behaviour will not arrive quickly. Upgrading is not a background update: the README says that if Windows restores the original boot loader you simply reinstall, and that changing the image or configuration later means choosing the option to install files only. Budget for a reboot, a shim confirmation and a possible BitLocker re-check each time.

Editorial conclusion

HackBGRT suits people who understand their UEFI boot chain and accept that BitLocker, anti-cheat and Windows PIN unlock may need to be disabled first. It is the wrong choice on a work laptop, a machine with anti-cheat titles, or any system where you cannot create a rescue disk. Before installing, confirm you have one bootable hard drive, read shim.md, and check that bcdedit /enum firmware succeeds.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Metabolix/HackBGRT on GitHub
4. README
5. Releases