Re: Verified Boot, Secure Boot, dm-verity, debcheckroot
There are tools that can help with checking all files on the hard drive
such as `debsums`. However, while `debsums` is more popular, it is
During development of Verifiable Builds experiences were made with
verification of MBR, VBR, bootloader, partition table, kernel and
initrd. Source code was created to analyze such files.
verifying the BIOS/UEFI:
Most of the computers I have support flashrom. Either I have added
support on my own or I have bought machines that were known to support it.
If you take a malware image with debcheckroot you should possibly also
add an image of your BIOS. I can report about the following discoveries:
Lately I have taken multiple BIOS images on a P5P41TUSB3, ASUS board:
* naturally that board does not boot from USB3
* some time I have found it to boot from sdcard but only when a certain
hard disk was attached via usb3 ob boot time, the boot sector of that
hard disk was blanked (containing zeroes).
This discovery would strongly indicate that the BIOS was manipulated
and that some boot code was fetched likely from the intermediate gaps in
the partition table of that USB hard disk used for downloads with Tails
* some time later it did boot from any usb3 slot also from the usb3
sdcard reader no matter what hard disk was attached
* now, since last week it does no more boot from usb3
If anyone wants to have these BIOS images I could upload them somewhere.
It is a question on how to determine if possibly malicious changes have
been applied to a bios image.
I have used bindiff (https://www.elstel.org/qemu/) to list the number of
bytes that differ between BIOS images.
- about 70 bytes differed between any two boots, even if you do not
enter the BIOS settings
- after flashing a new BIOS with ASUS EZ+Flash, a BIOS internal flash
utility a little more bytes differed, but not that many
- when leaving the computer alone for half a week far more bytes
differed + the boot behaviour as described above