OSDev.org

Note: I'm not sure if this should go here or in "General Programming".

I've been reading a lot about CIH and how it was one of the few known virus strains to overwrite the BIOS ROM with junk, rendering said computer useless without a reflash. I read the source code and it seems like the way it works is:

• Get ring 0 by modifying the IDT & causing an exception
• Inject into other PE files
• Overwrite BIOS EEPROM from 0x000E0000 to 0x000E007F

I also read the following:

Most modern ones sure, but many moons ago it was a coin toss whether you could update the firmware without physically replacing a chip. (yeah I'm old, talking 286/386/486 here)

Well designed computers require moving a physical jumper or motherboard switch and or a cryptographically signed firmware update.

Since most BIOSes back then were made by a few brands, and BIOS security wasn't much of a concern, writing something like CIH would work on a majority of computers. This also goes back to the quote about updating firmware without physically replacing a chip.

Assuming most computers are "well designed", then how does most firmware upgrades / BIOS flashing work? Wouldn't it be insecure if someone who had arbitrary ring 0 access, i.e. from a driver, to repurpose that driver to overwrite BIOS? Additionally, does the BIOS not have any security features in place to prevent someone from writing?

I know that there's so many different BIOS manufacturers and that there are a ton of different BIOS firmware providers, so writing CIH in the modern age would require a load of different routines for different firmware, and it'd be super tedious to do. Thanks in advance!

On modern PCs, only the firmware is allowed to write to the flash ROM. The chipset enforces write-protection and won't unlock unless the CPU is running in SMM (for the portion of the ROM containing NVRAM variables) or the whole PC reboots (for the rest of the ROM).

To perform an upgrade, you load the upgrade into RAM, update the NVRAM variables to point to it, and reboot. The firmware then verifies the cryptographic signature of your upgrade, and if it passes, the upgrade is written to the flash ROM.

A modern CIH would be extremely difficult, and any success would be short-lived since PC manufacturers would push fixes through Windows Update.

Octocontrabass wrote: ↑Thu Feb 06, 2025 5:26 pm On modern PCs, only the firmware is allowed to write to the flash ROM. The chipset enforces write-protection and won't unlock unless the CPU is running in SMM (for the portion of the ROM containing NVRAM variables) or the whole PC reboots (for the rest of the ROM).

To perform an upgrade, you load the upgrade into RAM, update the NVRAM variables to point to it, and reboot. The firmware then verifies the cryptographic signature of your upgrade, and if it passes, the upgrade is written to the flash ROM.

I was under the impression that some ring 0 process can write to BIOS ROM. I'm guessing the firmware has some lookup table from known firmware manufacturers (like American Megatrends(?)) and looks up the provided crypotgraphic signature in said table, if they match, then proceed, else, don't proceed.

I can see how it's more secure, as to prevent unsigned BIOS ROM to be flashed.

avcado wrote: ↑Thu Feb 06, 2025 6:26 pmI'm guessing the firmware has some lookup table from known firmware manufacturers (like American Megatrends(?)) and looks up the provided crypotgraphic signature in said table, if they match, then proceed, else, don't proceed.

Firmware upgrades are signed by the hardware manufacturer, not the firmware vendor.

Octocontrabass wrote: ↑Thu Feb 06, 2025 5:26 pm On modern PCs, only the firmware is allowed to write to the flash ROM. The chipset enforces write-protection and won't unlock unless the CPU is running in SMM (for the portion of the ROM containing NVRAM variables) or the whole PC reboots (for the rest of the ROM).

Maybe the issue is how to get into SMM mode and setup your own SMM handler? Perhaps this can be done in the AP core bootstrap?

Given that SMM code can be pretty fatal for real-time performance, disabling all kinds of virtualizations would be a benefit.

rdos wrote: ↑Sat Feb 08, 2025 10:19 amMaybe the issue is how to get into SMM mode and setup your own SMM handler?

You would have to exploit a bug in the firmware (or hardware) to do this. Such bugs are not unheard of, but they should mostly be fixed by now.

rdos wrote: ↑Sat Feb 08, 2025 10:19 amPerhaps this can be done in the AP core bootstrap?

Assuming the firmware isn't buggy, SMM will already be configured and locked on the APs before you can run any code on them.