TPM2_Load response too short?

[jezzab]

Everything appears to be working beautifully but the data seems to be a lot shorter than the other logs I have seen which is causing it to fail. The unit is a NUC using Intel PTT

Any ideas would be greatly appreciated

[kkamagui]

Hello @jezzab,

It seems that there is no 81000001h handle in your Intel PTT. Did you enable BitLocker with UEFI Secureboot?

Best regards,

Seunghun

[jezzab]

I assume it was enabled with it Secure Boot turned off as its off now and booting into Windows with Bitlocker enabled

[jezzab]

What would cause it not to be able to read the 0x81000001 handle? Is there something I can look into to try and work out what is going on?

Appreciate your help
Jeremy

[kkamagui]

Hi @jezzab, you can read 0x81000001 with the command below.

$> tpm2_readpublic -c 0x81000001

By the way, it's a weird case. If you don't mind, would you share the kernel log after my BitLeaker runs? You can get the kernel log with the below command.

# If you share the log, I will check what happened.
$> sudo dmesg > kernel_log.txt

Best regards,

Seunghun

[jezzab]

Thanks for the reply @kkamagui
Im having issues with the tpm2_readpublic -c 0x81000001

But here is the kernel log
kernel_log.txt

[jezzab]

jez@jez-NUC7i3DNB:$ sudo ./tpm2_readpublic -c 0x81000001 -o output_pubkey.txt -f pem -t primary.handle
name: 000bbb09152e398fd61af41715e3e67912624edce7ceffcb7ba1691dcc605600d8fc
qualified name: 000b43fec5cb008a56290a130a00203b97704c55db592758fe6554af4451a85c6b3b
name-alg:
  value: sha256
  raw: 0xb
attributes:
  value: fixedtpm|fixedparent|sensitivedataorigin|userwithauth|noda|restricted|decrypt
  raw: 0x30472
type:
  value: rsa
  raw: 0x1
exponent: 65537
bits: 2048
scheme:
  value: null
  raw: 0x10
scheme-halg:
  value: (null)
  raw: 0x0
sym-alg:
  value: aes
  raw: 0x6
sym-mode:
  value: cfb
  raw: 0x43
sym-keybits: 128
rsa: c6339de2abf69406cd98b98d774ce31d69cfe06fd0d9edeed3a4f0f9586a879752c506bce52760770818336fc3be2f7f33b8b681b04b4626f47d272f75119034c4c2fb290f8c133ed1194df786ebdee21f2fc9529466db78d015797e17445ff5a6d7f06ecb4d5ea740de2ef64a85531725c15771201a4876701fa2f316d944121d961d722733b004fb274825876b508d152c916b30b4301bb273f75d79ba29daf466d08786b1f1eecb1a07e2660e0d5603a6ad111a975e76cc2daec7415dde4032053baf8a769021d4e5feb266b5edd45de98ff156166305d311ad7db3c98db2505a0ae013e6466a6ab212c1e2dd7804979dbd6a516055641e75b1a7b07d1f55

output_pubkey.txt
output_raw.zip

[kkamagui]

Hello @jezzab,

Thank you for your data. According to your test result, the handle for the Bitlocker was created already. It seems that your machine had an unusual problem. Would you share the specification of your machine if you don't mind? If I have one, I should test it with the machine.

Best regards,

Seunghun

[jezzab]

Its an Intel NUC NUC7i3DNB
https://ark.intel.com/content/www/us/en/ark/products/122495/intel-nuc-kit-nuc7i3dnke.html
Running Windows 10 IoT Enterprise with an M.2 SSD (Windows, Bitlocker protected) and im booting off an external USB3 SSD for Bitleaker/Ubuntu full install

[jezzab]

Hi @kkamagui,
Did you have one of these NUC's?

Regards
Jeremy

[roboknight]

I noticed this thread. Just a question, have you run dislocker -v -v -v -v -V PathToYourBitlockerVolume ? Where, of course, PathToYourBitlockerVolume should point to your device with bitlocker. It will help you figure out if your version of bitlocker is actually using PCRs 7 & 11. You can also check by booting into Windows (assuming this is actually possible) and running PCPTool (you may have to compile this to run it). From the above, it doesn't actually appear that your SecureBoot is checked. If it isn't, bitlocker uses other PCRs from the TPM (2, 4, 5, and something else I think). While I believe bitleaker should technically still work, the TPM commands may differ slightly if SecureBoot isn't enabled. I don't know if key 0x81000001 is necessary if SecureBoot isn't enabled. This MAY explain why bitleaker can't find it.

[kkamagui]

Hi @jezzab,
Actually no. Maybe it would take a long time to have the machine. :( Please check @roboknight's answer. :)
Thanks

[israShafique]

i am dealing with the same issue in dell x-13 9360.

[thedarkmask]

im also dealing with the same error on Dell Latitude 3590 :(

[roboknight]

Also you might need to check tpm2_getcap. If it shows that the tpm clear bit is 1, then you have a TPM that might require 2 resets. The problem is that kkamagui’s solution sometimes sets a flag causing it not to work. To fix this, the TPM needs to be reset when all zeros, but with the bitleaker module unloaded. This resets the TPM and allows the “TPM state” to be restored. Once this happens, the TPM should work as normal because it thinks the state has been restored. This needed to be fixed on the Dell 7579. Basically, it means sleeping twice, once with the module loaded and a second time without.

[roboknight]

As a note, I think this flag was supposed to prevent Bitleaker by indicating the TPM is in an invalid state (I.e. restored without restoring state), but the flag is pointless because it can be cleared by saving and restoring a zero state.

[thedarkmask]

As a note, I think this flag was supposed to prevent Bitleaker by indicating the TPM is in an invalid state (I.e. restored without restoring state), but the flag is pointless because it can be cleared by saving and restoring a zero state.

would you mind giving me a whatsapp or any other contact so i can contact you directly ??? :)

[roboknight]

As a note, I think this flag was supposed to prevent Bitleaker by indicating the TPM is in an invalid state (I.e. restored without restoring state), but the flag is pointless because it can be cleared by saving and restoring a zero state.

would you mind giving me a whatsapp or any other contact so i can contact you directly ??? :)

If you need code, I've already got a fork of the project which contains the repeated reset. Kkamagui did the heavy lifting on this.

[Leufje]

Hi all,

I have exactly the same situation (dell 7490, bios downgraded till vulnerable, running bitleaker with same results).
I also tried your fork @roboknight, but it gave me the same results as the printscreens shown in the first post.

Any suggestions/tips/tricks left?

[roboknight]

You may have to look at the load response. Use tpm2_rc_decode to find the error (two bytes at end). That might clue you in to why the load fails. Maybe the data in the registers isn’t valid?