Ever got the dreaded Bitlocker Bootloop? You know the one where it refuses your windows password and demands a recovery key? Yea I have. Perhaps like me you didn't see the logic of storing an access code on a piece of paper or USB stick in close proximity to the device bitlocker was supposed to be protecting against proximity attacks - where the attacker has physical access to the device. Of course you could have just stored it on your Microsoft account as recommended by them, perhaps transmitted over insecure hotel WiFi... because everyone knows Microsoft accounts are impervious to exploits and phishing attacks and they've never suffered data breaches from hostile state actors, right? Anyway, thinking I was fine as long as I remembered my Windows Password, I deleted the recovery keys, only to get bootlooped 5 or so years later, because Microsoft decided it was cool to lock people out of their computers for wanting the access codes to be known only to the user and machine, rather than transmitting them over the internet and stored insecurely, potentially giving Microsoft themselves, and anyone else they decide, access to your data - and last I checked you could still exploit the ease of access tool after mounting and modifying the drive, essentially meaning an attacker would have root access to your machine. No thanks. So I wrote this fix for the problem, it is proactive, in that it needs to be applied before the BSOD appears, not after. It basically converts your windows password into a unique recovery key, then you can set that new key as your one and only recovery key and deleting all others (instructions below), that way, if you are ever Bootlooped, you simply need to get on another device, run this program again and re-enter your windows password and it will spit the exact same recovery key back at you, eliminating the need for insecure storage of an 8x6 key. It was compatible with older versions of bitlocker, where there were hex based restricions on each field - each of the 8 fields had to be under a certain value - something on the order of 720896 and it also had to be divisible by 11. It still works on new versions (as of 30/11/2025), and could be made even easier and more versatile as these restrictions have since been lifted. It is meant to be part of a larger program I am writing in C.

Instructions for setting a new key, and deleting old ones

Download the correct version for your architecture, x86 for Intel/AMD, ARM for Qualcomm, or if you don't trust me, compile the source code yourself.

Run the program, it does not require admin privileges, but setting new Rkeys does so then...

Run the following commands as ADMINISTRATOR - manage-bde -protectors -add C: -RecoveryPassword "8x6RKey"
Replacing C: with the drive letter (if different) and "8x6RKey" with the key generated by my program

Verify the new key was added with manage-bde -protectors -get C:
This lists all protectors (old and new). The new recovery key should appear with its Key Protector ID (GUID).

For each unwanted protector ID, run: manage-bde -protectors -delete C: -id {GUID}
Replacing {GUID} with the identifier shown in the previous step.

Confirm Only Your New Key Remains - manage-bde -protectors -get C:

That's it. As long as you are able to access a copy of this program on a separate device, you do not need to store this key in any insecure medium, such as paper, USB, or your oh-so-secure Microsoft account. I considered putting the Rkey implementation into the program itself, but I was concerned it could result in firewall action due to its attempt to access security features as admin.