[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Quote https://www.elstel.org/debcheckroot/

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

Reply to: