The badBIOS story is frustratingly short on details but this confused post seems to be making a lot of assumptions which add restrictions and then argue that it's impossible because of those guessed details:
1. He wastes time talking about “high frequency” as if it means radio EFI, which was never claimed and is an odd tangent.
2. Apparently at some point he actually read the original claims and realized that they were talking about sound and then makes the claim that this is simply impossible due to hardware limitations. See e.g. the running code at https://github.com/borismus/sonicnet.js demonstrating why this claim needed more than his personal assertion to be considered truth.
3. The main logical fault is the extended discussion about how limited the BIOS environment is, apparently under the belief that somehow everything must be implemented at that level rather than, say, shipping with different versions for various manufacturers which use that as a way to inject the actual payload into the OS. Put another way, what are the odds that someone would be competent enough to build any of the other pieces but not realize that you can do hardware detection and build a library of exploits for, say, common Mac laptops?
4. Claims about being able to catch this trivially by dumping the BIOS are suspect unless he's talking about extracting the chip and reading it on a known-good system — anything running on the suspect box runs into a textbook trust problem which isn't even acknowledged in this post.
He does address the high-frequency sound thing though. Basically, your laptop speaker will be lucky to transmit at near 20KHz and your laptop microphone would be even less likely to be able to pick up any ultrasonics that are supposedly being transmitted.
As for the specificity of the BIOS environment - he's saying you'd need to compile the BIOS code against the manufacturer's libraries AND make versions specific to board revisions. ESPECIALLY if you're doing stuff like initializing and using the soundcard (which he also addresses).
So for it to be true, this malware would be created by someone with access to several codebases and hardware docs, etc, of different motherboard manufacturers. Not to mention the test lab they must have to make sure this all works.
Not to mention the fact that in THREE YEARS none of this has been made open. OR a USB analyzer hasn't been tried, etc.
> He does address the high-frequency sound thing though. Basically, your laptop speaker will be lucky to transmit at near 20KHz
He asserted it but there are working demos showing this being possible. Which of the two is more convincing?
> As for the specificity of the BIOS environment - he's saying you'd need to compile the BIOS code against the manufacturer's libraries AND make versions specific to board revisions. ESPECIALLY if you're doing stuff like initializing and using the soundcard (which he also addresses).
The BIOS doesn't need to contain everything, only the portion needed to load an exploit which compromises the OS and uses the normal code to talk the soundcard, network, etc. Just as no operating system in existence needs to have per-board boot loaders, this doesn't need to do more than load the next stage.
> Way too many red flags here.
Again, I'm not saying the BadBIOS claims don't require proof - only that a post which is confused about those claims and makes arguments which are contradicted by running code isn't a good critique.
Yes, it looks more like a diary of somebody going insane (note: three years he sees it sometimes, now more often, he's "fighting" alone, he cuts the speaker and the mic in the notebook to block the malware, doesn't publish network captures, others see nothing in his BIOS captures (!)) than the pragmatic investigation of the real malware.
I kind of agree. Nothing in the badBIOS descriptions I've read is technically impossible — especially if you assume a vulnerability and updatable firmware in a widespread UHCI/EHCI implementation — but the story does sound a bit like other delusional people I've encountered on the net. The awful thing about being smart, competent, and crazy is that your own intelligence is working to construct the most bulletproof support it can for your delusion.
Hopefully someone will get some more definite evidence soon (eg, an external logic analyzer on the USB wires during a machine infection).
> belief that somehow everything must be implemented at that level
To make that concrete: I've known about commercial penetration test software[1] that uses multiple levels of agents, trading off footprint vs. capabilities, for over a decade. This is not even remotely a new idea.
That is not an example of what the author is talking about. Core agents are not implemented at different levels in the system vs bios sense. Impact doesn't have anything at all similar to what badbios is claimed to be doing.
Regarding #2: having this work would be hitting the frequency jackpot, especially with laptop gear.
Regarding the original claim: physically removing the microphone and speakers is a bad way to test for the networking hypothesis, unless you really wanna believe it.
There are multiple known examples of running code which does soundcard communication - see e.g. https://github.com/borismus/sonicnet.js. I can personally verify that it required no special handling to work on two laptops made by different manufacturers running different operating systems in a noisy room.
This doesn't mean that BadBIOS is true — only that it's annoying and tedious to play the skeptic with shoddy logic and trust-me assertions being presented as facts.
Can you describe your setup when doing this? It's also annoying and irritating having half the comment ignored. Don't care about the testimony unless it's backed up.
I made no changes, didn't turn off the music my phone was playing to a bluetooth speaker, etc. This is using the built-in speakers & mics at unadjusted volume levels – the only change I made was unmuting one of the two laptops.
To #3: how many exploits do you think you can fit in 383kB? That being the amount of free memory in his BIOS dump. Even assuming that you could find unused space inside other modules then how many exploits could fit even in 4MB?
You don't need to fit everything in 383KB: the initial vector claimed was a USB key so there's no reason that specific exploits couldn't be selected from a larger collection.
For that matter, since this thing is claimed to be on the visibly network there's also no reason why additional code couldn't be downloaded — the sound part is claimed as a slow covert channel for an already infected system.
For a different perspective, and Arduino (Uno) has 32kb of available RAM (minus a tiny bot used by the bootloader).
There's a tremendous amount of projects demonstrating amazing things that can be done with much less computing resources available than a BIOS. I have _very_ little doubt that bit-twiddled 12-20kHz audio communication could easily be implemented in under 10% of the 383kB that seems to be available. (Assuming the speaker and microphone are available as GPIO-like interfaces to the BIOS/CPU.)
To me it depends; a simple exploit, sure. The air-gapped ip over bare audio seems like it would take a fair amount of processing on its own, unless the system libraries provide signal analysis functions. Also, unless it can just decode raw bits and somehow shuffle them to the network layer of one of the existing adapters you're going to need quite a bit of code to handle that part of it as well.
Look at the 4KB demo scene from the early PC era to see just what is possible with sound and video in a tiny amount of space. Audio processing algorithms can be extremely simple and tiny.
This is way out of my league and maybe not relevant at all, but the Demoscene has forever changed how much I think about what can be accomplished with tiny amount of code.
unless it can just decode raw bits and somehow shuffle them to the network layer of one of the existing adapters you're going to need quite a bit of code to handle that part of it as well.
I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues.
The other option is that you don't have to do full tcp/ip over the "audio link" since it would only be used for specific types of traffic. If you control how the sender transmits you can ditch a ton of the tcp/ip logic and just hardcode to a minimalist subset of functionality.
> I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues.
Ignoring that this doesn't make any sense as a symptom for communication over an audio channel - the whole reason he believes that it is communicating is because a packet counter increased. Not because he has any logs, or because he observed it being controlled, or because he saw any code doing this.
Why are we even discussing the feasibility of the covert channel if the only reason that this topic was even introduced was because he saw packet counts increasing?
I can think of a million benign reasons why packet counts would increase on an unplugged system. That in no way means that the system is compromised or communicating externally. It's not even a reason to be suspicious.
if the only reason that this topic was even introduced was because he saw packet counts increasing?
He saw packet counts increasing and it stopped when he disabled the audio hardware. Then there is all the other circumstantial evidence regarding booting from a CD, "self-healing" and systemic blocking of his debug attempts.
I think it is absolutely fair to critique the individual symptoms but the one critique that doesn't fly is that an individual symptom is the only symptom.
Ignoring that this doesn't make any sense as a symptom for communication over an audio channel
"After doing a software update, my Mac Pro got stuck on the gray screen after restart (seems like a very common problem recently). I am able to boot into safe mode by holding shift (only works like 10% of the time) and verified permissions. It says I need to repair my disk, but i can only do this by booting from my install disk.
However, I can not boot from my install disk. It gets stuck at the gray screen every single time."
> "self-healing"
Didn't happen. Because there was nothing to self-heal.
> and systemic blocking of his debug attempts.
It didn't block any debug attempts. He says it disappears on him when he goes to look at it. That's because it isn't there. That's like saying the ghost beside me is evading my photography attempts, and citing this evasion as proof that something is up.
> In what way does that not make sense?
Beeps on the speakers or listening on the mic doesn't involve packets to begin with! Even if that was true, it wouldn't make packet counts go up. You would have to go out of your way to implement this in the stupidest possible way for your audio channel to have anything to do with a network interface. Compared to the obvious way, it would take way more code, completely ruin your stealth, be far less reliable, and add a ton of packet header overhead over what is already extremely low bandwidth. You cannot be smart enough to implement this malware and also be stupid enough to put your covert channel through network interfaces. Yet we are supposed to believe it's so stealthy that no debugging tools can see it ever, and it's disappearing from low level memory accesses and disk reads wherever he looks for it. But it's spewing packets out on an interface that it doesn't actually need to communicate. I mean...really?
But it's spewing packets out on an interface that it doesn't actually need to communicate. I mean...really?
Because bridging an air-gap firewall is the holy grail of network penetration. You can't discover the guy on the other side of the air-gap without "spewing" announcement packets.
Yes you can. By spewing them on the audio interface, which wireshark doesn't monitor and decode into packets, instead of onto a network interface, which is easily monitored. Especially when there is no reason to involve the network interface at all.
Beeps on the speakers or listening on the mic doesn't involve packets to begin with!
All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance.
Then there is the Blurt project - an 802.11 physical layer interface that runs over speakers and microphones. Its early stage but its just one guy hacking at it, not some billion dollar spy agency.
> All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance.
No, but evidently yours is. Sorry, this is quite straightforward to anyone who has ever used a packet sniffer. The fact that it's analog has nothing whatsoever to do with how packet sniffers work, and he wasn't monitoring a serial bus.
Blurt doesn't do what is being described here. It wouldn't show up in packet logs. Which proves my point.
Your conflating "serial bus" with serial transmission suggests that you don't even have the vocabulary necessary to participate in an informed discussion on the topic. Because of that I am kind of at a loss for where exactly to begin.
Here's a simplified start: all common network interfaces transmit serially at the physical layer - one bit at a time, wired ethernet, wifi, 3G/4G/LTE, WiMAX, fibre channel, dsl. None of them are inherently packetized at the very lowest level, they are all just a series of bits. Packetization is done through either synchronous clocking (fixed transmission periods) or, more commonly today, asynchronously via a special sequence of bits that indicate start/stop of a packet.
This is layer 1 of the OSI 7 layer model, we are not even talking packetization like a typical packet sniffer would see, that comes after the physical interface has decoded the transmission like OFDM and undone the 8b/10b then stripped off the bits that make up stuff like the preamble and frame delimiter in the case of ethernet.
Packet sniffers typically work at layer 2, where you can see things like MAC addresses or layer 3 where you see full-fledged IP packets. You run wireshark and you won't see things frame-start bits or the 8b/10b encoding because all that stuff is going on at a level that packet sniffers aren't intended for.
Any audio-based network system like Blurt and the suspected BadBios mechanism would be a full layer 1 implementation. They might do higher layers too or they might encapsulate IP packets and hand them off to the OS's network stack to handle, but the idea that "beeps" don't involve packets is pure ignorance of how modern datacomm systems work. It is ALL analog "beeps" at the lowest level, be it EM "beeps" or audio "beeps." Packetization occurs further up the stack.
Are you actually thinking before you say this? None of this is relevant to the claim being made and you're attacking a straw man. Let me make it really simple:
1. Play audio on one endpoint and record it from another
2. Open wireshark
YOU WON'T SEE THE AUDIO.
This is how he claimed to see it was communicating. Over IPv6 no less. IF it was happening, it wouldn't show up in a packet sniffer.
I am confused, do you mean that in the general case? That I should do that experiment right now and because wireshark won't show anything on my systems, that means whatever is going on with his systems is made up?
Yes. Whether your mic is picking up background noise, your own voice, or a legitimate modulated covert channel, wireshark is incapable of even attempting to pretend it's a network interface. At no point could this ever show up in wireshark.
I strongly suggest you try using a packet sniffer before you stubbornly engage in arguments about what they can and can't see.
I will send you $100 if you can configure wireshark to do what you describe. Using any of the tools in this thread, or any of your own, go ahead and try capturing even 1 packet from an audio interface in wireshark and post the pcap file.
It's not over anyone's head - we have interns who understand why this doesn't work. I have no idea why you might think it would.
Why do you need IP over airgap? A basic carrier sense scheme with maybe a 44khz fft can ensure atleast a slow speed networking even an arduino with 16kb(or probably even 8kb) flash can do this. This isnt like wifi where you would need complex signal analysis.
No, this is about keeping the discussion focused on facts and logic rather than strawmen and assertions. Right now, the onus is on Ruiu to provide more evidence but it's just adding noise if people start attacking claims he hasn't made or asserting that their personal knowledge is the limit of what is possible (e.g. all of the people claiming the soundcard channel couldn't work).
Dragos's original writing is, in fact, mostly incoherent, and highly suspect. However, this article seems to be almost as far out.
For instance, the author of this story claims that UEFI binaries are not compatible with each other. The kernel and processor support blobs of a UEFI ROM are not interchangeable, but more and more, the drivers are: UEFI does not just provide an API, but it also provides an ABI for both drivers and binaries to run. (That's the whole point of it.) Graphics card vendors do not have to produce a new driver for each UEFI implementation and motherboard; and, of course, Microsoft and Red Hat each produce just one UEFI bootloader shim, designed to run on every UEFI-compatible machine. The modular structure of UEFI ROM images, if anything, makes it more plausible that malware could inject itself "cleanly"! [1]
The argument about the BIOS not being able to initialize sound hardware is also surprisingly less-than-true these days. A handful of UEFI ROMs are now capable of calling up the sound card to "speak" error messages, if things have gone wrong during boot. The audio codecs, even if the UEFI ROM doesn't have code of its own to initialize, are relatively well-known, and easy to find datasheets for; I would imagine that a driver for one could be packed into 5 to 10kB of tightly written code, so there's no reason why the BIOS couldn't have this.
As acdha said upthread, too, there are other problems: the author conflates RF and audio frequencies; the BIOS protects its read access through System Management Mode (and hence could hide itself); etc., etc., etc.
Now, none of what I said here is to say that I believe Dragos's claims -- I don't. There are lots of good ways to dismantle his claims, and many people already have. But, well, the "the BadBIOS Analysis is wrong" is wrong.
[1] The author also gets quite a lot more wrong about the PC boot sequence in his technicalities. For instance, the "2Mhz 8088" is just not true these days; different processors boot in different ways, and most of the time, there is not even any DRAM available when the first instructions run! I put this as an aside because it is not part of my main point, but it serves to illustrate additionally how the author is using things that just aren't quite right to back up his argument.
(edited: removed excessive ad hominem against the author. My apologies.)
As to your aside: the 2mhz 8086 claim was about UEFI Shell - which is as close to native (usually 64bit) UEFI code as can be.
That, and the "UEFI binaries are unportable" bit really indicate that the author doesn't know very much about UEFI.
(Aside of my own: there are typically at most two places in x86 UEFI where you can find 16bit code: first at the init vector, where it sets up the system to move to 32bit - and then 64bit modes - as fast as possible, even before initializing DRAM at all. The other place is the CSM, which provides the legacy BIOS interface, if necessary)
Could you link some of the good Dragos debunkings?
I should disclaim that I know nothing about the author of this piece, and my knowledge of this whole area of computing is extremely limited. I just mostly suspect that the BadBIOS story is ridiculous.
> I just mostly suspect that the BadBIOS story is ridiculous.
I agree. The Ars piece yesterday seemed a bit paranoid and short on details. Then this piece today seems to be blowing smoke in the opposite direction. Somewhere in between lies the truth.
I'm hoping we'll hear of something more concrete in the coming days or weeks.
I would like to point out that the modern way to er.. "sidestep" the windows activation process on a UEFI system is to simply install a new bootloader. This is accomplished simply by writing a compiled EFI program to the EFI boot partition and setting it as your bootloader. It them lies to the kernel and makes it think it's running on an already-activated OEM system. Look up WindSLIC, I can't really give a link here for obvious reasons.
To note: this is a single binary that works on all x86_64 UEFI systems and can be written to the boot partition as any other file. Additionally, you can write a program to change boot order on UEFI bioses from within a running OS; example: efibootmgr. So while it is probably infeasible to infect the BIOS itself, it is somewhat trivial to infect the bootloader and do whatever you desire.
Infecting the bootloader has been a known technique for a while though (google "bootkits") - long before UEFI, actually. They are the whole reason behind Microsoft pushing for SecureBoot. This is not new, nor what badBIOS is supposedly about.
I honestly didn't think that anyone was seriously saying that the BIOS code was doing all that, just that the BIOS was infected so that it boots the malware instead of an OS.
Or you can use the malware to affect the behavior of a known OS and get it to do the rest of the work for you.
IIRC, the Code Red worm wasn't a terribly large exhibit of malware, but it still managed to propagate.
As it stands, I think the biggest complaint currently regarding badBIOS is the lack of information. Until we find out more, much of the commentary in the linked article (and the comments here and elsewhere) are little more than conjecture.
Still, conjecture can be fun! Let your imaginations run wild--until we get something more concrete.
> 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.
You only need to transmit the carrier at the high (inaudible) frequency, you can receive at any sub harmonic frequency as long as the transmission protocol is designed with this in mind.
So a carrier signal broadcast at 20KHz (within the range of the speakers) but inaudible to most humans can be picked up by sampling at 10KHz (within the range of laptop microphones). The protocol just needs to send each bit twice (or any multiple of two) at 20KHz.
Your sentence "The protocol just needs to send each bit twice (or any multiple of two) at 20KHz." nearly makes no sense. You should learn about modulation, sampling, aliasing, and so over.
If you want to stay ultrasonic you will need to use a narrow bandwidth around 20k, otherwise people with a good hearing and children will be able to hear it. I don't think you'll be able to receive anything useful by using a cheap PC microphone at 10k in those conditions, especially if you use it in the way it is intended to be used (the hardware will filter out high freq to prevent aliasing)... Maybe there is a convoluted way to receive a specially crafted transmission by sampling in a subharmonic when a special antialias filter (or no filter at all in otherwise quiet environment) is used.
I don't see much point in trying to use such a channel to transmit bios malware related stuff anyway. The original badBios article seems to be just a joke.
I think it'd be much easier to use spread-spectrum techniques. With enough coding gain the signal can even be well below the noise floor and still reliably recoverable. (This is the spread-spectrum equivalent to sending a very narrowband signal and receiving it through a very narrowband filter.) Generating a DSSS waveform is extremely computationally cheap; receiving one is less so, but probably still negligible amount of cpu time on a modern processor.
Considering how much research goes into these bootkits/rootkits lately, it is interesting. Kernelmode has some ideas on it(http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2998) and are running a thread on it. This is a rather unique malware though if it even does the airgap communication as well.
Bootkits have nothing to do with what is described by this article and badbios. They reside on the filesystem.
The thread you linked to doesn't contain any findings, but it does contain an analysis of Dragos' UEFI showing it to be completely clean, with the code matching the original factory image.
Leaving aside the crazy hypothesis coming from nowhere about sound transmission, what can probably be done is hiding a persistent malware in a microcontroler connected to the smbus. Very hard to detect, most (all?) modern motherboards already have at least one, FW distinct from the bios, might not be even readable without a dedicated hardware programmer and custom wiring (even in this case the FW might be locked down), and probably can own the whole system.
IIRC the smbus goes pretty much everywhere in a modern computer.
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?
This is absolutely insane, and I don't know what to believe. I do however enjoy thinking about the possibilities that exist in our world.
I'm not sure why he assumes the entire virus would be implemented in BIOS, as opposed to injecting code into the OS when it loads code of the disk during boot. Still kinda out there, though.
1. He wastes time talking about “high frequency” as if it means radio EFI, which was never claimed and is an odd tangent.
2. Apparently at some point he actually read the original claims and realized that they were talking about sound and then makes the claim that this is simply impossible due to hardware limitations. See e.g. the running code at https://github.com/borismus/sonicnet.js demonstrating why this claim needed more than his personal assertion to be considered truth.
3. The main logical fault is the extended discussion about how limited the BIOS environment is, apparently under the belief that somehow everything must be implemented at that level rather than, say, shipping with different versions for various manufacturers which use that as a way to inject the actual payload into the OS. Put another way, what are the odds that someone would be competent enough to build any of the other pieces but not realize that you can do hardware detection and build a library of exploits for, say, common Mac laptops?
4. Claims about being able to catch this trivially by dumping the BIOS are suspect unless he's talking about extracting the chip and reading it on a known-good system — anything running on the suspect box runs into a textbook trust problem which isn't even acknowledged in this post.