AmberWolf Research presented last month at DC34 an attack against some HP ThinPro models that I think deserves to be discussed in the context of PureBoot (coreboot/HEADS boot stack.)
Their Proof of Concept shows a UEFI critical flaw in the boot chain’s security, which PureBoot would have detected easily as tampering.
TL;DR: if you can steal a ThinPro 8 or 9, although the root partition is LUKS encrypted one can recover the TPM-sealed DUK (Disk Unlock Key) and decrypt all the data.
A blog post at: https://blog.amberwolf.com/blog/2026/august/hp-thinpro-tpm-sealed-disk-encryption-that-only-measured-half-the-boot-chain/ describes the attack (sorry, won’t preview in a box…)
The problem:
HP ThinPro 8 and 9 encrypt the root partition with LUKS and seal the key to the TPM. This is meant to keep the data safe if an attacker gets physical access to the disk. It does not, due to a rather large gap in the measurement of the boot chain.
Examining the boot loader showed the TPM seal only binds the key to PCRs that measure the BIOS, the option ROMs, and the GRUB binary. That trusted GRUB binary then loads a kernel and an initramfs that nothing measured at all.
If there is no measurement of what the bootloader loads - critical binaries can be forged in order to unveil the DUK and store a copy to the unencrypted /boot partition.
The attack:
It involves patching a particular shell script inside the initramfs: unseal_key
- Remove the M.2 SATA drive, attach it to your machine
- Mount the unencrypted
/bootpartition, unpack the initramfs - Patch
unseal_key, repack, write it back
- Reinstall the drive, power the device on
- PCRs 0, 2, 4 are unchanged, so the TPM unseals the key
- The patched script writes the key to .luks_key on
/boot - Pull the drive again, read the key,
cryptsetup luksOpenthe encrypted partition
No soldering, no reverse engineering, no exotic anything.
This attack would not have succeeded with PureBoot or any other coreboot/HEADS boot stack. Of course, the initrd in the unencrypted /boot partition can be unpacked and any script can be modified; but this sort of tampering would inevitably be caught because anything inside that partition that was modified after the last time it was signed by the security dongle, would alert the user of that change.