Award BIOS Code Injection

Hacking the bios is apparently easier than some would have you believe.

Prerequisites aside, x86 assembly language programming skills, it's frightening.

But what about the checksums?

Article

Between these two articles I've linked to, it's possible to maintain a persistance on a machine through Expansion ROM using the Pre Execution Environment and alter the users experience by hacking the bios and installing whatever you want to boot up. Ideally, this would be a baremetal VM that wouldn't leave any marks in the guest OS.

 

Hmmm .... no.

OK, so you can jump between code instructions. And? It's not as if there's tons of GB space in Bios to write line after line of code.

You would need a partition somewhere or something alike, where a hidden operating system might reside - and this one would be launching the OS virtualized (a la openvz or such). But to do this:

1. Need to get infected.
2. The infection has to be smart enough to create its own working environment, be able to virtualize entire OS (unknown) on a specific hardware (unknown) - and this without any changes in functionality, like graphic drivers, physical access to hardware etc.
3. The infection should be able to write to bios - successfully, including limited space, unknown version of bios, and 50% chance that bios reflash is going to fail as it usually does.

Disinfection - reflash bios again ...

Hidden code? Delete partition table and it's gone.

The only way would be to write to storage that users do not normally access or format, which would be peripherals, which is simply sci-fi without special pinpoint targeting of the specific machine, with specific hardware and OS.

Bare-metal Linux kernel is 8MB, now add to this drivers for every possible OS and hardware platform. I'll be generous, 10MB. Where are you gonna store this HUGE thing? And believe me, 10MB is an understatement and 10MB for onboard devices is like 100TB for your hard drive. And I've been extremely generous in driver / platform / os addition. It would be more like 100-200MB at least to work with most common names.

Writing to fancy-named thingies (eprom, cmos etc) is not viable or possible given the needed space requirements. These devices are tiny. And so is just about any other peripheral.

Write to DVD-ROM? Sure. Just don't expect it to work, since you just killed the firmware, oh-oh. And so forth.

Undetectable? Maybe. Virtualization that grants 100% transparency is called native installation. So, careful tracing of system calls, clock etc would show discrepancies.

All in all, you depend on so many factors, some that even do not exist, to make this work:

Successful execution of malware.
Successful creation of hidden storage OR use of onboard devices, without breaking their functionality, using the tiny space available.
Successful application of "virtualization" package to specific hw / ws.
Successful flashing of bios (and other devices).
Successful launching and control of os, without breaking functionality.

On top of all that:

Skills required: very high.
Prevention: easy, lock or reflash bios.
Space available: close to nil.
Ability to flash bios / devices: extremely risky and difficult.
Ability to make changes to hardware, hard disk layout, os kernel etc without breaking functionality: extremely risky and difficult.
Implementation: terribly convoluted, with low chance of success.
Financial gain: minimal compared to standard channels (simple malware, social engineering etc).

All combined: nice story for Matrix fans ...

Need I go on?

Mrk

 

There are three areas of importance for persistence.
The BIOS, the PXE ROM tied to the BIOS and the PXE ROM tied to the NIC.

Does flashing the BIOS also flash the PXE ROM tied to the BIOS?

What does flashing the BIOS do to the NICs PXE ROM?
Nothing, but you knew that.

If flashing the BIOS doesn't touch the PXE ROM connected to it, then you have a minimum of three flashing procedures to free yourself of any subversion in these areas.

It may require more indepth procedures if some one has changed the physical drives size reserving a raw space at the end for whatever it could be used for.

With a compromised or replaced PXE ROM, you have access to the client any time you want. You could even boot from image over the internet if the computer is always connected. How about switching mid stream to a network image?

The BIOS is just one place. Fixing that alone doesn't address all potential problems.

If all of these are fixed, then all you have to worry about is normal malware infections.

Merry Christmas Mark, don't drink too much Eggnog.

 

Okay..i am not of the same expertise level here but,wouldn't just limiting the BIOS user rights and adding a password simply kick out all those stuff?Except if you come up with a theory for BIOS brute forcers

 

It has already been pushed to the consumer as the actual hardware builds become standard and the norm for rooted boxes. Even building your own rig won't keep you from being rooted since the parts you-re only going to be able to get is already rigged so soon.......

 

Sooner or later we will see BIOS rootkits. But I think the protection wouyd be easier, just adding a physical protection like a jumper for the mobo that needs to be manually removed before BIOS update by the user.

 

The protection exists even now.

And you won't see bios rootkits unless bioses become huge storage monsters. The way they are made now - minimalistic bootloaders to allow launching of primary operating systems, it won't happen.

The largest bioses today are approx. 8MB - and this space is USED.

To get things into perspective, most basic Linux kernel is 8MB. You can get dos and such in less than that, but it won't be able to recognize any modern hardware. With minimal 'modernistic' hardware drivers, plus some functional software that actually does something, the pure "bad" code would have to be quite big - 15-20MB at least. So ...

And a bit from Wikipedia:

Mrk

 

You got your protection answer right here..

 

As to protection, I was talking about physical one on modern mobos.

The reference was about the one actual piece of malware that tried to do something remotely similar to what we're discussing here.

Indeed, you need to install something that hooks into the kernel, subverts its completely, mess up the drives, flashes the peripherals, lets everything continue working normally - and writes to bios ... I'm just wondering about one thing: if you can subvert the kernel so nicely, why bother writing to bios ...?

Mrk

 

Besides, FLASHROM will expand based on BIOS size needs. So even if BIOS someday requires 50MB of space, it will be entirelly filled with BIOS code anyway.

 

I have a 4mb bios and yet my bios file is only 1024kb. If my bios is completely filled, what is in the other 3mb of space?

 

If your motherboard is a new model (at least the later asus ones) have space reserved for overclocking profiles..could be that,could be not.

 

Actually those are 8Mbit not 8MB...

 

Making a BIOS rootkit is a VERY HARD TASK indeed. But, from my experience adding my own code into the BIOS, I think it's not impossible.

Ok, it's not possible to write the entire rootkit in the flashrom chip. But, some might be able to squeeze enough "precursor" code for a rootkit. I haven't researched how big the latest BIOS flashrom chips are. But, it should be around 8Mbit (1MByte) or 16Mbit (2MByte). There are free spaces in these
chips. Typically between 10KByte - 100KB, some BIOS has more space.
This happens because the BIOS components are compressed. The plain binary contains only very minimal initialization code and rescue code (when you made a bad flash -- not all bad flash can be rescued though).

It's very unfortunate that I cannot talk too much about the current state due to NDA, because most of the latest BIOS reverse engineering and code injection techniques I've researched is written in a book that I wrote a while ago.

The weakest point is the expansion ROM (which can be part of the motherboard BIOS or standalone in a PCI Expansion Card) because the mainboard BIOS only carry-out a simple checksum check into it.
Moreover, I have yet to find a PCI expansion card with a physical
flashrom protection .

The bad news is it's a bit more hard to flash an altered PCI expansion ROM binary into PCI expansion ROM in a standalone card compared to flashing an altered PCI expansion ROM to an expansion ROM which exists as part of the mainboard BIOS (in motherboards with integrated LAN).

Anyway, for those interested in PCI expansion ROM technicalities, this is what you can do with it .

Perhaps, it's very hard to alter the BIOS in the past. It's not getting easier in anyway, but people today are more informed. It's not a "blackbox" like it used to be.


PS:
-> Well, perhaps it's my mistake to release even the slightest BIOS reverse engineering information to the public back then. But, the reason I release it not for "the bad guys" to make use of it in the first place. There are other communities out there (that I'm still a part of) that need it: the overclockers. It's very natural for overclockers to modify their BIOS to achieve better performance and higher top speed. The BIOS reverse engineering article I made public is part of an attempt to improve the memory system performance of my system few years ago.

-> Happy new year

 

Even though if it's possible in a very limited case, it's useless for real world practical non targeted "generic" attacks. Too many combinations, too many things that can go wrong...

 

Yes, it's entirely true in my opinion. BIOS rootkit is only possible for very specific targeted attacks. It's unlike more "generic" attacks which prefer more "zombie PCs" to be acquired after the attacks. Perhaps, only millitary-inclined "bad guy" who will be interested.
For "bad guy" building botnet network, this type of rootkit is not particularly interesting. Because in that case, the number of PC acquired after the attack is much more important than the ability of the botnet PCs to withstand OS changes, etc.

 

Do I open myself up to a targeted attack of this kind by posting computer specifications in signatures, by posting some diagnostic reports in a public manner or listing softwares that I rely on on a daily basis?

@pinczakko
How can I find all accessible Expansion ROM? Is there a discovery tool?
I know at Rootkit.com there is a prog that reveals all flash locations on motherboards, but haven't seen it, didn't DL it.
In using rtflash, I guess flashing with .lom is for boards with lan on motherboards. .nic would be for addin cards. Am I correct?

Will reflashing the BIOS solve all possible corrupt PXE ROMs on the motherboard?

I have a laptop so it's not possible for me to just swap components if there is a data corruption.
On this laptop something wrote 5100 sectors to a freshly wiped drive while surfing with a LiveCD.

 

Old hats surely have these skills, we talk about people who are there from the beginning likely 15-20 years in bizz probably even longer. Prevention: difficult, most boards don´t have a bios lock. Financial gain not important for e.g. targeted attacks and secret organizations.

In vain, imo. Bios easy to reset I think only few lines in asm also masterpasses will make biospass useless.

Interesting to see you here, welcome, I heard from you at sysinternals.

The baddie could be implemented from the beginning, when you buy a new computer, e.g. in oa of cmos.
BTW I noticed most problems with Award PG 6.0 Bios from Phoenix. IT seems they never really changed much in bios code since 1999. So prepared bios rootkit could work for all awards but I think pinczakko is the specialist for this bios maybe he can explain more about.

Interesting, related to this I have a problem with Award PG 6.0. I overclock my cpu 30% it works until I set the system into sleep mode or shut it off. If I then restart the system it needs three attempts to restart the computer until it resets the original dualbios defaults with normal speed, I assume it has something to do with S-Ata, I didn´t noticed this problem with P-Ata, any idea to get a stable cold boot with the oc´d system and S-Ata hd? Sometimes it also happens that the computer ends up in a endless on and off loop until I turn the power off and make a new cold boot.

 

Award and Gigabyte not soo specific, I think your Rootkit Icelord is built for these reasons.

 

Are they separate items, BIOS and Expansion ROM?

If I flash the BIOS is the PXE ROM and PCI ROM also flashed on the MB/integrated LAN?

 

Well, a complete computer specification can be a nightmare if you post it online, unless the system you mentioned is physically disconnected from the net. If it's connected then we'll never know whether it has rootkit or not. If it has rootkit, then the owner of the rootkit can "elevate" to trying firmware level "rootkit"/rootkit "precursor".

It's also possible that it's not a nightmare suppose that the chipset datasheet for the specific mainboard is not available somewhere on the net. However, this is not always the case. Back in 2000, the VIA693A which is used in my test system has no official datasheet released by VIA. I try to obtain it from them but they refused to let it out unless you are a buyer of 10K quantities or more. However, I found it in the wild on the net. Someone must've hacked into VIA's network. I don't know who, but I found the datasheet. So, better be careful.

In windows, it's quite easy because you can just look at the memory map of your system. I believe it must be somewhere in the Device Manager. There's something called I/O map/range or something like that and also there is a Memory-Mapped I/O range and so, and so. I don't use Windows anymore these last 3 years. So, I forgot the details. Among the areas claimed by a device, there's sometimes a space for flash ROMs. SiSoftSandra can also help to find them if you are using Windows. As for Linux, well, lspci and friends could help.

Yes, I think so. As long as the PXE ROMs are part of the motherboard BIOS. Which is mostly the case for laptops.

To be sure, inspect the content of your laptop's BIOS. It's not trivial, but you might be able to do that.

 

The motherboard BIOS and the PCI Expansion ROM are logically separate items. However, PCI Expansion ROM can be integrated into the motherboard BIOS, but it can be placed in a flash ROM chip in a PCI card as well. It depends on the system configuration.

Why is that?
PCI Expansion ROM is meant to initialize the PCI/PCI-Express chip.
If the chip in question is soldered to the motherboard, the PCI Expansion ROM will be integrated into the mainboard BIOS.
If the chip in question is soldered to a PCI/PCI-Express card, then the
PCI Expansion ROM will placed in a flash ROM in the PCI/PCI-Express
card.


These days, the Expansion ROM, particularly PCI Expansion ROM for on-board NIC are integrated into the mainboard BIOS.

http://en.wikipedia.org/wiki/Expansion_ROM

 

with the "right" device driver, you can change the BIOS password or scramble the CMOS, forcing a default value on next boot in Windows, or Linux or whatever OS you know how to make a device driver for.

Someone directed me here he..he..he..

Well, actually the core code of the BIOS hasn't changed that much. There are still relics of code from the IBM PC AT in Award BIOS codes! As for code from 1999, I believe that's true because all Award PG v6.0 BIOS has the same basic structure.
However, inserting the core code of the BIOS (the so called system BIOS code) remains a black-art. If you miss something badly, the system won't boot. And also, it's quite hard to find the right BIOS modification tool these days. But, I believe it's probably somewhere on the net.
I imagine a scenario, with enough prolific programmers, say ten or more. One can build their own BIOS modification tool for certain very well known BIOS variants.
Well, I can say it's possible because back in the day, people who work on BIOS are very scarce. Yet, they can still make tools to modify some parts of it.
Also, very good disassembler such as IDA Pro can automate much of the mundane tasks. I'm just not experienced enough in IDA Pro to do that back then.

The system might fail because it cannot handle the boot interrupt correctly for SATA hard drives when the clock is changed. I'm not sure. But, I think the BIOS probably cannot handle that huge change in frequency due to some routine running too fast. Say, a delay in the BIOS routine which depends on a counter in the processor. Maybe there's this kind of thing in your motherboard BIOS. But, I'm not sure.

 

I thought so.

BTW, I figured out that this also happens with IDE. Yes a delay, I notice this delay but the strange thing is when I set computer into sleep mode it is never sure if he wakes up or end up in a bios-loop with black screen.
I can say that the chances are high the longer the oc´d system whiles in sleep mode the higher the probability that system ends up in a bios-loop instead of waking up normally. I use Auto-OC mode, only fsb changed manually.
Maybe you could also explain the click or clack init sound if I turn on the computer, what is the reason for this clack? Cmos, Bios or is the harddisk responsible? It sounds like locking or unlocking of something.