
Using signed bootloaders to bypass UEFI Secure Boot protection
Russian version of this article.
Secure Boot can be disabled on any store motherboard, but a physical requirement to change its settings is a physical presence at the computer. You need to go into the UEFI settings when the computer boots up, and only then will it be possible to disable the technology or change its settings.
Most motherboards come only with Microsoft keys as trusted, which is why the creators of the boot software are forced to contact Microsoft for the signature of the bootloaders, undergo an audit procedure, and justify the need for a global signature of their file if they want the drive or flash drive to run unnecessarily disable Secure Boot or manually add their key on each computer.
Microsoft has to sign bootloaders for developers of Linux distributions, hypervisors, antivirus boot disks, and computer recovery programs.
I wanted to make a bootable USB flash drive with various computer recovery software that would boot without disabling Secure Boot. Let's see how this can be implemented.
In response, the Linux Foundation released PreLoader , and Matthew Garrett wrote shim - small bootloaders that verify the signature or hash of the next download file. PreLoader and shim do not use UEFI db certificates , but contain a database of allowed hashes (PreLoader) or certificates (shim) inside themselves.
Both programs, in addition to automatically downloading trusted files, allow you to download any previously untrusted files in Secure Boot mode, but require the physical presence of the user: at the first start, you need to select the added certificate or hash file in the graphical interface, after which the data is entered into a special NVRAM variable a motherboard that is not available for change from a loaded operating system. Files become trusted only for these preloaders, and not for Secure Boot in general, and you can’t run them without PreLoader / shim anyway.

Actions required when starting an untrusted program for the first time through shim.
All current popular Linux distributions use shim, due to certificate support, which makes it easy to update the next bootloader without the need for user interaction. Typically, shim is used to run GRUB2, the most popular bootloader on Linux.
One way or another, using a signed GRUB from some Linux distribution will fail. There are two ways to create a universal bootable USB flash drive that does not require adding the keys of each downloaded file to the trusted ones:
The second option is preferable - downloaded untrusted programs will also be able to download untrusted programs (for example, you can download files through the UEFI Shell), and in the first version, only GRUB itself can download everything. We modify PreLoader , removing the extra code from it and allowing the launch of any files.
Total, the architecture of the flash drive is as follows:
So there was Super UEFIinSecureBoot Disk .
As it turned out - there are such loaders. One of them is used in Kaspersky Rescue Disk 18 - a boot disk with antivirus software. GRUB from disk allows you to load modules (insmod command), while modules in GRUB allow you to load regular executable code. The disk pre-loader is native.
Of course, just because GRUB from the disk does not load untrusted code. It is necessary to modify the chainloader module so that GRUB does not use the UEFI LoadImage / StartImage functions, but instead loads the .efi file into memory, performs relocation, finds the entry point and follows it. Fortunately, almost all the necessary code is in the GRUB repository with Red Hat Secure Boot support , the only problem: there is no PE header parsing code , the header parses and returns shim, in response to a function call through a special protocol. This can be easily fixed by porting the appropriate code from shim or PreLoader to GRUB.
So there was Silent UEFIinSecureBoot Disk. The resulting disk architecture is as follows:
Using the signed files of Kaspersky Rescue Disk, we achieved a “silent” download of any untrusted .efi files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK.
These files can be used both for good deeds (for downloading from USB flash drives) and for evil ones (for installing bootkits without the knowledge of the computer owner).
I assume that the Kaspersky certificate will not last long, and it will be added to the global list of revoked UEFI certificates, which will be installed on computers running Windows 10 via Windows Update, which will interrupt the loading of Kaspersky Rescue Disk 18 and Silent UEFIinSecureBoot Disk. Let's see how soon this will happen.
Download Disk UEFIinSecureBoot the Super: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
Download Silent UEFIinSecureBoot Disk network ZeroNet the Git Center : http://127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/
Introduction
The firmware of modern computer motherboards works according to the UEFI specification , and since 2013 they support the authentication technology of downloaded programs and Secure Boot drivers, which is designed to protect the computer from bootkits . Secure Boot blocks the execution of unsigned or untrusted program code: .efi-files of programs and boot loaders of operating systems, firmware of additional equipment (OPROM video cards, network adapters).Secure Boot can be disabled on any store motherboard, but a physical requirement to change its settings is a physical presence at the computer. You need to go into the UEFI settings when the computer boots up, and only then will it be possible to disable the technology or change its settings.
Most motherboards come only with Microsoft keys as trusted, which is why the creators of the boot software are forced to contact Microsoft for the signature of the bootloaders, undergo an audit procedure, and justify the need for a global signature of their file if they want the drive or flash drive to run unnecessarily disable Secure Boot or manually add their key on each computer.
Microsoft has to sign bootloaders for developers of Linux distributions, hypervisors, antivirus boot disks, and computer recovery programs.
I wanted to make a bootable USB flash drive with various computer recovery software that would boot without disabling Secure Boot. Let's see how this can be implemented.
Signed Bootloader Downloaders
So, to boot Linux with Secure Boot enabled, you need a signed bootloader. Microsoft has banned the signing of software licensed under GPLv3 due to the prohibition of tivoization by the rules of the license, so GRUB will not be able to sign .In response, the Linux Foundation released PreLoader , and Matthew Garrett wrote shim - small bootloaders that verify the signature or hash of the next download file. PreLoader and shim do not use UEFI db certificates , but contain a database of allowed hashes (PreLoader) or certificates (shim) inside themselves.
Both programs, in addition to automatically downloading trusted files, allow you to download any previously untrusted files in Secure Boot mode, but require the physical presence of the user: at the first start, you need to select the added certificate or hash file in the graphical interface, after which the data is entered into a special NVRAM variable a motherboard that is not available for change from a loaded operating system. Files become trusted only for these preloaders, and not for Secure Boot in general, and you can’t run them without PreLoader / shim anyway.

Actions required when starting an untrusted program for the first time through shim.
All current popular Linux distributions use shim, due to certificate support, which makes it easy to update the next bootloader without the need for user interaction. Typically, shim is used to run GRUB2, the most popular bootloader on Linux.
GRUB2
To prevent the attackers from quietly doing business with the help of a signed bootloader of some distribution kit, Red Hat made patches for GRUB2 blocking the "dangerous" functions when Secure Boot was enabled: insmod / rmmod, appleloader, linux (replaced by linuxefi), multiboot, xnu, memrw, iorw. The chainloader module, which loads arbitrary .efi files, was supplemented with its own .efi (PE) loader, without using the UEFI LoadImage / StartImage commands, as well as the validation code of the downloaded files via shim, so that the ability to download files trusted for shim but not trusted in terms of UEFI. Why they did just that is not clear; UEFI allows you to redefine (hook) the function of checking downloaded images, this is how PreLoader works, and shim itself has such a function , but it is disabled by default.One way or another, using a signed GRUB from some Linux distribution will fail. There are two ways to create a universal bootable USB flash drive that does not require adding the keys of each downloaded file to the trusted ones:
- Using a modified GRUB that downloads EFI files on its own, without checking a digital signature, and without blocking modules;
- Using your own preloader (second) overriding the UEFI digital signature verification functions (EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication)
The second option is preferable - downloaded untrusted programs will also be able to download untrusted programs (for example, you can download files through the UEFI Shell), and in the first version, only GRUB itself can download everything. We modify PreLoader , removing the extra code from it and allowing the launch of any files.
Total, the architecture of the flash drive is as follows:
______ ______ ______
╱│ │ ╱│ │ ╱│ │
/_│ │ → /_│ │ → /_│ │
│ │ → │ │ → │ │
│ EFI │ → │ EFI │ → │ EFI │
│_______│ │_______│ │_______│
BOOTX64.efi grubx64.efi grubx64_real.efi
(shim) (FileAuthentication (GRUB2)
override)
↓↓↓ ↑
↑
______ ↑
╱│ │ ║
/_│ │ ║
│ │ ═══════════╝
│ EFI │
│_______│
MokManager.efi
(Key enrolling
tool)
So there was Super UEFIinSecureBoot Disk .
Super UEFIinSecureBoot Disk - a disk image with the GRUB2 bootloader, designed to conveniently run unsigned efi-programs and operating systems in UEFI Secure Boot mode.
The disk can be used as the basis for creating a USB drive with computer recovery utilities, for launching various Linux live distributions and WinPE, booting from the network, without disabling Secure Boot in the settings of the motherboard, which can be convenient when servicing other people's computers or corporate laptops, for example, with a password set to change the UEFI settings.
The image consists of three components: the shim preloader from Fedora (signed with the Microsoft key preinstalled on the vast majority of motherboards and laptops), the modified Linux Foundation PreLoader preloader (to disable signature verification when loading .efi files), and the modified GRUB2 bootloader.
During the first boot of a disk on a computer with Secure Boot, you need to select a certificate through the MokManager menu (it starts automatically), after which the bootloader will work as if Secure Boot is off: GRUB loads any unsigned .efi file or Linux kernel, downloaded EFI programs can run other programs and drivers with a missing or untrusted signature.
To demonstrate operability, the image contains Super Grub Disk (scripts for searching and loading installed operating systems, even if their bootloader is damaged), GRUB Live ISO Multiboot (scripts for convenient Linux LiveCD boot directly from ISO, without preliminary unpacking and processing), One File Linux (kernel and initrd in one file, for system recovery), and several UEFI utilities.
The drive is compatible with UEFI without Secure Boot, as well as older computers with BIOS.
Signed Downloaders
I was wondering if it was possible to somehow get around the need to add a key via shim on first start. Maybe there are some signed downloaders that allow you to do more than the authors expected?As it turned out - there are such loaders. One of them is used in Kaspersky Rescue Disk 18 - a boot disk with antivirus software. GRUB from disk allows you to load modules (insmod command), while modules in GRUB allow you to load regular executable code. The disk pre-loader is native.
Of course, just because GRUB from the disk does not load untrusted code. It is necessary to modify the chainloader module so that GRUB does not use the UEFI LoadImage / StartImage functions, but instead loads the .efi file into memory, performs relocation, finds the entry point and follows it. Fortunately, almost all the necessary code is in the GRUB repository with Red Hat Secure Boot support , the only problem: there is no PE header parsing code , the header parses and returns shim, in response to a function call through a special protocol. This can be easily fixed by porting the appropriate code from shim or PreLoader to GRUB.
So there was Silent UEFIinSecureBoot Disk. The resulting disk architecture is as follows:
______ ______ ______
╱│ │ ╱│ │ ╱│ │
/_│ │ /_│ │ → /_│ │
│ │ │ │ → │ │
│ EFI │ │ EFI │ → │ EFI │
│_______│ │_______│ │_______│
BOOTX64.efi grubx64.efi grubx64_real.efi
(Kaspersky (FileAuthentication (GRUB2)
Loader) override)
↓↓↓ ↑
↑
______ ↑
╱│ │ ║
/_│ │ ║
│ │ ═══════════╝
│ EFI │
│_______│
fde_ld.efi + custom chain.mod
(Kaspersky GRUB2)
Conclusion
In this article, we found out that there are not enough reliable bootloaders signed with a Microsoft key enabling Secure Boot mode.Using the signed files of Kaspersky Rescue Disk, we achieved a “silent” download of any untrusted .efi files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK.
These files can be used both for good deeds (for downloading from USB flash drives) and for evil ones (for installing bootkits without the knowledge of the computer owner).
I assume that the Kaspersky certificate will not last long, and it will be added to the global list of revoked UEFI certificates, which will be installed on computers running Windows 10 via Windows Update, which will interrupt the loading of Kaspersky Rescue Disk 18 and Silent UEFIinSecureBoot Disk. Let's see how soon this will happen.
Download Disk UEFIinSecureBoot the Super: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
Download Silent UEFIinSecureBoot Disk network ZeroNet the Git Center : http://127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/
About ZeroNet
ZeroNet is a very powerful system for creating decentralized distributed dynamic websites and services. When visiting a resource, the user begins to download and distribute it, as in BitTorrent. At the same time, it is possible to create full-fledged resources: blogs with comments, forums, video hosting, wiki-sites, chats, email, git.
ZeroNet separates the concepts of code and site data: user data is stored in .json files, and when synchronized, they are imported into the sqlite database of the site with a standardized scheme, which allows you to do amazing things: local text search on all ever open sites in milliseconds, automatic real-time analogue of RSS for all sites at once.
Standardized authentication and authorization system (similar to OAuth), support for working behind NAT and through Tor.
ZeroNet is very fast, user friendly, has a modern interface and small, but very convenient features, such as global switching of day / night themes on sites.
I consider ZeroNet a very underrated system, and I intentionally publish the Silent version only in ZeroNet Git, to attract new users.
ZeroNet separates the concepts of code and site data: user data is stored in .json files, and when synchronized, they are imported into the sqlite database of the site with a standardized scheme, which allows you to do amazing things: local text search on all ever open sites in milliseconds, automatic real-time analogue of RSS for all sites at once.
Standardized authentication and authorization system (similar to OAuth), support for working behind NAT and through Tor.
ZeroNet is very fast, user friendly, has a modern interface and small, but very convenient features, such as global switching of day / night themes on sites.
I consider ZeroNet a very underrated system, and I intentionally publish the Silent version only in ZeroNet Git, to attract new users.