*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!