Putting an image parser in the first stage of boot seems like a mistake in the first place tbh. Surely you could skip that and just bake the decoded image into the firmware? Or is this all so vendors can rebrand their BIOS without having to rebuild and sign it?
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.
Lenovo 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.
From 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.
UEFI 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)
I 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.
