I am about to make a forensic image (using dc3dd from OSFClone) of two laptops and in this specific case I'd like to startup using an bootable USB stick with OSFClone and image the disk to an external disk. The laptops (HP ProBooks) in this case uses Bitlocker and has (according to the vendor specifications) an TPM 2.0 Embedded Security Chip shipped with Windows 10 (Common Criteria EAL4+ Certified). One laptop has a Kioxia KBG30ZMV256G NVMe SSD, the other a SanDisk SSD X400 M.2 2280 (SD8SN8U-128G).

I did receive a Bitlocker recovery key for this laptop but I cannot be 100% sure that the recovery key is correct. I did also receive a local Windows Administrator user which I could use to boot and login to Windows and check the recovery keys but I rather don't want to boot the machine into Windows at all.

My plan is to (temporarily) disable Secure Boot, boot from the OSFClone USB and make a forensic image to an external disk. After that I want to re-enable Secure Boot again. I wonder if Bitlocker will prompt to enter a Recovery Key in this case when booting normally again? Or will it boot straight into Windows (after re-enabling) like nothing has happened?

It's an option if I have to enter the Bitlocker recovery key once after imaging and boot into Windows. But I rather don't boot into Windows and as I said I cannot be 100% sure the recovery key I've received is correct.

Lastly, what happens if I do (accidentally) boot into Windows before re-enabling Secure Boot, does re-enabling Secure Boot change back the old behavior (no recovery key required) or did it then save that one "unsecure boot" state and prompt it anyway till a recovery key is entered?

Also in this case I am not sure if OSFClone will image the unencrypted disk (which I suspect in case of a SED disk with TPM-only, as it should unlock when the machine with TPM and disk power on) or will I only manage to image the encrypted disk (which I suspect when SED and/or TPM is not used). Either way, the forensic processing software we use (Intella by Vound-Software) should be able to handle Bitlocker encrypted images when the recovery key is supplied but I rather want to understand exactly how it works and if my understanding of this matter is correct.

  • I have encountered one example where the laptop (MS Surface) would not boot again after doing this. Honestly I'm not sure why. Commented Feb 25, 2021 at 17:13
  • @user10216038 it did not even prompt for a Bitlocker recovery key? The hardware was untouched? How did you deal with this? Was the data lost and did you have at least a proper usable (encrypted) image?
    – Bob Ortiz
    Commented Feb 25, 2021 at 18:27
  • It was a test system, so it just needed rebuilding. I think it may have had custom keys in the TPM that were lost, but it's just a guess. Commented Feb 26, 2021 at 18:49
  • Any reason you can't take the drive out to scan? But, yes --- I believe you can temporarily disable Secure Boot without any problems as long as you don't boot from the disk while it's disabled (that might compromise the forensic integrity of the image) Commented Feb 26, 2021 at 20:38
  • 1
    I found the reason: If the system is an MS Surface device with a TPM chip (and possibly others as well), changing the BIOS to allow an untrusted OS to boot for imaging will wipe the BitLocker token from the device. It will then no longer boot without the Recovery Key. Commented Apr 30, 2021 at 16:07

3 Answers 3


OK, first things first: if you're trying to make a forensic image of a disk, and you're doing ANYTHING AT ALL that involves booting the machine it's in before you initiate the image, stop and ask yourself why you aren't just removing the disk and cloning it using dedicated hardware. Or at least disabling auto-mount and attaching the disk as removable storage to another PC from which you will create an image or clone of the unmounted volume.

If you absolutely must image the disk in place inside the PC, REMOVE the disk before making any modifications to the system (such as disabling or reconfiguring Secure Boot). Only once you're confident you can boot into your alternate OS, reliably, should you even consider re-inserting the disk. Ideally with a write-blocker in place, but that might not be practical for a laptop's internal drive.

Booting Windows - even as far as the login screen - will modify the data on disk unless it's forced to be read-only. In addition to the changes that Windows itself will make, booting will also start background processes (services) that may do anything else possible in software at all.

Disabling Secure Boot will probably modify the instructions that the CPU executes on bootup, which are one of the things the TPM tracks and determines whether or not the BitLocker key can be released. As such, I expect that yes, you would need to enter the recovery key. If you do enter the recovery key and boot the system, it should then update the TPM unlock to be able to automatically unlock in the future until you change the boot process again. If you don't boot to Windows, re-enabling Secure Boot would probably result in TPM automatic unlock working again.

As for Self-Encrypting Disks, if that covers the entire disk without leaving a single partition in plain-text for boot code (which is what BitLocker normally does), then attempting to image the disk will either just fail (if the unlock requires that the boot process not have been tampered with) or it will image the plain-text data (because the decryption happens transparently on the disk controller). In all other cases (including non-SED), your image would be the encrypted data (plus the small non-encrypted boot volume).


The answer by CBHacking states that

if you don't boot to Windows, re-enabling Secure Boot would probably result in TPM automatic unlock working again.

I would like to confirm and extend this statement.

In my experiment:

  1. I disabled secure boot
  2. Booted into Kali Linux
  3. Rebooted into Windows, and was asked for the bitlocker recovery key
  4. Without entering the key, I rebooted and re-enabled secure boot
  5. Booted into Windows, and bitlocker was automatically unlocked again

This experiment shows that (at least in my case) TPM automatic unlock will work again after secure boot is re-enabled, without having to enter a recovery key. Even when Windows was booted in the meantime.

  • Thank you for sharing this. The remaining question is what would have happened if you A) entered the recovery key B) rebooted C) re-enabled secure boot -- would you have to re-enter the key? would you have to enter a different key? would it unlock automatically? Commented Jun 24, 2023 at 13:52

I've managed to do make an forensic physical image of both systems using OFSClone with Secure Boot disabled. The machine configuration was slightly different so both machine’s required slightly different steps to disable Secure Boot although the BIOS looked identical.

  1. For one machine I went into bios by pressing F10 during startup. I then selected the option “… disable secure boot”. After restarting the BIOS screen prompted without user interaction and asked to confirm by typing a four digit code.

  2. On the other machine I tried exactly the same but I didn’t get the four digit prompt and after checking a few times the new secure boot disabled setting was toggled back to enabled making me suspect it wasn’t saved. I figured that I should maybe use a different charger, test the battery or replace the CMOS battery but then I read that someone wrote to manually directly reenter the BIOS again. So, after disabling secure mode again, saving it and rebooting I manually went into the BIOS again using F10 where, this time I did get the same prompt to enter a four digit code.

After that I’ve started the machine using the ESC key to enter the boot menu and selected my bootable OFClone USB with an external docking station and disk attached to write the image to. I choose to use the dd image with OSFClone as the AFF image generated by OSFClone is AFF version 3 and the processing software Intella (Vound Software) only supports AFF version 4 and up and I wasn’t sure if the used EWF dialect from OSFClone was 100% compatible with Intella (E01-S01) so I choose for DD, which is supported by both.

After imaging both machines, I changed back the secure boot setting to enabled. The customer has confirmed that one machine directly booted into Windows without any prompt for a Bitlocker Recovery key. The other required a Bitlocker Recovery key after which it also started normally.

You must log in to answer this question.

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