Probably you've head about the BootHole vulnerability, which allows to bypass the EFI/UEFI SecureBoot mechanism via GRUB2 bootloader. I personally use my own EFI/UEFI keys (including the PK key), and don't have any MS keys inside the EFI/UEFI firmware. So this vulnerability doesn't really affect me. Anyway, there's a fix which allows users to update the DBX variable using the UEFI Revocation List File. According to the website:

These files are used to update the Secure Boot Forbidden Signature Database, dbx. It contains the raw bytes passed in *Data to SetVariable()... an EFI_VARIABLE_AUTHENTICATION_2 concatenated with the new variable value. Example usage: SetVariable( "dbx", EFI_IMAGE_SECURITY_DATABASE_GUID, NV+BS+RT+AT+AppendWrite, dbxUpdateDotBin_sizeInBytes, *dbxUpdateDotBin_bytes). dbxupdate.bin already contains a Microsoft KEK signature (encoded as specified by the UEFI spec).

So it has the MS KEK cert, but what about situations where the machine's EFI/UEFI firmware doesn't have this cert? How to update the DBX variable using this file in such case?

1 Answer 1


It depends on what KEK certificates the machine has.

If it has a KEK certificate that you have the private key for, you could strip the existing signature from the beginning of the dbxupdate_x64.bin file and sign the resulting EFI_SIGNATURE_LIST (I've seen .esl suffix for it) with your own KEK certificate, and then you should be able to apply it to the Secure Boot dbx variable with e.g. the efi-updatevar command from jejb's efitools.

Based on this Microsoft support article that links to this PowerShell script, the procedure is:

  1. Ignore the first 40 bytes of the file.

  2. The next two bytes of the file must be 0x30 0x82

  3. The next two bytes of the file are the length of the signature in big-endian. For example, if the next two bytes are 0x0c and 0xda, then the signature is 0x0cda == 3290 bytes long.

  4. The bytes after the signature till the end of the file are the the EFI_SIGNATURE_LIST contents. Taking the 0x0cda example, this means that the contents start at 40 + 2 + 2 + 0x0cda == 3334 bytes from the start of the file. That's 40 bytes + 2 bytes of 0x30 0x82 + 2 bytes for the signature length + 0x0cda bytes for the signature.

If the firmware allows you to edit the Secure Boot variables directly without checking the signatures in the "BIOS Setup" menus, you might be able to store the dbxupdate_x64.bin to your EFI System Partition, and then edit the dbx variable to replace its existing contents with the contents of that file. But that might technically be a security vulnerability in and of itself: allowing the BIOS Setup to change Secure Boot settings without restrictions is probably not what the designers of Secure Boot had in mind.

If the firmware allows you to only delete the Secure Boot Primary Key (PK for short), you should be aware that deleting the PK should switch Secure Boot into what is called Setup Mode, in which all Secure Boot variables can be edited without signature requirements until a new PK is defined. (This is the minimum BIOS Setup functionality needed to allow you to take full control of your Secure Boot configuration.)

But if you don't have a KEK certificate of your own, and can't get one into the system, you'll have to get an equivalent signed update file from your hardware vendor, or from whoever has the KEK for your hardware.

  • Is there a tool that would print/remove the file signature? For instance, sbverify/sbattach , but those dont't work with this file. Also, I have my own PK, KEK and db private keys, so there's no problem with having access to them. Commented Jul 30, 2020 at 19:14
  • I can confirm that this solution works -- it includes 189 signatures + debian/ubuntu certs. But I need more general solution, for future use. Could you write a little bit about the reverse engineering you did? Commented Jul 30, 2020 at 21:10
  • I'll have to stare at a hex dump of the beginning of dbxupdate_x64.bin a little more before I can give a coherent procedure, but this page has a good description of the structure of that file. To find the beginning of the EFI_SIGNATURE_LIST I basically just looked for occurrences of the SignatureType or HashType GUID, as they have known values. The first one of them tells me where the authentication header ends and the actual signature list begins. Then just trim off the authentication header.
    – telcoM
    Commented Jul 31, 2020 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .