Don't use with Bitlocker enabled

[RealDekkia]

It should go without saying but I tried it anyways todays: If you have this installed while Bitlocker is activated, Bitlocker will ask for the Recovery Key every time your system boots. Removing HackBGRT and disabling and re-enabling Bitlocker will revert everything back to normal. If Bitlocker doesn't get re-enabled it will ask for the key even after removing HackBGRT.

I assume this can't really be befixed, since Bitlocker is intended to detect modifications like this. But maybe you could add this to the readme-file.

[sylveon]

This occurs because the TPM, the device responsible for storing the encryption keys, will only unlock when booting a preapproved bootloader. I'm not sure, but I think that clearing and setting up the TPM while HackBGRT is installed will make it work (so that the HackBGRT bootloader is registered to the TPM).

It's also possible that it's a secure boot issue. If BitLocker drive encryption was set up with secure boot active, it will refuse to automatically unlock when secure boot is disabled.

[RealDekkia]

I tried your reccomendations but it's still the same.

I did it in this order:

• Disable Bitlocker
• Disable Secure-Boot
• Install HackBGRT
• Clear TPM
• Enable Bitlocker

I turned it off and on twice and both times it asked for the key.

[ghost]

I managed to get HackBGRT working with Bitlocker. The process I followed was this:

1. Disable Secure Boot.
2. Install HackBGRT.
3. Disable Bitlocker.
4. Clear TPM in TPM Administration.
5. Generate Secure Boot PK, KEK, and DB keys with OpenSSL under Windows Subsystem for Linux, referencing these guides:
   • https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
   • https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
6. Mount the EFI partition with diskpart.
7. Use Explorer++ to copy HackBGRT's bootx64.efi to a writable directory from /EFI/HackBGRT, as Windows Explorer will not let you.
8. Sign HackBGRT's bootx64.efi with sbsign under Windows Subsystem for Linux, referencing these guides:
   • https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
   • https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
   • Note: I also signed the Windows Boot Manager bootx64.efi in /EFI/boot as well as the original manager bootmgfw-original.efi with my DB keys with sbsign, but this was only because I revoked Microsoft's Secure Boot keys; if you're only appending your keys and not revoking all others, you likely don't need to do this.
9. Copy the signed bootx64.efi back to /EFI/HackBGRT.
10. Copy the Secure Boot keys to /EFI/Custom Keys and reboot to UEFI setup.
11. Turn on Secure Boot custom mode and enroll your PK, KEK, DB in /EFI/Custom Keys; your UEFI will likely want the *.auth files, but this may vary per OEM.
    • If you don't have Secure Boot key management available in your UEFI firmware setup utility, you can use KeyTool.
12. Re-enable Secure Boot.
    • If Secure Boot doesn't allow your device to boot, you may need to go back into the UEFI firmware settings and create a new boot option for /EFI/HackBGRT/bootx64.efi; this was necessary for Secure Boot to work for me, but I believe this is a bug in my UEFI firmware setup utility, as the path/location of this executable did not change, only the file itself.
13. Re-enable Bitlocker.

---

Probably Optional steps:

14. Open the Group Policy Editor (gpedit) and navigate to Computer Configuration>Administrative Templates>Windows Components>BitLocker Drive Encryption>Operating System Drives and turn on (select Enabled) Require Additional Authentication at Startup.
15. Open a Command Prompt (cmd) as an admininstrator and run manage-bde -protectors -add c: -TPMAndPIN.
16. Choose a secure PIN of your liking.
    • Windows defaults to numbers-only PINs, but you can enable "enhanced PINs"/full passwords by opening gpedit and enabling Allow enhanced PINs for startup in Configuration>Administrative Templates>Windows Components>BitLocker Drive Encryption>Operating System Drives, but not all computers support this, so have your recovery ready before you reboot or you may lose all your data permanently.
17. Add a UEFI boot entry in UEFI firmware settings for /EFI/HackBGRT/bootx64.efi and make it the default, so Windows Updates won't overwrite HackBGRT.

---

I believe this works because Bitlocker uses Secure Boot for verifying boot chain integrity if available, but if not checks for it itself.

[sylveon]

And your TPM actually allows this to work?

[ghost]

@sylveon

Correct, it works with no issues, 100% equivalent to the original Windows Boot Manager. I am using a modern TPM 2.0, however; no idea if this would work on TPM 1.2, but I imagine older versions are less secure, not more.

[sylveon]

I guess that either I misunderstood the purpose of the PCR or that Microsoft set its Platform Validation Profile to allow chainloading the bootloader. I'll open a PR with relevant info added to the readme when I get time.

[ghost]

@sylveon

Yeah, chainloading the bootloader doesn't violate the PVP (or if it does, MS has messed up the PVP and it isn't detected); Bitlocker can be used without problems when running rEFInd, grub-efi, etc. as well, so long as it is enabled after the chainloader is setup. Perhaps it's a "last known good state" or similar. However, I did not test with Secure Boot off, so I can't guarantee it works without it; it is possible Bitlocker leaves bootchain validation to Secure .Boot if it's enabled, but attempts to verify it itself if SB is off.

[FIocker]

I managed to get HackBGRT working with Bitlocker. The process I followed was this:

1. Disable Secure Boot.

2. Install HackBGRT.

3. Disable Bitlocker.

4. Clear TPM in TPM Administration.

5. Generate Secure Boot PK, KEK, and DB keys with OpenSSL under Windows Subsystem for Linux, referencing these guides:

   • https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
   • https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

6. Mount the EFI partition with diskpart.

7. Use Explorer++ to copy HackBGRT's bootx64.efi to a writable directory from /EFI/HackBGRT, as Windows Explorer will not let you.

8. Sign HackBGRT's bootx64.efi with sbsign under Windows Subsystem for Linux, referencing these guides:

   • https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
   • https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
   • Note: I also signed the Windows Boot Manager bootx64.efi in /EFI/boot as well as the original manager bootmgfw-original.efi with my DB keys with sbsign, but this was only because I revoked Microsoft's Secure Boot keys; if you're only appending your keys and not revoking all others, you likely don't need to do this.

9. Copy the signed bootx64.efi back to /EFI/HackBGRT.

10. Copy the Secure Boot keys to /EFI/Custom Keys and reboot to UEFI setup.

11. Turn on Secure Boot custom mode and enroll your PK, KEK, DB in /EFI/Custom Keys; your UEFI will likely want the *.auth files, but this may vary per OEM.

    • If you don't have Secure Boot key management available in your UEFI firmware setup utility, you can use KeyTool.

12. Re-enable Secure Boot.

    • If Secure Boot doesn't allow your device to boot, you may need to go back into the UEFI firmware settings and create a new boot option for /EFI/HackBGRT/bootx64.efi; this was necessary for Secure Boot to work for me, but I believe this is a bug in my UEFI firmware setup utility, as the path/location of this executable did not change, only the file itself.

13. Re-enable Bitlocker.

Probably Optional steps:

1. Open the Group Policy Editor (gpedit) and navigate to Computer Configuration>Administrative Templates>Windows Components>BitLocker Drive Encryption>Operating System Drives and turn on (select Enabled) Require Additional Authentication at Startup.

2. Open a Command Prompt (cmd) as an admininstrator and run manage-bde -protectors -add c: -TPMAndPIN.

3. Choose a secure PIN of your liking.

   • Windows defaults to numbers-only PINs, but you can enable "enhanced PINs"/full passwords by opening gpedit and enabling Allow enhanced PINs for startup in Configuration>Administrative Templates>Windows Components>BitLocker Drive Encryption>Operating System Drives, but not all computers support this, so have your recovery ready before you reboot or you may lose all your data permanently.

4. Add a UEFI boot entry in UEFI firmware settings for /EFI/HackBGRT/bootx64.efi and make it the default, so Windows Updates won't overwrite HackBGRT.

I believe this works because Bitlocker uses Secure Boot for verifying boot chain integrity if available, but if not checks for it itself.

Sorry but there's gotta be a simpler way than that.

No HackBGRT it is.

[sylveon]

No there is not. Secure Boot is designed require a physical presence and be non-trivial to modify, so that every change is completely intentional from the user instead of being something done by malicious software.

[ghost]

Great to know now- is there anyway to recover the PC if Ive already installed it and now cannot boot into Windows...

[Metabolix]

BitLocker recovery options are detailed on a Microsoft article Finding your BitLocker recovery key in Windows.

The next release will have a warning about BitLocker.

[GekkaSaori]

There is a possibility of PCR value changes during the chain booting sequence. Run Event Manager, apply filters related to BitLocker, and then we can find what caused BitLocker to fail to decrypt system volume using password.

1. ERROR: Bootmgr failed to unseal VMK using the TPM.
2. ERROR: Bootmgr failed to obtain the BitLocker volume master key from the TPM + enhanced PIN.
3. WARNING: Bootmgr failed to obtain the BitLocker volume master key from the TPM because Secure Boot configuration changed unexpectedly.
4. WARNING: A recovery password was used to start Windows. Protector ID: {uuid}.
5. INFOMATION: BitLocker determined that the TCG log is invalid for use of Secure Boot. The filtered TCG log for PCR[7] is included in this event.
6. WARNING: BitLocker resealed boot settings to the TPM for volume C:.
7. WARNING: BitLocker cannot use Secure Boot for integrity because the TCG Log entry for the OS Loader Authority is invalid. The signature contained in the EFI_SIGNATURE_DATA structure from the OS authority event could not be found in the verified certificate chain for the boot loader.
8. INFORMATION: BitLocker determined that the TCG log is invalid for use of Secure Boot. The filtered TCG log for PCR[7] is included in this event.
9. INFORMATION: A trusted WIM file has been added for volume C:. The SHA-256 hash of the WIM file is: 0x3AD378D179A2BEA2D107F4382340046992188A6432F7C068BFD4F50ECBB400E7

It shows the TCG logs stored in PCR[7] has changed, and BitLocker has failed to use Secure Boot for integrity since HackBGRT was not signed by Microsoft UEFI KEK/db (of course it won't be sealed into TPM). But if BitLocker was enabled before, PCR[7] was included in PCR Validation Profile of BitLocker, (since at that time Secure Boot Intergrity was available for BitLocker). So, BitLocker will ask for recovery key every time your system boots (even signed loader.efi of HackBGRT by a self-signed certification).

Using method comment by @sylveon mentioned, the PCR Validation Profile actually is 0, 2, 4, 11, which are the profile used by BitLocker when Secure Boot Integrity is not available (omitted check of PCR[7]).

Thus, if we can:

• Obtain an certification for HackBGRT (then a full "trusted" boot chain is created, which is not realistic).
• Or, omit PCR[7] check of BitLocker. Then BitLocker will work as normal.

So, we can configure Group Policy before we enable BitLocker (Group Policy > Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for native UEFI firmware configuration), omit PCR7, or directly set to PCR 0, 2, 4, 11, then enable BitLocker, and BitLocker should work without asking Recovery Key to be entered every time system boots.

Notice: omitting PCR[7] could cause some vulnerability which is not yet very clear for me. For example, a malicious HackBGRT you signed could boot your system with a malicious boot loader, causing damage or information leaking (i.e., BootKit), etc. So, after replacing UEFI certifications with your own ones, the security of boot is up to you. USE AT YOUR OWN RISK.

UEFI CA can be used to sign third-party applications, Option ROMs or even third-party boot loaders that can load malicious (UEFI CA signed) code. In this case, BitLocker switches to PCR 0, 2, 4, 11. In the cases of PCR 0,2,4,11, Windows measures exact binary hashes instead of the CA certificate.

Windows is secure regardless of using TPM profile 0, 2, 4, 11 or profile 7, 11.

PS: Microsoft has described in its document as below:

BitLocker only accepts the Microsoft Windows PCA 2011 certificate to be used to sign early boot components that will be validated during boot. Any other signature present on boot code will cause BitLocker to use TPM profile 0, 2, 4, 11 instead of 7, 11. In some cases, the binaries are signed with UEFI CA 2011 certificate, which will prevent you from binding BitLocker to PCR7.

[My1]

what exactly does PCR 7 store? any chance it does what it should if you suspend and re-enable bitlocker? at least back in vista days when the TPM got some fun ideas that helped maybe. alternatively re-creating the TPM protector, so it gets "accustomed" to its current environment?

[GekkaSaori]

PCR 7 stores, as said, "Secure Boot Status", but according to documentation mentioned above, if Windows could not bind PCR 7, it won't modify the value stored in PCR 7. Thus, if you want to use the alternative TPM measurement (just simply skip PCR 7), BitLocker will work as you want.

At this point, as Microsoft stated, "Windows is secure regardless of using TPM profile 0, 2, 4, 11 or profile 7, 11", so it just works as fine as PCR 7, 11 validation.

You can first modify the Group Policy settings, tweak the PCR validation, remove protectors, and then re-add protectors. It should work as expected, without modifying the Recovery Key or existing protectors.

Test is below:

C:\Users\gekka> manage-bde -protectors C: -get
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: []
All Key Protectors

    Numerical Password:
      ID: {guid}
      Password:
        blabla-blabla-blabla-blabla-blabla-blabla-blabla-blabla

    TPM And PIN:
      ID: {guid}
      PCR Validation Profile:
        7, 11
        (Uses Secure Boot for integrity validation)

C:\Users\gekka> manage-bde -protectors C: -delete -Type TPMAndPIN
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: []
Key Protectors of Type TPM And PIN

    TPM And PIN:
      ID: {guid}
      PCR Validation Profile:
        7, 11
        (Uses Secure Boot for integrity validation)

Key protector with ID "{guid}" deleted.
C:\Users\gekka> manage-bde -protectors C: -add -TPMAndPIN
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Type the PIN to use to protect the volume:
Confirm the PIN by typing it again:
Key Protectors Added:

    TPM And PIN:
      ID: {guid}
      PCR Validation Profile:
        0, 2, 4, 11

C:\Users\gekka> manage-bde -protectors C: -get
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: []
All Key Protectors

    Numerical Password:
      ID: {guid}
      Password:
        blabla-blabla-blabla-blabla-blabla-blabla-blabla-blabla

    TPM And PIN:
      ID: {guid}
      PCR Validation Profile:
        0, 2, 4, 11

PS C:\Users\gekka>

I am too lazy to study about TPM and PCRs, as PCR 0, 2, 4, 11 validation now just works for my use case. If you have turned off Secure Boot, you should use PCR 0, 2, 4, 11 validation, since PCR 7 validation is not available (but it WAS available before you install HackBGRT, and PCR 7, 11 validation is not change automatically during installation of HackBGRT), and thus, BitLocker will just f**k up without telling you what exactly happened.

My opinions:

• If you have self-signed EFI bootloader of HackBGRT, YOU may now take up the responsibility of system boot security, as you are now controlling the certification chain of EFI Secure Boot, you choose to sign binary or not.
• If you have turned off Secure Boot to use HackBGRT, it means YOU GIVED UP BENEFITS of Secure Boot, as YOU chose to turn off Secure Boot.

Newer computers will automatically enable Device Encryption or BitLocker as soon as you activate it. This is caused by the default policy of Device Encryption. If 1. you didn't pre-configure the Group Policy, 2. your computer has TPM 2.0 3. Secure Boot is enabled, Windows will automatically apply Device Encryption, and the default PCR validation is 7 and 11.

[Metabolix]

I've included shim for Secure Boot with HackBGRT v2.2.0. Can someone tell if shim makes any difference to this BitLocker situation? I don't know anything about these PCR's but here's a nice shim/README.tpm for those who do. I'll be happy to update my README or merge a BitLocker.md if there's any reasonable way to support BitLocker.

[sylveon]

Is HackBGRT signed for shim? Just including shim as a chainloader without signing won't help much I fear. shim by default recognizes Canonical signatures but you could maybe program the MOK from user mode in the installer.

[Metabolix]

It's self-signed, so the user has to enroll binary hash (safer choice) or MOK key into shim during first boot, which is easy to do with the detailed instructions in shim.md. It would be technically possible to make an enrollment request in the installer to save a few clicks, but I don't think it's actually worth the effort.