You are not logged in.

#1 2024-05-06 02:55:15

zonzon510
Member
Registered: 2022-07-27
Posts: 6

Changing bits in gpt partition area between boots - why?

Hello
I regularly use fully encrypted install (LVM on LUKS). The boot partition is
the only part that is not encrypted, and I recently started thinking about the
security of the unencryped kernel files at /boot (evil maid attack), and I
started using chkboot (https://aur.archlinux.org/packages/chkboot), which
verifies the hash of all the unencryped files stored in /boot. In addition to
checking the files on the boot partition, it also monitors for changes in the
"disk head", which should contain the master boot record.

it uses this command:

dd if=/dev/nvme1n1 of=/tmp/diskheadfile bs=512 count=1 > /dev/null 2>&1

stores it the output to a file, and monitors for changes in that file between boots.

to my surprise, the disk head part regularly changes, and I get notifications
from chkboot that my boot files have been changed. So, now I am trying to
understand what is changing and why. I have been looking at hex dumps of the
first bytes of /dev/nvme1n1.

this is the change I am looking at, at offset 000001c0.

.....
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0200 eeff ffff 0100 0000 af88 e0e8 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
.....
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0200 eeff ffff 0100 0000 af12 9e3b 0000  .............;..
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
.....

just below 000001c0, I see this "EFI PART" asci characters, which, from what I
gather is part of the GPT partition table,
(https://en.wikipedia.org/wiki/GUID_Partition_Table)
....
000001c0: 0200 eeff ffff 0100 0000 af88 e0e8 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
00000200: 4546 4920 5041 5254 0000 0100 5c00 0000  EFI PART....\...
00000210: ce4d 226a 0000 0000 0100 0000 0000 0000  .M"j............
00000220: af88 e0e8 0000 0000 0008 0000 0000 0000  ................
00000230: 8e88 e0e8 0000 0000 4e1a 2611 f66b cf4f  ........N.&..k.O
....

here is what my partitions (encrypted root and unencrypted boot) look like when
mounted "lsblk":

NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme1n1                    259:3    0   1.8T  0 disk 
|-nvme1n1p1                259:4    0   300M  0 part  /boot
`-nvme1n1p2                259:5    0   1.8T  0 part 
  `-cryptlvm               254:0    0   1.8T  0 crypt
    |-NVME2TBVolGroup-swap 254:1    0    40G  0 lvm   [SWAP]
    `-NVME2TBVolGroup-root 254:2    0   1.8T  0 lvm   /

here is the "fdisk -l /dev/nvme1n1"

Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WD_BLACK SN850X 2000GB                 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 11261A4E-6BF6-4FCF-811D-A928DE8B24ED

Device          Start        End    Sectors  Size Type
/dev/nvme1n1p1   2048     616447     614400  300M EFI System
/dev/nvme1n1p2 616448 3907028991 3906412544  1.8T Linux filesystem

so, I don't understand why anything would be changing in the GPT partition area
before the start of the EFI boot partition at sector 2048 (512 * 2048 = 1048576
bytes offset). (And, in fact nothing should be changing in the EFI boot
partition either, because chkboot doesn't indicate any of the hashes of my
files in /boot have changed) And according to that hex dump, I'm seeing changes
in (000001c0), which is around 448 bytes offset. Can anyone tell me why these
bytes are changing, and what they represent? Or some insights on what else I
can use to find out what they are?

Last edited by zonzon510 (2024-05-06 02:56:58)

Offline

#2 2024-05-06 22:16:39

exuvo
Member
Registered: 2010-12-07
Posts: 19

Re: Changing bits in gpt partition area between boots - why?

You can also just encrypt the /boot partition, grub supports unlocking. https://wiki.archlinux.org/title/GRUB#Encrypted_/boot or https://wiki.archlinux.org/title/Dm-cry … ion_(GRUB)

Last edited by exuvo (2024-05-06 22:19:29)

Offline

Board footer

Powered by FluxBB