3 ms·
IIUC There are two vectors: 1. Logos in EFI binaries (OS, bootloader, shell, etc), not the UEFI firmware logo itself. For these, "bake it into the firmware" is
by Arnavion 3y ago
IIUC There are two vectors:
1. Logos in EFI binaries (OS, bootloader, shell, etc), not the UEFI firmware logo itself. For these, "bake it into the firmware" is not relevant because these are just files that anything, such as malware, can drop into the ESP.
2. The UEFI firmware logo itself. This would only be updated by firmware updates, which ought to be signed, but apparently these vendors put the logo in non-signed sections, so malware could edit a pending update to use a malicious image.
- tadfisher 3y agoLenovo ships the standard Phoenix shell app named ShellFlash.efi (which calls itself ShellFlash64). One of its CLI flags is to flash the UEFI logo. The Lenovo BIOS package includes instructions to update the logo by dropping the image file in the ESP where their updater (BootX64.efi) can find it. So flashing unsigned logo images is supported and intended behavior here.
- jeroenhd 3y agoFrom what I can tell by the demo video, the Windows process seems to be injecting the bitmap before calling a reboot without calling into the flash utility. I wish I could put up a nice customised image without having to mess with firmware files. It's kind of stupid to include a logo feature but then to remove the image file every time you install an UEFI firmware update.
- p_l 3y agoUEFI update protocols have a variant where you store the update Capsule in memory, mark it so that it's not overwritten on reboot and picked up by update handler during boot. The same protocols are afaik used by the bootable updaters (there are IIRC three ways to pass the update capsule to flasher that is actually part of the firmware)
- jeroenhd 3y agoI see, that would explain how they managed to flash the image file without writing to the ESP. That would also bypass naive detection mechanisms for antivirus solutions.