Get PCR data from BitLeaker driver... Fail

[paulga]

Failed at getting PCR data from BitLeaker driver. No more details directly available. Is this error code common?
I was able to get some PCR output from napper-for-tpm, but no success with bitleaker.

Alienware 15 R3 Intel PTT, secure boot disabled

root@ubuntu:~/bitleaker# ./bitleaker.py ,║▒▒▒▒▒▒@╖ ╥▒▒╝ ▒▒▒╢ ]▒▒╢ ]▒▒╢ ]▒▒▒ j▒▒╢ , ,╖║▒▒▒ ,╓╖, ╓@╬@╥╥╬╣╢╢▓▓ ╖▒╖▒╙▒▒▒░░░▒░▒▒▒▒. ║╬@▓╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢[ ╜╜╜╢╢▒▒░░░░░░▒@▓▓▄▒▒▒▒╖ ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢[ ░░░░░╙╢▓╣╬▓▓@@▓▓@░░æ▓▓▓[ ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢..[ ░░░░░ ░▒▒▒▒▒▒▒▒▒▒▓▓▓▒▒▒H ╢ ╢░░░░░░░▒▒▒▒▒▒▒▒▒▒╢▒▒╢╢╢[ ..╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢ ░░░░░░░▒▒▒▒▒▒▒▒▒▒╢╢╢╢╢╢[ ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢[ ¿░░░,░░░░░░░▒▒▒▒▒▒▒▒▒▒╢╢╢╢╢╢[ ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢░░░░░░░░░░░░╣▓▓@░░░▒▒▒▒▒▒▒▒▒▒╫╣╣╣▓▓[ ╙╙ ╙╬ ╨╜╙╬╢╢╢╣╣╢╢╢░░░░░░░░░░░░░░░░╫▓@▓▓▓▒▒▒▒▒▒▒▓▓▓▓▓▓[ ,,, ,░░░░░░░░░░╙╨░░░░░░░░░░░░░░░░░░▓▒▒▒▓▓▓▓▓▓▓▓▓▓▓▀" ,,.░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]▒░░░╙╢▒▓╣▓▒▒▒▒ ] ▐▓█████▄░░░░▒░░░░░░░░░░░░░░░░░░░░░░░░░░╟▒▒▒▒▒▒▒▒▒╣▓╢╢╢ ░░ ▐▓▓██████████▄░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▓╢▒▒▒▒╢▓╢╢▒┌░░ ▐▓▓█████████████████▄░░░▒▒░░▒▒▒▒▒▒▒╢╢╢╢╢╢Ñ▒▒▓╢▒▒▒▒▓╣╢╜▒░░ ╜▓▓██▀████████████████▌║▒▒▒▒╢╢╢╢╣╢╢╢╣╣╣╣╣╣╣╝╣▒▒╢▓" ▒░░ "╙``╙╣▀█▀▀██████████▌╢╢╢╢╢╢╢╣╣╣╣╣╢Ñ╜╨Ñ╝ ╙ ,, ▒▒▒ ""╨╢▀▀▓▓███▌╢╣╣╣╣╣╣╜╜╨╨╜ ▄, ░░ ,▌ ░░▒▒▒ ░ e ╙╣▓▌Ñ╜╙╙╜ ▌▓ ░░░ ░░░░░▒▒▒ ░░░░╧╤░░░ , , ▐░ ░░░░ ░░░░░░░░█▐░▒░▒▒▒ ░░░░,░░░░░░ ▐, j▌█ ░ ░░░░░░░░░░░▐░░▒░░░░░░░▒░▒▒▒ ░░░░▌█░░░░░░░░░░░░ ░░░░░░░░░░░░╪░░░░░░░░░░░▒░░▒░▒▌▒▒▒▒▒▒` ▒▒▒▒░▒▒▒▒▒▒░░æ▄▒░▒▒░░æ▄▒▒▒▒▒▒▒▒▌▓▒▒▒▒▒▒▒æ▒▒▒▒▒▒▒▓▓▒▒▒▒▒▒ ]▒▒▒▒░▒▒▒▒▒▒▒▒╬▒▒▒▒▒▒▒╬▒▒▒▒▒▒▒▒▒▐▌▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░ └ ▒░░▒▒▒▒▒░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒]▒░▒▒░▒░▒▒▒░▒▒▒░░░ ░░░; ░░ ▒░░▒▒░▒║░▒▒▒▒▒▒░▒▒▒▒▒░▒]▒▒]░░▒▒░░ ░░▒░▒░▒░░ ░░ ⌡ ░ ░ ░░▒░▒] ░░▒░▒░░▒▒░]░░▒;▒▒]░░░░ ░ ░░j░░░▒░ ░ ! ░▒L░░└ ░░ ░▒ ░ ░░▒!▒▒ ░ ░ ░ ░░└ ░ ▒ ▒L░ ░▒ ░ ░ ░ ░ ░ └ ░

BitLeaker v1.0 for decrypting BitLocker with the TPM vulnerability
         Made by Seunghun Han, https://kkamagui.github.io
       Project link: https://github.com/kkamagui/bitleaker 

Search for BitLocker-locked partitions. [>>] BitLocker-locked partition is [/dev/nvme0n1p3]

Loading BitLeaker kernel module... Success Entering sleep... [>>] Please press any key or power button to wake up... Waking up... [>>] Please press any key to continue...

Preparing PCR data. [>>] Get PCR data from BitLeaker driver... Fail

[paulga]

Does the dmesg output look right? It doesn't have "SHA256" and "End of Data", so I guess the buffers were never written out as intended (line 64 - 84 in bitleaker-kernel-module.c). if so what's the reason?

[ 2451.159783] bitleaker: [ 2451.159783] bitleaker: Dump event logs [ 2451.159784] bitleaker: Virtual address 0000000000000000 physical address 0000000010bced01 [ 2456.398224] wlp61s0: deauthenticating from c4:b3:01:df:6b:5b by local choice (Reason: 3=DEAUTH_LEAVING) [ 2456.925638] PM: suspend entry (deep) [ 2456.934889] Filesystems sync: 0.009 seconds [ 2456.936209] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 2456.938152] OOM killer disabled. [ 2456.938152] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.

[roboknight]

Can’t really read your output from the first message. It just looks like extended characters. Many versions use SHA1, even though SHA256 is available. Also, if secure boot isn’t enabled, is the TPM even a protector for Bitlocker in your windows setup? It can be, but Bitlocker uses different PCRs in that case. Bitleaker should still work, as it replays the PCR log, but sometimes Windows is a bit finicky about adding the TPM protector without Secure Boot.

[paulga]

the key message from 1st output is "Fail". the reason traces back to line 64 - 84 in bitleaker-kernel-module.c, it looks like the var "buffer” is empty, so no buffers was written to output. "SHA256" and "End of Data" were supposed to be in the output.

i will enable secure boot and try again. enabling secure boot requires adding bitleaker to MOK key - not sure how to do it.

Can’t really read your output from the first message. It just looks like extended characters. Many versions use SHA1, even though SHA256 is available.

[roboknight]

If you see no output in your syslog from bitleaker, then the module didn’t run. It should still run and catch the event log without the secure boot set. You should see bitleaker running on boot up. The “fail” usually means there is no output in the syslog.

[paulga]

when I start the laptop today, I saw an error message

Verification failed: 0x1A security violation.

I pressed ok to see the 2nd msg:

shim UEFI key management, Press any key to perform MOK management

if i do nothing, the next error msg is:

Failed to load image: security policy violation, start_image() returned security policy violation

Yesterday, all i did was:

1. boot into live ubuntu 18.04 from a thumbdrive,
2. installed ubuntu on a portable ssd,
3. disabled secure boot and boot into ubuntu from the portable ssd, tested napper and bitleaker
4. then reenable secure boot.

not sure what triggered MOK management and how to restore it to normal?

https://imgur.com/YQyT219

[paulga]

[kkamagui]

I always thank you for your support, @roboknight! Hi @paulga, it seems that your BIOS didn't allow the Bitleaker's bootloader. Would you check SecureBoot-related options in your BIOS menu?

[roboknight]

You can make it “go away” by enrolling the hash of whatever version of grub you’re booting into (assuming it’s grub). The other thing to check is the boot order. I presume you were expecting your normal boot. Maybe the thumb drive or external ssd was plugged in and booted? It’s basically just saying it doesn’t see the thing you’re booting with in its list of OK’d boot things. You can okay it with MOK, or check to make sure what you are booting is ok. The other way to get rid of it is to create a boot signing key and sign the boot loader. That’s a little involved and I can’t point you to any handy list of steps. At any rate, I always see the same thing when I boot my Bitleaker thumb drive on a new machine with secure boot. I just enroll the boot loader and let it secure boot (usually I need that).

[paulga]

You can make it “go away” by enrolling the hash of whatever version of grub you’re booting into (assuming it’s grub). The other thing to check is the boot order. I presume you were expecting your normal boot. Maybe the thumb drive or external ssd was plugged in and booted? It’s basically just saying it doesn’t see the thing you’re booting with in its list of OK’d boot things. You can okay it with MOK, or check to make sure what you are booting is ok. The other way to get rid of it is to create a boot signing key and sign the boot loader. That’s a little involved and I can’t point you to any handy list of steps. At any rate, I always see the same thing when I boot my Bitleaker thumb drive on a new machine with secure boot. I just enroll the boot loader and let it secure boot (usually I need that).

with both the thumb drive (live ubuntu) and portable ssd (installed ubuntu, bitleaker is built) disconnected, still the same verification error message. not sure what has changed due to my operation..

settings in bios were same as before

if secure boot mode (in the middle photo) is switched from Standard to Custom, there will appear a "key management" item:

I don't know what these keys are and where they are stored. my guess is, after i install unbuntu to the portable ssd, the originally win10 only machine somehow becomes multi boot, this change is then detected by the secure boot mechnism..

[roboknight]

That sounds like grub was installed on your hard drive. If you enroll it’s hash in MOK, it should work. However, if you had Bitlocker installed on your Windows partition, you will likely need your recovery key, if you have one.

[roboknight]

I forgot to mention that is because now your PCR 7 will have changed if you were using TPM as a protector. Also, above should read hash, instead of has… that’s what I get for using my phone.

[paulga]

yes, bitlocker was enabled with tpm + pin. pcr 7 is secure boot stuff, right? It should already have changed a month ago, that was when I could not boot to windows (see the screen below), and the reason of my search. recovery keys are no longer accessible.

if it is possible to restore the PCR values, then bitlocker may not trigger recovery.

[roboknight]

Yes. That is correct. You might be able to remove MOK manager and grub. You will have to restore Windows boot manager. However, if there was a bios update, you may be out of luck.

[roboknight]

Btw, are you a victim of a Dell update? Or HP?

[paulga]

bios was last updated in Sep 2021. alienware is dell. the accident started from a hard reboot. the machine was fixing the C drive, and then bitlocker was triggered recovery. now, explicitly it says "because secure boot policy has changed ", there could be other reasons as well. I was thinking to use bitleaker to decrypt the system volume then boot into windows, however it may not be this straightforward, esp. with the bitlocker PIN enabled.

maybe it's worth a try to restore the PCR values first. could you shed light on how to start？

1. remove MOK manager and grub.
2. restore Windows boot manager

[paulga]

@roboknight @kkamagui Hi, did you have time to read my last two questions?

also, where does bitleaker save syslog? when i select "windows boot manager" from grub, bitleaker will hook its process to the boot process and had some output until bitlocker recovery screen. I will post those output here if there is a log saved.

If you see no output in your syslog from bitleaker, then the module didn’t run. It should still run and catch the event log without the secure boot set. You should see bitleaker running on boot up. The “fail” usually means there is no output in the syslog.

[roboknight]

So, normally, you’d have to boot into Linux to see the output. If you are seeing bitleaker’s output at boot, that’s good. When you boot Linux, you should be able to run: sudo dmesg | grep bitleaker That will tell you if everything is run okay. The problem is, if you are suffering from an unexpected update, the hash of your bios may have changed. This means that unless you have a hack for the TPM, it won’t give you the encryption key because PCR7 will be incorrect out of the gate, and you don’t have the correct values to replay. I do know that, based on other work I’ve done, technically, if you can skip the PCR check, the TPM actually can decrypt your data. This is actually done early in the process. The PCR check is just a gate keeping measure and not a true cryptographic hurdle. At any rate, if the hashes don’t match, bitleaker won’t be able to help.

[paulga]

@roboknight do you mean an unexpected Windows update may have changed the hash of bios? even if this "update" is uninstalled, the bios hash will never revert back to the same? previous windows update never triggered bitlocker recovery. The cause may not be an update.

[roboknight]

Dell issued an update on some of their BIOSes. When they did this, it was part of an update. Generally, when this is done, there is a way to tell Bitlocker to unlock for some number of reboots. They didn’t do this, and it caused this sort of an issue. However, they were SUPPOSED to at LEAST register the recovery key. I think some people were able to retrieve their keys. However, there were some that weren’t able to get a recovery key from either Microsoft or Dell. Those people were pretty much out of luck. If you knew your exact BIOS version and could verify things, you’d have a better shot at recovery. But, if the BIOS is wrong, then you won’t be able to get PCR7 to match. That’s true of any system. I mentioned Dell because they enabled Bitlocker on users without letting them know. HP didn’t have any of those incidents that I know of. Asus never cared, so, no issues. If you didn’t have a BIOS update, then hopefully your TPM or fTPM didn’t get cleared. Then you are out of luck without the recovery key. But THAT doesn’t seem to be the case.

[paulga]

@roboknight in previous calls to Dell and MS, they told me they don't have copies of recovery keys. I set system update to manual. previous bios updates did't trigger bitlocker recovery. there was a time when bitlocker was triggered, probably due to wifi card replacement, however, the system boot into windows after i clicked skip this drive. the current bios version is 1.13.0, it was updated in last september. how is pcr 7 hash determined? does MOK change, grub install affect it?

[roboknight]

I just read back through previous posts. There COULD be another issue. This is an issue that can occur with any encrypted system and is one reason I never encrypt drives myself. Not that I don't believe in data protection, but it could very well be that the sectors that were storing the info for Bitlocker got damaged and, for whatever reason, it isn't looking to a backup copy of the sectors. I'm not sure in what condition your drive is in, but have you checked the health of your drive? If Bitlocker can't get a good copy of the encrypted VMK, then it is unlikely to be able to decrypt the drive with the TPM.

It is also true that Grub will change PCR7. Basically, PCR7 is the hash of several things, including bootmgfw.efi (if it boots Windows...it is the Windows boot manager) or Grub (if booting Linux) as well as certain BIOS things (one being the state of Secure Boot, which, if on, it hashes the unicode string 'Secure Boot', prefixed with a few things that I'm unsure of their origin story. So, in order for it to actually boot, you'll have to avoid Grub and boot straight to Windows (unless of course you were Dual booting Linux when you enabled Bitlocker). Bitleaker is able to work by replaying the hashes up to the point where Grub would've gotten hashed in and add in bootmgrfw.efi's hash instead.

I did forgot you had a TPM+PIN. This is something Dell (or MS) would never enable, so yes, they are probably correct when they say they don't have your recovery key. That was probably generated when you turned on TPM+PIN. They only ever turned on the TPM alone (and yet, have managed to screw up many people all the same). No PIN. So if you no longer have your recovery key, you might be out of luck. You CAN try dislocker-metadata under Linux. Basically, you'd have to do something like this: Locate which drive is the Bitlockered drive either through dmesg or lsblk Once you've located the drive, note which partition is Bitlockered. It will likely be labelled 'Microsoft Basic Data' and will likely be the largest one (you may have to use gdisk -l /dev/device_containing_your_main_disk). Then you can use dislocker-metadata -V path_to_the_partition_located_above It SHOULD show you a lot of output (I don't have a handy example), but if you see one with something like 'TPM+PIN' then it is likely that the disk is good.

Another possibility is that the place where the PIN is needed doesn't have the PIN anymore? I've actually never used a PIN with Bitlocker, so don't know how entering the PIN works. If you need to enter it every time you boot (which I would imagine is the case, but since I've not used it, don't know), then I suspect it asked you for it and then showed you the recovery key screen? Or did you just see the recovery key screen?

One final possibility is that because you used TPM+PIN, that the TPM is locked out. I do know that this can happen, but as I've not tried to lock out a TPM, I don't know if that's a permanent state or if you can just wait a long period of time and try again. But, unless the PIN was mangled somehow, this doesn't seem likely.

[paulga]

@roboknight I remember seeing tpm+pin in windows command line, so the disk is still good. i checked the esp partition and got some questions

1）I thought the 4 secure boot keys are never changed. however it looks like they are dated Feb 16. probably i have unintentionally installed factory default key in bios. will this change pcr 7 measurement? 2) an ubuntu entry (it includes grub) is added to the esp partition due to the installation of ubuntu on a portable ssd. this will also change the pcr 7 hash, right？if i remove the ubuntu entry, will pcr7 restore to the same value as before ubuntu was added?

[paulga]

I also recorded windows boot process. it looks like recovery was triggered half way through.

https://youtu.be/ziV-Cl1byvQ

[paulga]

@kkamagui Could you take time to look at this video? what could we tell from those outputs?

[paulga]

1）I thought the 4 secure boot keys are never changed. however it looks like they are dated Feb 16. probably i have unintentionally installed factory default key in bios. will this change pcr 7 measurement? 2) an ubuntu entry (it includes grub) is added to the esp partition due to the installation of ubuntu on a portable ssd. this will also change the pcr 7 hash, right？if i remove the ubuntu entry, will pcr7 restore to the same value as before ubuntu was added?

@roboknight did you have time to answer my questions?

[kkamagui]

@paulga I'm sorry to hear that you still have problems. I think your system has changed because of some updates, so PCR 7 may change. As you know, the firmware extends PK, KEK, db, dbx, and certificate for verifying the bootloader to PCR 7. It means PCR 7 could change if you recover secure-boot keys to the factory default. If then, Bitleaker can't help you because Bitleaker assumes the values haven't changed. PK, KEK, db, dbx are unique in every model, so you could recover the specific values by extracting them from the same model.

Please check my Black Hat Asia conference talk below (page 47 shows what I said): https://i.blackhat.com/asia-20/Thursday/asia-20-Han-BitLeaker-Subverting-BitLocker-With-One-Vulnerability.pdf

[paulga]

@kkamagui I read the slides last month. As these keys are the same for the same model, reinstalling the keys should not have changed them, right? After all I got it, as pcr7 may have changed, bitleaker doesn't work to extract the vmk. I thought it reads the pre sealed pcr7 and replay it to tpm. With Intel ptt, is it possible to do bus sniffing, assuming tpm has not been cleared, and it releases the key during boot?

[roboknight]

1）I thought the 4 secure boot keys are never changed. however it looks like they are dated Feb 16. probably i have unintentionally installed factory default key in bios. will this change pcr 7 measurement? 2) an ubuntu entry (it includes grub) is added to the esp partition due to the installation of ubuntu on a portable ssd. this will also change the pcr 7 hash, right？if i remove the ubuntu entry, will pcr7 restore to the same value as before ubuntu was added?

Okay, I have my data in front of me, so I can more acurately describe the processes. The information comes from the Windows logging tool (I can't remember off the top of my head, but I can track it down and post it. kkamagui is familiar with the tool as well, so he might be able to list it): 1) "Boot Guard Measured S CRTM" is hashed into PCR0 ... You'd only care about this if your policy had the PCR0 bit set. 2) Some 16 byte value is hashed into PCR0 ... I do not know where these 16 bytes come from. They are tagged CRTM version. 3) Another 16 bytes, tagged Post Code is hashed into PCR0 4) Dell's signing key is hashed into PCR7 ... According to some of the text in my Dell 7579, it is basically the Dell UEFI signing key (the one they sign the UEFI with presumably). I presume they could update this if they updated the UEFI BIOS. I believe you might be able to obtain this from ANY Dell with the correct BIOS, unless they use different ones for different product lines. 5) Microsoft's KEK certificate is hashed into PCR7. Again, I presume they could update this, but it is their Third Party Marketplace key. I don't think they would update this if they didn't have to. I presume they use this to sign whatever key that will sign the boot manager firmware. So technically, "shim" is signed with this, so this is ok. This, likely can be obtained from ANY device out there. 6) Microsoft's Third Party root cert hashed into PCR7. I am guessing this key signs the previous one... but maybe I've got the order backwards here. Again, don't think this key would be changed if Microsoft didn't have to change this. But presumably, it could be obtained from any machine. 7) Microsoft's Root cert hashed into PCR7. I'm guessing this key signs the Third Party root cert. Again, maybe I've got it backwards, but at any rate, it likely can be culled from any machine. 8) The Separator is hashed into PCR7... This is a "sealing" value of sorts. It's just 4 zeros, hashed. Always produces the same hash. 9) Separators are hashed into PCRs 0-6 as well. These are likely "don't cares" if your Policy is just PCR7 & PCR11. 10) PCR5 gets a copy of the EFI partition list hashed into it at this point. Don't use PCR5 in a Policy if you want to change disks later, if the disks don't have the same partitions. 11) PCR1 get "BootOrder" in Unicode hashed into it (it is prefixed with some unknown value). 12) PCR1 then gets the bootable things, in some order, hashed into it. 13) PCR1 also gets the handoff table hashed in. 14) PCR7 gets the bootmgfw.efi signed cert hashed into it. This is the thing Bitleaker would have to replace if you boot with something else. 15) PCR4 gets the hashed in value of the boot services application. So, the path of what booted, from the looks of it, in Unicode. 16) PCR11 gets the value 0x10000000 hashed in. It is tagged "Compact_Hash". Effectively, this seals you from retrieveing the VMK after Windows is booted. So steps 1-15 will get Windows booted. Step 16 prevents you from getting the VMK later. This is because the PCR policy that is saved, usually has PCR11 as all zeros.

At any rate, You likely only need the hashes related to PCR7 above. The only one that really concerns me, in your case, is the one related to Dell's signing key. If it was updated, that would screw you up. However, if you can get the CORRECT one, you could likely adjust the Bitleaker script to read the appropriate hashes from a list, instead of from the log, in which case you'd save your device. But I do not know how many copies of Dell's CERT are out there that are different. It is possible that Microsoft has updated one too, but likely, if they updated anything, it was only the KEK. The other two are likely more permanent.

[roboknight]

As a note, I do not know if your hashes are SHA1 or SHA256. Both are out there. I've mostly run across SHA1. kkamagui 's original code was for SHA256, though he might have tested it for SHA1. My version supports both, but, you'll have to get the right hashes (as you are aware). I just remembered the tool: PCPTool ... You have to compile it yourself. Its not TOO hard, but you do have to find the right version of Visual Studio. I think I might have been able to use Version 13 or something like that.

[roboknight]

Hopefully that list of steps verifies what kkamagui said earlier, if in a more verbose form, because his list is essentially correct, and I think more accurately describes where the things being hashed actually come from. Also note that I stopped after the hashing into PCR11 because beyond that, most things don't care (unless you don't use secure boot and turn on Bitlocker... then you get 4 PCRs you must deal with... 2, 4, 5, and I think 12... but maybe its another one. At any rate, that is only for Bitlocker WITHOUT secure boot... Oh, and I missed ONE step... BEFORE everything else gets hashed into PCR7... "SecureBoot" in Unicode is hashed in with a prefixed value... In fact, that value prefixes EVERYTHING that goes into PCR7. I think this makes things "Unique" between devices (but I'd have to verify this to be absolutely sure)... so maybe you can't just grab any old device's hashes... you may have to verify this... However, you CAN grab the data from PCPTool, and likely "mix and match" the data so that you get a correct hash for your own device. So, to provide a more concrete example of what I mean: 61dfe48bca93d211aa0d00e098032b8c <-- "random" value 0a000000000000000100000000000000 <-- unknown data 53006500630075007200650042006f006f00740001 <-- "SecureBoot" in unicode, with 1 appended

Some of what is below is slightly off. So, the 1st 16 bytes are prefixed to EVERY PCR7 value that I can see. The NEXT 16 bytes (labelled unknown data above) change, and I don't know exactly why (I do know... see below). It is possible that the SECOND set of 16 bytes is always the same between machines. Not sure about that. Just to be clear, I think the second set of 16 bytes is a set of 4, 4 byte values. The first 4 bytes is 0x0a 00 00 00, which, is just 10... the length of the tag (SecureBoot). Then there is another 4 zeros. Don't know what that is. Then 4 bytes of data length. Then another 4 zeros. Don't know what this is. So I think the first 32 bytes just tell you who and how long the data are... If I'd paid more attention sooner, I'd have figured that out already... ugh...

The bit labelled "random" value is something I have no clue how to derive (see below... I think I've figured it out). However, if you could run PCPTool on another device (it's a Windows tool, so you'll have to be able to use a device that can boot Windows), you might be able to determine whether or not that value changes between Dell devices (I don't know how many Dell's you have access to). At any rate, once you have that data, all you have to do is hash it with either SHA1, or SHA256. If the "random" value changes between devices for some reason, then maybe you could find out what it is for your target and then just generate all the appropriate hashes. PCPTool will help you figure out what data is being hashed to help you determine what data you'll need to collect to generate hashes that MIGHT work. There is no guarentee you'll be able to recreate the hashes you need, but if you REALLY need the data, then maybe you can do it. All of this ALSO presumes the "unknown data" is the same between machines. It may not be, but maybe you could collect it for your target, if you can get the 1st 16 bytes for your target.

EDIT: Okay, being stupid... the "unknown data" above is basically just a length, minus the 32 bytes for the "prefix" and the number of bytes for the "tag", "SecureBoot" in unicode, in this case. So there is only a boolean "1" at the end, indicating SecureBoot is on in my case. As I said above, I think the 0x0a is the length of the tag, or why there are so many ZERO included, but ultimately, its 16 bytes total. So, this data is probably ALL the same between devices. Its just the first 16 bytes that may differ.

[roboknight]

In my above list, I also missed a step for PCR1 after the PCR7 Separator. It gets the platform config flags hashed into it. After that comes all of the other Separators hashed into PCR00-PCR06.

[roboknight]

Okay, so it seems there are 2 values. One is as above for many of the PCR7 values. However, the ones from Microsoft have a different 16 bytes value. At any rate, what I said before can still be done, if you can get the correct 16 byte values and the appropriate data to hash. But I don't know if you can get the data or not. If I knew where the odd looking 16 byte data is coming from, I could tell you if the hashes will differ between devices or not for sure, but I do not know where this comes from. It could be a simple MD5 sum of something, or it could be a generated checksum. I don't have a solid way of determining where this data is coming from. Maybe kkamagui knows what this data is as he's probably dug further into this data than I have. Ultimately, it looks like some kind of data structure prefixed to the data that is going to be included in the hash. Again, kkamagui probably knows more about this part of the structure than I do.

[roboknight]

1）I thought the 4 secure boot keys are never changed. however it looks like they are dated Feb 16. probably i have unintentionally installed factory default key in bios. will this change pcr 7 measurement? 2) an ubuntu entry (it includes grub) is added to the esp partition due to the installation of ubuntu on a portable ssd. this will also change the pcr 7 hash, right？if i remove the ubuntu entry, will pcr7 restore to the same value as before ubuntu was added?

@roboknight did you have time to answer my questions?

I did look at the video as well. I saw where the PIN was entered. You probably need a stand for your camera, but it does appear that bitleaker is attempting to dump data into the device. I don't know exactly where the PIN for TPM+PIN goes. What I mean by this is that I don't know if it is used to unlock the TPM so bitlocker can access things. It is possible that if the wrong PIN is provided, maybe the TPM locks. I don't know a good way to check the status of your TPM to see whether or not it decided to lock itself. The PIN also could just be a "mix-in" to information returned from the TPM. At any rate, you are definitely seeing the recovery screen because Bitlocker can't unlock the key to your drive (obviously), but I can't tell if that is because TPM access is being denied, or if it is because the PIN is incorrect, or if, as mentioned before, some update has now caused something in PCR7 to change. Any one of those things can lead to the recovery screen, unfortunately. And the recovery screen doesn't give you any information as to which thing is occuring (it would be NICE, for example, if it said "TPM FAILURE" on it somewhere... that wouldn't necessarily let you in on the secret, but it would be better than nothing).

[roboknight]

With regards to Intel PTT, this is a firmware thing. Not a hard TPM. Only hard TPMs can be monitored by bus sniffing... At the moment. Its kind of like TrustZone for ARM, but for Intel chips. They basically include another "co-processor" in their SoC and use that for a TPM instead of making the OEM supply a hard TPM. I should also mention here that PINs also preclude bus sniffing. I forgot the mention that. You need to provide the correct PIN, provided the TPM isn't locked out, to sniff the bus. If the TPM is locked out, or you don't know the PIN, you'll be out of luck in almost every case... unless you guess the TPM PIN correctly within the number of lockout attempts.

[roboknight]

If I understand this correctly, the PIN in TPM+PIN does refer to the PIN that locks the TPM. So hopefully you aren't locked out of the TPM. In this case, I'm not sure what can be done. I've not tried to lock out a TPM before, so maybe you just need to reboot and try again (you've obviously done this) and "no harm done"tm. Or maybe it really did decide to lock you out. In which case it is clear why Bitleaker and everything else is failing... the TPMs locked out. Again, I don't know how to check this to be 100% sure.

[roboknight]

Not to put to much IT fud here, but this does indicate that a TPM lockout needs resetting and can be entered by incorrectly entering the PIN too many times: Microsoft documentation

Its info on resetting a lockout isn't likely to prove very useful to you unless you actually HAVE your TPM creds to get it to unlock. However, that means your PIN was wrong in the first place and that STILL won't let you in without it. Hopefully someone didn't maliciously lock your computer by providing wrong PIN attempts in an effort to lock you out of your device. If so, they've done an effective job.

[roboknight]

So, it dawns on me that the first 16 bytes that are hashed with each PCR7 value indicate which UEFI entity hashed the data. So this likely won't change. So, it SHOULD be possible to obtain the hashes from another Dell PC with the correct firmware. I can't tell you what firmware version you should look for, but if I've got that correct, and those first 16 bytes are just the GUID of the UEFI entity that is sending the data, then the first 32 bytes, plus the tag, won't change (that is, unless the entity that does the hashing changes... in which case... YIKES!)... I checked here and found those 16 bytes in the log. So it appears that it is just the GUID ID of the thing sending the data (still a bit of a presumption, but I think its a good guess). And that doesn't change from machine to machine, so any Dell with the right version of UEFI firmware, should be able to give you the correct hashes.

[paulga]

@roboknight thank you. Will read and follow up later as my knowledge is quite not there to be able to follow you.

[roboknight]

I modified a few things above. I realized that the data that prefixes the PCR7 data is basically just data from a certain UEFI entity. If I looked through the UEFI code, I suppose I could tell you which entity wanted to extend PCR7. Ultimately though, it appears that you might have a locked out TPM. Again, I don't know how to verify that. Linux might be able to help there, using the TPM Tools. Not sure though. If that IS NOT the case, then it is likely you can try to find the correct hash values from another Dell device. The easiest would be another Alienware desktop (laptop? not sure what you have, but maybe it was a laptop) and get the values from there. That said, you'll have to feed them into bitleaker (you might just be able to edit the /var/log/syslog, or whereever linux is storing the syslog these days, so that bitleaker reads the values you need). As I say, this presumes your TPM isn't locked out. Also, you have one final problem... You'll have to figure out how to send the PIN to the TPM so that bitleaker can access it. Neither my own code, nor kkamagui's code, has a provision for the PIN. So you'll likely have to figure that part out.

[roboknight]

So that thing I said was a GUID above is a GUID. It is the EFI_GLOBAL_VARIABLE GUID. So, it is likely the rest of those PCR7 values are prefixed in the same way. There is only 1 case where it isn't prefixed like this: hashing bootmgrfw.efi ... the last thing sent into PCR7. It doesn't appear to have the same format here. But that value doesn't matter, as it has been computed. The other two are here ... except in binary form (which means certain values are flipped around for GUID form). But anyway, going through this demystified that little bit of info for me. At any rate, those GUIDs don't change either. So nothing in those hashes will change except based on new data from Dell or Microsoft. As I said above, I don't think the stuff from Microsoft has changed. That leaves the signing key from Dell, most likely. And, of course, if the PIN was wrong.

EDIT: Forget what I said about the last value. Its the same as the rest from Microsoft. Prefixed with a GUID, and indicating its from the DB (not DBX). Which is what you'd want from bootmgrfw.efi.

[paulga]

@roboknight thanks for your input. With Intel ptt, the "correct" pcr7 should be saved on disk or in a chip on the mb. The reason that you have to go to lengths to decode is, the "correct answer" platform measurement cannot be read or sniffed @kkamagui , right?

[paulga]

I just read back through previous posts. There COULD be another issue. This is an issue that can occur with any encrypted system and is one reason I never encrypt drives myself. Not that I don't believe in data protection, but it could very well be that the sectors that were storing the info for Bitlocker got damaged and, for whatever reason, it isn't looking to a backup copy of the sectors. I'm not sure in what condition your drive is in, but have you checked the health of your drive? If Bitlocker can't get a good copy of the encrypted VMK, then it is unlikely to be able to decrypt the drive with the TPM.

It is also true that Grub will change PCR7. Basically, PCR7 is the hash of several things, including bootmgfw.efi (if it boots Windows...it is the Windows boot manager) or Grub (if booting Linux) as well as certain BIOS things (one being the state of Secure Boot, which, if on, it hashes the unicode string 'Secure Boot', prefixed with a few things that I'm unsure of their origin story. So, in order for it to actually boot, you'll have to avoid Grub and boot straight to Windows (unless of course you were Dual booting Linux when you enabled Bitlocker). Bitleaker is able to work by replaying the hashes up to the point where Grub would've gotten hashed in and add in bootmgrfw.efi's hash instead.

I did forgot you had a TPM+PIN. This is something Dell (or MS) would never enable, so yes, they are probably correct when they say they don't have your recovery key. That was probably generated when you turned on TPM+PIN. They only ever turned on the TPM alone (and yet, have managed to screw up many people all the same). No PIN. So if you no longer have your recovery key, you might be out of luck. You CAN try dislocker-metadata under Linux. Basically, you'd have to do something like this: Locate which drive is the Bitlockered drive either through dmesg or lsblk Once you've located the drive, note which partition is Bitlockered. It will likely be labelled 'Microsoft Basic Data' and will likely be the largest one (you may have to use gdisk -l /dev/device_containing_your_main_disk). Then you can use dislocker-metadata -V path_to_the_partition_located_above It SHOULD show you a lot of output (I don't have a handy example), but if you see one with something like 'TPM+PIN' then it is likely that the disk is good.

Another possibility is that the place where the PIN is needed doesn't have the PIN anymore? I've actually never used a PIN with Bitlocker, so don't know how entering the PIN works. If you need to enter it every time you boot (which I would imagine is the case, but since I've not used it, don't know), then I suspect it asked you for it and then showed you the recovery key screen? Or did you just see the recovery key screen?

One final possibility is that because you used TPM+PIN, that the TPM is locked out. I do know that this can happen, but as I've not tried to lock out a TPM, I don't know if that's a permanent state or if you can just wait a long period of time and try again. But, unless the PIN was mangled somehow, this doesn't seem likely.

@roboknight @kkamagui ...."the sectors that were storing the info for Bitlocker got damaged" ... the chance should be very small as i didn't find lots of threads discussion over it. if this happens, is VMK the only way to unlock the drive? or only FVEK is the 100% sure thing? if two drives C: (OS) and D: are turned on bitlocker, is it easy to get VMK and FVEK of both drives?

[customautosys]

I got this error the first time round and also nothing in dmesg | tail.

Now it is stuck:

                                            ,║▒▒▒▒▒▒@╖
                                           ╥▒▒╝    ▒▒▒╢
                                          ]▒▒╢      ]▒▒╢
                                          ]▒▒▒      j▒▒╢
                      ,                 ,╖║▒▒▒
        ,╓╖,  ╓@╬@╥╥╬╣╢╢▓▓            ╖▒╖▒╙▒▒▒░░░▒░▒▒▒▒.
    ║╬@▓╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢[           ╜╜╜╢╢▒▒░░░░░░▒@▓▓▄▒▒▒▒╖
    ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢[           ░░░░░╙╢▓╣╬▓▓@@▓▓@░░æ▓▓▓[
    ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢..[           ░░░░░ ░▒▒▒▒▒▒▒▒▒▒▓▓▓▒▒▒H
    ╢                    ╢`           ░░░░░░░▒▒▒▒▒▒▒▒▒▒╢▒▒╢╢╢[
    ..╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢            ░░░░░░░▒▒▒▒▒▒▒▒▒▒╢╢╢╢╢╢[
    ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢[      ¿░░░,░░░░░░░▒▒▒▒▒▒▒▒▒▒╢╢╢╢╢╢[
    ╢╢╢╢╢╢╢╢╢ ╢╢╢╢╢╢╢╢╢╢╢╢░░░░░░░░░░░░╣▓▓@░░░▒▒▒▒▒▒▒▒▒▒╫╣╣╣▓▓[
      ╙╙   ╙╬ ╨╜╙╬╢╢╢╣╣╢╢╢░░░░░░░░░░░░░░░░╫▓@▓▓▓▒▒▒▒▒▒▒▓▓▓▓▓▓[
         ,,, ,░░░░░░░░░░╙╨░░░░░░░░░░░░░░░░░░▓▒▒▒▓▓▓▓▓▓▓▓▓▓▓▀"`
    ,,.░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]▒░░░╙╢▒▓╣▓▒▒▒▒  ]
    ▐▓█████▄░░░░▒░░░░░░░░░░░░░░░░░░░░░░░░░░╟▒▒▒▒▒▒▒▒▒╣▓╢╢╢ ░░
    ▐▓▓██████████▄░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▓╢▒▒▒▒╢▓╢╢▒┌░░
    ▐▓▓█████████████████▄░░░▒▒░░▒▒▒▒▒▒▒╢╢╢╢╢╢Ñ▒▒▓╢▒▒▒▒▓╣╢╜▒░░
    ╜▓▓██▀████████████████▌║▒▒▒▒╢╢╢╢╣╢╢╢╣╣╣╣╣╣╣╝╣▒▒╢▓"    ▒░░
    ` "╙``╙╣▀█▀▀██████████▌╢╢╢╢╢╢╢╣╣╣╣╣╢Ñ╜╨Ñ╝`    ╙  ,,   ▒▒▒
             "` "╨╢▀▀▓▓███▌╢╣╣╣╣╣╣╜╜╨╨╜      ▄, ░░   ,▌ ░░▒▒▒
     ░   e             ╙╣▓▌Ñ╜╙╙╜`            ▌▓ ░░░  ░░░░░▒▒▒
     ░░░░╧╤░░░    ,       ,         ▐░ ░░░░  ░░░░░░░░█▐░▒░▒▒▒
     ░░░░,░░░░░░  ▐,     j▌█    ░ ░░░░░░░░░░░▐░░▒░░░░░░░▒░▒▒▒
     ░░░░▌█░░░░░░░░░░░░ ░░░░░░░░░░░░╪░░░░░░░░░░░▒░░▒░▒▌▒▒▒▒▒▒`
    ▒▒▒▒░▒▒▒▒▒▒░░æ▄▒░▒▒░░æ▄▒▒▒▒▒▒▒▒▌▓▒▒▒▒▒▒▒æ▒▒▒▒▒▒▒▓▓▒▒▒▒▒▒
    ]▒▒▒▒░▒▒▒▒▒▒▒▒╬▒▒▒▒▒▒▒╬▒▒▒▒▒▒▒▒▒▐▌▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░
    └ ▒░░▒▒▒▒▒░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒]▒░▒▒░▒░▒▒▒░▒▒▒░░░ ░░░; ░░
      ▒░░▒▒░▒║░▒▒▒▒▒▒░▒▒▒▒▒░▒]▒▒]░░▒▒░░ ░░▒░▒░▒░░  ░░ ⌡  ░
      ░ ░░▒░▒] ░░▒░▒░░▒▒░]░░▒;▒▒]░░░░ ░ ░░j░░░▒░   ░  !
        ░▒L░░└   ░░  ░▒ ░ ░░▒!▒▒ ░ ░  ░ ░░└ ░ ▒
         ▒L░       ░▒  ░ ░      ░ ░ ░ └ ░

BitLeaker v1.0 for decrypting BitLocker with the TPM vulnerability
         Made by Seunghun Han, https://kkamagui.github.io
       Project link: https://github.com/kkamagui/bitleaker 

Search for BitLocker-locked partitions. [>>] BitLocker-locked partition is [/dev/nvme0n1p3]

It hangs here

[roboknight]

It looks like you were attempting to use a newer kernel. Glad you provided your patch. Ran into this trying to use 20.04 and did the same. If you need SHA256, be warned: I noticed more than one bug in my script as I was refactoring it. Trying to make it more reliable and a little more ‘idiot proof’ (though that never really works). Namely with the PCR policy generation. It can be off. Especially if the data from dislocker isn’t complete. So check that too.

[roboknight]

I just read back through previous posts. There COULD be another issue. This is an issue that can occur with any encrypted system and is one reason I never encrypt drives myself. Not that I don't believe in data protection, but it could very well be that the sectors that were storing the info for Bitlocker got damaged and, for whatever reason, it isn't looking to a backup copy of the sectors. I'm not sure in what condition your drive is in, but have you checked the health of your drive? If Bitlocker can't get a good copy of the encrypted VMK, then it is unlikely to be able to decrypt the drive with the TPM. It is also true that Grub will change PCR7. Basically, PCR7 is the hash of several things, including bootmgfw.efi (if it boots Windows...it is the Windows boot manager) or Grub (if booting Linux) as well as certain BIOS things (one being the state of Secure Boot, which, if on, it hashes the unicode string 'Secure Boot', prefixed with a few things that I'm unsure of their origin story. So, in order for it to actually boot, you'll have to avoid Grub and boot straight to Windows (unless of course you were Dual booting Linux when you enabled Bitlocker). Bitleaker is able to work by replaying the hashes up to the point where Grub would've gotten hashed in and add in bootmgrfw.efi's hash instead. I did forgot you had a TPM+PIN. This is something Dell (or MS) would never enable, so yes, they are probably correct when they say they don't have your recovery key. That was probably generated when you turned on TPM+PIN. They only ever turned on the TPM alone (and yet, have managed to screw up many people all the same). No PIN. So if you no longer have your recovery key, you might be out of luck. You CAN try dislocker-metadata under Linux. Basically, you'd have to do something like this: Locate which drive is the Bitlockered drive either through dmesg or lsblk Once you've located the drive, note which partition is Bitlockered. It will likely be labelled 'Microsoft Basic Data' and will likely be the largest one (you may have to use gdisk -l /dev/device_containing_your_main_disk). Then you can use dislocker-metadata -V path_to_the_partition_located_above It SHOULD show you a lot of output (I don't have a handy example), but if you see one with something like 'TPM+PIN' then it is likely that the disk is good. Another possibility is that the place where the PIN is needed doesn't have the PIN anymore? I've actually never used a PIN with Bitlocker, so don't know how entering the PIN works. If you need to enter it every time you boot (which I would imagine is the case, but since I've not used it, don't know), then I suspect it asked you for it and then showed you the recovery key screen? Or did you just see the recovery key screen? One final possibility is that because you used TPM+PIN, that the TPM is locked out. I do know that this can happen, but as I've not tried to lock out a TPM, I don't know if that's a permanent state or if you can just wait a long period of time and try again. But, unless the PIN was mangled somehow, this doesn't seem likely.

@roboknight @kkamagui ...."the sectors that were storing the info for Bitlocker got damaged" ... the chance should be very small as i didn't find lots of threads discussion over it. if this happens, is VMK the only way to unlock the drive? or only FVEK is the 100% sure thing? if two drives C: (OS) and D: are turned on bitlocker, is it easy to get VMK and FVEK of both drives?

The VMK is encrypted by your TPM. VMK=Volume Master Key. The FVEK=Full Volume Encryption Key. It is encrypted by VMK. It is also, typically, encrypted by the Bitlocker recovery key… the 48 digit monstrosity you didn’t have (if memory serves…these days…eh). I’m guessing your drive was healthy, but your TPM became locked. If so, hopefully you replaced your machine.