40hz: you don't need the user to do anything - it's not like the idea is to create an infected image and have the user flash that to his BIOS.
Instead, you use whatever traditional infection vector that gives you admin/root privileges. From there, you a drive (Windows) or LKM (Linux) to go kernel-mode/ring0, from where you have full access and can re-flash the BIOS.
The flashing process is going to be chipset-specific, but how much I don't know - I would assume that there's a couple of standard flash controllers, so you don't have to support a lot of different ones. Whether the type of controller can be auto-detected I don't know either. This is one part of the challenge.
The second part of the challenge is finding a "bios cave" to hide your malware in. This is probably easier than it sounds, though - scan the BIOS space for an appropriately large block of zeroes. From what I remember about BIOS initialization sequences, BIOSes will at boottime scan their memory image at <some kilobytes> boundaries looking for a magic identifier. When such a magic identifier is found, and a checksum after the chunk matches, an entry-point in the chunk is called; this is used for BIOS extensions, and you can think of this type of malware as, well, a BIOS extension. The tricky part here is exploiting the system in a way that doesn't interfere with chipset setup and such, but it's probably doable doing this relatively generically.
AFAIK there hasn't been any malware/rootkits doing this before, the closest was the CIH virus which would simply erase your BIOS... which is of course bad enough. Many BIOSes these days have "flash protection", but I'm not sure how well that works - does it disable the flash controller, and can it be re-enabled by software without a reset cycle? (certain CPU features like hypervisor support can be disabled, and once disabled requires a reset cycle to be re-enabled... should be possible to use the same design for flash controllers, but is it done that way?)
