The badBIOS Analysis Is Wrong.

NOTE2: Holy crap lots of comments and I find out that the comment setup isn’t threading them properly so it’s a BEAR to try and make sense of. I am truly and terribly sorry about that. Talk about counter-productive to a conversation! Trying to see if there’s some way to fix this.

NOTE: Approving comments as I get time. If I didn’t do it yet, I just haven’t gotten to it. If I don’t approve yours, it’s either because A) you made it clear you didn’t read or have no clue what you’re talking about, and therefore detract from the conversation or B) you’re trolling / blindly defending / blindly attacking to derail the conversation. In either case, rebutting basic ignorance of technology, complete lack of reading comprehension or someone just being an ass is a waste of everyone’s time. Including your own.

Look, I’m not known for pulling punches and I’m not about to start now. The fact is that everything I have read about #badBIOS is completely and utterly wrong; from the supposed “escaping air gap” to well.. everything. And I should know. I’ve dealt with malicious BIOS and firmware loads in the past. I’ve also dealt with BIOS development and modification for two decades. It’s a very important skill to have when you regularly build systems that are well outside manufacturer ‘recommended’ areas.

The whole of the analysis would be laughable if people weren’t actually taking it seriously and believing it because they’ve seen edge cases or very specific examples. And the result is that they’re looking in the wrong place.

First and foremost, the very idea that there is some malicious BIOS load that can escape airgapping and is portable is beyond laughable. I don’t care what you think you know – BIOS code is not portable, period. Oh, sure, you can have a common source for multiple motherboards. But every single model, revision and minor version requires you to recompile UEFI elements best case. That’s before you get into changes to UEFI libraries and shells.


AMI MMTool Screenshot

Secondly, the concept that BIOS malware could somehow escape detection is beyond laughable. Look. I’ve been doing BIOS work for ages and then some. I can and would spot any malicious load pretty much instantly even before flashing a board. Certainly I would have no trouble finding it from a ROM dump. Period.

When I open a BIOS dump in American Megatrend’s MMTool (this is for Aptio V, their UEFI product,) I can not only see but extract every single executable element of the BIOS. That includes CPU microcode, Ethernet Option ROMs, sound hardware firmware, you get the idea. A simple comparison instantly exposes modifications to almost any element. This is not a ‘freely available’ tool, but a bit of searching will easily get it in your hands.

Still not enough for you? Here’s a partially annotated report from MMTool. Notice something? Yeah. Firmware volumes are broken down into paged regions. This is an 8MB (64Mbit) AMI BIOS for a Gigabyte motherboard – which makes it one of the largest BIOSes on the market. Most UEFI motherboards are 4MB (32Mbit). There’s not exactly a lot of room – though I’ll be the first to say I’ve seen a lot more in a lot less. (Scene, ho!)

Here’s the point: any modification here is easily spotted, picked out, and disassembled. Attempting to encrypt anything here would render it so highly system specific that it would literally only work on one computer in the entire world (at least in theory) due to signature fail. And any time you modify any one of these elements, the non-accessible checksum region will alert you. “BIOS Checksum Error: Press F1 to continue, DEL to enter SETUP” is a dead giveaway.

AMI BCP Showing DMI TablesNot only that, but a BIOS is extremely extremely specific. This is code that operates at a level most people are completely incapable of conceptualizing these days. Literally, until you’re in the UEFI shell itself, your $1000 Xeon E5 is a ~2MHz 8086. Not figuratively – quite literally. It’s called real-mode and it’s part of why we have the atrocity that is UEFI.

Regardless, you’re still at an extreme level of specificity because you’re literally manipulating pins and wires alongside registers. You can’t just take an AMI ROMBIOS8 from one board and slap it on another. Yes, there’s a common core – that’s why we have AMI, Phoenix Technologies and used to have Award (plus Insyde as used by Sony/HP.) But to actually use that core requires extensive work to support the specific silicon and wiring used by a given motherboard. That information is always trade secret, and heavily protected.

This is what makes the belief that systems are air gapping with high frequency so utterly hilarious. First of all, yes, it is absolutely possible in theory and there have been proof of concepts using FPGAs and unshielded boards. ProTip: your laptop or desktop meets zero of these conditions period. First of all, to end up on your desk the system requires substantial EFI/RMI shielding which prevents transmission of said signals using voltage varying techniques. Secondly, manipulating said voltages requires running code which can only ever run on one extremely specific motherboard (not even multiple revisions) and is easily detected at 6+ different points before the fault inducing aspects nevermind the relatively low precision of a typical PC SMPS.

And the idea that someone could just release into the wild a multi-platform multi-motherboard highly resistant BIOS because of UEFI only exposes epic ignorance of what UEFI is. UEFI is NOT A DAMN PORTABLE EXECUTABLE SYSTEM. It is about PORTABLE CODE, and even that is fundamentally broken – Intel Tiano code will not run on Phoenix SecureCore will not run on Aptio V will not run on InsydeH2O without modifications. The end. Period. Actually running the code means building it against your target platform – the same as portable C. (Hey, funny how UEFI which uses C behaves just like portable C code, isn’t it? Siiiiiiigh.)

And the idea of it using the sound card to defeat airgapping is beyond hilariously wrong. PC Speaker != Realtek AC889. You have no audio input at the BIOS level because the MIC line even if present isn’t hooked or initalized. People quit wasting precious shadow RAM region on BIOS-level sound card initialization to play sounds around ’05 because it’s pointless and sucks. Oh, you think it does because it makes a “bong” over speakers? NOPE. That’s a soft hook to a GPIO-like soft-trigger in the audio codec’s firmware. Been done in laptops since the late 90’s. So the BIOS is NEVER listening to the microphone, and you don’t have a speaker capable of HFT anyway.

Look. Basic audio 101. A given element has a specified input/output range. Your typical laptop microphone has an input range of say 5,000Hz to 14,000Hz just as an example. Anything outside that range clips to uselessness or is ignored. Your typical laptop speakers are maybe 160Hz to 20,000Hz if you’re lucky. Again: you are SOL. Oh, and anything in that range would be audible too. High-frequency transmission requires that you have elements capable of transmitting externally at very high frequencies and elements capable of receiving at very high frequencies. Between those limitations and FCC mandated and required shielding from high frequency interference, there’s a reason every POC has required one or more unshielded elements.

Is it possible? Yes. In theory it is possible to release an extremely resilient and resistant BIOS level piece of malware. It also would only ever infect one specific machine ever, period. It also would not be even remotely capable of escaping detection using basic diagnostic techniques. Not even advanced security techniques; just basic BIOS diagnostics. Anyone who can follow a guide on updating the Intel RSTe OROM (about half the Internet) could compare dumps and instantly spot it.

So what do I think? I think that A) a number of security experts flapping their gums are good at security and know nothing about how hardware works and B) it’s absolutely not a BIOS/Firmware level piece of malware. There are far, far too many blatant and obvious detection points. There is no way it could hop from Apple to PC, or even PC to PC or Macbook 2013 to Macbook 2011. (Forget Macbook to Mac Pro.)

I’m not saying that UEFI or BIOS is secure – I’ll get to that in another post – but I am saying that calling it badBIOS is wrong.  It’s absolutely not. Either it is an extremely limited piece of BIOS malware or it is occurring at the OS and escaping detection through previously unknown methods. Half the claims made regarding what it does (disabling registry editing, etc.) are so far from reasonable and possible with the BIOS it makes me facepalm. Point blank, these things are absolutely not possible, period. This is something going on at the OS level, the end.

Leave a Reply

  1. Pingback: The BadBIOS Analysis is Wrong | Enjoying The Moment

  2. Pingback: The BadBIOS Analysis is Wrong | Rocketboom

  3. You’ve provided even more good reasons why BadBIOS is incorrect.

    I’d assumed that their “HF” nonsensical theory was about acoustical audio, nothing to do with FCC and Shielding and such. It’s utterly nutty either way. No concept about Hardware 101.

    Thank you.

  4. TL;DR is that CD-ROM/DVD-ROM/etc can be disabled in the OS. If they were being disabled in the BIOS, it would raise alarms. Whereas disabling it in the OS would make it possible to avoid any such alarms. There have been a few instances of ATAPI firmware bricking drives, but from bugs and not deliberate actions generally. (Or from unauthorized modifications.)
    It also wouldn’t be a viable delivery method. The ATAPI drive ROM is self-contained. It only provides the identifying string (e.g. “Optiarc DVD RW AD-7260S”.) The rest of it is entirely self-contained to prevent interaction bugs from doing bad things like ‘hey here’s all the wattage into the laser and oops the blank’s on fire!’

  5. Thanks for putting succinctly what I thought from reading the same article(s). No one invented magic that suddenly makes BIOS do things that BIOS can’t do.

  6. Phillip,

    Thank you for your thoughtful and professional post! I am EE with 30+ years of experience and know a thing (or two) about audio capabilities (heck designed a number of things that are used in laptops / cell phones today), RF and many other things. When I read the original “bad BIOS” post, I thought that either the author can use some help or that this is more like “Ancient Alien Astronauts” show… many strange claims thrown at you in rapid succession, some are remotely possible (within a lab setting and a lot of spare time to waste) but completely improbable in a real world. Then there were other posts from different types generally supporting this BS. And nobody seems to care that all this “hacker activities” that sounds so scary to the everyday Joe Blow – are completely meaningless and yes, useless to a real-world hacker. Why? Simply because the hackers do not want you to notice that they are there, in your machine for as long as possible. They do not want to damage your machine; once penetrated – it is precious to them, they will even defend it from another hackers. The idea of a malware that goes around disconnecting people’s CD ROMs, changing their software behavior in most noticeable ways… Why? Who? Not Govs or Corps (and they are the ones with the resources). Not any “for profit” hackers. So, the only ones that are left are the crazies – and these do not have neither resources or the attention span required for such an undertaking.

  7. Pingback: ste williams – Indestructible, badass rootkit BadBIOS: Is this IT’s Loch Ness Monster? VOTE NOW

  8. to add another nail in the “high-frequency audio” coffin, with input signals around 20khz you’ll start to run into whatever anti-aliasing lowpass is present in the audio codec, which will also vary somewhat from vendor to vendor. at 44100hz, your nyquist is 22050hz so on a cheap card (i.e. the embedded ones on motherboards) 20000hz is likely to already be in the transition band. you don’t have a lot of range to play with up there, because the edge of human hearing is generally where a manufacturer will put their filter.

  9. Thank you for your explanation, the badBIOS article seemed very suspicious to me.

    Regarding the disabling the registry thing, it could somehow write data to the hard drive, and create an executable in the operating system. It could just rewrite important libraries and root the system… but why would it disable the registry, when it could simply change the Windows API to hide a few keys? Disabling the registry is pretty lame for such a sophisticated piece of engineering.

    • Theoretically? Yes.
      In practice? No. The BIOS, including UEFI elements, have a very limited understanding of what’s on the disk, even before matters like Intel RSTe, secure boot, etcetera. What it understands is “write blocks as the OS dictates.” In the case of UEFI, Aptio V only handles FAT32 without the full shell. So you’d basically be trying to write bits with a magnetized needle with a blindfold on, or you’d be writing a run of the mill GPT Boot Sector virus. (MBR viruses, not new.) The whole registry claim I’ve read just.. does not ring at all possible. I don’t know very much malware that does that, and all it does is change keys to SYSTEM owner – and it’s all been unsophisticated drive-by crap.

  10. Best analysis of this that I’ve seen and I agree with all of it.

    The high-frequency audio thing especially seems strange – what would be the purpose of it? Not to mention, what would be the range of it? I couldn’t imagine HF audio escaping a PC case. Maybe, maybe a laptop, but still unlikely.

    There are loads of inconsistencies in that story. It’s just too fishy. Hopefully it’s just over-analysis and not a case of a beautiful mind.

  11. Pingback: badBIOS Malware

    • Unfortunately, I do not – this was a good 16, 17 years ago so even if I kept the floppies, probably corrupted beyond reading. Off the top of my head and not counting CIH both of the ones I ran into were extremely basic. One that would mess with the date/time/RTC and another that would corrupt MBR under certain conditions. Both on unknown source OEM motherboards, both isolated, so might have just been experiments that got out.

  12. I think the original guy is either having a good troll, or has an infected USB device. It might be possible to access the memory bus with the right drivers and OS support (especially if it’s got something like the WD drives that make you install that stupid driver), and that would be a good exploitation vector. But there’s simply no way to invoke Windows functionality from the BIOS.

  13. It seems to me you are completely missing the point here by forgetting key aspects of software security. And your own analysis is actually laughable by what aspects of software vulnerabilities and malwares you are omitting…

    – On evading detection: you seem to consider a malware would HAVE to reflash the BIOS upon successful exploitation which is NOT a requirement. An infection vector seeks code execution *only*. Persistance is another thing, and can be done in multiple ways. If you get code execution at the BIOS level, you pretty much own the machine and can easily attack the OS to set up persistance there. And you would not see that with all the ROM dumps you want.
    Your statements are about the same as saying you could discover every windows malware on this planet by only looking at binaries on the hard drive, which will backfire very badly if you are a computer forensic expert.
    Learn about all-in-RAM malwares. Here’s one for you:

    – On portability: you have the very wrong misconception that recompiling everything for specific targets deters exploits, which is utterly wrong. Even more wrong at the BIOS level where there are LESS memory protections such as ASLR and stuff. ANY vulnerable function, even when recompiled as part of a binary for another platform will still be vulnerable. Mediocre exploits will fail because of too much hardcoded offsets, but vulnerabilities dont always required hardcoded offsets. Learn about return-oriented programming (ROP).

    – UEFI is far more portable than you want to make it look like, and it offers a pretty big API for controlling much of the machine. Here’s a proof of concept that owns an entired machine with a pwned UEFI bootrom: (french)

    – More: there have even been proof of concepts on bios infection surviving reflashing, by detecting updates, matching hooked functions to patch them on the fly:

    – On jumping the airgap: nowhere have I seen stated that the audio device was solely controlled by the BIOS. In fact there has been much discussion about a windows payload with very strange behaviour. It is very common these days to have multistaged exploits that end up depositing a payload for the OS that will handle most of the persistance and communication (C&C) work (remember vupen owning the chrome browser sandbox with a 13 stage or so exploit). It is not unrealistic that such a payload could, from the OS, control the audio devices. And it is not unrealistic that such a payload could have been deposited from code execution gained from a BIOS vulnerability.

    – Again on portability: you’re always running x86 code in the end. BIOS, UEFI, or OS-specific, the byte code is the same language. You get code execution in one of them, you own them all. No need to recompile, the code is portable among all x86 devices. It may use different infection vectors, but the payload, after successful exploitation can be the same everywhere. We’re not talking about infection through a peripheral here (say a network adapter), where the embedded microcontroller has its own architecture, but exploiting x86 software, that runs the same instruction set as every other PC in the world.

    I don’t know if BADBIOS is real or not, I don’t really care for that matter, but it is damn credible and so far, nothing contradicts what is possible today.

    Maybe you’re just ignoring how vulnerabilities are actually exploited or persistence is achieved.

    • *sigh* I’m just going to dismantle this one by one, because I abhor people presenting bad and false information as truthful or factual. Hey, guess what? I’m not an InfoSec guy – and I don’t claim to be. But you’re clearly not a computer guy, and you definitely shouldn’t be claiming to be.

      – On evading detection: you seem to consider a malware would HAVE to reflash the BIOS upon successful exploitation which is NOT a requirement.

      And I’m going to stop you right there, because you just demonstrated you don’t know the first thing about BIOS and flash management. I don’t care what somebody told you. If you are MISSING a block, you will fail checksum and fail a basic differential. If you have AN EXTRA block, you will fail checksum and fail basic differential. There is no ‘maybe’ no ‘if’ no ‘but.’ If it’s in the BIOS, it’s in a dump. If it’s in a dump, it’s detectable and extractable. The same as on disk.
      Or are you going to claim that there is some magical malware out there that somehow can escape all forms of forensic detection, yet somehow is stupid enough to expose itself by taking overt, clumsy, highly detectable action? Nevermind the fact that $20 and 20 IQ points is all you need to do a cold extract using the SPI pins or just popping out the PLCC. Hell, bump it to $60 and you can even do it on something that can’t run the code that magically self executes when transferred across a wire.

      – On portability: you have the very wrong misconception that recompiling everything for specific targets deters exploits, which is utterly wrong.

      Funny, that’s absolutely not even close to what I said. In fact, I said nothing about deterring exploits. I pointed out a technical limitation that makes it exceptionally difficult and time consuming, and therefore unprofitable and between inconvenient and rage inducing to try and implement.

      – UEFI is far more portable than you want to make it look like,

      I await your modified BIOS that allows a Phoenix SecureCore to run Gigabyte’s AMI built Q-Flash with an InsydeH2O shell with ext2 support. For a Supermicro C224 board, of course.
      What’s that? You can’t do that, because there’s about a dozen blocking issues ranging from the relatively simple library differences to crazy things like having to know unpublished and often undocumented technical details from a dozen different manufacturers? Well crap! I thought I just said that.

      – More: there have even been proof of concepts on bios infection surviving reflashing

      Funny, I never said anything about reflashing. I only talked about detection. And hey what do you know, that presentation also points out part of the flaw was a buffer overflow in signature check. Boy, buffer overflows in poorly secured and poorly written applications like the SMM handler are totally new, right? Oh wait… and even I know that! Hell, the bulk of that is predicated on poor coding practices.

      – On jumping the airgap: nowhere have I seen stated that the audio device was solely controlled by the BIOS.

      Meanwhile, over in the real world, we have a number of airgap jumping POCs which are dependent on either audible signal, unshielded system, or both. Which again, is pretty much exactly what I pointed out as being utterly absent.
      And again: how are you going to HEAR it to jump the airgap? Meaning: it’s in the OS and runs afoul of.. well, thankfully folks who know audio better than I do have chimed in. (Thanks folks!)

      – Again on portability: you’re always running x86 code in the end.

      I imagine you have great success running Microsoft Office 2013 natively in Linux with AMD drivers from Windows using an OpenBSD kernel and Solaris x86 network stack too, yes? What’s that? It doesn’t actually work that way? But you just said…

      but it is damn credible

      Only if you throw out every single limitation of every single technological component ever made in the past 40 years and pretend that users are deaf, blind, and immune to all forms of human error.

      Which is my whole. Bleeding. Point. It’s not credible. Individual elements being malware, perhaps credible. All being one piece of malware? Eh, maybe some sloppy commercial ‘super suite.’ BIOS loaded, completely undetectable with forensics, runs on multiple OSes and so on, and jumps airgaps?
      Uh. No. That’s not at all credible. Remind me again, how did Stuxnet get in? Ah right. Infected USB drives. What was the size of the payload? 512KB for Stuxnet – let’s see, does it fi-NOPE. More capable and complex than Flame – which weighs in at 20MB+ – yet somehow fits in <1/10th the size? It’s just not even remotely credible.

  14. Your knowledge is way, way above mine on such matters, but I do know a hell of a lot about sound. That was where I went “dafuq?”.

    As you pointed out, PC speakers and mics don’t operate up into ultrasonic ranges. A really good studio mic and monitors *might* but are often filtered in those frequency ranges. The reason is simple; If you don’t need it in the recording, take it out so it doesn’t have the potential to create comb filtering artifacts on lower frequency audio.

    But the really big thing is the higher the frequency of sound, the more directional it tends to become. Ultrasonic drivers, even with horns to spread their output, tend to border on nearly beam like or narrow cones. Very low frequency goes pretty much everywhere, but is really hard to produce with a tiny PC speaker (I won’t say impossible, just really hard at any reasonable level – again, as you pointed out, no stock machine has hardware capable of this).

    I get the feeling this report is leading up to something. What I can’t say for sure, but if we suddenly see “Laptop earplugs” on the market, I’d be mighty suspicious.

  15. Pingback: Indestructible, badass rootkit BadBIOS: Is this tech world's Loch Ness Monster? VOTE NOW | Techbait Tech News

  16. Perhaps they’re designer malware that target specific bioses, even specific motherboards. After stuxnet this would not be surprising for the gov’t spooks to have this ability.

  17. Thanks for writing this up. My “gut” feeling was that badBIOS was a bunch of FUD, but I don’t have the background or experience to rule out all of the claims. This will help me next time someone comes to me with questions about it.

  18. I like your analysis. I have been suspecting that, if he does has malware running around, it’s not infecting the bios, UNLESS it’s doing some serious backend work on the system, determining what hardware it’s running on and downloading what is needed and pushing that up on the fly, which would take an incredible amount of processing, coordination, and control.

    I believe that it is more likely that something is going on at the OS level, perhaps even on the boot sector.

    As for the acoustic data transfer, it seems that he may not be very far off in his analysis of that, I did a little searching and came across this granted they are combining the data with audible sound so they could simply be modulating that, but what about the high frequencies, I know that the ‘cricket’ ring tones were popular with young kids because adult hearing had been sufficiently been diminished in the high end that most adults couldn’t hear them.

  19. @Pierre: “I don’t know if BADBIOS is real or not, I don’t really care for that matter, but it is damn credible and so far, nothing contradicts what is possible today.”

    There is nothing to contradict. Someone released a set of claims based on never-before seen exploits but no actual breakdown would appear to have been done, no independent verification has been done so far. All we can do until then is nod and wait.

  20. I’m not a bios expert, and have a few questions:

    1) Everyone keeps saying that a BIOS dump will show what’s happening here. If the “BIOS Dump” function a feature of the bios/motherboard itself, wouldn’t the malware have the ability to exclude itself from the returned dump?

    2) The argument about a bios-specific malware not being possible because the BIOS itself is not transportable. Couldn’t the malware perform a dump of the bios, inject itself based upon a series of patterns found in the dump, and restore itself with the malware intact? Also, couldn’t it include multiple malicious bios images, and infect with one specific image based upon a simple check of DMI data (to match the motherboard model)?

    This is absolutely insane, and I don’t know what to believe. I do however enjoy thinking about the possibilities.

    • Happy to answer your questions, Mike.

      As far as a BIOS dump goes; there’s multiple types of ways to dump it. Remember that a BIOS is stored on a PLCC or EEPROM, and is SPI capable. So there’s a ‘hot’ dump (writing BIOS contents to disk in BIOS), a running dump (writing BIOS contents to disk from OS), cold (use 2-wire or a socket reader to pull contents) and cold clip (use clip to pull contents.) In the last two cases, stealthing is impossible because the code is not running or the read bypasses any ability to execute code.

      As far as the second one: it’s too complex to do that on a wide scale. The injection setup would have to be massive out of necessity, because the strings are incredibly varied. ACPI/DMI is not a reliable indicator because these are meant to be customized, as well as versions and so on. Injection is also not possible easily because you have extremely limited space in which to work and any sort of erase-write hot flashing is still high risk and extremely visible as it impacts the system. e.g. if I were to hot flash an IME upgrade and try to stealth it, I would still notice it because IME would drop out and OS would report errors.

  21. Huh, I just came and then and read this (from a comment link in XDA-Developers, and just because I was reading stuff about the new kernel features that could fuck-up root-ing in most OEM-Android devices), and I’ve been modding BIOS since the not-so-good planned strategy of MS on creating a offline activation on Windows Vista/7 (now gone on 8 and 8.1 ofc), I never laughed so hard on people that actually don’t understand (those who believe the badBIOS thing could actually be true lol). If it was THAT easy, I mean, couldn’t anyone in a single facility of the thousands manufacturing motherboards or even someone in facilities manufacturing BIOS/UEFI chips start this on his/her own? And I’m not talking about now, since BIOS has been around so long, various decades and then some guy/lad on the net actually started to read about how IBM BIOS Standard works or even the UEFI specification by Intel (and other ones, since you could look in MDL and start doin stuff). I mean, after the BIOS post, everyone (and I’m taking the approach of DAZ Loader for Win Vista/Seven) could install GRUB4DOS in Windows PCs and then make load something (a text, a virus, a /dev/urandom joke, whatever you want) in memory and then chainload the Windows bootloader? If you ever worked with DAZ Loader is almost unoticeable that GRUB4DOS boots before Windows, and loads stuff that then Windows reads for activation (I mean, a SLIC string that should be on DSTD tables on NVRAM if I remember correctly). And since it boots BEFORE Windows, you could actually hide from the NT kernel.
    And nope, Microsoft has done nothing on fixing this, they can’t, and believe me, only with Windows 8 microsoft came with a solution, with changing a lot of the activation stuff.

    And is a simple program around 2MB with a single installation per Windows install. And most of that is because as you said, stuff on low-level hardware is not the same on every computer, so there are some options to make it work and debug if it can be done normally.

  22. @Philip Jaenke: not every part of the payload has to be present everywhere (multi-staged payload => initial infection vector on a USB stick + various payloads on it, delivered fitting to the system configuration)), so the size does not have to matter.

    And as for hiding, well… you don’t just have a flashable BIOS chip. Pretty much every component these days has its own microprocessor + storage – and the components are pretty much the same across multiple boards. Realtek NIC/Audio chipsets, Intel network chipsets, mostly just the same cheap crap everywhere.

    • Right, Marco. Not saying the whole payload is on there, but a payload this complex is A) going to be huge B) still beyond size constrained. (See another reply where I pointed out that a 64Mbit Supermicro load has 6KB free.)
      The thing you miss is that actually, all that microcode? Is stored in the BIOS. No joke. Classic example of this is ITE’s SuperIO controllers. They contain exactly zero bytes flash, and IIRC up to 2KB SRAM at the very top end. All operating code loads off the BIOS operating region. Crazy, no? But the case for the vast majority of controllers out there is that f/w is in BIOS; even those with private regions like Intel i82574L’s, the BIOS usually contains a failsafe or backup image. (For i82574L, it’s in the IME load. For Realtek, it.. varies.) There’s a lot of regions, sure, but there’s not space.

      And as I mentioned; any sort of bootstrapper is largely constrained to available space. Reason being that it can’t interfere with normal operations as that would A) make it ridiculously easy to detect (duh!) B) render the system a brick.

  23. i can’t believe actual credible sites like slashdot or wired posted about such hokum.. anyone worth their salt on basic security knowledge can debunk most of the bs being spewed by the so called “researcher” crying wolf..

    Thankfully this post articulates some key points on the BS and provides counter reasoning why they don’t compute in the real world..

  24. “NOTE: Approving comments as I get time. If I didn’t do it yet, I just haven’t gotten to it. If I don’t approve yours, it’s either because A) you made it clear you didn’t read or have no clue what you’re talking about, and therefore detract from the conversation or B) you’re trolling / blindly defending / blindly attacking to derail the conversation. In either case, rebutting basic ignorance of technology, complete lack of reading comprehension or someone just being an ass is a waste of everyone’s time. Including your own.”

    This is why I like Schneier’s blog rather than most forums and private blogs and mailing lists – he allows much more open minded and technical discussion without any ‘overlords’ controlling content.

    • Normally, I would agree with you, and normally I don’t moderate comments in such a fashion. However, A) there’s over 200 comments still in queue right now and B) probably more than 80% of them are either purely toxic with no point or completely and utterly unrelated to the topic at hand.

      I really wish I were joking. Welcome to the modern Internet. Where people leave anonymous comments about fluoride conspiracies on posts like this and I have to delete several hundred word rants about it being the NSA turning laptops into ECHELON receivers or people just pasting racial slurs or homophobic epithets several hundred times. :(

  25. Thanks for clearing things up. I guess with malware such as Stuxnet and Flame, its follows that more advanced techniques will follow, but that doesn’t mean the malware developers can change the functioning of the BIOS to do so.

    • Oh, don’t get me wrong, they absolutely could. Hell, I can rattle off a variety of ways to use malware to screw up the BIOS. Emphasis on ‘screw up’ though. Is BIOS handling insecure in the extreme? Hell yes. Even before UEFI. But tweaking it in nigh undetectable ways to interfere with the OS in highly varied and extremely specific ways on multiple highly divergent platforms? Nope. Doing it in a handful of kilobytes? Hell no.

  26. this so called blog stinks of COINTELPRO behavior. isn’t it fun to control then shape the comments to match your own ideas? delete this or comment crap on it your choice, red tron suit.

  27. [quote]And I’m going to stop you right there, because you just demonstrated you don’t know the first thing about BIOS and flash management. I don’t care what somebody told you. If you are MISSING a block, you will fail checksum and fail a basic differential. If you have AN EXTRA block, you will fail checksum and fail basic differential. There is no ‘maybe’ no ‘if’ no ‘but.’ If it’s in the BIOS, it’s in a dump. If it’s in a dump, it’s detectable and extractable. The same as on disk.[/quote] (I hope this is correct shortcode)

    The comment Pierre made was that you assumed the malware payload was stored in BIOS. He argued that the payload could be stored anywhere, thus leaving the BIOS untouched. There seems to be a lot of misinformation being spread around, and it could be due to people misinterpreting or misusing terms. Even though #badbios seems to be trending it could have not much to do with flashing the bios directly. I’ve been trying to find any binaries (w/e format or platform) related to this, but dragosr seems to have provided little information, and a lot of people are drawing a lot of conclusions that could have nothing to do with the few points he has made.

    In the end it could just be something stupid like a simple rootkit that has a gimmicky way of communicating via speakers/mic.

    • Here’s my point though, Patrick. ANY payload, including a bootstrapper, is going to be exposed in the BIOS. Any modification like a bootstrapper is going to cause a checksum failure. Believe me, I understand multi-stage and bootstrapping. (I do it regularly! Just not for you know, malware and such.) But the BIOS is a very highly sensitive area even though it isn’t handled adequately as such, and a very fragile area. Basically anything that tampers with it is going to raise alarms or cause unacceptable interference in normal operations. Even bulk store would trigger it.
      That’s really why I’m guessing it’s something like a boot sector virus leveraging GPT, probably on a flash drive. That’s the most reasonable way I’m aware of from a technical standpoint that would permit leveraging any UEFI elements, it can be stealthed, and that gives it many megabytes or gigabytes of space for necessary payloads.

  28. Let me go on a completely fictional tangent here.

    Let’s assume badBIOS is real. Just assume.

    Consider how stuxnet is estimated to have cost millions to develop. Indeed, the engineering involved many man-years of top secret clearance’d, highly qualified engineers’ work. We’re talking about a stealth virus that had one, and only one specific target.

    Consider that it was easily analyzed by specialists (not Russian nuclear technology specialists, computer security specialists) rather easily. It stands to reason that badBIOS would have cost 10, 100 times more than that.

    Now who could have those resources? Well Charles Stross wrote a short story, “Antibodies,” that reminded me of this: after the Singularity, mental viruses appear that take over the human brain. Eh, if badBIOS’s so powerful, maybe it could do that?

    Anyway, my point is: if badBIOS is real and as described, it was designed by hostile aliens. Reductio ad absurdum: either it’s BS, or either Aliens are among us (or at least among our data).

  29. Philip,

    It’s obvious you are not an InfoSec guy. If you were, you would know that we’ve had hypervisor based rootkits for some time that can evade traditional forensic analysis. Meaning, you will get a bios dump from whatever virtual environment the malware presents to you.

    Try thinking of it this way…

    You have a piece of malware that attacks USB micro-controllers. This vastly reduces the scope of the attack as there are only a handful of vendors out there (six I think). This is stage 1.

    Stage 2 is the installation of the hypervisor rootkit (google ‘blue pill rootkit’ for a working example of this). This does not have to be installed into the BIOS. In fact, I don’t think the BIOS is getting modified in any meaningful way, other than disabling booting from the CDROM. It’s important to note that this rootkit could actually include an embedded system with an IPv6 stack and audio drivers.

    Stage 3 is the downloading of further components to hook into the specific guest OS.

    But, to be clear, I’m not saying this is what is happening. What I am saying is that everything described so far is both technically possible and in most cases has already been demonstrated by IT security researchers.

    Re: Jumping the airgap. Modern PC audio systems can easily generate and record 20khz audio at least, which will be inaudible to most adults at a normal volume. I’ve even personally verified this. Using short (millisecond) bursts of audio would be even harder to detect.

    • Well, never claimed to be. But as I said, I am a BIOS guy. I’ve been up to my guts in it for many, many years.

      The problem herein is that even your initial payload would have to be absolutely and utterly board specific. The other factor in it is the space and limited facilities. Hypervisors run in, you guessed it, protected mode. And on nearly any compatible hardware. Not so with something in the BIOS. In addition to that, you’ve got very, very limited space to work with. Where by ‘limited’ I mean ‘none.’ Let’s say I wanted to load a UEFI driver that hijacks memory space to figure out the OS and download a payload – that means it has to go into Volume 02. Well, your typical UEFI Aptio V BIOS, it’s not technically possible.
      Consider this. UEFI gives you all the tools, sure. But you still need room for the initial bootstrap itself. Typical UEFI board has 32Mbit to 64Mbit of SPI Flash. The Supermicro X9SCM/X9SCL family with 64Mbit? Has 6KB or less available. Sure, you can do lots in 64KB using various tricks. But 6KB or less? Something that complicated? Even leveraging the UEFI networking stack, that’s not enough room for something that complex. I mean consider the most comparable known one: Flame. The payload is 20MBish. And any bootstrap has to NOT interfere with the majority of the BIOS, since that would prevent the system from operating potentially. There’s no value in a bricked system, and nobody on earth is going to put that much effort into something with a significant risk of bricking. There are much easier ways to brick it thanks to the lack of security in BIOS handling – which is another post.

      As I mentioned: my suspicion is that there’s a bootstrapper lurking on a GPT boot layout as a boot sector virus, which would give it the ability to stealth payload, leverage certain common UEFI behaviors, and escape detection through non-interference. (Run payload, boot normal device.)

  30. Thanks for this write up. You precisely put down my thoughts when I’ve read those claims about “badBIOS”; especially that sound based air-gap bridging theory has so many gaps that I can’t take it seriously (for the very reasons you gave). Oh, another thing you forget to mention: Nyquist frequency and what it means for the choice of the antialiasing lowpass filter (a piece of hardwired, literally hardware, namely a capacitor and a resistor) in the soundcard’s circuitry.

    Just one remark on the portability of UEFI modules and for which it would be great if you could comment on it: AFAIK one of the main incentives for UEFI was, that you could install hardware drivers (for hardware connected to PCI-e) which follow a common API on the UEFI partition, that would then work for all operating systems. Also UEFI provides runtime facilities for (portable) applications called “extension” you can launch from the UEFI shell; in short UEFI acts (well actually is) a operating system for those things. However I don’t know if those could be used for implementing a portable UEFI rootkit and how well this portability of UEFI extensions loaded from the partition actually goes.

    • You raise a good point with UEFI extensions. However, that’s also one of my major complaints with UEFI. While the API and such is absolutely supposed to be highly common, it is in fact, not. I literally can show you two systems which are both built on AMI Aptio V, both using Intel C600-series chipset, which have wildly different UEFI capabilities. One has shell, the other doesn’t. One can read NTFS and ext2, the other is only FAT32 capable. You get the idea.

  31. The thing that struck me most on reading Ruiu’s claims, is that while seeing packets pass between airgapped machines, when he disconnected speakers and mic cables and the packets stopped, his conclusion that the link is therefore proven to be audio, is NOT valid.

    It’s not valid because the hypothetical malware could probably see when the cables are disconnected. So to obfuscate the real (unknown) link, the malware could be playing red herrings.

    The link has to be audio, RF, or IR. Why does a supposedly technical guy apparently NEVER think to just get some test gear able to a) observe those channels, or b) jam them?
    Accoustics – simple, just a wideband mic, amp and oscilloscope. RF – its called a spectrum analyzer. Set up the test systems in a RF quiet location, look for RF energy. IR – every TV has an IR receiver, rip one out and use it. Or buy the part…
    As for jamming (to see what stops the covert communication) that’s dead easy too. Or he could just move the machines apart; see at what range they lost link.
    Why do I even have to point this out?

  32. Different firmwares can be downloaded on demand – no need to have them all in one binary. Extracting the firmware should happen on a dedicated ROM reader. I would not trust the results from whatever utility run on the system with the malware. Transmitting data via audio is nothing new ( Stuxnet did something similar via bluetooth (bypassing the OS).
    Somewhere in the comments you say something very true:
    “Individual elements being malware, perhaps credible.”
    But then you follow it up with not believing it could all be combined in one piece of super-malware. Well, before the NSA revelations by Snowden I would probably have agreed but not anymore. The NSA or any other state sponsored secret service of similar capabilities would have another department that do nothing but creating firmware images for systems the want to take over.. The NSA supposedly has expoited over 84.000 machines and equipped them with backdoors that ensure that they can return even after the systems have been reinstalled – this would seem like a cost-effective and scalable way to do it.
    So I remain 50% convinced that this is real. Time will tell.

  33. It is obvious that assuming this was real, most features would run on the OS level as a rootkit, with a tiny module in the BIOS used to re-infect clean operating systems (or possibly providing an hypervisor, I think something like that was also mentioned). It would certainly be possible to generate interceptable signals. There was a paper analyzing the sound emitted from some power regulating component on mainboards during RSA private key operations, and AFAIK they were able to at least distinguish which key from a certain set is being used. On many cheap notebooks, you can observe this yourself by simply listening very closely while applying different CPU loads (e.g. encryption, scrolling in a PDF file, …)

    If the mechanical vibrations caused by the varying load are strong enough to be audible to the human ear, I’m pretty sure you can use it to send signals to highly sensitive equipment designed to intercept such signals. You can transmit AM radio, receivable with a regular shortwave receiver, using just a CRT and a piece of software (google “tempest for ELIZA” if you don’t believe me – it works, I tried). TEMPEST is a problem by itself, so it certainly can become a bigger one if it is used intentionally.

    Now, I’m sceptical, because the effort required to build such a thing would be huge – most likely even beyond the abilities of the NSA & Co – but I do think that given giant amounts of resources and effort, it would be possible. And with the NSA & Co., you never know what they do manage to do in secret, having unlimited money, lots of bright people, and access to confidential information of manufacturers. I doubt they would be stupid enough to leak something like this to a security researcher known to take that stuff apart, though. I’m really interested in seeing how this turns out in the end. The latest post on Google+ I saw just reeks of bullshit. Most likely, he will be unable to extract anything “because the virus is too good and deletes it as he tries”…

    If it were true, however, it would mean that we can stop caring and researching it – just roll over and let them do whatever they want, because they are going to anyways.

  34. “It also wouldn’t be a viable delivery method. The ATAPI drive ROM is self-contained. It only provides the identifying string (e.g. “Optiarc DVD RW AD-7260S”.)”

    I think you might want to look in to the history of Xbox 360 hacking, and even drive swapping in the original Xbox. There’s more than just identifiers in the flashable areas of DVD drives. The Xbox reflashes were mostly about using PC drives that read R/RW media better in the console, but the 360 flashes actually modified significant chunks of drive code to bypass security mechanisms in the system. Microsoft even reflashed a lot of the consoles’ drives as part of an official update to roll out a new security measure.

  35. To be clear though, I don’t disagree on your general conclusion that a lot of the claims made about this are entirely impossible and/or so improbable as to be safe to reject without strong evidence for them. The audio C&C thing really has me laughing.

  36. I’m really new to all of this, but I’ve been an analyst for over a decade.

    Some of the areas that I’ve operated in have rooms that are wall to wall with the exact same kind of computer.

    Ignoring some of the more fantastic claims, limiting the discussion to an environment with a single type of computer handled in an enterprise fashion, do some of these claims seem much more plausible? The ability for a persistent malicious code to run and “hide” across such a one-dimensional ecosystem seems much more plausible to me, particularly if such an attack is occurring across multiple layers of operation (not strictly limited to BIOS code).

    The audio portion is something I can comment on. You can’t push significant amounts of covert data across a standard computer audio system. I can’t see how it would be used as an infection vector (I can’t remember the exact math, but I think you’re looking at hundreds of bytes per second, maybe a kilo…. maybe), but it could be used as a signaling path sending a very simple signal to any likewise infected computer within listening distance.

    But again, My understanding (Echoed by Mr. Jaenke) is that this is completely outside the realm of a BIOS operation.

    • I have looked at it late last night, didn’t have a chance – that’s not a dump. The size is right, but somebody screwed it up or dumped the wrong area. There’s also not anywhere near enough information to perform proper analysis, nor has the information been forthcoming. To analyze properly, at the minimum, need to know exact motherboard or system planar manufacturer, model, and configuration. Either way, the dump is a brick – nothing could boot off it.

      The quick run down:
      Image size claimed 800000, aligns ok.
      FV Descriptors 00 FFS, 01 NVRAM, 02 Boot Block. This is normal, but unfortunately doesn’t identify the BIOS at all.
      No nested firmware.
      NCB Region is mostly normal. 0 is at 00000000 with a length of 600000 – position reversal. It’s an OEM option, just not one I see frequently.
      Volume 00 is empty; this is okay. Volume 01 is empty; this is absolutely not okay. Volume 01 being empty means the system won’t boot. Volume 02 is intact, and I’m able to extract individual elements. Volume 02 reports a total usage of 311KB and 72KB free (total 384KB – just trust me on the rounding up. It’s an MMTool thing) but total reports 8119KB used with 72KB free. There’s an inordinate amount of padding too – it looks like Volume 01 is entirely zero padded.
      Which means one of two things. A) Wrong toolchain for the dump. Except yeah, what’s with the zero padding? B) Dump was performed incorrectly or OS screwed it up. This is the more likely problem.

  37. And also, even if you could get the (cheap) mic to recieve info via some magical HF, wouldn’t you have to get the system infected in the first place? If so, why bother with air gap features?, you’re already there! Just for C&C ?!

    Don’t think is that “damn possible”
    (Great post, BTW)

  38. I believe you have missed two important points.

    1) It IS possible to communicate via ultrasound with speakers and microphones. Recent examples in Finland, where they used that to communicate between “secure isolated” computers.
    You can use Google translate to read it

    2) Its is not claimed that the entire virus residents in BIOS. Only some parts of it. Maybe the parts that execute main virus on the hidden sectors of hdd or firmware somewhere. Then that acts as rootkit, fooling you to see “ok bios” while infact the bios is infected.

  39. Pingback: badBIOS Malware – a Hoax? I hope so… | Roger Halbheer on Security

  40. Presuming it’s not just a false story to see what people without evidence assume it is (I.e. jumping to conclusions) and a social engineering experiment; what if the actual target has been wrongly identified as the BIOS/EFI chip? What if it’s actually the USB microcontroller? They are all roughly the same – architecture and firmware wise (hence the “U” in USB) and would be an easy target for a widespread injection point if there was a vulnerability in the controller firmware. The payload would still have to be small, and the resources available to said controller wouldn’t actually be available until the controller was initialized by a host operating system. But it would explain it’s ability to sustain through BIOS flashes and system reformatting. It’s still a very long shot though, either through hardware or software it would have to interface with the audio controller to produce the communication link that is described.

  41. What about Intel Management Engine- or whatever code runs the chipset. Isn’t this the same code for all boards and capable of doing weird things to your hardware?

    • Good thought, but no, IME is not actually that common. IME is chipset specific and unique to the BIOS ODM at the minimum.
      This handy thread explains the process of modifying it fairly well. That isn’t to say it’s a potential vector for simple payloads – but that’s another post.

    • Well, I don’t think any of us disbelieve it’s impossible to do. I used to deal with modems far more regularly than I like to admit. 😉 Just that ultra high frequency and the like or being completely inaudible is beyond far fetched.

  42. Pingback: Indestructible, badass rootkit BadBIOS: Is this tech world’s Loch Ness Monster? VOTE NOW

    • The catch there is that CompuTrace isn’t actually using the BIOS for much more than a bulk store. (And in fact, uses a separate protected ROM region I believe.) IIRC the exact procedure involves copying to a FAT32 recovery partition, but don’t hold me to it. Freaking trade secrets. Anyhow, CompuTrace is much coarser than that regardless. It can set BIOS boot password, force power off via ACPI, etcetera but anything else requires a running OS and installation of supporting software.

  43. I was a BIOS dev for a big PC co for many years, before UEFI came out, and the odds of successfully infecting more than one of those with the same code set is close to zero too, decreasing exponentially with each additional target.

    The old BIOS code was a fragile thing. There are a whole lot of comments scattered through the source saying things like “I don’t know what this does, but don’t move it, or XY and Z will break”

    To bring up a new mobo, you’d start with the closest code you could find, then hack in the new vendor/chipset proprietary specifics as best you could, assemble the code and plug in your logic analyzer. A home-run was the first try making it to the first Int 10 call without locking up. It could be days before you could boot to DOS.

    • Hahaha, why did you have to remind me of this, Ray? Even from the OEM side rather than ODM side, it’s still that bad and that fragile. I have a UEFI splash image for AMI that causes a wedge at OROM init. Change something like ten pixels, no more wedge!
      We should just rename the BIOS to what it actually is. Black Magic, Voodoo and Dumb Luck. 😉

  44. Has anyone set up a suitable microphone next to the speaker of an infected machine and looked at its output on a scope?

  45. People with more knowledge than I have weighed in on the technical elements, and the technical limitations, of both the alleged HF communications, and the idea that it’s in the BIOS/chipset, but I want to throw in my two cents.

    Talented people have looked at Dragos’s BIOS dump, which appears to be clean. What this means is that either Dragos hasn’t dumped the BIOS in three years, or he has dumped it and found no evidence but is still telling us that there’s an infection. Both of those should cast a shadow of doubt upon this entire story: the first, because it means that he hasn’t performed basic forensics, and the second means that he has some ulterior motive convincing us (and/or himself) that it’s BIOS-based.

    Why would the malware be so overt? Even assuming that it exists and has the incredible resilience Dragos claims it does, once he knew he was infected, he could just take his hard drives and extract the files he needs, throw out his machines and USBs, and start over, or hell, keep it contained on his lab machines. Some of his tweets imply that all of his machines in the last three years have been infected. That simply isn’t physically possible if he’s following anything near best practices for handling an infection.

    Why is he claiming it’s completely immune to modern forensics? This thing has to be coming from somewhere, and this multi-platform stuff means it has to be pretty big. Either there’s a multi-stage, modular virus hiding on his USBs, or it’s fetching itself from the internet somewhere. This should not be too hard to locate either way, even if it’s encrypted until it’s actually on the target machine.

    Either the motives and methodology of the people behind this alleged malware are suspect, or the motives or methodology of Dragos Ruiu are suspect. Occam’s Razor points to the latter. The idea that he has been working on his computers believing they’re infected by invisible malware (which coincidentally seems to be inspired by Rutkowska’s most evil theories) that communicates over HF transmissions in order to prevent him removing it for over three years sounds very John Nash, honestly. Even if someone had the technology to do this, and convert all of these proof-of-concept or theoretical attacks into practical forms, he simply isn’t that important.

  46. I must admit I *love* the audio crap – that really made me sit up and start reading all of it with a big smile on my face.

    I’ve not been near PC BIOSes – the last time I’ve been that close to a CPU was hand coding some routines for a 6303 – but I have been playing with electronics since transistors replaced radio tubes, and pretty much grew up with computers and audio. In short – I know what works and what doesn’t, on a very practical level, and how you coax a computer in makings sounds. And I know about sound too.

    It takes an astonishing and, frankly whole new and uncharted level of ignorance of the most basic facts about electronics, audio, sound and our own physiology to consider the audio part feasible. Even if transmission was in the audible range (ruining the chance to remain undetected), it would not be feasible to use audio as a transmission channel in this context.

    Anyway, it was briefly amusing, can we now please get back to work and protect stuff for real? This thing has demonstrated in a fairly painful fashion that a lot of those so-called experts are utterly without a clue, yet are willing to spout a lot of BS as fact, dragging in data from resources that do not match the issue or the prevailing conditions at hand.

    I really hope they don’t have their hands on anything valuable…

  47. As a BIOS engineer in an open computing project, I agree with most, if not all, what Phillip posted. One thing is that all you have to compare is a 4MB-8MB SPI, not 4GB of memory with lots of whatwedontknow in it, not even a 2TB HDD.
    There can be a chance to hack OpROM in SPI or additional volume for utilities running in UEFI shell. However, you have to reflash part of the SPI to make the hacks persistent, and recalc all checksums. It can be possible to call vendor-specific SMI functions to do all these things for you, and make the intrude even much less portable…

  48. Coop: don’t trust what you dump from OS. always use an SPI reader.

    Intel ME can be a really nice place to stealth and do manoeuvre. Most ODM don’t understand ME well (and Intel don’t give us enough documents). However, for most SiEn configuration that you see everywhere, there’s no chance to do a thing. You bettet bump into a DM or DNM (even rare among servers) where you can mount drivers and do screen dumps…

  49. I think that it’s conceivable that malware could pull the current BIOS image, append its code as an ISA component and then reflash itself. This component could perhaps ensure the persistence of malware in a similar way that Computrace antihijack software does it (NTFS aware bit of code that executes in the bios that renames rpcnet.exe to rpcnetp.exe and injects the software into rpcnet.exe knowing it will be executed by Windows on startup). But yes – such a thing would be trivially detected by dumping the BIOS and inspecting.

    Re comms using audio – while theoretically possible you’d have to keep it below about 20khz to avoid filtering and thus you run the risk of it being detected. I guess this component of the malware would be running in win32 and not in the BIOS (the latter is laughable) so its conceivable that it could use a combination of system time and also sample ambient noise via the mic to only transmit when it is late at night AND quiet. You could conceivably use one of the amateur radio modes like 1200bps FSK.

    I guess until this guy gives us more data we have to remain skeptical.

  50. Pingback: More Thoughts On badBIOS | Mike the Crypto Goat

  51. Pingback: Meet the mother of all malware which can jump airgaps

  52. Pingback: Security News #0×57 | CyberOperations

    • Funny, I never said they don’t exist. I said they were rare and extremely specific. And hey what do you know, Mebromi can only affect Award BIOSes of a certain version using a certain flash chip.

  53. I believe that us, as software professionals (we don’t master the hardware, mean low level, even when we program chips!). Some motherboards components are assembled and bought from a little number of suppliers.
    Knowing the exact function of each transistor in a cpu or other chip is really difficult (hardware reverse engineering).
    So, if there where a “BadBIOS”, we would have to consider hardware “pre-infected with open-doors”, which looks again like the “holy mystic conspiraton”. It may be or may not, I am (and most of us are) not expert capable to confirm on not.

    Also, I agree that the name “BadBIOS” is a trendy generic name that helps propagate some ideas, not more than that related to BIOS…
    Medias need simple names like that… and of course, medias ans some IT guys/companies want to take advantage of the NSA/Prism issues…

    Then, some are looking for new technologies, while most attacks use the same and old techniques that work… no need for the mic/speaker thing…

  54. A central point seems to be a checksum failure upon modification of BIOS blocks. What part of the system calculates this checksum and where is the value stored to match the calculated checksum against?

    Could the algorithm for the computation of the checksum be modified to yield always the checksum known as the correct one. Or could the comparison value be changed to match the wrong checksum?

    • There’s ways to force the checksum to go clean. The catch is that, no surprise, they’re not easy and more or less require a running operating system to obscure the erase-write cycles required to force it or blatantly blocking and obvious because they halt the system and require a power cycle even before OS entry.

  55. For this thing to survive three years implies no regard or use of “best practices.”
    And after reading this article, the choice of “badBIOS” as a name is a poor one.
    That said, the rest requires us to chain together known proven processes, add a dose of luck, then squint a little sideways for some conspiracy theories.

    There are more things to consider; who would do this, why, and what if this discovery was due to a bug in the code? As I recall, one of the first UNIX virus’ discovery was due to a bug in its code that made it obvious something was wrong. wish I could remember that article….

    Another article I cannot recall where I read proposed that most malware has 3 main drivers.
    The first is for jollies. Usually some lone wolf trying to prove he could. Money is not necessarily the object.
    The second is money. Apparently its easier to have people tell you their vital info than stealing it, hence the desire to gain control of machines to mount massive spam phishing expeditions.
    The third is espionage. Money is not the object, nor is it a hinderance. State agencies like NSA are the culprits. They would have the desire and the resources to figure out those “Idontknowwhatthisdoesbutdontchangeit” routines, and change them. In the main system and subsystems.

    I’m just an old hardware tech, not a programmer. But I do know that systems have grown incredibly complex. Subsystems report a lot more info to the system before the OS ever loads and they often have firmware updates themselves. GPUs have more horsepower and as much dedicated memory as the main system does (check the new PowerMac). Heck, my TV told me to upgrade its firmware the first time I turned it on. Given that and the number of people that just click OK to anything on the screen (is there really anybody left that can fall for that Nigerian millionaire or computer ransomware scam? Guess so.) it would seem that a firmware flash could go unnoticed. There are places for a simple malware bootstrapper to burrow and hide AFTER the initial infection.
    So potentially, infect, inventory, report, receive proper payload, hide.

    Again, we have to chain together some known working procedures with some conspiracy theory and some dumb luck to get there. Maybe its all just logical sounding but still drawing the wrong conclusions. And that won’t change until someone gets to dissect one of the infected machines.

    Thanx for writing this article.

  56. Pingback: On BadBIOS and Bad Behavior | I Am Security

  57. Thanks, Phillip, for bringing insightful reason to the table.

    I feel that people really *want* believe that skynet is going to take over, that AI will spontaneously erupt taking over mankind, and Mt Dew machines will kill children at truck stops by firing cans into their heads.

    That’s for people who detest reason.

  58. Pingback: No, Malware Can't Infect Your Computer Over The Air | Gizmodo Australia

  59. Just a note – everyone here keeps talking about ultrasonic sound. Dragos never said it was ultrasonic; he specifically said that it was audible (and irritating). That’s not to say I believe the story, but hey. If this does pan out to be real, I suspect it’s someone just fucking with Dragos, not any sophisticated organized effort.

  60. “and obvious because they halt the system and require a power cycle even before OS entry”
    Over the years on different PCs I had some sudden reboots during or after the BIOS processing and before the Windows logon is displayed.
    I attributed it to either build up of static electricity, spike in the mains, RAM problem, processor overheat due old thermal paste, registry errors, driver incompatibility or
    failing hard drive blocks. And I had one or two BIOS checksum failures. Most of the time the problem was gone after a power cycle and Windows is able to recover from some registry and driver errors.
    So for the average PC user it is not especially alarming to have an occasional reboot during the boot process now and then.

    Could you recommend a way to check a system against a vendor BIOS? Either the current BIOS or a newly updated BIOS against a known good BIOS.
    I think there are different ways to dump the BIOS or part of it and the checksums of the dump may vary by installed devices.
    What would be the best way to dump the BIOS for checking?

    • That’s the other annoying part – checksum failure is obnoxiously easy to trigger as well. Faulty CMOS battery? Checksum failure. Abrupt power loss in certain situations? Failure! List goes on. I have a board around here which has a faulty solder joint in the CPU socket which continually causes very obvious BIOS problems.
      But really, checking integrity is as simple as getting a confirmed clean sample and comparing a 2-wire or clip dump of the flash IC to the confirmed clean sample. Or any dump in most cases – the less room available, the harder it is to hide. Since the DMI area gets dumped but typically not the CMOS (depends on your vendor’s utilities – sometimes it’s both, sometimes neither) a simple diff is often sufficient to confirm it’s clean.
      As far as the best way to dump it – use your vendor’s update utilities. Every update utility has two modes – erase-write and read. Meaning there’s a switch, usually well documented, for dumping the BIOS to disk.

  61. Phillip/Phillipe: Assuming this is real, I don’t it has much (if anything) to do with the motherboard firmware. As has been mentioned this probably isn’t technically feasible and more importantly, isn’t even necessary.

    Rather, I think its more specifically targeting the least common denominator of commodity x86 systems. So, it spreads using vulnerabilities in standard USB micro-controllers and can install itself in any number of places (including, of course, the hard drive). I think part of the problem here is that Dragos is out of his element and isn’t at all setup to analyze something like this (as he himself has mentioned). I don’t believe he has a SPI analyzer or USB debugger, which I would think would be mandatory at this point.

    As an example of how it wouldn’t be particularly difficult to pull this off, imagine installing a tiny embedded linux system (including a generic kernel) somewhere on a local disk. This could even been hidden in the ‘rescue’ partition that is commonly available on PC’s. This system then in turn boots the previously installed system inside a hypervisor. The embedded system could connect to an external CnC mechanism using its own networking stack and drivers and to air-gapped peers using ultrasonic networking. POC code and demo available here:

    Now its just a matter of automating the installation of this system from a usb stick via an exploit kit.

    As I mentioned, none of the features described in this malware are new in and off themselves. But put together, they could create the malware equivalent of an autonomous drone.

  62. You are the man.

    So nice to find real informed opinions.

    Will follow you. It’s s pleasure to read…

    Thanks for giving proof to support what I knew but didn’t have enough low level knowledge for today’s systems (my assembler knowledge ended with the spectrum and the z80 era).

  63. Nobody is concerned why there isn’t any data about the stuff the malware is up to? Like data exfill? Dragos never said anything about this. Thinking as a guy/government who invested(if) a huge amount of money and resources in developing such a state of the art malware, I can imagine that the entity that developed(if) this, wants something more practical than computers chatting to each other in a ghostly manner. Or where is/are the C&C server(s)? Sounds pretty stupid to me that in the months that Dragos is supposed to have studied this malware, that he haven’t came up with anything as simple and practical as this. And don’t tell me that he’s afraid of what could happen if he leaves the “ghosts” loose. At the level of visibility he’s gotten, if #badbios exists, the entity that developed it, already knows about Dragos more than Dragos himself. So this sounds rather as a #badJoke than #badBios.

    I’m surprised that nobody was asking this simple question. Anyway, it was nice to read the blog and the comments. Thanks @philip for demystifying this.

  64. Pingback: Bitcoin Weakness & Hack – WSWiR Episode 84 | WatchGuard Security Center

  65. Pingback: Tech Mind #44: Aggiornamento su badBIOS e PGP | EasyPodcast

  66. Pingback: Monday Morning JETLawg: Cybercrime and Cybersecurity | JETLaw: Vanderbilt Journal of Entertainment & Technology Law

  67. Just want to comment on the audio aspect: bridging the airgap using. Lots of commenters above assume the badbios would have to use high-frequency narrowband transmission. This is not correct. A spread sprectrum (SS) audio signal (e.g. using direct sequence pseudonoise modulation) would be better, and possible. SS would provide jamming and detection resistance, by using all of the available audio bandwith to send data via a low-power noise-like signal, masked by ambient sounds in the room.

    I’m not saying badbios is real. I am saying that objections based on narrowband audio transmission are flawed.