UEFI-Editor VS IFRExtractor-RS

For all other use cases, here are the couple of steps missing for unlocking a BIOS: https://github.com/BoringBoredom/UEFI-Editor

I’m not sure exactly what you mean, like do you want to change hidden bios settings? Bios modding can be risky unless you can roll back bios or have multiple bioses or some sort of feature that can help you “unbrick” if your goal is to change hidden settinfs use this method which is known as “grub” it’s much less risky and iirc if you brick with grub the only thing you need to do is clear cmos(Yes i’ve used this method and yes it works) https://github.com/BoringBoredom/IFR-Formatter

>this makes your machine once and always pwned.

Well, no, it doesn't, but that's besides the point.

These specific image decoding bugs are indeed a bit of a nothingburger in terms of the implications they give rise to. There's just no reason to overwrite the boot logo graphic and leverage these exploits if another (simpler) method of achieving the same end result exists, and often it does.

For example, many systems to this day are shipped in a configuration such that you can disable write protections for certain ranges (or all) of the SPI EEPROM on which the firmware resides simply by changing some NVRAM variables (typically the variables correspond to (often hidden) 'BIOS settings' in common firmwares such as those from AMI or Phoenix), after which you can write contents of your choosing (eg. using Intel FPT) to the chip which will promptly be executed without any checks upon the next restart. This is by design, not even abusing any exploit or flaw in the software (of which there are plenty). If you want you can try it out on some of your own systems, for instance dump the firmware, extract (for example) the AMI setup menu form and simply run it through something like LongSoft's IFRExtractor[1] to locate the regions and offsets of said NVRAM variables, then try writing to them. It is true that the NVRAM regions for these settings (and others) are sometimes write protected or locked in such a way that you can't overwrite them after the firmware has started another program (eg. your bootloader), but often there are even ways around that. It's clear that firmware security is not always much of a concern for a surprising number of vendors currently shipping computer systems / motherboards today.

[1]: https://github.com/LongSoft/IFRExtractor-RS

Download the last release of https://github.com/LongSoft/IFRExtractor-RS/releases for example ifrextractor_v1.5.1_Windows.zip and extract it