search

kkamagui / bitleaker

This tool can decrypt a BitLocker-locked partition with the TPM vulnerability
Other
187 stars 35 forks source link

Does bitleaker have a log? #6

Open roboknight opened 4 years ago

roboknight commented 4 years ago

I was wondering if bitleaker has some kind of log for when you are attempting to boot windows to discover what the TPM messaging looks like? If so, how can I activate it? If not, do you have any ideas on how to implement one? I don't know what kind of logging grub already has available. My current quick approach would be a video camera I guess.

roboknight commented 4 years ago

This is just a note for running bitleaker: If you are trying to boot windows using bitleaker, the following commands will help --

search --no-floppy --file /EFI/Microsoft/Boot/bootmgfw.efi --set temp set root="($temp)" chainloader "($temp)/EFI/Microsoft/Boot/bootmgfw.efi" . . . stuff from bitleaker . . . boot . . . more stuff from bitleaker . . .

I just put this note here because I had the hardest time getting windows to boot with secure mode and it was likely because I wasn't setting the root variable, which is needed.

kkamagui commented 4 years ago

Hi @roboknight ,

Do you want to see the measurement log of BIOS/UEFI firmware? If so, you can find it with the "sudo dmesg" command after executing Bitleaker. You don't need to record the messages on screen because Bitleaker saves them into the kernel area. ;)

If it's not the exact point that you want to know, feel free to ask me. :)

Best regards,

Seunghun

roboknight commented 4 years ago

I was trying to see the output that bitleaker leaves. It is very convenient because the output of bitleaker's "SEND/RECV" format shows the same commands as if you were monitoring the TPM with hardware (my usual method... but fTPM I can't do that). And I was able to compare commands between the two and see what PCR registers were being extended and with what values. The value I posted in the other "issue" does seem to be correct across two devices. This tells me that, for the MOST part, the shim doesn't matter. It does matter, though, in two other spots. But THOSE spots are all stored in the log. So I believe your technique will work, and that value you had for PCA hash, is instead, the value that I posted. But it is extended with a SHA1 hash, instead of a SHA256. I was trying to determine how I could calculate this value, just to know for sure what is going on there, but since I'm able to independently verify it two ways, I'm not worried that its the wrong value.