this will work on BIOs systems and possibly systems with CSM mode which emulate legacy BIOS in efi.
UEFi has a different interface, not IVT to make BIOS calls and no code to catch them. you would use raw disk access protocols its really easy maybe even easier once u know how to use handles and protocols in uefi to implement this for uefi.
the problem then becomes secureboot, which if enabled will be bypassable only via misconfigurations or exploits. it would refuse to from the usb or an alternate disk image when set up correctly and no exploits are known by the dumper.
for that reason there's i think attacks that can be done by removing the ram sticks and sticking them into specialized device to dump it.
theres some tutorials on how to connect ram sticks to breadboards etc. , but idk if theres other details besides raw talking to the ram and dumping it that would make it less reliable. (not sure how long bits are retained, usually ud wanna reboot and instant dump afaik if its totally off for a while its unrecoverable but i am not really sure on that last part. (so removing it to seat them in another device might make bits decay and data less reliable?)
Spot on! That is exactly why I chose the legacy 16-bit method via CSM. It was a deliberate design choice to completely avoid the EFI bootloader and, consequently, bypass Secure Boot entirely.
By relying on Legacy BIOS, the system doesn't check for signed EFI binaries or block the custom boot drive. It drops directly into the 16-bit real mode, allowing me to do the job without dealing with UEFI handles, protocols, or security restrictions. It essentially eliminates the need for any exploits or moving physical RAM sticks to specialized breadboards!
P.S. I'm using AI to translate my messages because I don't speak English. Hope my point is clear!
You are absolutely correct, and I highly appreciate the clarification! I definitely misspoke in my previous comment.
CSM doesn't magically bypass an active Secure Boot state. Rather, to even boot via CSM, Secure Boot typically must be disabled in the firmware settings beforehand. What I really meant is that by targeting Legacy/CSM, I bypassed the development requirement of writing an EFI application, dealing with complex UEFI protocols, or figuring out how to get a payload signed.
You are also completely right about the initialization sequence. UEFI still runs first (SEC/PEI/DXE phases) and touches RAM before the CSM hands control over to my MBR payload. My 16-bit approach mostly just helps minimize any additional memory clobbering that a more complex, modern UEFI bootloader environment might introduce.
Anyway, to get access to RAM before it is clobbered by other software, you need to run your code really really early. By the time the BIOS has decided to let you run code from a USB stick, it could be way too late.
RAID cards have option ROM that can run before a bootloader has started, that is one way to get something running earlier.
UEFi has a different interface, not IVT to make BIOS calls and no code to catch them. you would use raw disk access protocols its really easy maybe even easier once u know how to use handles and protocols in uefi to implement this for uefi.
the problem then becomes secureboot, which if enabled will be bypassable only via misconfigurations or exploits. it would refuse to from the usb or an alternate disk image when set up correctly and no exploits are known by the dumper.
for that reason there's i think attacks that can be done by removing the ram sticks and sticking them into specialized device to dump it.
theres some tutorials on how to connect ram sticks to breadboards etc. , but idk if theres other details besides raw talking to the ram and dumping it that would make it less reliable. (not sure how long bits are retained, usually ud wanna reboot and instant dump afaik if its totally off for a while its unrecoverable but i am not really sure on that last part. (so removing it to seat them in another device might make bits decay and data less reliable?)