

The BadBIOS Analysis is Wrong - llimllib
http://www.rootwyrm.com/2013/11/the-badbios-analysis-is-wrong/

======
acdha
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](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.

~~~
Fr0styMatt
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.

Way too many red flags here.

~~~
acqq
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.

~~~
wiml
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).

------
jwise0
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.)

~~~
llimllib
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.

~~~
Zancarius
> 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.

------
anonymous
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.

~~~
delroth
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.

------
jevinskie
This is a hard article to read between the arrogance of the author and their
writing style (I counted six instances of "Period.").

~~~
jaxbot
While you nitpick on grammar, I'll remind you that "their" is plural. ;) /s

~~~
gfody
He obviously meant the indefinite, generic and epicene, non-referring anaphor
"their" and not the definite, plural, referring pronoun "their".

------
wmt
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.

~~~
Zancarius
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.

------
alexkus
> 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.

~~~
xorblurb
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.

------
tptacek
Looking around for that animated GIF of a young Michael Jackson eating popcorn
in the movie theater...

~~~
llimllib
I reply to the important comments.
[http://media.giphy.com/media/ftXvsSyRzKXXG/giphy.gif](http://media.giphy.com/media/ftXvsSyRzKXXG/giphy.gif)

------
jlgaddis
FWIW, @rootwyrm is a pretentious know-it-all. Take anything he claims with a
grain of salt.

------
switch33
Uhm. . . [http://www.slideshare.net/matrosov/modern-bootkit-trends-
byp...](http://www.slideshare.net/matrosov/modern-bootkit-trends-bypassing-
kernelmode-signing-policy)

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](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.

~~~
lawnchair_larry
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.

------
xorblurb
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.

------
mb0
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?

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.

------
diorray
I still think it's a halloween prank

~~~
sitkack
It feels like it. It also feels like it has kickstarted the real thing. I feel
like working on it myself.

------
wcummings
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.

------
yuhong
As a side note, I wonder why nobody bothered to create a UEFI sound protocol.

~~~
geofft
I've heard that this was a deliberate limitation so that nobody has the clever
plan of trying to run their general-purpose OS without leaving UEFI.

And that accessibility means that it'll probably end up getting created sooner
or later.

------
od2m
THANK YOU!

