HBoot: watch your machine’s boot with a “fingerprint” of the disk’s first blocks

HBoot (rootedcon/HBoot) is a small script that reads the first blocks of a disk, computes a hash, and compares it on every boot. If the hash changes, it raises an alert—a cheap, early signal of potential boot tampering (MBR/GRUB/first sectors).

It doesn’t replace Secure Boot, TPM/measured boot, or a full trust chain, but it’s a practical canary for labs, kiosks, critical workstations, or red-team scenarios where “paranoia is a feature”.

---

What problem does it solve?

An attacker with physical or low-level access can inject code into the first sectors (MBR/EFI/GRUB) to persist before the OS loads. HBoot simply photographs that area (N initial blocks) and warns you if the photo no longer matches the original.

Philosophy: “we’re paranoid about boot hijacking; what’s the simplest way to spot it?”

---

How it works (1-minute version)

1. Pick the device that holds the boot code (e.g. /dev/sda, /dev/nvme0n1).
2. Read N blocks of fixed size (default: sector_size=1024, sector_count=10).
3. Compute a hash (default: sha512).
4. Save/compare against a sentinel file at SENTINEL_SIGNATURE_FILE (default: /etc/sentinel.sig).
5. If different → SENTINEL-KO (exit -1). If identical → SENTINEL-OK (exit 0).

You decide the reaction: turn the wallpaper red, pop up a warning, cut network, shut down, or ping your SIEM/webhook.

---

Key configuration variables

Variable	Example	Meaning
boot_device	/dev/sda	Disk to read the leading blocks from (NVMe: /dev/nvme0n1)
sector_size	1024	Block size in bytes (512/1024/4096 depending on HW)
sector_count	10	Number of blocks to read. 10×1024 = 10 KiB
SENTINEL_SIGNATURE_FILE	/etc/sentinel.sig	Where the “good” signature is stored
ALGORITHM	sha512	Hash algorithm (ensure your OpenSSL/hashlib supports it)

Tip: On UEFI/GPT systems, consider reading more than 10 KiB (e.g., 2 MiB: sector_size=4096, sector_count=512) to cover gaps where some bootkits hide. Validate against your partition layout.

---

Installation & first “seal”

1. Download the script from GitHub and place it at /usr/local/sbin/hboot.
2. Make it executable: sudo install -m 0755 hboot /usr/local/sbin/hboot
3. Edit variables at the script’s header (boot_device, sector_size, …).
4. Create the baseline signature (from a clean/verified state): sudo /usr/local/sbin/hboot --init # or the script’s “seal” mode # Expect SENTINEL-OK and /etc/sentinel.sig to be created
5. Sanity-check detection: sudo mv /etc/sentinel.sig /etc/sentinel.sig.bak sudo /usr/local/sbin/hboot; echo $? # Should print SENTINEL-KO and exit -1 sudo mv /etc/sentinel.sig.bak /etc/sentinel.sig

Note: Legitimate changes to GRUB, firmware, or partition tables may alter the first blocks. After verified maintenance, re-seal the signature.

---

Run at boot

Quick way: rc.local

Append to /etc/rc.local:

/usr/local/sbin/hboot || /usr/local/sbin/hboot-alert
exit 0
Code language: JavaScript (javascript)

Example hboot-alert:

#!/bin/sh
# Red GNOME wallpaper
gsettings set org.gnome.desktop.background picture-uri 'file:///usr/share/backgrounds/red.jpg'
# Popup
zenity --error --text="BOOT WARNING: Signature changed!"
# Optional: cut network
# nmcli networking off
# Log
logger -p auth.alert "HBoot: SENTINEL-KO on $(hostname)"
Code language: PHP (php)

Preferred: systemd unit

/etc/systemd/system/hboot.service:

[Unit]
Description=HBoot boot integrity check
DefaultDependencies=no
After=local-fs.target
Before=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/hboot
ExecStartPost=/bin/sh -c '[ "$$?" -eq 0 ] || /usr/local/sbin/hboot-alert'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Code language: JavaScript (javascript)

Enable:

sudo systemctl daemon-reload
sudo systemctl enable --now hboot.service
Code language: CSS (css)

---

UEFI notes (ESP)

On UEFI, boot code lives in the EFI System Partition (ESP), typically /boot/efi. The disk’s first blocks may not change if the attacker only swaps EFI files. Options:

1. Read more leading blocks (1–2 MiB) to cover boot gaps.
2. Hash the ESP as well: monitor critical EFI files (/boot/efi/EFI/*/*.efi).
3. Hash MBR + GPT headers and, in parallel, hash /boot and /boot/efi based on a whitelist.

HBoot is intentionally minimal. For deeper UEFI coverage, pair it with file integrity (AIDE/IMA) or TPM PCR measurements.

---

Limits & good practices

• Not a trust chain: HBoot detects, it doesn’t prevent. It doesn’t replace Secure Boot, measured boot, or BitLocker/LUKS with TPM.
• False positives: GRUB/firmware updates or partition changes will alter the signature—plan a re-seal procedure.
• Which disk? On RAID/NVMe hosts, hash the actual boot disk and document mapping (lsblk, efibootmgr, grub-install -v).
• Logging/SIEM: log via logger and, if needed, send a webhook to your alerting pipeline.
• Full-disk encryption: with LUKS, the header sits at the beginning of the encrypted partition, not necessarily LBA0—decide to hash disk or partition.

---

DIY equivalent (no script)

# Read 2 MiB (4096 B × 512 blocks) from /dev/sda and compute SHA-512
sudo dd if=/dev/sda bs=4096 count=512 status=none | sha512sum > /etc/sentinel.sig

# Later, compare on boot
sudo dd if=/dev/sda bs=4096 count=512 status=none | sha512sum | diff -q - /etc/sentinel.sig \
  && echo "SENTINEL-OK" || echo "SENTINEL-KO"
Code language: PHP (php)

---

Incident response (when SENTINEL-KO fires)

1. Isolate the host (pull network).
2. Do not reboot before collecting evidence: image the first MiB(s), copy /boot and /boot/efi.
3. Compare against previous signatures and planned changes.
4. If unexplained, forensics: live boot, clone, analyze.
5. Reinstall/repair bootloader (GRUB/EFI) from a trusted medium; re-seal once integrity is verified.

---

FAQ

Is 10 × 1 KiB enough?
Maybe for classic MBR. On UEFI/GPT, increase coverage (1–2 MiB) or also hash EFI files.

Other hash algorithms (SHA-256/Blake2)?
Yes, if supported by your OpenSSL/hashlib. Adjust ALGORITHM and verify availability (openssl dgst -help, Python’s hashlib.algorithms_available).

NVMe devices?
Use /dev/nvme0n1 (disk, not partition like /dev/nvme0n1p1) if you want the whole-disk leading blocks.

False negatives?
If the attacker only touches the ESP (EFI files) and not the first blocks you hash, HBoot won’t see it. That’s why we recommend wider coverage or combining with file integrity/TPM.

---

Bottom line

HBoot is a small, understandable, effective sensor for the most critical phase of your system: boot. It’s not a silver bullet, but in minutes you can add a cheap, early-warning layer that shouts when something changed where it shouldn’t. For anyone serious about boot integrity, it’s a quick yes.