<i>35c3 preroll music</i>

Herald: So, Dennis, the left speaker,
finished his M.Sc. in IT security this

year. The next talk is based on his master
thesis, InternalBlue, which is a Bluetooth

experimentation framework for which he
even received a prize. Jiska, the right

speaker, or for you left speaker, has been
his supervisor during the thesis and she

loves breaking things. After several talks
about wireless security, software-defined

radio and Fitbits, she is now talking
about Bluetooth. Please welcome on stage

Dennis Mantz and Jiska Classen to their
talk "Dissecting Broadcom Bluetooth".

<i>Applause</i>
Dennis: Yeah. Thank you for the

introduction and welcome you all to our
talk. I'm Dennis and as said I choose

Bluetooth as the topic for my master's
thesis and the outcome basically was I

reverse engineered the firmware of a
Bluetooth controller which was

manufactured by Broadcom, and I built a
little experimentation framework around

it. And today we are not only going to
present the framework, but also various

kinds of use cases around it, and we also
brought along some demos. Now, if you

start such a big reversing project you
certainly know that this will not be an

easy task and also quite time consuming.
So you might want to ask: why did we do

that in the first place? So there are
several good reasons. For one, dissecting

the firmware and exploring it for
reverse engineering is really helpful if

you want to get insights from a security
perspective. And this is what I had in

mind when I first started my thesis. But
then secondly and even better, once you're

able to modify the firmware you can
actually leverage this fully featured and

working Bluetooth implementation to be
your very own experimentation platform, where

you can add new features or can also alter
existing behavior, and it almost feels

like you can add a kind of open source
touch to a closed source and proprietary

platform which I really like about this
project. Certainly this requires a certain

background in many different departments
like security, code analysis, wireless

signals, embedded programming, and also
not every researcher has resources and

time to do such a reverse engineering
project, but we think that the outcomes of

this project are really helpful and
beneficial for the security community. So,

and last but not least we actually really
like reverse engineering. So we already

had great experiences with similar
projects in the past. For example, some of

you might know the NexMon project, where
we reverse engineered and also modified

the firmware of a Wi-Fi controller. Okay,
before we show our work, we first have to

introduce a few Bluetooth protocols which
we will be mentioning quite a lot

throughout this talk. So the first one
would be the host controller interface.

Some of you might know that, it's the HCI,
and it's a protocol layer between the

Bluetooth controller and the host system,
where the health system would be for

example an Android phone, or iOS, or
Linux, or any other operating system which

implements those upper layers of the
Bluetooth protocol stack, and all the

lower layers are actually implemented
inside the Bluetooth controller. And one

of them would be for example the Link
Manager Protocol, the LMP. And this one is

also really interesting. It actually
manages connections to other remote

Bluetooth devices. For example, pairing is
also done on this protocol layer. And

what's an interesting difference is that
the Link Manager Protocol is actually

transmitted over the air to communicate
with other devices, whereas the HCI

protocol is only used locally to
communicate between the operating system

and the Bluetooth controller. And another
interesting fact to know is that the HCI

is actually able to be observable from the
host site. So if you maybe tried to capture

on a Bluetooth interface in Linux before,
or if you turned on the BT snoop log

feature under the development settings in
Android, you probably have seen HCI packets

in Wireshark before, because this is an
easy task to do. However you probably did

not see LMP packets in Wireshark before,
because this protocol layer is actually

implemented inside the controller and it's
not observable from the host side. You

won't see those packets if you just
capture on a Bluetooth interface because

you can only see what's above the HCI
layer. And so the other thing is that you

cannot also simply sniff this from the air
because Bluetooth has frequency hopping

and encryption. So it's a lot harder to
sniff those packets from the air just as

with Wi-Fi for example. But today we try
to change that. Now I will introduce the

framework I developed and show its
features, and later we go into more

details and also present some demos. As
already mentioned, we named the framework

InternalBlue. It's open source and you can
find it on GitHub and currently it's only

compatible with the Nexus 5 if you want to
use all of its features, but we are also

working to port it to other Bluetooth
chips in other smartphones, and also other

platforms like the Raspberry Pi, and yeah,
soon you will have more devices which are

supported by this framework. We also
already gave a talk where we introduced

the framework and give some details about
the internals and how it works. So if

you're interested and want to learn more
then you should check out our previous

talk which was also recorded and you can
find a link down at the bottom of the

slide as well. Basically in a nutshell we
use vendor specific HCI commands which are

implemented by Broadcom and allow us to
read out and modify the firmware while the

chip is actually running. And on top of
this, we basically implemented a Python

API to interact with the firmware, and we
use this API to then implement all kinds

of features which we find interesting. For
example one of the first things we did was

implementing such a LMP monitoring mode so
that we can finally see LMP traffic on our

laptop in Wireshark. And what comes along
with this is that we are also able to

inject arbitrary LMP packets inside
existing Bluetooth connections. And this

turned out to be also very interesting
because then we can test how other devices

react to maybe packets they don't accept
or yeah, at least it's very good for

experimentation and for example we use
this to write a little proof of concept

script for the fixed coordinate invalid
curve attack that was released this

summer, not by us but by other
researchers, and we were able to actually

prove that other devices are vulnerable to
this attack. So this is a really helpful

and practical tool. Also, at some point we
found a crash our own. So we found back in

some older Broadcom firmwares which allows
us to remotely crash the firmware in some

of the Broadcom chips, and in some cases
we are even able to execute a limited set

of functions, so this might be even more
interesting than just a crash - but more

on that later. Now if you first start with
the main thing about this is, how do we

actually modify the firmware, How is
patching being done? And I already said

that Broadcom uses those vendor-specific
HCI commands. To read them out, they are:

READ_RAM, WRITE_RAM and LAUNCH_RAM, and
they do exactly what you think they would

do. So basically we are able to read and
write in the address space of the

firmware, and also to execute arbitrary
code snippets in the context of the

firmware. And this is pretty powerful.
Broadcom actually uses this to do their

firmware updates, so they ship so-
called HCD files, which are files that

contain firmware updates. If you have a
Broadcom chip inside your laptop or inside

your phone, you should find such a file
with the extension ".hcd" on your

filesystem, and those files actually
contain just a sequence of those commands

to upload all the changes and patches, and
they're even able to do temporary patches

to the ROM of the firmware by another
mechanism that they call "Patchram." We also

had to reverse engineer this and now we
are finally able to do all those patching

ourselves. Now, what is also interesting
is that those files, the .hcd files, are

neither encrypted nor signed. So it's
quite easy to actually modify them once

you understand how they work. And also the
firmware itself on the controller is not

obfuscated. So there are basically no
major attempts done by Broadcom to prevent

anyone to reverse engineer and modify
this firmware. Currently, we write our

code and assembler, so we write assembler
patches, but we're working on including

this in our NexMon project to finally be
able to write patches in C code, which

will be more comfortable and portable.
First of course we have to do the

reversing.
Jiska: Yeah. So as Dennis told you the

code is not obfuscated but there is no
strings and no function names. So you end

up with thousands of functions that just
have no name, it's just sub 1, sub 2, sub

some-thousand something. And then there is
a tool that I used which is called CodeCut

to try to separate those functions into
modules. But also the modules don't really

tell you that much because the problem is:
then you have hundreds of modules and then

you know which modules are central and you
might to start reversing but it's not

really fun. You have 2800 pages of
Bluetooth standards, you might have some

parameter checks in there, so you have
bounds which the parameters should be in,

and then you search for those numbers
again in assembly code and you might find

some matches and then you have concrete
functions. So that's what we both did for

months. staring at standards, staring at
the code. Then people asked me: "Yes,

that's not nice, but does it work on on
recent devices?" And now the problem is

even the Nexus 6P has a firmware from end
of 2014. So I just decided to buy a

development board, which has also a
slightly outdated firmware, I mean just

one year old. Meanwhile, this part of
Broadcom was acquired by Cypress so it's

called Cypress. But it doesn't matter,
it's still the same mechanisms in there.

And I was able to use the same HCI
commands, so I can still modify the

firmware on this, I can extract the
firmware, and actually I just got that on

December 6, and 3 days later I had all
function names because somewhere someone

forgot a patch.elf with all function names
in the development kit. So that's 11 000

function names, 3000 object names. Nice.
Yeah.

<i>Applause</i>
J: So, buy development kits earlier.

<i>Laughter</i>
D: OK. Let's get closer to the first demo.

So as mentioned we have this Link Manager
Protocol which does interesting things

like pairing and all kinds of stuff. And
it's implemented in the firmware so we

cannot really see it from outside, we
cannot capture it in Wireshark. And we

wanted to change that. So we wrote a patch
that will actually hook some of the

functions inside the firmware, those that
are handling LMP, to actually forward all

the traffic over the HCI interface back to
our Android phone. And then on the Android

phone we use a Android Bluetooth stack
which has debugging features compiled into

it so that we can also forward all the HCI
traffic via TCP to our host computer. And

from there we can then show it in
Wireshark. We use a custom LMP dissector

plugin which we borrowed from the
Ubertooth project. And yeah, that's it. We

have a LMP monitor mode. I will show that
in just a second. We also have an LMP

injection mode, so we can simply invoke
functions inside the firmware. And so we

can also invoke the function which
actually sends LMP packets to other

devices which are connected to our Nexus
5. And so, yeah, with this we have both

channels of the communication and can
actually send arbitrary traffic to other

devices. So, for this let's go into a
command line and start the framework. The

framework has a command line interface we
can use all of its features and interact

with the firmware and to start a monitor
mode, I can just type this command which

will start a Wireshark instance and also
install all the patches which we need into

the firmware of the phone. Now from this
time on, we actually have all LMP traffic

forwarded and shown in the Wireshark
frame, but currently we don't have a

Bluetooth connection, that's why you don't
see anything. Ok. Yeah, so we still need a

Bluetooth connection, right? I could just
pair those devices to create a connection

and then we would see LMP traffic, but I
want to show something else. So this will

be a combined demo actually, because
Bluetooth has some more interesting

features which maybe not everyone knows -
at least for me that was a surprise when I

first learned about this. So even if your
device is not being set to be discoverable

by other devices, it still accepts
connections from any other device, the

other device just needs to know your MAC
address and can simply connect to you,

without even being paired before, you
don't even notice this because the device

does not have to trigger the pairing
process, and then the user won't be

notified. And so by just finding out the
MAC address of any other device I can

connect to it on this LMP layer and start
communicating with it. And finding out the

MAC address is also not that hard. There
was another talk which we mention down on

the bottom of the slide, it's called
"Bluetooth smells like chicken" by Dominik

Spill, Michael Ossmann and Mark Steward,
which shows that this is actually possible

and not hard to do. So, I can actually
just type "connect" and give it the MAC

address of another phone.
J: We need again... ah great.

D: Yes. Perfect! On the right side you
actually see a Nexus 6P, which will be our

target. You can hopefully barely read the
MAC address which is shown there on the

left side as the Nexus 5 which is the
phone we use for for testing like the

phone which is connected to my laptop here
and is used for InternalBlue. And as you

also can see the Nexus 6P is currently not
in the Bluetooth menu, so it's not

actually discoverable by by means of
Bluetooth. I still can connect to it when

I actually type "connect" and the MAC
address this might may take a few ... no

it worked directly, perfect. So now we can
see that we actually have traffic on the

LMP layer. What you also might notice that
that on the Nexus 6P there wasn't

anything. So the user didn't notice, but I
have an established connection to this

other phone and you can see the LMP
traffic which is going on on this protocol

layer. As you can see it is quite a lot:
There are feature requests, version

requests, also name requests so that the
phones know how the name of each other is.

And yeah, from now on I can also try to
inject arbitrary LMP packets. For

example I can send an LMP packet with code
"01" which would be a name request and ask

for a name at offset 0. And you should see
that the name request has popped up here

and the other device even answered with
its name. If you scroll down here should

at some point see that we have the name
"Nexus 6P" because we don't renamed our

devices. But I can also send
arbitrary LMP packets so I'm not bound to

anything that is in the specification.
J: You already got the detach!

D: So the other device actually detached
which happens from time to time ... can

reconnect.
J: If we don't do anything in between we

will get a detach from the other device
because we didn't do a paring or something

so we re-established connection. And now
Dennis is going to send something that is

not specified ... just an LMP 99.
D: So it's even saying here this is

unknown. But as you can see the payload is
actually sent and the other device

correctly answers with "this is not
accepted and I don't want this". But you

can probably see that this is very
interesting for a security researcher,

because now he can see how the other
device happens in certain conditions, if

you send them certain packets. Yeah. Quite
nice to actually experiment with. OK. I

think that's it for the first demo. Let's
stop this and go back to this.

J: I don't need the in-screen anymore.
Yeah. Great. Okay.

<i>Applause</i>
D: Thank you.

J: Another thing in the Bluetooth standard
is that you need a possibility to pair

devices, which have no input and no output
capability, so they cannot show a PIN and

you cannot enter a PIN. And this is the
standard for any headset. But also a Man-

in-the-Middle can change the input/output
capabilities and then you might just get

displayed this "yes/no" pairing without a
PIN request. Even though your smartphone

could show more than this. And I have a
demo video again of the same thing. That's

this one. So on the left hand side I have
again a Nexus 5 on the right hand side I

have an iPhone and I am pairing them. I
just changed the request and the

capabilities that it's, that I'm not having
input output capability. So you can see on

the right hand side on the iPhone it's
just showing this "yes/no" question. And

on the left hand side you still have the
same algorithm which just does the same

thing. So pairing will succeed, there's
the same cryptographic routines but you

are not being warned on the iPhone and
that's a bit critical. So the standard is

not saying: "Please warn the user to check
if the other phone really has no input

output." So I just say pair and it pairs.

Yup.
<i>Applause</i>

So far that's only things that are as

they are in the standard, so it's not too
surprising. So the question is: Can we

find more bugs? Yeah. Finding bugs in
Bluetooth. Actually I didn't even want to

find bugs in the beginning, I just wanted
to understand how everything works. So I

went through the handlers and I checked
the... there's these checks of the

parameters, so there is a parameter check
in the beginning of each handler that

shows me a bit which handler it could be
according to the standard. And suddenly

there is a handler which does not have any
check. So there's just the missing "if"

somewhere. And then I compared to firmware
versions that I had and found out they

silently patched that already some time
between June 2nd and August 19th in 2014.

But they never updated older devices, so
they never shipped an .hcd-patch. So I

contacted Broadcom and said: "Yeah you
have a problem!" and they said "No, we

don't." And I said: "You really have a
problem there." And so on... And then they

said: "It doesn't exist." And then I
showed them more and then they said "Yeah

ok, but it's not compliant to the standard
what you're doing!"

<i>Laughter</i>
<i>Applause</i>

I'm sorry, my next exploit will be
standard complaint.

<i>Laughter</i>
And then we discussed a bit more and then

they said: "It does not affect Wi-Fi
performance." Well, in my tests it did...

whatever... doesn't matter. So basically
you can switch off Bluetooth on another

device and then Bluetooth restarts
typically depending on configuration. And

as Broadcom didn't tell me much about this
I started testing out things on my own. So

which devices actually still have a
firmware that is affected in their

Broadcom chip? It's quite a lot. So it's
like the iPhone 6, MacBook Pro from 2016,

of course my Nexus 5, Raspberry Pi 3 and
so on. And this list is really not

complete this is just like, I asked my
students: "Can I test your smartphone?"

Some of them said: "No. Are you crazy?!"
<i>Laughter</i>

And that's the list I got just during the
last weeks. And this is the one I'm going

to demo. I just named it BT-B-g0ne, so you
can kill the Bluetooth of annoying songs

or something.
<i>Applause</i>

So I need to go into the Bluetooth here,
yeah, screen-in-screen... That's great. I

even had a "Bluetooth is not real" and so
on. That's really great. What is going on

here.
D: OK.

J: Yeah let's go for the demo. So first we
are going to patch the Nexus 5 with our

funny attack and then just press enter and
now it takes a while until the the iPhone

is realizing like "Oops my Bluetooth is
gone." So if I'm playing music you will

see it faster, the music would already
stop playing. Let me just enter another

time. Just... Yes, and there it's gone!
Oops!

<i>Applause</i>

And then it appears again and so on I can

just do it again and again and again. And
it's actually so fast that the other

person could not play music, because music
also stops playing after this disconnect.

Yeah that's the demo. Now we were
wondering, yeah, what is actually

happening. So actually that the crash -
the crash is the best case. So there is a

handler. I call it "Handler A", because
I'm not leaking the actual problem here.

Broadcom didn't fix it yet. So there is
this handler which just should take, let's

say, two arguments or something. But it
doesn't check the parameter range and the

compiler likes to put one handler after
the other. And then we just go into the

next handler, and so we have something
like 250 functions that we can call from

the next handler but with wrong
parameters. So it's a bit buggy, and

sometimes if a function expects to get
other parameters it just crashes. But

otherwise we can execute functions. And on
the Nexus 5 we looked a bit more into this

and I found out that I can enable test
mode. So test mode should be something

only locally to be enabled on a phone if
you have root access to the driver and

then you tell the driver: "I'm now going
to test your frequencies and so on please

go in test mode." But I can now do this
remotely.

<i>Applause</i>

So I didn't bring this one as a live demo.

I mean I have a HackRF with me, we can do
that during Q and A, because the problem

is there is probably too much going on in
the spectrum here and you wouldn't see the

test mode starting anyway. So I'm just
doing the attack and then on the left hand

side, I just took a quick pause, you can
see the test mode, so that's just the

default test mode hopping around in all
channels. The packets now appear a bit out

of order because I just put them into a
queue, send them. This "???" payload is

the malicious payload. I just send
"test_control" and "test_activate". And

first they get this not_accepted. And then
after this "???" payload you can see that

it's accepted. And on the left hand side
you can still see that there is the test

mode going on, so really block things for
longer time. And then it's accepted, magic!

<i>Applause</i>

If you combine this with disabling
adaptive frequency hopping you can even

force the other device, which is also then
in test mode, to stop hopping for a while

and then just jam a selected frequency, so
you could also jam a selected Wi-Fi

frequency that this device is currently
using. And it's a combo chip, so you would

really be on the same antenna. We can
confirm this works on Nexus 5 and Xperia

Z3, because they both have to be same
BCM4339 chip. It might also work on other

devices with that chip. It's a bit random
to find out what is in there. You need to

find teardowns and on. So when finding
this bug we started developing a

toolchain. So Dennis added a feature for
tracepoints. You can add now a tracepoint

to a function which is then called once
and dumps all the registers and the stack

and heap. I then fed this into an
emulation framework, which is currently

quite slow with unicorn and radare2,
but I get a full call trace, which is very

nice to look at. So I have an idea what is
going on, what is changed in the memory.

And I currently have a student working on
a qemu/gdb set up, which is faster but

producing less output, just to fuzz more
efficiently. However, you get really a lot

of output that we weren't able to
completely analyze yet, so there's

probably more. Maybe tell you somewhen
later. Now you need to somehow fix that

bug. And that's that's really a problem,
and that's also why I didn't tell you the

exact payload that is causing these
issues. Because, well, the fix would be in

one of those .hcd-files. It would be
plaintext. It would not be signed and it

would just tell you directly "This handler
is vulnerable in exactly this position!"

and so on. The patch is just 14 bytes, but
you need to install it and then it's easy

to understand what it does, right? So I
had an idea: Let's do some more generic

fix. So what I planned to do was having a
generic filter, filtering some packets

like that you won't reply to, pings
connection establishments and so on, to

untrusted devices. And then just over
Christmas I started testing that one with

bigger setups, with more phones and so on.
And then I realized: OK if I throw away

some packets and the other device does not
expect me to throw away packets, then the

Bluetooth stack of a device which now
tries to connect to me is going to crash.

So I had the next bug! So I tried to fix
one bug. I get the next bug, you know

this. So I actually cannot release any
fix, because ... uh. Yeah. Because all of

them still cause the next bug and so on.
So how long will this bug be around?

Pretty long probably because there is some
devices which are no longer getting vendor

updates. It needs to be in the vendor
update, it needs to be this special .hcd-

file. And so on. I mean we can also
publish .hcd-files if needed. That's

possible with our framework. That's the good
news, but it will probably never be an

official update. And the vendor updates
will obviously leak the vulnerability. So

it's chicken-egg. As we found this bug
still to be present in devices that were

produced in 2016, we recommend you to turn
off Bluetooth - especially if you have a

Broadcom chipset produced before 2017.
But in general just turn it off. That's

probably the safest option. And we found
out that very old devices having something

like Bluetooth 3.0 are not vulnerable,
because that feature that we used didn't

exist back then. But still it's a large
number of devices having this issue.

So, thanks for listening.

<i>Long Applause</i>

Herald: And again if you have questions we
have 8 microphones in the hall. Please

line up at the microphones and you can ask
your questions.

The Signal Angel has the first
question from the Internet.

Signal Angel: Yes some of the Internet
asked if you can guess the Bluetooth MAC

address from the wifi MAC address of a device.
Jiska: Yes. So if I go into... Can we

switch the camera on again? On my magic
box here. Is that possible? Yes. So

actually, if you go to the "Settings",
"About", and then you will see that the

WiFi and Bluetooth MAC address, they are
just off by one.

<i>Laughter and applause</i>
Dennis: So yeah. You have to note however

that this is not the case with every
phone. So usually I think new phones

actually try to randomize their Wi-Fi MAC
address to be not traceable anymore. Not

sure which devices do that. I think the
Nexus 6P does that so the first part will

be the same, because it specifies which
vendor this chip was made from. But then,

the lower and least significant bits will
change. So it's sometimes possible,

sometimes not. Yeah. I think that's the
answer to this question.

Herald: OK. The next question was from the
microphone 8 at the very end of the hall.

Eight: Hello. Thanks for your talk. I was

wondering in your second demo, you showed
us how you connect to a device, just using

the MAC address and this device was not
advertising his name. How do you find a

MAC address, if it's not advertising?
Dennis: Yeah. So there are ways to find

out the MAC address of devices which are
nearby you. So for example if your device

has Bluetooth turned on but it's not
discoverable at the moment, but you're

listening to music on your headphones or
if you have a smartwatch connected or

any other Bluetooth device connected, then
you will certainly send Bluetooth traffic

and you can sniff that from the air. For
example with a software-defined radio or

an Ubertooth. And so in the talk we
mentioned and we also have a link to this

in the slide, I guess it was here,
"Bluetooth smells like chicken". Michael

Ossman and Dominic Spill, they actually
explained very detailed how you can then

infer the MAC address from those packets
you sniffed. And, yeah, it's doable. It's

not as easy as with Wi-Fi but it's
certainly possible.

Eight: Thank you.
Herald: Okay. The next question was at

Microphone number one.
One: Thanks for your talk and demos. The

question is, does this firmware have any
mitigations against exploitation? And if

we imagine that it has, would it help
against such bugs?

Dennis: So. There's no, like real address
randomization, kind of the obvious way,

because there's... Most of the things are
actually global offsets inside the

firmware. So everything is at fixed
addresses, like you would use global

variables all over. There's also the RAM,
it's actually executable, so you can

execute on the stack, you can execute on
the heap, everywhere. So there's no real

mitigations for such a exploitation. It's
like, I don't think even the newer ones

have that sort of, and the Nexus 5
obviously.

Jiska: And another thing that really helps
us. So LMP has a version_request,

version_response, which is always sent. So
I can ask a device actually: Do you have a

vulnerable firmware and which version? And
then I can run exactly the exploit. And

the firmware, I mean, the firmware is
standard and I can just run the addresses

that I know for a certain firmware.
Herald: Okay. The next question was at

microphone number two. Then again number
one, three and five.

Two: Hi. Thanks for the work especially
for BT-B-g0ne since like it's the TV-B-

Gone. And I'm not sure of which kind of
iPhone that works, because you had a slide

about iPhone up until 6, and then you had
a slide that saying if the chip is older

than 2017. So does that work with the last
phones as well?

Jiska: Only up to iPhone 6 that was used
was the latest I could get. So if you have

an iPhone 8 or something, our attack does
not work.

Two: So you're going to work on it?
Because a lot of people are playing very

bad music and have new phones.
<i>Laughter</i>

Jiska: You mean the attack. The attack is
not working on iPhone 6, but the general

framework like patching .hcd-files or
changing the firmware will obviously work

on any Broadcom chip.
Two: Okay, thanks.

Dennis: Broadcom actually uses this
mechanism for all their chips, all their

Bluetooth chips, so you can use this
framework for every Broadcom chip, every

device that has a Broadcom chip. You only
need to do the reverse engineering, as to

get like the real addresses and offsets
inside the firmware to do meaningful

patches.
Jiska: But for this you always need to be,

to have a rooted device. You need root
access on the device to run our patching

framework.
Two: Okay. Thanks.

Herald: Okay. Now the question at
microphone number one.

One: Do you have a list of vulnerable
chipsets? So I can check if my phone is

vulnerable if it's not like in those
slides.

Jiska: Yeah, but it's very incomplete. So
I also have that, the version numbers and

subversion numbers of those phones. But
just consider the time range. So if your

smartphone does Bluetooth 4.0 to 4.2 and
it has a Broadcom chip then it's very

likely to be vulnerable.
Herald: Okay, now the question from

microphone number three.
Three: Thank you for the codes and the

talk. Quick question, so have you looked
at a car Bluetooth? And if not, are you

thinking about it?
Dennis: So I actually used this tool. As I

mentioned previously, we are also able to
test other vulnerabilities, for example

this fixed coordinate invalid curve
attack. And so I used my tool to actually

check if a car radio was vulnerable to
this fixed coordinate invalid curve attack

that was released this summer. So it's
basically patched since half a year but

the car was still vulnerable to this. So
the framework is basically usable to test

car radios as well, but I haven't like
specifically looked into a car radio.

Three: Thank you.
Herald: Okay. Now a question from

Microphone number five. Then we take a
question from the Internet and microphone

number six.
Five: What is the attack surface exposed

by your exploits? What's the worst case?
Could you manipulate memory or something?

Jiska: Worst case it's hard to estimate. I
mean we can change some memory addresses

at least in the Nexus 5. And for each
smartphone there are other functions by

the compiler put there. So to really know
what is happening, we would now need to

analyze like really tons of firmwares and
check what is in there and do some

fuzzing. We already found out that some
things only happen if you combine multiple

packets and so on. So it's really hard to
estimate what is the worst case. So the

very worst case would be, so to say, that
you can run arbitrary code in the

Bluetooth, in the Bluetooth firmware
itself, and then the next worst case would

be if there would be another vulnerability
in the driver, that you could escape

the firmware. So that would be the next
step. But that really requires an exploit

chain. So the very worst case would be
something similar. So there has been

vulnerabilities in the Wi-Fi part of
Broadcom chips where you had the

possibility to really run an exploit chain
which then rooted a device in the end. But

it's hard to estimate if you can do it
with this or not.

Herald: OK. Now the question from the
Internet please.

Internet: Do you know if any older but
still supported devices like old MacBooks

are patched and can you actually detect
this in any way other than a chip crash?

Jiska: Not really, so we can try to not
crash the chip by first checking if it is

sending appropriate answers, but typically
the really only thing to be sure is that

it crashes. So that so far is the only
way, because I mean obviously, if Broadcom

would tell "the following chips are
vulnerable", which they didn't so far,

because that's also to protect themselves
probably, then you could be sure. But yeah

as of now that's the only way to check it.
Herald: Thank you. Now the question from

microphone number six please.
Six: Yeah. Would it be possible to

increase the Bluetooth radio transmission
power by patching the firmware? So that

Bluetooth works across entire
buildings and not only in a single room?

Dennis: Yeah. So the thing is, we are
actually now patching the firmware of the

chip, and the firmware does like all the
the link layer stuff of Bluetooth. The

real physical part is probably done in
another component inside the chip which

may be running another kind of small real-
time firmware and we haven't found that

yet. We are still looking for it because
that must be in there somewhere, like that

Bluetooth modem and maybe we can actually
change the settings for this modem. I

don't think it will be too drastical. But
maybe if you're in different areas of the

world and like your Bluetooth has
different strengths in different areas of

the world, you can maybe manipulate that.
But we haven't found it yet.

Six: OK. Thank you.
Herald: Okay. Next question is coming from

microphone number four.
Four: Does the Bluetooth chipset have

access to system RAM?
Dennis: Sorry I didn't get the last word.

Jiska: The system rights or what do you
mean?

Four: The system RAM, memory.
Dennis: You mean the memory of the main

processor like where Android or iOS is
running on?

Four: Yes.
Dennis: No it's not like as with Wi-Fi

where you have direct memory access. But
Bluetooth, the HCI interface is the only

interface between those two processors.
And this is usually done over either USB

or in the Nexus 5 is actually UART.
Herald: Next question is coming from

microphone number three.
Three: Many thanks for the enlightening

and scary talk. I missed a little bit of
the beginning maybe that question was

inside there. Did you or do you considered
to disclose this vulnerability for example

to BSI (Bundesamt für Sicherheit in der
Informationstechnik)? As I would consider

their obligation to inform general public
like put a note on their website saying:

"Look, if you're running a certain
smartphone you're vulnerable to a certain

attack!" And that would put much more
stress on the vendors to really look into

this.
Jiska: Yeah that sounds like a good

option. So far we're, so we asked Broadcom
when we can publish things and at least

they agreed that it's no problem to
publish it in summer, then it would be

public for everyone. But yeah, BSI would
also be a nice option.

Three: Thank you.

Herald: OK. Is there another question
from the Internet?

…

Please switch on the
microphone for the Internet.

Internet: Hello? Hi. So do you know if any
devices have been patched yet, which have

not been released after 2017, or are there
no rolled out patches?

Jiska: I don't think so. So, it took
Broadcom two months to actually confirm

that there is this vulnerability. So on
December 3rd they said, ooops it really

exists. And then on December 9th, they
were like: "Ooh, do you really plan to do

that talk here?!"
<i>Laughter</i>

And I did the most recent iOS update on
the iPhone 6 that I just showed you. And

this one is still valuable. I think it
takes some time for testing. So I would

say the first patches will come out maybe
in 1, 2 months, but we don't know.

Herald: Okay. One last quick question from
microphone number one.

One: So is it … do you think it is
possible to trace back when was this

vulnerability introduced, so we can go
back and try to hack old devices that

probably have the same firmware or
firmware vulnerability? Because they

should be backward compatible, right? So
if the same handler is implemented I

know in 2012 first and for the first time
then uh...

Jiska: Yeah.
One: Probably the devices can be narrowed

down, right?
Jiska: So at least.. so the Nexus 5 has a

firmware from 2012 actually. So somewhere,
so the June 2nd is when it still existed

in 2014. I don't know. So in each firmware
there is a build date and I would then

need to extract the firmware of vulnerable
devices and so on, so it's a long process,

but at least the vulnerability was there
for multiple years.

Herald: Okay now give please a huge round
of applause for Jiska Classen

and Dennis Mantz for their talk.

<i>Applause</i>

Dennis: Thank you!
<i>Applause</i>

<i>35C3 outro music</i>

subtitles created by c3subtitles.de
in the year 2019. Join, and help us!