36C3 - All wireless communication stacks are equally broken

36C3 preroll music

Herald Angel: Our next speaker is jiska.
jiska is attending this conference since

ages like a decade? even more?
jiska: 20, 22 C3

Herald Angel: Long, long time. Sometimes
she is also doing some talks here. The

last one last year was about Bluetooth.
There she was in depth. This time it will

be a more general talk about wireless
protocols NFC, LTE, Wi-Fi, and, of course,

Bluetooth. So she will tell us what is
broken in all those protocols. So have fun

and enjoy the talk "All wireless
communications stacks are equally broken"

by jiska.

applause

jiska: So welcome to my talk. I thought it
first to be a foundation talk, but it will

also have new topics about everything that
is kind of fundamentally broken in

wireless communication and it will cover
anything in your smartphone soul like NFC,

Bluetooth, Wi-Fi, LTE. You could order
them like by communication range or by

specification length or lines of code. But
the thing is, so the specification length

and line of code also mean increased
complexity. And if there is increased

complexity, you might have issues with
security in it, in the very end. And then

there is something that is even worse than
LTE, which is vendor specific additions

that would be when you open like five
instances of IDA and like tried to

analyze where the wireless message is
going and what it is doing. So most of

this in this talk will be about wireless
exploitation and the new stuff will be

fuzzing techniques and a new escalation
target. But everything else is more like a

general view on wireless exploitation. So
first, to understand what the wireless

exploit does is to separate it in
different layers. So there is the lowest

layer, which is some hybrid chip which
runs a firmware, let's say bluetooth

firmware, which is then attached to a
driver. Then there's some privileged

stuff, it depends a bit on what kind of
system you're on. And in the end, there

will be applications and no matter where
you exploit is on that layer that you're

exploiting, some security measures become
ineffective. So, for example, if there is

encryption and you have an exploit for
that layer, it would become ineffective.

And it depends, so the higher you are, the
higher also the exploit prices get. So for

the Wi-Fi RCE, you would be at 100K, for
baseband RCE with local privilege

escalation, it gets already 200 K, and if
it's just a messenger or something, then

it's like really, really high in the
price. So the question is like, why is

this wireless stuff a bit cheaper? So
well, you need a certain distance. And so

that's probably a thing. And then also,
maybe they are just too easy to find. I

don't know. Like at least, maybe for me, I
don't know for normal people. Or maybe the

market demand is not that high for them.
Or they are not privileged enough. I don't

know. But actually they'd need like only
like non or less interaction. So. Yeah.

Still a thing I would say. So within the
group I am working at we had a lot of

wireless research and also tools that we
released. And the first one I think that

was running on a mobile phone is NFCGate,
which is currently managed by Max. Then

there is nexmon, which is our largest
project, which is patching of Broadcom

Wi-Fi. And Matthias, who did that, reached
his goal by just saying, like, I now have

kind of a software defined radio in a
commodity like Broadcom Wi-Fi chip. And so

he was a bit bored and kicked off two new
projects before he left, which he then

handed over. The first one is Qualcomm LTE
and the second one was Broadcom Bluetooth,

which I ended up with. And then we have
someone else who is Milan and he is doing

stuff that comes more like from the
application layer. So he implemented an

open source solution for Apple Airdrop
that you can run on your Raspberry Pi. And

well hackers gonna hack, so this stuff has
been used a lot for exploitation, not by

us, but by others. So there were three
groups using nexmon for Wi-Fi

exploitation, at least like what is
publicly known and like the bigger ones,

maybe I forget someone, but so there is a
lot of exploitation going on there. Then

internal blue has been used to demonstrate
an attack against a key negotiation of

Bluetooth just this august. And the open
Airdrop implementation was used for some

honeypots at Black Hat and AirDos. And
like a lot of stuff is going on there. And

then you might ask yourself, like, yeah,
so, if everybody is using it for

exploitation why don't we just do it
ourselves. And we actually did that and we

even did that for this very first project,
this NFC project. And the most important

thing you need to know about NFC is that
the near field is not really a near field.

So there's -- it's just communication, but
it's not near field communication, which

means so if you are able to forward the
communication, so for example, you have

like your credit card and then a
smartphone with NFC, you could forward it

over the cloud or some server and then to
another smartphone and then to the payment

terminal. And usually there's no time
constraint or distance pounding that would

prevent this. So you can at least forward
and relay messages and you might even be

able to modify them on the way. And some
students of us did like some testing in

some systems of some third parties who
then politely asked them to please stop

the testing. So it was not really a cool
thing overall. Like, not not good to

publish and so on. And the more happy I am
about that there's other researchers who

actually used some other tooling to look
into NFC. So just this month there has

been a talk at Black Hat, so not by us,
but by others about the visa credit cards.

And it's just all broken and it's cool
that some people like just did it anyway.

Yeah. So this is more about -- the NFC
stuff is more about forwarding and the

actual specification, but something that
is also cool is -- If you get code

execution within a chip and this is very
different attack scenario. And for

Bluetooth, I think it's especially bad
because of how everything is designed. And

the first design issue in Bluetooth is
that the encryption key is stored in a way

that the chip can always ask for
encryption keys here at the host, or it's

even already on the chip. And there is no
kind of security there. So whenever you

have code execution on the chip, it means
you can get all the encryption keys, not

of just the active connection, and then
break everything that is kind of a trusted

connection by this key. And that even
breaks features like the Android Smart

Lock. And Android Smart Lock is a thing
you can unlock your Android smartphone, if

you have a trusted device and if you'd
like add this, you might do this for your

car because it's nice in your car when you
have like your audio and your navigation

and everything without a locked
smartphone. But the question is like, how

secure is the Bluetooth of your car? Would
you trust that one to unlock your

smartphone? I don't know. And the next
thing is, so if you have code execution on

a Bluetooth chip, it also means that you
might be able to escalate into some other

components so that you go up all the
layers. The next question, is the exploit

persistent? So let's say I have something
that is running on the chip and I don't

know, extracting encryption keys or doing
whatever. You might ask yourself, so how

long will it be on the chip? I mean, it's
just a Bluetooth chip you switch Bluetooth

off sometimes and then the specifications.
So it's just a page like almost 1000. So

just like the first third of the
specification it says not the HCI_Reset

command will not necessarily perform a
hardware reset. This is implementation

defined. Then I looked into the Cypress
and Broadcom chips and saw, yeah, so if

you do each day reset, it's obviously not
a full hardware reset, it's just flashing

some queues connection stuff here and
there. So there is definitely a memory

area where you could put your exploit and
it would be persistent. So then you might

say, yeah, OK, so what do I do? I don't
know. I put my smartphone into flight mode

for a hard reset. That usually doesn't
work. You might also like reboot your

phone. In most cases, this works. For some
other coexistence stuff, I had the

impression that sometimes so it's a bit
strange, it might not necessarily like,

reset. Turning off for a while might hard-
reset the chip I think. Or you just put

your smartphone in a blender and then.
Yeah. So that might turn off the Bluetooth

chip finally. Yeah. So the next issue is
so let's say we have an exploit running

there, but we first need an exploit. So
the very first step is still missing as a

building block. And after the talk last
year, I did some stuff with the unicorn

and fuzzing on the chip and it was super
slow. And then suddenly Jan showed up and

Jan said, Hey, I want to build a fully
emulated chip for superfast fuzzing and

attach it to Linux and everything should
like run on the real -- like as on a real

system, just the over the air input will
be fast. And I was like, you cannot do

this for a master thesis. And then he was
building that thing within three months

and the remaining three months he was
writing a thesis and e-mails to vendors.

So here we go. What does Frankenstein do?
So it's running on an evaluation board of

that, yeah, it's just a normal Bluetooth
Bord that's connected to a Linux host over

UART and a modem over the air and then you
would snapshot that thing and emulate it

and give it fast input attached to the
real host. And that means that if you find

some vulnerability, it might be within all
the components or it might also be under

Linux host or it might be something that
is full stack. So you have something that

starts on the chip, gets to the host, the
host requests further things and then it

goes back to the chip. So you could build
like quite complex stuff. And for this I

have a short demo video. So the reason why
I do this as a video is that it might

happen that it finds heap overflows
otherwise. And then also it's not super

stable at the moment. So you can see it's
scanning for LE devices and then Wireshark

most of the time would get malformed
packets, but sometimes it could also get

normal packets and like some mesh stuff,
whatever. So this is Frankenstein running.

Ja, so what Jan focused on is early
connection states. That means stuff

where you don't need a pairing. And then
he found like heap overflows there in very

basic package types. So quite interesting.
And then the stuff was fixed, I think, or

hope, whatever. So at least like in very
recent devices and then the iPhone 11 came

out and in contrast to the specification,
over the air, the iPhone 11 says, hey, I'm

Bluetooth 5.1. I was like, wow, first
consumer device, Blueotooth 5.1. And I was

like, I don't really mind my way of the
exploitation as long as I can get code

execution on chip. So if it is with user
interaction and a pairing and whatever, I

don't care as long as I get code execution
on it. And then I was like, okay, let's

add some fuzz cases to Frankenstein,
continue fuzzing. And then I found that

specific evaluation board that Jan was
building this for has a problem with the

heap configuration for certain packet
types. And so if you change that, you

would hard-brick the device. I mean, I
bricked two evaluation boards trying to

fix stuff. So, yeah, it's just
bricked. And so that means for me to

continue fuzzing to write like to port
something like 200 handwritten hooks to

another evaluation board. It's almost
running. So there's just some stuff with

thread switching that's not super smooth
yet, but like it's almost on the next

board. And further plans are to add more
hardware. So we're also working on the

Samsung Galaxy S 10 and probably a MacBook
to get it in there. So then it would not

just be Linux, but at least macOS, maybe
Android. I don't know yet. And another

thing that would be cool and also we
didn't build yet, but it might be feasible

with some USRP X310 over PCI Express and
with FPGA and all the fancy stuff to get

real over the air input, which then would
mean that you would have a full queue like

from over the air real Bluetooth packets
going all the way up and then to a host

and the way back. And you could also use
that just to test your new emulation

scheme or whatever you want to change. So
not just security. Ja, so the next thing

is, so if you have code execution, what do
you do with it? And the normal approach is

to try to go all the layers up. But there
might also be some chip level escalation

and you might immediately see it on the
next picture. So this is from a Broadcom

chip, but that's something that you would
also see in many other chips, which is

that you have a shared antenna. And you
could also have two antennas, but they are

both on 2.5GHz and it's in the very same
smartphone super close next to each other

and you would get interference. So usually
you just have the same antenna and do some

coordination like when it's Bluetooth
sending, when it's Wi-Fi sending so that

they don't interfere. And this feature is
called coexistence and there is tons of

coexistence interfaces. So this is just
the one from Broadcom. And when I saw it,

I was like, oh, Francesco, let's look into
this. You know, all the Wi-Fi stuff, I

know all the Bluetooth stuff let's do
something. And he was like, no, it's just

it's just a marketing feature so that it
can like sell one chip for the price of

two chips or something. And I was like,
no, no, no, it must be an exploitation

feature. So, and then to end this
discussion, I went to Italy for eating

some ice cream and saw reality somewhere
in between. It's more like it's hardcoded

blacklisting for wireless channels and
stuff. It's traffic classes for different

types of traffic for Bluetooth and Wi-Fi.
And you can look it up in tons of patents

and it's like super, super proprietary.
And so we let's say we played a game which

was like I tried to steal his antenna and
he tried to steal my antenna. And so it

turned out, if you do that, yeah, you can
turn off Wi-Fi via Bluetooth, Bluetooth

via Wi-Fi. And then also like on most
phones, you need to reboot them and some

of them even reboot them themselves. So
this is just like a speed accelerated

thing with an Samsung Galaxy S 8 that is
not up to date. For iPhones, you would

just immediately see a reboot without any
interaction of things going off and on. So

Broadcom is still in the process of fixing
it. I don't know if they can fix it, but

they said they could fix it. But something
you should definitely fix is like the

driver itself so that the smartphone
reboots and so on. So I don't know. I

thought it would be fixed, actually, in
iOS 13 because it mentions Francesco and

me, but still on 13.3 I don't know, it,
it's still - um - you can

still crash the iPhone that way. But

it's just some resource blocking so it's
like not super dangerous thing, I would

say. And you still need a Bluetooth RCE
before you could do it and so on. But

still not cool that it's still not fixed.
Yeah, so what about the other stacks and

the escalations? So there is tons of
different Bluetooth stacks, so it's really

a mess. And obviously because of
Frankenstein, we had this first Linux

Bluetooth stack attached and so on. But,
yeah. So what has been there for a

wireless 2017, these BlueBorne attacks,
you might have heard of them. And they

found escalations like on Android,
Windows, Linux, iOS, whatever. And then

you might say, like in security, you often
say, so someone looked into it. It must be

secure now. And then there's so many
features coming. So there's all these IoT

devices. So everybody nowadays has
wireless headphones and fitness trackers

and Bluetooth always on. And in the Apple
ecosystem, it's really a mess. So if you

have more than one Apple device, you would
have Bluetooth enabled all the time.

Otherwise you couldn't use a lot of
features. And then there is like stuff

like Web Bluetooth so Bluetooth LE
support from within the browser. So it's

like a lot of new attack surfaces that
arised since then. I think -- So that's

more my personal estimation is, 2020 might
be more BlueBorne like attacks. The

saddest Bluetooth stack somehow is the
Linux Bluetooth stack. So I don't want to

blame the developers there. I mean, it's
not their fault, but it's not enough

people contributing to that project. And
if you would try to to analyze something

that is going on in the stack and you
don't really know what is going on, you

would do git blame or whatever and you
would always see the same guy as the

commiter. So at least if you're on a
specific problem, then there's only one

person committing there. And so the
picture down there actually has the same

guy thrice. So this is also a bit of a pun
here intended. We did some fuzzing in

there. We still need to evaluate some of
the results. So yeah, but I also feel like

nobody's really using it and it's kind of
sad. I mean, there's some Linux users, I

guess, but ... Yeah. Then there is the
weirdest stack I would say. So there's the

Apple Bluetooth stack and this one is
actually three. So there is there is the

MacOS Bluetooth stack. There's an iOS
Bluetooth stack. They are definitely

different. And then there is a third
embedded one, for example, for the

AirPods. They are all running different
different things. So, yeah, whatever. And

then they also have tons of proprietary
protocols on top of their Bluetooth stuff

that they're also very special. And I had
like at least two students, just one

porting it to iOS one to MacOS. And then
we also have students working on the other

protocols that are on top of Bluetooth.
And if you look into this, it's like, what

the hell? It's really hard to reverse
engineer because you have like three

different implementations and then
sometimes you're like: "yeah, okay. Maybe

it's also just bad code." And in the end,
so from what I saw so far, I would say

that it's kind of both. And then there is
the stack that I played also lots around

with, which is the Android Bluetooth
Stack. And they did a lot for the security

in the recent releases. And it annoys me
so much that when I want to get internal

blue running on it, I just echo to the
serial port instead so I bypass everything

that the operating system does. And so
something that Android cannot do, which

Apple does, is so Apple has all the
proprietary protocols. And if something

goes wrong, they immediately cut the
connection. But Android doesn't because of

compatibility and stuff. So you could just
send garbage for like two minutes and try

and see what happens. And it would
continue listening and asking and

confirming. But that's kind of an
overall design issue, I think. And yet

there's Windows and I couldn't find any
students to work on Windows. laughter

If someone wants to do this, that would be
great. And so another stack that's kind of

missing here is LTE. And I would call this
like the long term exploitation plan. So

it's not. I think if the long term
evaluation, evolution, whatever, but

exploitation I think is the best thing for
the E. So we have like tons of wireless

stuff where we are working on and I mean
like even PowerPC. And then there is

Qualcomm and they have they have this
Qualcomm hexagon DSP. I hate it so much.

So there's even source code leaks for
their LTE stuff. But it's just such a pain

to work on it. So you might have noticed
is that ARM has this LTE project with

Qualcomm, but it's just not fun. But other
people were doing a lot in this area and

they've already presented here today and
yesterday. So the first thing is the SIM

card in the phone. So the SIM cards should
be a thing like. From from my perspective,

that should be secure because it protects
your key material. And then it runs tons

of applications. I don't know. And then
you can exploit them and get the victim's

location, dial premium numbers and launch
a browser. And then I didn't really

understand, like there's just this WIB set
browser whatever, and then there's launch

browser what, is it? And I think it even
launches a browser then on the smartphone,

whatever. It's just crazy. And then I was
trying to call Deutsche Telekom and I'm a

business customer. So it's just like
three minutes for a call for me. So giving

a call there is nice. And then the first thing
they told me is: "You are secure. We know

you have three SIM cards and they are all
up to date." So I have to say, one of them

is more than 10 years old, but maybe it's
up to date. And my answer is like, what

exactly is running on my SIM card? They of
course not answered. So yeah, something is

running there. If you want to know more
about SIM cards, there has been talk

already yesterday evening and it's already
online. And then there's also a lot of

people looking into LTE. And I think the
most popular one is to work by Yongdae

Kim. He did even some LTE fuzzing
framework that he didn't release publicly

so far, because of the findings. So it's
like, should you publish? Should you not

publish? But so the findings are super
interesting. And he also has students here

who just did a talk this morning.
Responsible disclosure. So that's the

thing. When you find stuff you need to do
is responsible disclosure. And so I said

Jan was writing a lot of e-mails. And one
of the first that he wrote was to ThreadX,

because ThreadX is the operating system
that runs on the Broadcom Bluetooth

chip. And so he said, like, your
heap is a bit broken and does not have any

checks. You could implement the following
checks, which are pretty cheap and it

should be cool. And then I could not
attack it anymore. And then ThreadX was

answering, which was a bit unexpected,
that they already knew about this

exploitation technique and that it is up
to the application to not be vulnerable to

memory corruption, so not to cause any
memory corruption. So it's the programmers

fault if they do something and it's not
the operating system that has to take care

of the heap. Okay. Yeah. Next issue. So
the bin diffing and the testing if a

vulnerability is still there. So you might
not always get feedback from all the

vendors. If they fix it, they may just fix
it at a certain point in time and then you

tell them all we tested the next release
and it's still vulnerable. And then they

would say, like for Samsung said, Yeah, we
cannot send your patches in advance

without an NDA because Broadcom, blah,
blah, blah and so on and so forth. And

then Broadcom offered to send us patches
in advance. And I said, Yeah. Nice. And I

also sent them a device list because they
already knew it from the previous process.

So if you tell them the following 10
devices have an issue, then you would

already know that we can test those
devices anyway. And so and after I sent

them the list, they said: "Oh, wait, but
you need an NDA." So no, I mean, we are

doing this for free anyway. And signing an
NDA, I wouldn't do that. Yeah. So overall,

it also did Broadcom Product Security
Incident Response Team is a bit strange so

they wouldn't hand out any CVEs. And what
I mean what I do is like I first get a CVE

and then informed them and the other
customers because I also don't get any

incident number or something. So if I
wouldn't do this, I wouldn't have any

number to refer a vulnerability to. And
well, at least they are also not doing

that much legal trouble. But it's just.
Yeah, not really something happening

there. But some of their customers were
nice at least to my students, so they paid.

So one customer, they don't want to be
named here, but they payed to fly to DefCon

for one of my students and Samsung gave a
bounty off one thousand dollar. I mean,

still I mean we are in the range of of
very very more expensive exploits if it

would be on the black market, but for
students it's definitely nice. Yeah.

Responsible disclosure timelines. So this
is something that I thought like maybe

some of this responsible disclosure
timeline is just because of how I

communicate with the vendor. And sometimes
I'm writing e-mails like a five year old

or something - I don't know. But actually.
So this is a timeline of Quarkslab, who

also found just this year vulnerabilities
in Broadcom Wi-Fi chips. And so they've

also asked about NDA and then also their
exploit timeline. It's a bit fun because

they had similar exploitation strategies
as the very first exploit that you could

see by Google Project Zero and then, yeah,
more distorted timeline, whatever. And in

the end, well. So it's just taking time.
And again, no CVE id issued and so on and

so forth. So it's the very same stuff for
others, which is pretty sad. And then so

for Cyprus, which is partially having
source code of Broadcom, it also

manufactures chips. It's also very slow
for the response of disclosure. And then I

got told by other people, like, yeah, if
you would disclose something to Qualcomm,

it also takes very long. And luckily we
didn't find something in an Intel CPU. But

yeah, there is ... so on the wireless
market, there still so many other vendors

to become friends with. So yeah. So
practical solutions to end my talk. What

could you do to defend yourself if you
don't have a tinfoil hat? Other things I

can recommend is the secure Wi-Fi set up.
So don't use antennas, just use antenna

cables. If you do that in our lap a lot.
So this is a setup by Felix. And so when I

was sending my slides to Francesca in
advance she just said "cool, I have the

same one right now at my desktop". So it's
a very common setup. Maybe not at your

home, but for us it is. Or you'd just go
to the air-gapped device. So this is my

Powerbook 170, that's a really great
device. Almost impossible to get it online

and it has Word and Excel.
So ask all the questions.

Applause

Herald Angel: Thank you very much to
jiska. We still have several minutes left.

You will find eight microphones in the
room. Please line up in behind the

microphones to ask a question. And the
first question goes to the Internet.

Signal Angel: So at jiska, the question
is, are the Bluetooth issues you are

talking about also present in Bluetooth
Low Energy IoT devices.

jiska: Yes. So, I mean, there is IoT
devices, I cannot tell the vendor, but

there is also some popular devices that
have like Cypress Broadcom chips and then

it's even worse because they don't have a
separate stack, but often they have an

application running on the same arm core
and then you don't even need any

escalation.
Herald: All right. We have another

question at the microphone number one,
please.

Microphone 1: Thank you for the talk. My
question is, could you like did you

actually when you fuzzed the Bluetooth low
energy chip, did you when you managed to

get code execution, did you actually
climb up the protocol?

Did you like access Bluetooth profiles or
something like this?

jiska: Ah, so we, for example with the
link key extraction, we were building some

proof of concepts. But so it depends. We
don't currently have like a fully exploit

chain in terms of first on the chip and
then on the host. We have something that

goes directly on some hosts, but yeah,
there's tons of things there to do. Sorry?

Microphone 1: Yeah. And when you fuzz the
... how did you actually fuzz the chip

itself? How did you extract the
firmware from the chip?

jiska: So there is ... so Broadcom and
Cyprus are very nice because they have a

read RAM command so you don't need any
secure bypass or something. And for the

evaluation kits, there is even symbols
that we found in it. So symbols only means

like function names and global variable
names, that's it. But that's something to

work with.
Herald: Thank you. Another question from

the Internet, please.
Signal: Would you like the return of

physical switches for
the network controller?

jiska: Yeah, so that would be nice to like
physically switch it off. Actually, I

don't know where Paul is, but he is
building ... There is Paul. He is building

such a device. When is your talk at 10
o'clock. Paul is giving a talk about a

device where you have a physical
controller to switch off your wireless

stuff.
Herald: OK. The next question is again

microphone number one, please.
Microphone 1: Yes. Thank you. We just

bought a new car and by because
connecting the Bluetooth of my phone to

the car's system was very, very hard. And
I had to reboot the radio several times.

And then I found a message that the radio
must be directly connected to the CAN-bus

of the car. So you have a blueooth stack
connected directly to a CAN-bus. It was a

very cheap car. But if you
have an idea of what this means then...

jiska: Can you can you borrow me that car?
Microphone 1: It's a Toyota Aygo, you can

have it everywhere.
jiska: Well, that shouldn't be.

Herald: Alright, do we have a question at
microphone number eight, please?

Microphone 8: Hi and thank you for the
talk first of all. Uh well, if I

understood correctly, you said that the
vendors didn't mention if they fixed it or

not or they don't know if they fixed it.
jiska: Umm, yeah. So it depends. I know

like so if you look into the Android
security updates, so for example, August 5

has some Broadcom issue that was fixed and
I know which one that was and so on and so

forth. But so then it also means I like to
get that one onto a Samsung device. I

would need ... so they wouldn't build it
in the August update, but only in the

September update and then release it to
Europe, which is like mid or end of

September. And then I could download it to
my phone and test it over the air if it's

like really fixed and so on and so forth.
So it's ... there is like the first thing

is like that is listed publicly that it is
fixed. And then the next thing is that it

is actually fixed and it's really hard.
And for the communication with Apple, I

don't know. So sometimes they fix it
silently without mentioning us. And then

there's this iOS 13 thing where they
mentioned us but didn't fix it. So, yeah.

Microphone 8: Were there any issues like
that they found and they didn't know if

they fixed it or not. And you did like
patch-diffing or something like that?

jiska: Yeah, I did a lot of patch-diffing
and I currently have a student who is

doing nothing else than developing diffing
tools for the particular issues that I

have.
Microphone 8: And did you find that they

fixed it or not?
jiska: So it's first of all ... so we are

... so first of all, it's currently about
speed and stuff and I gave him some some

iPhone stuff for the next task.
But yes, it's work in progress. So most of

the other stuff I did by hand, so I also
have a good idea about like what a changed

within each kind of chip generation.
Microphone 8: Okay. Thank you very much.

Herald: All right. We had another question
from the Internet.

Signal: Yes. So from Mastodon, how exactly
was the snapshot of the Samsung Bluetooth

stack extracted for the fuzzing process?
jiska: The Samsung is ... so for Samsung

we have snap shotting, but for Samsung, we
don't have the rest of Frankenstein. The

other stuff is running on an evaluation
board. So the first part is mapping all

the hardware registers. So this is the
first trip that runs and tries to find

like all the memory regions. And once that
is done, there is a snapshotting hook that

you set to the function. So let's say you
want to look into a device scanning so you

would set the function into device
scanning. And once that it's called by the

Linux stack, he would freeze the whole chip
and disable like other interrupt stuff,

whatever that would kill it otherwise and
then copy everything that is in the

registers ... so that is kind of the snap
shotting. And once you have a snapshot,

then you can try to find everything that
kills your emulation like interrupts again

and thread switches and so on.
Herald: All right. We have one more

question from microphone, number one,
please.

Microphone 1: OK. So do you think that
open source, the driver or that open

hardware design will improve the
situation?

jiska: So open source? I think it would
improve the situation. But also one thing.

So I had to talk at mrmcd in September
this year. Another thing which is not

about open source is that the patching
capabilities of the Broadcom bluetooth

chips are very limited in terms of how
much can be fixed. So just open sourcing

wouldn't help Broadcom, for example.
Microphone 1: Like you mean like the

firmware is burnt into the chip and it's
limited to ...

jiska: Yeah
Microphone 1: Yeah, it's limited, right?

jiska: Yes, it's in the ROM. And then you
have patch ROM slots and you have like 128

patch ROM slot and each patch ROM slot is
a four byte override breakpoint thingy

that branches then somewhere else into
RAM. And then RAM is also limited.

So you couldn't like branch into large
chunks of RAM all the time. Yeah.

Microphone 1: Thank you.
Herald: All right. If there are not any

more questions?
jiska: Internet!

Herald: Internet? Oh, more Internet
questions. Then, please go ahead.

Signal: Yes. So winfreak on Twitter asks
what stack was tested when mentioning

Android? There are several and Google is
convinced rewriting it every year is a

good idea.
jiska: Ah, yeah. So this stuff that's like

the standard stack that runs on a Samsung
phone for example. So I think, like for

the main entry, there's only one ... I
know that there's like legacy stacks, but

they switch to only one.
Herald: So Signal Angel, do you have more

for us?
Signal: Yes. What is your hat made of?

jiska: My hat? So it's like aluminum foil.
And then there is the cyber cyber thingy.

So that's also important. Yeah. So but as
I said, it doesn't really help. It would

more help to put the smartphone in a
blender, for example.

Herald: Alright. Thank you very much for
this awesome talk. Give her a huge round

of applause to jiska.

applause

36c3 postroll

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