[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:18.38,Default,,0000,0000,0000,,{\i1}35c3 preroll music{\i0}
Dialogue: 0,0:00:20.13,0:00:27.63,Default,,0000,0000,0000,,Herald: So, Dennis, the left speaker,\Nfinished his M.Sc. in IT security this
Dialogue: 0,0:00:27.63,0:00:33.18,Default,,0000,0000,0000,,year. The next talk is based on his master\Nthesis, InternalBlue, which is a Bluetooth
Dialogue: 0,0:00:33.18,0:00:38.70,Default,,0000,0000,0000,,experimentation framework for which he\Neven received a prize. Jiska, the right
Dialogue: 0,0:00:38.70,0:00:45.23,Default,,0000,0000,0000,,speaker, or for you left speaker, has been\Nhis supervisor during the thesis and she
Dialogue: 0,0:00:45.23,0:00:49.97,Default,,0000,0000,0000,,loves breaking things. After several talks\Nabout wireless security, software-defined
Dialogue: 0,0:00:49.97,0:00:55.20,Default,,0000,0000,0000,,radio and Fitbits, she is now talking\Nabout Bluetooth. Please welcome on stage
Dialogue: 0,0:00:55.20,0:01:00.22,Default,,0000,0000,0000,,Dennis Mantz and Jiska Classen to their\Ntalk "Dissecting Broadcom Bluetooth".
Dialogue: 0,0:01:00.22,0:01:06.94,Default,,0000,0000,0000,,{\i1}Applause{\i0}\NDennis: Yeah. Thank you for the
Dialogue: 0,0:01:06.94,0:01:10.74,Default,,0000,0000,0000,,introduction and welcome you all to our\Ntalk. I'm Dennis and as said I choose
Dialogue: 0,0:01:10.74,0:01:16.81,Default,,0000,0000,0000,,Bluetooth as the topic for my master's\Nthesis and the outcome basically was I
Dialogue: 0,0:01:16.81,0:01:19.99,Default,,0000,0000,0000,,reverse engineered the firmware of a\NBluetooth controller which was
Dialogue: 0,0:01:19.99,0:01:24.04,Default,,0000,0000,0000,,manufactured by Broadcom, and I built a\Nlittle experimentation framework around
Dialogue: 0,0:01:24.04,0:01:27.95,Default,,0000,0000,0000,,it. And today we are not only going to\Npresent the framework, but also various
Dialogue: 0,0:01:27.95,0:01:33.13,Default,,0000,0000,0000,,kinds of use cases around it, and we also\Nbrought along some demos. Now, if you
Dialogue: 0,0:01:33.13,0:01:37.41,Default,,0000,0000,0000,,start such a big reversing project you\Ncertainly know that this will not be an
Dialogue: 0,0:01:37.41,0:01:41.66,Default,,0000,0000,0000,,easy task and also quite time consuming.\NSo you might want to ask: why did we do
Dialogue: 0,0:01:41.66,0:01:48.54,Default,,0000,0000,0000,,that in the first place? So there are\Nseveral good reasons. For one, dissecting
Dialogue: 0,0:01:48.54,0:01:53.35,Default,,0000,0000,0000,,the firmware and exploring it for\Nreverse engineering is really helpful if
Dialogue: 0,0:01:53.35,0:01:56.89,Default,,0000,0000,0000,,you want to get insights from a security\Nperspective. And this is what I had in
Dialogue: 0,0:01:56.89,0:02:01.25,Default,,0000,0000,0000,,mind when I first started my thesis. But\Nthen secondly and even better, once you're
Dialogue: 0,0:02:01.25,0:02:05.82,Default,,0000,0000,0000,,able to modify the firmware you can\Nactually leverage this fully featured and
Dialogue: 0,0:02:05.82,0:02:10.27,Default,,0000,0000,0000,,working Bluetooth implementation to be\Nyour very own experimentation platform, where
Dialogue: 0,0:02:10.27,0:02:16.48,Default,,0000,0000,0000,,you can add new features or can also alter\Nexisting behavior, and it almost feels
Dialogue: 0,0:02:16.48,0:02:20.80,Default,,0000,0000,0000,,like you can add a kind of open source\Ntouch to a closed source and proprietary
Dialogue: 0,0:02:20.80,0:02:25.95,Default,,0000,0000,0000,,platform which I really like about this\Nproject. Certainly this requires a certain
Dialogue: 0,0:02:25.95,0:02:31.13,Default,,0000,0000,0000,,background in many different departments\Nlike security, code analysis, wireless
Dialogue: 0,0:02:31.13,0:02:36.51,Default,,0000,0000,0000,,signals, embedded programming, and also\Nnot every researcher has resources and
Dialogue: 0,0:02:36.51,0:02:42.16,Default,,0000,0000,0000,,time to do such a reverse engineering\Nproject, but we think that the outcomes of
Dialogue: 0,0:02:42.16,0:02:46.71,Default,,0000,0000,0000,,this project are really helpful and\Nbeneficial for the security community. So,
Dialogue: 0,0:02:46.71,0:02:50.82,Default,,0000,0000,0000,,and last but not least we actually really\Nlike reverse engineering. So we already
Dialogue: 0,0:02:50.82,0:02:55.13,Default,,0000,0000,0000,,had great experiences with similar\Nprojects in the past. For example, some of
Dialogue: 0,0:02:55.13,0:02:59.09,Default,,0000,0000,0000,,you might know the NexMon project, where\Nwe reverse engineered and also modified
Dialogue: 0,0:02:59.09,0:03:05.96,Default,,0000,0000,0000,,the firmware of a Wi-Fi controller. Okay,\Nbefore we show our work, we first have to
Dialogue: 0,0:03:05.96,0:03:09.88,Default,,0000,0000,0000,,introduce a few Bluetooth protocols which\Nwe will be mentioning quite a lot
Dialogue: 0,0:03:09.88,0:03:15.39,Default,,0000,0000,0000,,throughout this talk. So the first one\Nwould be the host controller interface.
Dialogue: 0,0:03:15.39,0:03:20.39,Default,,0000,0000,0000,,Some of you might know that, it's the HCI,\Nand it's a protocol layer between the
Dialogue: 0,0:03:20.39,0:03:25.03,Default,,0000,0000,0000,,Bluetooth controller and the host system,\Nwhere the health system would be for
Dialogue: 0,0:03:25.03,0:03:29.93,Default,,0000,0000,0000,,example an Android phone, or iOS, or\NLinux, or any other operating system which
Dialogue: 0,0:03:29.93,0:03:34.31,Default,,0000,0000,0000,,implements those upper layers of the\NBluetooth protocol stack, and all the
Dialogue: 0,0:03:34.31,0:03:38.43,Default,,0000,0000,0000,,lower layers are actually implemented\Ninside the Bluetooth controller. And one
Dialogue: 0,0:03:38.43,0:03:43.55,Default,,0000,0000,0000,,of them would be for example the Link\NManager Protocol, the LMP. And this one is
Dialogue: 0,0:03:43.55,0:03:48.24,Default,,0000,0000,0000,,also really interesting. It actually\Nmanages connections to other remote
Dialogue: 0,0:03:48.24,0:03:54.87,Default,,0000,0000,0000,,Bluetooth devices. For example, pairing is\Nalso done on this protocol layer. And
Dialogue: 0,0:03:54.87,0:03:58.76,Default,,0000,0000,0000,,what's an interesting difference is that\Nthe Link Manager Protocol is actually
Dialogue: 0,0:03:58.76,0:04:03.54,Default,,0000,0000,0000,,transmitted over the air to communicate\Nwith other devices, whereas the HCI
Dialogue: 0,0:04:03.54,0:04:07.71,Default,,0000,0000,0000,,protocol is only used locally to\Ncommunicate between the operating system
Dialogue: 0,0:04:07.71,0:04:14.18,Default,,0000,0000,0000,,and the Bluetooth controller. And another\Ninteresting fact to know is that the HCI
Dialogue: 0,0:04:14.18,0:04:20.27,Default,,0000,0000,0000,,is actually able to be observable from the\Nhost site. So if you maybe tried to capture
Dialogue: 0,0:04:20.27,0:04:24.42,Default,,0000,0000,0000,,on a Bluetooth interface in Linux before,\Nor if you turned on the BT snoop log
Dialogue: 0,0:04:24.42,0:04:28.88,Default,,0000,0000,0000,,feature under the development settings in\NAndroid, you probably have seen HCI packets
Dialogue: 0,0:04:28.88,0:04:33.53,Default,,0000,0000,0000,,in Wireshark before, because this is an\Neasy task to do. However you probably did
Dialogue: 0,0:04:33.53,0:04:37.75,Default,,0000,0000,0000,,not see LMP packets in Wireshark before,\Nbecause this protocol layer is actually
Dialogue: 0,0:04:37.75,0:04:41.91,Default,,0000,0000,0000,,implemented inside the controller and it's\Nnot observable from the host side. You
Dialogue: 0,0:04:41.91,0:04:45.10,Default,,0000,0000,0000,,won't see those packets if you just\Ncapture on a Bluetooth interface because
Dialogue: 0,0:04:45.10,0:04:50.71,Default,,0000,0000,0000,,you can only see what's above the HCI\Nlayer. And so the other thing is that you
Dialogue: 0,0:04:50.71,0:04:55.31,Default,,0000,0000,0000,,cannot also simply sniff this from the air\Nbecause Bluetooth has frequency hopping
Dialogue: 0,0:04:55.31,0:04:59.92,Default,,0000,0000,0000,,and encryption. So it's a lot harder to\Nsniff those packets from the air just as
Dialogue: 0,0:04:59.92,0:05:06.89,Default,,0000,0000,0000,,with Wi-Fi for example. But today we try\Nto change that. Now I will introduce the
Dialogue: 0,0:05:06.89,0:05:10.33,Default,,0000,0000,0000,,framework I developed and show its\Nfeatures, and later we go into more
Dialogue: 0,0:05:10.33,0:05:16.77,Default,,0000,0000,0000,,details and also present some demos. As\Nalready mentioned, we named the framework
Dialogue: 0,0:05:16.77,0:05:21.79,Default,,0000,0000,0000,,InternalBlue. It's open source and you can\Nfind it on GitHub and currently it's only
Dialogue: 0,0:05:21.79,0:05:26.20,Default,,0000,0000,0000,,compatible with the Nexus 5 if you want to\Nuse all of its features, but we are also
Dialogue: 0,0:05:26.20,0:05:30.25,Default,,0000,0000,0000,,working to port it to other Bluetooth\Nchips in other smartphones, and also other
Dialogue: 0,0:05:30.25,0:05:35.99,Default,,0000,0000,0000,,platforms like the Raspberry Pi, and yeah,\Nsoon you will have more devices which are
Dialogue: 0,0:05:35.99,0:05:39.94,Default,,0000,0000,0000,,supported by this framework. We also\Nalready gave a talk where we introduced
Dialogue: 0,0:05:39.94,0:05:44.01,Default,,0000,0000,0000,,the framework and give some details about\Nthe internals and how it works. So if
Dialogue: 0,0:05:44.01,0:05:47.11,Default,,0000,0000,0000,,you're interested and want to learn more\Nthen you should check out our previous
Dialogue: 0,0:05:47.11,0:05:50.71,Default,,0000,0000,0000,,talk which was also recorded and you can\Nfind a link down at the bottom of the
Dialogue: 0,0:05:50.71,0:05:56.91,Default,,0000,0000,0000,,slide as well. Basically in a nutshell we\Nuse vendor specific HCI commands which are
Dialogue: 0,0:05:56.91,0:06:01.90,Default,,0000,0000,0000,,implemented by Broadcom and allow us to\Nread out and modify the firmware while the
Dialogue: 0,0:06:01.90,0:06:06.58,Default,,0000,0000,0000,,chip is actually running. And on top of\Nthis, we basically implemented a Python
Dialogue: 0,0:06:06.58,0:06:11.87,Default,,0000,0000,0000,,API to interact with the firmware, and we\Nuse this API to then implement all kinds
Dialogue: 0,0:06:11.87,0:06:16.68,Default,,0000,0000,0000,,of features which we find interesting. For\Nexample one of the first things we did was
Dialogue: 0,0:06:16.68,0:06:22.59,Default,,0000,0000,0000,,implementing such a LMP monitoring mode so\Nthat we can finally see LMP traffic on our
Dialogue: 0,0:06:22.59,0:06:27.49,Default,,0000,0000,0000,,laptop in Wireshark. And what comes along\Nwith this is that we are also able to
Dialogue: 0,0:06:27.49,0:06:32.61,Default,,0000,0000,0000,,inject arbitrary LMP packets inside\Nexisting Bluetooth connections. And this
Dialogue: 0,0:06:32.61,0:06:36.34,Default,,0000,0000,0000,,turned out to be also very interesting\Nbecause then we can test how other devices
Dialogue: 0,0:06:36.34,0:06:40.77,Default,,0000,0000,0000,,react to maybe packets they don't accept\Nor yeah, at least it's very good for
Dialogue: 0,0:06:40.77,0:06:45.40,Default,,0000,0000,0000,,experimentation and for example we use\Nthis to write a little proof of concept
Dialogue: 0,0:06:45.40,0:06:50.28,Default,,0000,0000,0000,,script for the fixed coordinate invalid\Ncurve attack that was released this
Dialogue: 0,0:06:50.28,0:06:54.02,Default,,0000,0000,0000,,summer, not by us but by other\Nresearchers, and we were able to actually
Dialogue: 0,0:06:54.02,0:06:59.19,Default,,0000,0000,0000,,prove that other devices are vulnerable to\Nthis attack. So this is a really helpful
Dialogue: 0,0:06:59.19,0:07:06.88,Default,,0000,0000,0000,,and practical tool. Also, at some point we\Nfound a crash our own. So we found back in
Dialogue: 0,0:07:06.88,0:07:12.03,Default,,0000,0000,0000,,some older Broadcom firmwares which allows\Nus to remotely crash the firmware in some
Dialogue: 0,0:07:12.03,0:07:17.44,Default,,0000,0000,0000,,of the Broadcom chips, and in some cases\Nwe are even able to execute a limited set
Dialogue: 0,0:07:17.44,0:07:21.44,Default,,0000,0000,0000,,of functions, so this might be even more\Ninteresting than just a crash - but more
Dialogue: 0,0:07:21.44,0:07:27.64,Default,,0000,0000,0000,,on that later. Now if you first start with\Nthe main thing about this is, how do we
Dialogue: 0,0:07:27.64,0:07:33.09,Default,,0000,0000,0000,,actually modify the firmware, How is\Npatching being done? And I already said
Dialogue: 0,0:07:33.09,0:07:37.74,Default,,0000,0000,0000,,that Broadcom uses those vendor-specific\NHCI commands. To read them out, they are:
Dialogue: 0,0:07:37.74,0:07:42.18,Default,,0000,0000,0000,,READ_RAM, WRITE_RAM and LAUNCH_RAM, and\Nthey do exactly what you think they would
Dialogue: 0,0:07:42.18,0:07:46.56,Default,,0000,0000,0000,,do. So basically we are able to read and\Nwrite in the address space of the
Dialogue: 0,0:07:46.56,0:07:50.84,Default,,0000,0000,0000,,firmware, and also to execute arbitrary\Ncode snippets in the context of the
Dialogue: 0,0:07:50.84,0:07:55.53,Default,,0000,0000,0000,,firmware. And this is pretty powerful.\NBroadcom actually uses this to do their
Dialogue: 0,0:07:55.53,0:08:01.31,Default,,0000,0000,0000,,firmware updates, so they ship so-\Ncalled HCD files, which are files that
Dialogue: 0,0:08:01.31,0:08:05.03,Default,,0000,0000,0000,,contain firmware updates. If you have a\NBroadcom chip inside your laptop or inside
Dialogue: 0,0:08:05.03,0:08:08.75,Default,,0000,0000,0000,,your phone, you should find such a file\Nwith the extension ".hcd" on your
Dialogue: 0,0:08:08.75,0:08:13.62,Default,,0000,0000,0000,,filesystem, and those files actually\Ncontain just a sequence of those commands
Dialogue: 0,0:08:13.62,0:08:18.15,Default,,0000,0000,0000,,to upload all the changes and patches, and\Nthey're even able to do temporary patches
Dialogue: 0,0:08:18.15,0:08:23.75,Default,,0000,0000,0000,,to the ROM of the firmware by another\Nmechanism that they call "Patchram." We also
Dialogue: 0,0:08:23.75,0:08:28.34,Default,,0000,0000,0000,,had to reverse engineer this and now we\Nare finally able to do all those patching
Dialogue: 0,0:08:28.34,0:08:34.57,Default,,0000,0000,0000,,ourselves. Now, what is also interesting\Nis that those files, the .hcd files, are
Dialogue: 0,0:08:34.57,0:08:38.89,Default,,0000,0000,0000,,neither encrypted nor signed. So it's\Nquite easy to actually modify them once
Dialogue: 0,0:08:38.89,0:08:42.84,Default,,0000,0000,0000,,you understand how they work. And also the\Nfirmware itself on the controller is not
Dialogue: 0,0:08:42.84,0:08:47.84,Default,,0000,0000,0000,,obfuscated. So there are basically no\Nmajor attempts done by Broadcom to prevent
Dialogue: 0,0:08:47.84,0:08:53.04,Default,,0000,0000,0000,,anyone to reverse engineer and modify\Nthis firmware. Currently, we write our
Dialogue: 0,0:08:53.04,0:08:57.52,Default,,0000,0000,0000,,code and assembler, so we write assembler\Npatches, but we're working on including
Dialogue: 0,0:08:57.52,0:09:02.72,Default,,0000,0000,0000,,this in our NexMon project to finally be\Nable to write patches in C code, which
Dialogue: 0,0:09:02.72,0:09:07.86,Default,,0000,0000,0000,,will be more comfortable and portable.\NFirst of course we have to do the
Dialogue: 0,0:09:07.86,0:09:10.86,Default,,0000,0000,0000,,reversing.\NJiska: Yeah. So as Dennis told you the
Dialogue: 0,0:09:10.86,0:09:15.06,Default,,0000,0000,0000,,code is not obfuscated but there is no\Nstrings and no function names. So you end
Dialogue: 0,0:09:15.06,0:09:20.14,Default,,0000,0000,0000,,up with thousands of functions that just\Nhave no name, it's just sub 1, sub 2, sub
Dialogue: 0,0:09:20.14,0:09:25.02,Default,,0000,0000,0000,,some-thousand something. And then there is\Na tool that I used which is called CodeCut
Dialogue: 0,0:09:25.02,0:09:32.77,Default,,0000,0000,0000,,to try to separate those functions into\Nmodules. But also the modules don't really
Dialogue: 0,0:09:32.77,0:09:36.25,Default,,0000,0000,0000,,tell you that much because the problem is:\Nthen you have hundreds of modules and then
Dialogue: 0,0:09:36.25,0:09:41.72,Default,,0000,0000,0000,,you know which modules are central and you\Nmight to start reversing but it's not
Dialogue: 0,0:09:41.72,0:09:45.59,Default,,0000,0000,0000,,really fun. You have 2800 pages of\NBluetooth standards, you might have some
Dialogue: 0,0:09:45.59,0:09:51.58,Default,,0000,0000,0000,,parameter checks in there, so you have\Nbounds which the parameters should be in,
Dialogue: 0,0:09:51.58,0:09:55.86,Default,,0000,0000,0000,,and then you search for those numbers\Nagain in assembly code and you might find
Dialogue: 0,0:09:55.86,0:10:00.50,Default,,0000,0000,0000,,some matches and then you have concrete\Nfunctions. So that's what we both did for
Dialogue: 0,0:10:00.50,0:10:08.79,Default,,0000,0000,0000,,months. staring at standards, staring at\Nthe code. Then people asked me: "Yes,
Dialogue: 0,0:10:08.79,0:10:15.02,Default,,0000,0000,0000,,that's not nice, but does it work on on\Nrecent devices?" And now the problem is
Dialogue: 0,0:10:15.02,0:10:20.45,Default,,0000,0000,0000,,even the Nexus 6P has a firmware from end\Nof 2014. So I just decided to buy a
Dialogue: 0,0:10:20.45,0:10:24.90,Default,,0000,0000,0000,,development board, which has also a\Nslightly outdated firmware, I mean just
Dialogue: 0,0:10:24.90,0:10:31.30,Default,,0000,0000,0000,,one year old. Meanwhile, this part of\NBroadcom was acquired by Cypress so it's
Dialogue: 0,0:10:31.30,0:10:37.25,Default,,0000,0000,0000,,called Cypress. But it doesn't matter,\Nit's still the same mechanisms in there.
Dialogue: 0,0:10:37.25,0:10:42.04,Default,,0000,0000,0000,,And I was able to use the same HCI\Ncommands, so I can still modify the
Dialogue: 0,0:10:42.04,0:10:48.95,Default,,0000,0000,0000,,firmware on this, I can extract the\Nfirmware, and actually I just got that on
Dialogue: 0,0:10:48.95,0:10:56.05,Default,,0000,0000,0000,,December 6, and 3 days later I had all\Nfunction names because somewhere someone
Dialogue: 0,0:10:56.05,0:11:03.54,Default,,0000,0000,0000,,forgot a patch.elf with all function names\Nin the development kit. So that's 11 000
Dialogue: 0,0:11:03.54,0:11:09.44,Default,,0000,0000,0000,,function names, 3000 object names. Nice.\NYeah.
Dialogue: 0,0:11:09.44,0:11:17.68,Default,,0000,0000,0000,,{\i1}Applause{\i0}\NJ: So, buy development kits earlier.
Dialogue: 0,0:11:17.68,0:11:23.42,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\ND: OK. Let's get closer to the first demo.
Dialogue: 0,0:11:23.42,0:11:26.59,Default,,0000,0000,0000,,So as mentioned we have this Link Manager\NProtocol which does interesting things
Dialogue: 0,0:11:26.59,0:11:30.72,Default,,0000,0000,0000,,like pairing and all kinds of stuff. And\Nit's implemented in the firmware so we
Dialogue: 0,0:11:30.72,0:11:34.60,Default,,0000,0000,0000,,cannot really see it from outside, we\Ncannot capture it in Wireshark. And we
Dialogue: 0,0:11:34.60,0:11:37.99,Default,,0000,0000,0000,,wanted to change that. So we wrote a patch\Nthat will actually hook some of the
Dialogue: 0,0:11:37.99,0:11:42.70,Default,,0000,0000,0000,,functions inside the firmware, those that\Nare handling LMP, to actually forward all
Dialogue: 0,0:11:42.70,0:11:47.21,Default,,0000,0000,0000,,the traffic over the HCI interface back to\Nour Android phone. And then on the Android
Dialogue: 0,0:11:47.21,0:11:50.53,Default,,0000,0000,0000,,phone we use a Android Bluetooth stack\Nwhich has debugging features compiled into
Dialogue: 0,0:11:50.53,0:11:56.64,Default,,0000,0000,0000,,it so that we can also forward all the HCI\Ntraffic via TCP to our host computer. And
Dialogue: 0,0:11:56.64,0:12:00.35,Default,,0000,0000,0000,,from there we can then show it in\NWireshark. We use a custom LMP dissector
Dialogue: 0,0:12:00.35,0:12:05.13,Default,,0000,0000,0000,,plugin which we borrowed from the\NUbertooth project. And yeah, that's it. We
Dialogue: 0,0:12:05.13,0:12:11.10,Default,,0000,0000,0000,,have a LMP monitor mode. I will show that\Nin just a second. We also have an LMP
Dialogue: 0,0:12:11.10,0:12:15.96,Default,,0000,0000,0000,,injection mode, so we can simply invoke\Nfunctions inside the firmware. And so we
Dialogue: 0,0:12:15.96,0:12:20.41,Default,,0000,0000,0000,,can also invoke the function which\Nactually sends LMP packets to other
Dialogue: 0,0:12:20.41,0:12:25.49,Default,,0000,0000,0000,,devices which are connected to our Nexus\N5. And so, yeah, with this we have both
Dialogue: 0,0:12:25.49,0:12:30.66,Default,,0000,0000,0000,,channels of the communication and can\Nactually send arbitrary traffic to other
Dialogue: 0,0:12:30.66,0:12:38.79,Default,,0000,0000,0000,,devices. So, for this let's go into a\Ncommand line and start the framework. The
Dialogue: 0,0:12:38.79,0:12:43.62,Default,,0000,0000,0000,,framework has a command line interface we\Ncan use all of its features and interact
Dialogue: 0,0:12:43.62,0:12:50.07,Default,,0000,0000,0000,,with the firmware and to start a monitor\Nmode, I can just type this command which
Dialogue: 0,0:12:50.07,0:12:55.33,Default,,0000,0000,0000,,will start a Wireshark instance and also\Ninstall all the patches which we need into
Dialogue: 0,0:12:55.33,0:13:01.08,Default,,0000,0000,0000,,the firmware of the phone. Now from this\Ntime on, we actually have all LMP traffic
Dialogue: 0,0:13:01.08,0:13:06.06,Default,,0000,0000,0000,,forwarded and shown in the Wireshark\Nframe, but currently we don't have a
Dialogue: 0,0:13:06.06,0:13:17.38,Default,,0000,0000,0000,,Bluetooth connection, that's why you don't\Nsee anything. Ok. Yeah, so we still need a
Dialogue: 0,0:13:17.38,0:13:22.99,Default,,0000,0000,0000,,Bluetooth connection, right? I could just\Npair those devices to create a connection
Dialogue: 0,0:13:22.99,0:13:27.68,Default,,0000,0000,0000,,and then we would see LMP traffic, but I\Nwant to show something else. So this will
Dialogue: 0,0:13:27.68,0:13:31.09,Default,,0000,0000,0000,,be a combined demo actually, because\NBluetooth has some more interesting
Dialogue: 0,0:13:31.09,0:13:36.56,Default,,0000,0000,0000,,features which maybe not everyone knows -\Nat least for me that was a surprise when I
Dialogue: 0,0:13:36.56,0:13:42.31,Default,,0000,0000,0000,,first learned about this. So even if your\Ndevice is not being set to be discoverable
Dialogue: 0,0:13:42.31,0:13:46.90,Default,,0000,0000,0000,,by other devices, it still accepts\Nconnections from any other device, the
Dialogue: 0,0:13:46.90,0:13:51.74,Default,,0000,0000,0000,,other device just needs to know your MAC\Naddress and can simply connect to you,
Dialogue: 0,0:13:51.74,0:13:56.24,Default,,0000,0000,0000,,without even being paired before, you\Ndon't even notice this because the device
Dialogue: 0,0:13:56.24,0:13:59.54,Default,,0000,0000,0000,,does not have to trigger the pairing\Nprocess, and then the user won't be
Dialogue: 0,0:13:59.54,0:14:03.75,Default,,0000,0000,0000,,notified. And so by just finding out the\NMAC address of any other device I can
Dialogue: 0,0:14:03.75,0:14:09.16,Default,,0000,0000,0000,,connect to it on this LMP layer and start\Ncommunicating with it. And finding out the
Dialogue: 0,0:14:09.16,0:14:13.24,Default,,0000,0000,0000,,MAC address is also not that hard. There\Nwas another talk which we mention down on
Dialogue: 0,0:14:13.24,0:14:17.01,Default,,0000,0000,0000,,the bottom of the slide, it's called\N"Bluetooth smells like chicken" by Dominik
Dialogue: 0,0:14:17.01,0:14:20.81,Default,,0000,0000,0000,,Spill, Michael Ossmann and Mark Steward,\Nwhich shows that this is actually possible
Dialogue: 0,0:14:20.81,0:14:28.43,Default,,0000,0000,0000,,and not hard to do. So, I can actually\Njust type "connect" and give it the MAC
Dialogue: 0,0:14:28.43,0:14:33.57,Default,,0000,0000,0000,,address of another phone.\NJ: We need again... ah great.
Dialogue: 0,0:14:33.57,0:14:37.83,Default,,0000,0000,0000,,D: Yes. Perfect! On the right side you\Nactually see a Nexus 6P, which will be our
Dialogue: 0,0:14:37.83,0:14:44.19,Default,,0000,0000,0000,,target. You can hopefully barely read the\NMAC address which is shown there on the
Dialogue: 0,0:14:44.19,0:14:48.43,Default,,0000,0000,0000,,left side as the Nexus 5 which is the\Nphone we use for for testing like the
Dialogue: 0,0:14:48.43,0:14:54.92,Default,,0000,0000,0000,,phone which is connected to my laptop here\Nand is used for InternalBlue. And as you
Dialogue: 0,0:14:54.92,0:14:58.79,Default,,0000,0000,0000,,also can see the Nexus 6P is currently not\Nin the Bluetooth menu, so it's not
Dialogue: 0,0:14:58.79,0:15:04.92,Default,,0000,0000,0000,,actually discoverable by by means of\NBluetooth. I still can connect to it when
Dialogue: 0,0:15:04.92,0:15:10.88,Default,,0000,0000,0000,,I actually type "connect" and the MAC\Naddress this might may take a few ... no
Dialogue: 0,0:15:10.88,0:15:16.11,Default,,0000,0000,0000,,it worked directly, perfect. So now we can\Nsee that we actually have traffic on the
Dialogue: 0,0:15:16.11,0:15:20.28,Default,,0000,0000,0000,,LMP layer. What you also might notice that\Nthat on the Nexus 6P there wasn't
Dialogue: 0,0:15:20.28,0:15:23.80,Default,,0000,0000,0000,,anything. So the user didn't notice, but I\Nhave an established connection to this
Dialogue: 0,0:15:23.80,0:15:28.62,Default,,0000,0000,0000,,other phone and you can see the LMP\Ntraffic which is going on on this protocol
Dialogue: 0,0:15:28.62,0:15:33.37,Default,,0000,0000,0000,,layer. As you can see it is quite a lot:\NThere are feature requests, version
Dialogue: 0,0:15:33.37,0:15:39.52,Default,,0000,0000,0000,,requests, also name requests so that the\Nphones know how the name of each other is.
Dialogue: 0,0:15:39.52,0:15:44.27,Default,,0000,0000,0000,,And yeah, from now on I can also try to\Ninject arbitrary LMP packets. For
Dialogue: 0,0:15:44.27,0:15:49.38,Default,,0000,0000,0000,,example I can send an LMP packet with code\N"01" which would be a name request and ask
Dialogue: 0,0:15:49.38,0:15:55.26,Default,,0000,0000,0000,,for a name at offset 0. And you should see\Nthat the name request has popped up here
Dialogue: 0,0:15:55.26,0:16:01.29,Default,,0000,0000,0000,,and the other device even answered with\Nits name. If you scroll down here should
Dialogue: 0,0:16:01.29,0:16:07.56,Default,,0000,0000,0000,,at some point see that we have the name\N"Nexus 6P" because we don't renamed our
Dialogue: 0,0:16:07.56,0:16:11.62,Default,,0000,0000,0000,,devices. But I can also send\Narbitrary LMP packets so I'm not bound to
Dialogue: 0,0:16:11.62,0:16:15.09,Default,,0000,0000,0000,,anything that is in the specification.\NJ: You already got the detach!
Dialogue: 0,0:16:15.09,0:16:20.34,Default,,0000,0000,0000,,D: So the other device actually detached\Nwhich happens from time to time ... can
Dialogue: 0,0:16:20.34,0:16:22.34,Default,,0000,0000,0000,,reconnect.\NJ: If we don't do anything in between we
Dialogue: 0,0:16:22.34,0:16:26.99,Default,,0000,0000,0000,,will get a detach from the other device\Nbecause we didn't do a paring or something
Dialogue: 0,0:16:26.99,0:16:31.88,Default,,0000,0000,0000,,so we re-established connection. And now\NDennis is going to send something that is
Dialogue: 0,0:16:31.88,0:16:36.40,Default,,0000,0000,0000,,not specified ... just an LMP 99.\ND: So it's even saying here this is
Dialogue: 0,0:16:36.40,0:16:40.48,Default,,0000,0000,0000,,unknown. But as you can see the payload is\Nactually sent and the other device
Dialogue: 0,0:16:40.48,0:16:45.47,Default,,0000,0000,0000,,correctly answers with "this is not\Naccepted and I don't want this". But you
Dialogue: 0,0:16:45.47,0:16:48.67,Default,,0000,0000,0000,,can probably see that this is very\Ninteresting for a security researcher,
Dialogue: 0,0:16:48.67,0:16:52.48,Default,,0000,0000,0000,,because now he can see how the other\Ndevice happens in certain conditions, if
Dialogue: 0,0:16:52.48,0:16:57.76,Default,,0000,0000,0000,,you send them certain packets. Yeah. Quite\Nnice to actually experiment with. OK. I
Dialogue: 0,0:16:57.76,0:17:02.88,Default,,0000,0000,0000,,think that's it for the first demo. Let's\Nstop this and go back to this.
Dialogue: 0,0:17:02.88,0:17:06.59,Default,,0000,0000,0000,,J: I don't need the in-screen anymore.\NYeah. Great. Okay.
Dialogue: 0,0:17:06.59,0:17:14.76,Default,,0000,0000,0000,,{\i1}Applause{\i0}\ND: Thank you.
Dialogue: 0,0:17:14.76,0:17:17.94,Default,,0000,0000,0000,,J: Another thing in the Bluetooth standard\Nis that you need a possibility to pair
Dialogue: 0,0:17:17.94,0:17:23.38,Default,,0000,0000,0000,,devices, which have no input and no output\Ncapability, so they cannot show a PIN and
Dialogue: 0,0:17:23.38,0:17:29.89,Default,,0000,0000,0000,,you cannot enter a PIN. And this is the\Nstandard for any headset. But also a Man-
Dialogue: 0,0:17:29.89,0:17:35.67,Default,,0000,0000,0000,,in-the-Middle can change the input/output\Ncapabilities and then you might just get
Dialogue: 0,0:17:35.67,0:17:41.48,Default,,0000,0000,0000,,displayed this "yes/no" pairing without a\NPIN request. Even though your smartphone
Dialogue: 0,0:17:41.48,0:17:48.58,Default,,0000,0000,0000,,could show more than this. And I have a\Ndemo video again of the same thing. That's
Dialogue: 0,0:17:48.58,0:17:53.00,Default,,0000,0000,0000,,this one. So on the left hand side I have\Nagain a Nexus 5 on the right hand side I
Dialogue: 0,0:17:53.00,0:17:59.68,Default,,0000,0000,0000,,have an iPhone and I am pairing them. I\Njust changed the request and the
Dialogue: 0,0:17:59.68,0:18:04.03,Default,,0000,0000,0000,,capabilities that it's, that I'm not having\Ninput output capability. So you can see on
Dialogue: 0,0:18:04.03,0:18:09.18,Default,,0000,0000,0000,,the right hand side on the iPhone it's\Njust showing this "yes/no" question. And
Dialogue: 0,0:18:09.18,0:18:12.56,Default,,0000,0000,0000,,on the left hand side you still have the\Nsame algorithm which just does the same
Dialogue: 0,0:18:12.56,0:18:21.46,Default,,0000,0000,0000,,thing. So pairing will succeed, there's\Nthe same cryptographic routines but you
Dialogue: 0,0:18:21.46,0:18:24.75,Default,,0000,0000,0000,,are not being warned on the iPhone and\Nthat's a bit critical. So the standard is
Dialogue: 0,0:18:24.75,0:18:30.15,Default,,0000,0000,0000,,not saying: "Please warn the user to check\Nif the other phone really has no input
Dialogue: 0,0:18:30.15,0:18:34.91,Default,,0000,0000,0000,,output." So I just say pair and it pairs.
Dialogue: 0,0:18:38.05,0:18:45.18,Default,,0000,0000,0000,,Yup.\N{\i1}Applause{\i0}\N
Dialogue: 0,0:18:46.26,0:18:49.43,Default,,0000,0000,0000,,So far that's only things that are as
Dialogue: 0,0:18:49.43,0:18:55.74,Default,,0000,0000,0000,,they are in the standard, so it's not too\Nsurprising. So the question is: Can we
Dialogue: 0,0:18:55.74,0:19:02.55,Default,,0000,0000,0000,,find more bugs? Yeah. Finding bugs in\NBluetooth. Actually I didn't even want to
Dialogue: 0,0:19:02.55,0:19:06.17,Default,,0000,0000,0000,,find bugs in the beginning, I just wanted\Nto understand how everything works. So I
Dialogue: 0,0:19:06.17,0:19:11.86,Default,,0000,0000,0000,,went through the handlers and I checked\Nthe... there's these checks of the
Dialogue: 0,0:19:11.86,0:19:15.81,Default,,0000,0000,0000,,parameters, so there is a parameter check\Nin the beginning of each handler that
Dialogue: 0,0:19:15.81,0:19:21.33,Default,,0000,0000,0000,,shows me a bit which handler it could be\Naccording to the standard. And suddenly
Dialogue: 0,0:19:21.33,0:19:26.13,Default,,0000,0000,0000,,there is a handler which does not have any\Ncheck. So there's just the missing "if"
Dialogue: 0,0:19:26.13,0:19:30.96,Default,,0000,0000,0000,,somewhere. And then I compared to firmware\Nversions that I had and found out they
Dialogue: 0,0:19:30.96,0:19:39.54,Default,,0000,0000,0000,,silently patched that already some time\Nbetween June 2nd and August 19th in 2014.
Dialogue: 0,0:19:39.54,0:19:44.96,Default,,0000,0000,0000,,But they never updated older devices, so\Nthey never shipped an .hcd-patch. So I
Dialogue: 0,0:19:44.96,0:19:48.86,Default,,0000,0000,0000,,contacted Broadcom and said: "Yeah you\Nhave a problem!" and they said "No, we
Dialogue: 0,0:19:48.86,0:19:53.32,Default,,0000,0000,0000,,don't." And I said: "You really have a\Nproblem there." And so on... And then they
Dialogue: 0,0:19:53.32,0:19:58.27,Default,,0000,0000,0000,,said: "It doesn't exist." And then I\Nshowed them more and then they said "Yeah
Dialogue: 0,0:19:58.27,0:20:01.90,Default,,0000,0000,0000,,ok, but it's not compliant to the standard\Nwhat you're doing!"
Dialogue: 0,0:20:01.93,0:20:08.52,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\N{\i1}Applause{\i0}
Dialogue: 0,0:20:08.52,0:20:11.65,Default,,0000,0000,0000,,I'm sorry, my next exploit will be\Nstandard complaint.
Dialogue: 0,0:20:11.65,0:20:14.78,Default,,0000,0000,0000,,{\i1}Laughter{\i0}\NAnd then we discussed a bit more and then
Dialogue: 0,0:20:14.78,0:20:18.00,Default,,0000,0000,0000,,they said: "It does not affect Wi-Fi\Nperformance." Well, in my tests it did...
Dialogue: 0,0:20:18.00,0:20:23.68,Default,,0000,0000,0000,,whatever... doesn't matter. So basically\Nyou can switch off Bluetooth on another
Dialogue: 0,0:20:23.68,0:20:29.59,Default,,0000,0000,0000,,device and then Bluetooth restarts\Ntypically depending on configuration. And
Dialogue: 0,0:20:29.59,0:20:34.35,Default,,0000,0000,0000,,as Broadcom didn't tell me much about this\NI started testing out things on my own. So
Dialogue: 0,0:20:34.35,0:20:38.13,Default,,0000,0000,0000,,which devices actually still have a\Nfirmware that is affected in their
Dialogue: 0,0:20:38.13,0:20:46.54,Default,,0000,0000,0000,,Broadcom chip? It's quite a lot. So it's\Nlike the iPhone 6, MacBook Pro from 2016,
Dialogue: 0,0:20:46.54,0:20:51.27,Default,,0000,0000,0000,,of course my Nexus 5, Raspberry Pi 3 and\Nso on. And this list is really not
Dialogue: 0,0:20:51.27,0:20:55.64,Default,,0000,0000,0000,,complete this is just like, I asked my\Nstudents: "Can I test your smartphone?"
Dialogue: 0,0:20:55.64,0:20:59.70,Default,,0000,0000,0000,,Some of them said: "No. Are you crazy?!"\N{\i1}Laughter{\i0}
Dialogue: 0,0:20:59.70,0:21:06.59,Default,,0000,0000,0000,,And that's the list I got just during the\Nlast weeks. And this is the one I'm going
Dialogue: 0,0:21:06.59,0:21:12.68,Default,,0000,0000,0000,,to demo. I just named it BT-B-g0ne, so you\Ncan kill the Bluetooth of annoying songs
Dialogue: 0,0:21:12.68,0:21:22.62,Default,,0000,0000,0000,,or something.\N{\i1}Applause{\i0}
Dialogue: 0,0:21:22.62,0:21:33.73,Default,,0000,0000,0000,,So I need to go into the Bluetooth here,\Nyeah, screen-in-screen... That's great. I
Dialogue: 0,0:21:33.73,0:21:38.00,Default,,0000,0000,0000,,even had a "Bluetooth is not real" and so\Non. That's really great. What is going on
Dialogue: 0,0:21:38.00,0:21:39.43,Default,,0000,0000,0000,,here.\ND: OK.
Dialogue: 0,0:21:39.43,0:21:44.42,Default,,0000,0000,0000,,J: Yeah let's go for the demo. So first we\Nare going to patch the Nexus 5 with our
Dialogue: 0,0:21:44.42,0:21:50.55,Default,,0000,0000,0000,,funny attack and then just press enter and\Nnow it takes a while until the the iPhone
Dialogue: 0,0:21:50.55,0:21:54.79,Default,,0000,0000,0000,,is realizing like "Oops my Bluetooth is\Ngone." So if I'm playing music you will
Dialogue: 0,0:21:54.79,0:21:58.53,Default,,0000,0000,0000,,see it faster, the music would already\Nstop playing. Let me just enter another
Dialogue: 0,0:21:58.53,0:22:01.95,Default,,0000,0000,0000,,time. Just... Yes, and there it's gone!\NOops!
Dialogue: 0,0:22:01.95,0:22:08.92,Default,,0000,0000,0000,,{\i1}Applause{\i0}\N
Dialogue: 0,0:22:08.92,0:22:10.97,Default,,0000,0000,0000,,And then it appears again and so on I can
Dialogue: 0,0:22:10.97,0:22:14.94,Default,,0000,0000,0000,,just do it again and again and again. And\Nit's actually so fast that the other
Dialogue: 0,0:22:14.94,0:22:20.07,Default,,0000,0000,0000,,person could not play music, because music\Nalso stops playing after this disconnect.
Dialogue: 0,0:22:20.07,0:22:25.44,Default,,0000,0000,0000,,Yeah that's the demo. Now we were\Nwondering, yeah, what is actually
Dialogue: 0,0:22:25.44,0:22:31.49,Default,,0000,0000,0000,,happening. So actually that the crash -\Nthe crash is the best case. So there is a
Dialogue: 0,0:22:31.49,0:22:37.38,Default,,0000,0000,0000,,handler. I call it "Handler A", because\NI'm not leaking the actual problem here.
Dialogue: 0,0:22:37.38,0:22:43.18,Default,,0000,0000,0000,,Broadcom didn't fix it yet. So there is\Nthis handler which just should take, let's
Dialogue: 0,0:22:43.18,0:22:50.11,Default,,0000,0000,0000,,say, two arguments or something. But it\Ndoesn't check the parameter range and the
Dialogue: 0,0:22:50.11,0:22:55.83,Default,,0000,0000,0000,,compiler likes to put one handler after\Nthe other. And then we just go into the
Dialogue: 0,0:22:55.83,0:23:01.53,Default,,0000,0000,0000,,next handler, and so we have something\Nlike 250 functions that we can call from
Dialogue: 0,0:23:01.53,0:23:06.54,Default,,0000,0000,0000,,the next handler but with wrong\Nparameters. So it's a bit buggy, and
Dialogue: 0,0:23:06.54,0:23:12.99,Default,,0000,0000,0000,,sometimes if a function expects to get\Nother parameters it just crashes. But
Dialogue: 0,0:23:12.99,0:23:18.50,Default,,0000,0000,0000,,otherwise we can execute functions. And on\Nthe Nexus 5 we looked a bit more into this
Dialogue: 0,0:23:18.50,0:23:23.79,Default,,0000,0000,0000,,and I found out that I can enable test\Nmode. So test mode should be something
Dialogue: 0,0:23:23.79,0:23:28.64,Default,,0000,0000,0000,,only locally to be enabled on a phone if\Nyou have root access to the driver and
Dialogue: 0,0:23:28.64,0:23:32.45,Default,,0000,0000,0000,,then you tell the driver: "I'm now going\Nto test your frequencies and so on please
Dialogue: 0,0:23:32.45,0:23:35.53,Default,,0000,0000,0000,,go in test mode." But I can now do this\Nremotely.
Dialogue: 0,0:23:37.01,0:23:42.100,Default,,0000,0000,0000,,{\i1}Applause{\i0}\N
Dialogue: 0,0:23:43.23,0:23:45.22,Default,,0000,0000,0000,,So I didn't bring this one as a live demo.
Dialogue: 0,0:23:45.22,0:23:49.36,Default,,0000,0000,0000,,I mean I have a HackRF with me, we can do\Nthat during Q and A, because the problem
Dialogue: 0,0:23:49.36,0:23:52.91,Default,,0000,0000,0000,,is there is probably too much going on in\Nthe spectrum here and you wouldn't see the
Dialogue: 0,0:23:52.91,0:24:01.15,Default,,0000,0000,0000,,test mode starting anyway. So I'm just\Ndoing the attack and then on the left hand
Dialogue: 0,0:24:01.15,0:24:04.33,Default,,0000,0000,0000,,side, I just took a quick pause, you can\Nsee the test mode, so that's just the
Dialogue: 0,0:24:04.33,0:24:09.69,Default,,0000,0000,0000,,default test mode hopping around in all\Nchannels. The packets now appear a bit out
Dialogue: 0,0:24:09.69,0:24:15.17,Default,,0000,0000,0000,,of order because I just put them into a\Nqueue, send them. This "???" payload is
Dialogue: 0,0:24:15.17,0:24:19.91,Default,,0000,0000,0000,,the malicious payload. I just send\N"test_control" and "test_activate". And
Dialogue: 0,0:24:19.91,0:24:28.12,Default,,0000,0000,0000,,first they get this not_accepted. And then\Nafter this "???" payload you can see that
Dialogue: 0,0:24:28.12,0:24:32.51,Default,,0000,0000,0000,,it's accepted. And on the left hand side\Nyou can still see that there is the test
Dialogue: 0,0:24:32.51,0:24:39.98,Default,,0000,0000,0000,,mode going on, so really block things for\Nlonger time. And then it's accepted, magic!
Dialogue: 0,0:24:42.45,0:24:48.65,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:24:48.86,0:24:52.33,Default,,0000,0000,0000,,If you combine this with disabling\Nadaptive frequency hopping you can even
Dialogue: 0,0:24:52.33,0:24:58.08,Default,,0000,0000,0000,,force the other device, which is also then\Nin test mode, to stop hopping for a while
Dialogue: 0,0:24:58.08,0:25:02.88,Default,,0000,0000,0000,,and then just jam a selected frequency, so\Nyou could also jam a selected Wi-Fi
Dialogue: 0,0:25:02.88,0:25:07.75,Default,,0000,0000,0000,,frequency that this device is currently\Nusing. And it's a combo chip, so you would
Dialogue: 0,0:25:07.75,0:25:13.36,Default,,0000,0000,0000,,really be on the same antenna. We can\Nconfirm this works on Nexus 5 and Xperia
Dialogue: 0,0:25:13.36,0:25:18.95,Default,,0000,0000,0000,,Z3, because they both have to be same\NBCM4339 chip. It might also work on other
Dialogue: 0,0:25:18.95,0:25:24.63,Default,,0000,0000,0000,,devices with that chip. It's a bit random\Nto find out what is in there. You need to
Dialogue: 0,0:25:24.63,0:25:31.74,Default,,0000,0000,0000,,find teardowns and on. So when finding\Nthis bug we started developing a
Dialogue: 0,0:25:31.74,0:25:37.72,Default,,0000,0000,0000,,toolchain. So Dennis added a feature for\Ntracepoints. You can add now a tracepoint
Dialogue: 0,0:25:37.72,0:25:41.41,Default,,0000,0000,0000,,to a function which is then called once\Nand dumps all the registers and the stack
Dialogue: 0,0:25:41.41,0:25:47.65,Default,,0000,0000,0000,,and heap. I then fed this into an\Nemulation framework, which is currently
Dialogue: 0,0:25:47.65,0:25:52.51,Default,,0000,0000,0000,,quite slow with unicorn and radare2,\Nbut I get a full call trace, which is very
Dialogue: 0,0:25:52.51,0:25:56.96,Default,,0000,0000,0000,,nice to look at. So I have an idea what is\Ngoing on, what is changed in the memory.
Dialogue: 0,0:25:56.96,0:26:01.17,Default,,0000,0000,0000,,And I currently have a student working on\Na qemu/gdb set up, which is faster but
Dialogue: 0,0:26:01.17,0:26:06.87,Default,,0000,0000,0000,,producing less output, just to fuzz more\Nefficiently. However, you get really a lot
Dialogue: 0,0:26:06.87,0:26:11.06,Default,,0000,0000,0000,,of output that we weren't able to\Ncompletely analyze yet, so there's
Dialogue: 0,0:26:11.06,0:26:19.58,Default,,0000,0000,0000,,probably more. Maybe tell you somewhen\Nlater. Now you need to somehow fix that
Dialogue: 0,0:26:19.58,0:26:23.05,Default,,0000,0000,0000,,bug. And that's that's really a problem,\Nand that's also why I didn't tell you the
Dialogue: 0,0:26:23.05,0:26:29.20,Default,,0000,0000,0000,,exact payload that is causing these\Nissues. Because, well, the fix would be in
Dialogue: 0,0:26:29.20,0:26:33.88,Default,,0000,0000,0000,,one of those .hcd-files. It would be\Nplaintext. It would not be signed and it
Dialogue: 0,0:26:33.88,0:26:38.75,Default,,0000,0000,0000,,would just tell you directly "This handler\Nis vulnerable in exactly this position!"
Dialogue: 0,0:26:38.75,0:26:44.08,Default,,0000,0000,0000,,and so on. The patch is just 14 bytes, but\Nyou need to install it and then it's easy
Dialogue: 0,0:26:44.08,0:26:48.72,Default,,0000,0000,0000,,to understand what it does, right? So I\Nhad an idea: Let's do some more generic
Dialogue: 0,0:26:48.72,0:26:54.39,Default,,0000,0000,0000,,fix. So what I planned to do was having a\Ngeneric filter, filtering some packets
Dialogue: 0,0:26:54.39,0:26:58.27,Default,,0000,0000,0000,,like that you won't reply to, pings\Nconnection establishments and so on, to
Dialogue: 0,0:26:58.27,0:27:04.80,Default,,0000,0000,0000,,untrusted devices. And then just over\NChristmas I started testing that one with
Dialogue: 0,0:27:04.80,0:27:10.65,Default,,0000,0000,0000,,bigger setups, with more phones and so on.\NAnd then I realized: OK if I throw away
Dialogue: 0,0:27:10.65,0:27:16.21,Default,,0000,0000,0000,,some packets and the other device does not\Nexpect me to throw away packets, then the
Dialogue: 0,0:27:16.21,0:27:23.13,Default,,0000,0000,0000,,Bluetooth stack of a device which now\Ntries to connect to me is going to crash.
Dialogue: 0,0:27:23.13,0:27:26.73,Default,,0000,0000,0000,,So I had the next bug! So I tried to fix\None bug. I get the next bug, you know
Dialogue: 0,0:27:26.73,0:27:34.65,Default,,0000,0000,0000,,this. So I actually cannot release any\Nfix, because ... uh. Yeah. Because all of
Dialogue: 0,0:27:34.65,0:27:43.71,Default,,0000,0000,0000,,them still cause the next bug and so on.\NSo how long will this bug be around?
Dialogue: 0,0:27:43.71,0:27:47.90,Default,,0000,0000,0000,,Pretty long probably because there is some\Ndevices which are no longer getting vendor
Dialogue: 0,0:27:47.90,0:27:53.00,Default,,0000,0000,0000,,updates. It needs to be in the vendor\Nupdate, it needs to be this special .hcd-
Dialogue: 0,0:27:53.00,0:27:59.96,Default,,0000,0000,0000,,file. And so on. I mean we can also\Npublish .hcd-files if needed. That's
Dialogue: 0,0:27:59.96,0:28:04.10,Default,,0000,0000,0000,,possible with our framework. That's the good\Nnews, but it will probably never be an
Dialogue: 0,0:28:04.10,0:28:09.07,Default,,0000,0000,0000,,official update. And the vendor updates\Nwill obviously leak the vulnerability. So
Dialogue: 0,0:28:09.07,0:28:15.79,Default,,0000,0000,0000,,it's chicken-egg. As we found this bug\Nstill to be present in devices that were
Dialogue: 0,0:28:15.79,0:28:21.61,Default,,0000,0000,0000,,produced in 2016, we recommend you to turn\Noff Bluetooth - especially if you have a
Dialogue: 0,0:28:21.61,0:28:29.43,Default,,0000,0000,0000,,Broadcom chipset produced before 2017.\NBut in general just turn it off. That's
Dialogue: 0,0:28:29.43,0:28:34.72,Default,,0000,0000,0000,,probably the safest option. And we found\Nout that very old devices having something
Dialogue: 0,0:28:34.72,0:28:40.42,Default,,0000,0000,0000,,like Bluetooth 3.0 are not vulnerable,\Nbecause that feature that we used didn't
Dialogue: 0,0:28:40.42,0:28:46.74,Default,,0000,0000,0000,,exist back then. But still it's a large\Nnumber of devices having this issue.
Dialogue: 0,0:28:48.80,0:28:50.68,Default,,0000,0000,0000,,So, thanks for listening.\N
Dialogue: 0,0:28:50.68,0:29:02.66,Default,,0000,0000,0000,,{\i1}Long Applause{\i0}
Dialogue: 0,0:29:03.14,0:29:09.27,Default,,0000,0000,0000,,Herald: And again if you have questions we\Nhave 8 microphones in the hall. Please
Dialogue: 0,0:29:09.27,0:29:12.77,Default,,0000,0000,0000,,line up at the microphones and you can ask\Nyour questions.
Dialogue: 0,0:29:15.54,0:29:18.61,Default,,0000,0000,0000,,The Signal Angel has the first\Nquestion from the Internet.
Dialogue: 0,0:29:18.64,0:29:22.97,Default,,0000,0000,0000,,Signal Angel: Yes some of the Internet\Nasked if you can guess the Bluetooth MAC
Dialogue: 0,0:29:22.99,0:29:30.50,Default,,0000,0000,0000,,address from the wifi MAC address of a device.\NJiska: Yes. So if I go into... Can we
Dialogue: 0,0:29:30.50,0:29:38.80,Default,,0000,0000,0000,,switch the camera on again? On my magic\Nbox here. Is that possible? Yes. So
Dialogue: 0,0:29:38.80,0:29:49.84,Default,,0000,0000,0000,,actually, if you go to the "Settings",\N"About", and then you will see that the
Dialogue: 0,0:29:49.84,0:29:53.13,Default,,0000,0000,0000,,WiFi and Bluetooth MAC address, they are\Njust off by one.
Dialogue: 0,0:29:53.13,0:30:02.26,Default,,0000,0000,0000,,{\i1}Laughter and applause{\i0}\NDennis: So yeah. You have to note however
Dialogue: 0,0:30:02.26,0:30:06.64,Default,,0000,0000,0000,,that this is not the case with every\Nphone. So usually I think new phones
Dialogue: 0,0:30:06.64,0:30:13.09,Default,,0000,0000,0000,,actually try to randomize their Wi-Fi MAC\Naddress to be not traceable anymore. Not
Dialogue: 0,0:30:13.09,0:30:18.67,Default,,0000,0000,0000,,sure which devices do that. I think the\NNexus 6P does that so the first part will
Dialogue: 0,0:30:18.67,0:30:24.04,Default,,0000,0000,0000,,be the same, because it specifies which\Nvendor this chip was made from. But then,
Dialogue: 0,0:30:24.04,0:30:28.59,Default,,0000,0000,0000,,the lower and least significant bits will\Nchange. So it's sometimes possible,
Dialogue: 0,0:30:28.59,0:30:32.89,Default,,0000,0000,0000,,sometimes not. Yeah. I think that's the\Nanswer to this question.
Dialogue: 0,0:30:32.89,0:30:38.30,Default,,0000,0000,0000,,Herald: OK. The next question was from the\Nmicrophone 8 at the very end of the hall.
Dialogue: 0,0:30:38.73,0:30:41.93,Default,,0000,0000,0000,,Eight: Hello. Thanks for your talk. I was
Dialogue: 0,0:30:41.93,0:30:47.16,Default,,0000,0000,0000,,wondering in your second demo, you showed\Nus how you connect to a device, just using
Dialogue: 0,0:30:47.16,0:30:53.32,Default,,0000,0000,0000,,the MAC address and this device was not\Nadvertising his name. How do you find a
Dialogue: 0,0:30:53.32,0:30:58.64,Default,,0000,0000,0000,,MAC address, if it's not advertising?\NDennis: Yeah. So there are ways to find
Dialogue: 0,0:30:58.64,0:31:04.75,Default,,0000,0000,0000,,out the MAC address of devices which are\Nnearby you. So for example if your device
Dialogue: 0,0:31:04.75,0:31:07.88,Default,,0000,0000,0000,,has Bluetooth turned on but it's not\Ndiscoverable at the moment, but you're
Dialogue: 0,0:31:07.88,0:31:12.06,Default,,0000,0000,0000,,listening to music on your headphones or\Nif you have a smartwatch connected or
Dialogue: 0,0:31:12.06,0:31:16.29,Default,,0000,0000,0000,,any other Bluetooth device connected, then\Nyou will certainly send Bluetooth traffic
Dialogue: 0,0:31:16.29,0:31:19.94,Default,,0000,0000,0000,,and you can sniff that from the air. For\Nexample with a software-defined radio or
Dialogue: 0,0:31:19.94,0:31:26.31,Default,,0000,0000,0000,,an Ubertooth. And so in the talk we\Nmentioned and we also have a link to this
Dialogue: 0,0:31:26.31,0:31:30.42,Default,,0000,0000,0000,,in the slide, I guess it was here,\N"Bluetooth smells like chicken". Michael
Dialogue: 0,0:31:30.42,0:31:35.46,Default,,0000,0000,0000,,Ossman and Dominic Spill, they actually\Nexplained very detailed how you can then
Dialogue: 0,0:31:35.46,0:31:40.29,Default,,0000,0000,0000,,infer the MAC address from those packets\Nyou sniffed. And, yeah, it's doable. It's
Dialogue: 0,0:31:40.29,0:31:42.94,Default,,0000,0000,0000,,not as easy as with Wi-Fi but it's\Ncertainly possible.
Dialogue: 0,0:31:42.94,0:31:45.90,Default,,0000,0000,0000,,Eight: Thank you.\NHerald: Okay. The next question was at
Dialogue: 0,0:31:45.90,0:31:50.36,Default,,0000,0000,0000,,Microphone number one.\NOne: Thanks for your talk and demos. The
Dialogue: 0,0:31:50.36,0:31:59.58,Default,,0000,0000,0000,,question is, does this firmware have any\Nmitigations against exploitation? And if
Dialogue: 0,0:31:59.58,0:32:03.00,Default,,0000,0000,0000,,we imagine that it has, would it help\Nagainst such bugs?
Dialogue: 0,0:32:03.00,0:32:10.63,Default,,0000,0000,0000,,Dennis: So. There's no, like real address\Nrandomization, kind of the obvious way,
Dialogue: 0,0:32:10.63,0:32:14.93,Default,,0000,0000,0000,,because there's... Most of the things are\Nactually global offsets inside the
Dialogue: 0,0:32:14.93,0:32:18.13,Default,,0000,0000,0000,,firmware. So everything is at fixed\Naddresses, like you would use global
Dialogue: 0,0:32:18.13,0:32:25.18,Default,,0000,0000,0000,,variables all over. There's also the RAM,\Nit's actually executable, so you can
Dialogue: 0,0:32:25.18,0:32:29.12,Default,,0000,0000,0000,,execute on the stack, you can execute on\Nthe heap, everywhere. So there's no real
Dialogue: 0,0:32:29.12,0:32:34.55,Default,,0000,0000,0000,,mitigations for such a exploitation. It's\Nlike, I don't think even the newer ones
Dialogue: 0,0:32:34.55,0:32:36.84,Default,,0000,0000,0000,,have that sort of, and the Nexus 5\Nobviously.
Dialogue: 0,0:32:36.84,0:32:41.80,Default,,0000,0000,0000,,Jiska: And another thing that really helps\Nus. So LMP has a version_request,
Dialogue: 0,0:32:41.80,0:32:46.58,Default,,0000,0000,0000,,version_response, which is always sent. So\NI can ask a device actually: Do you have a
Dialogue: 0,0:32:46.58,0:32:51.56,Default,,0000,0000,0000,,vulnerable firmware and which version? And\Nthen I can run exactly the exploit. And
Dialogue: 0,0:32:51.56,0:32:55.55,Default,,0000,0000,0000,,the firmware, I mean, the firmware is\Nstandard and I can just run the addresses
Dialogue: 0,0:32:55.55,0:33:01.47,Default,,0000,0000,0000,,that I know for a certain firmware.\NHerald: Okay. The next question was at
Dialogue: 0,0:33:01.47,0:33:05.63,Default,,0000,0000,0000,,microphone number two. Then again number\None, three and five.
Dialogue: 0,0:33:05.63,0:33:10.68,Default,,0000,0000,0000,,Two: Hi. Thanks for the work especially\Nfor BT-B-g0ne since like it's the TV-B-
Dialogue: 0,0:33:10.68,0:33:17.27,Default,,0000,0000,0000,,Gone. And I'm not sure of which kind of\NiPhone that works, because you had a slide
Dialogue: 0,0:33:17.27,0:33:22.23,Default,,0000,0000,0000,,about iPhone up until 6, and then you had\Na slide that saying if the chip is older
Dialogue: 0,0:33:22.23,0:33:26.48,Default,,0000,0000,0000,,than 2017. So does that work with the last\Nphones as well?
Dialogue: 0,0:33:26.48,0:33:30.16,Default,,0000,0000,0000,,Jiska: Only up to iPhone 6 that was used\Nwas the latest I could get. So if you have
Dialogue: 0,0:33:30.16,0:33:34.18,Default,,0000,0000,0000,,an iPhone 8 or something, our attack does\Nnot work.
Dialogue: 0,0:33:34.18,0:33:38.58,Default,,0000,0000,0000,,Two: So you're going to work on it?\NBecause a lot of people are playing very
Dialogue: 0,0:33:38.58,0:33:42.46,Default,,0000,0000,0000,,bad music and have new phones.\N{\i1}Laughter{\i0}
Dialogue: 0,0:33:42.46,0:33:48.07,Default,,0000,0000,0000,,Jiska: You mean the attack. The attack is\Nnot working on iPhone 6, but the general
Dialogue: 0,0:33:48.07,0:33:53.34,Default,,0000,0000,0000,,framework like patching .hcd-files or\Nchanging the firmware will obviously work
Dialogue: 0,0:33:53.34,0:33:55.91,Default,,0000,0000,0000,,on any Broadcom chip.\NTwo: Okay, thanks.
Dialogue: 0,0:33:55.91,0:33:58.98,Default,,0000,0000,0000,,Dennis: Broadcom actually uses this\Nmechanism for all their chips, all their
Dialogue: 0,0:33:58.98,0:34:03.86,Default,,0000,0000,0000,,Bluetooth chips, so you can use this\Nframework for every Broadcom chip, every
Dialogue: 0,0:34:03.86,0:34:07.65,Default,,0000,0000,0000,,device that has a Broadcom chip. You only\Nneed to do the reverse engineering, as to
Dialogue: 0,0:34:07.65,0:34:12.17,Default,,0000,0000,0000,,get like the real addresses and offsets\Ninside the firmware to do meaningful
Dialogue: 0,0:34:12.17,0:34:14.49,Default,,0000,0000,0000,,patches.\NJiska: But for this you always need to be,
Dialogue: 0,0:34:14.49,0:34:18.66,Default,,0000,0000,0000,,to have a rooted device. You need root\Naccess on the device to run our patching
Dialogue: 0,0:34:18.66,0:34:20.82,Default,,0000,0000,0000,,framework.\NTwo: Okay. Thanks.
Dialogue: 0,0:34:20.82,0:34:23.66,Default,,0000,0000,0000,,Herald: Okay. Now the question at\Nmicrophone number one.
Dialogue: 0,0:34:23.66,0:34:28.42,Default,,0000,0000,0000,,One: Do you have a list of vulnerable\Nchipsets? So I can check if my phone is
Dialogue: 0,0:34:28.42,0:34:31.82,Default,,0000,0000,0000,,vulnerable if it's not like in those\Nslides.
Dialogue: 0,0:34:31.82,0:34:36.62,Default,,0000,0000,0000,,Jiska: Yeah, but it's very incomplete. So\NI also have that, the version numbers and
Dialogue: 0,0:34:36.62,0:34:42.31,Default,,0000,0000,0000,,subversion numbers of those phones. But\Njust consider the time range. So if your
Dialogue: 0,0:34:42.31,0:34:47.74,Default,,0000,0000,0000,,smartphone does Bluetooth 4.0 to 4.2 and\Nit has a Broadcom chip then it's very
Dialogue: 0,0:34:47.74,0:34:52.79,Default,,0000,0000,0000,,likely to be vulnerable.\NHerald: Okay, now the question from
Dialogue: 0,0:34:52.79,0:34:58.75,Default,,0000,0000,0000,,microphone number three.\NThree: Thank you for the codes and the
Dialogue: 0,0:34:58.75,0:35:06.22,Default,,0000,0000,0000,,talk. Quick question, so have you looked\Nat a car Bluetooth? And if not, are you
Dialogue: 0,0:35:06.22,0:35:12.64,Default,,0000,0000,0000,,thinking about it?\NDennis: So I actually used this tool. As I
Dialogue: 0,0:35:12.64,0:35:17.52,Default,,0000,0000,0000,,mentioned previously, we are also able to\Ntest other vulnerabilities, for example
Dialogue: 0,0:35:17.52,0:35:23.35,Default,,0000,0000,0000,,this fixed coordinate invalid curve\Nattack. And so I used my tool to actually
Dialogue: 0,0:35:23.35,0:35:27.36,Default,,0000,0000,0000,,check if a car radio was vulnerable to\Nthis fixed coordinate invalid curve attack
Dialogue: 0,0:35:27.36,0:35:31.44,Default,,0000,0000,0000,,that was released this summer. So it's\Nbasically patched since half a year but
Dialogue: 0,0:35:31.44,0:35:37.03,Default,,0000,0000,0000,,the car was still vulnerable to this. So\Nthe framework is basically usable to test
Dialogue: 0,0:35:37.03,0:35:41.44,Default,,0000,0000,0000,,car radios as well, but I haven't like\Nspecifically looked into a car radio.
Dialogue: 0,0:35:41.44,0:35:45.13,Default,,0000,0000,0000,,Three: Thank you.\NHerald: Okay. Now a question from
Dialogue: 0,0:35:45.13,0:35:49.23,Default,,0000,0000,0000,,Microphone number five. Then we take a\Nquestion from the Internet and microphone
Dialogue: 0,0:35:49.23,0:35:55.99,Default,,0000,0000,0000,,number six.\NFive: What is the attack surface exposed
Dialogue: 0,0:35:55.99,0:36:02.78,Default,,0000,0000,0000,,by your exploits? What's the worst case?\NCould you manipulate memory or something?
Dialogue: 0,0:36:02.78,0:36:07.27,Default,,0000,0000,0000,,Jiska: Worst case it's hard to estimate. I\Nmean we can change some memory addresses
Dialogue: 0,0:36:07.27,0:36:12.19,Default,,0000,0000,0000,,at least in the Nexus 5. And for each\Nsmartphone there are other functions by
Dialogue: 0,0:36:12.19,0:36:16.77,Default,,0000,0000,0000,,the compiler put there. So to really know\Nwhat is happening, we would now need to
Dialogue: 0,0:36:16.77,0:36:22.89,Default,,0000,0000,0000,,analyze like really tons of firmwares and\Ncheck what is in there and do some
Dialogue: 0,0:36:22.89,0:36:28.75,Default,,0000,0000,0000,,fuzzing. We already found out that some\Nthings only happen if you combine multiple
Dialogue: 0,0:36:28.75,0:36:32.32,Default,,0000,0000,0000,,packets and so on. So it's really hard to\Nestimate what is the worst case. So the
Dialogue: 0,0:36:32.32,0:36:36.92,Default,,0000,0000,0000,,very worst case would be, so to say, that\Nyou can run arbitrary code in the
Dialogue: 0,0:36:36.92,0:36:43.43,Default,,0000,0000,0000,,Bluetooth, in the Bluetooth firmware\Nitself, and then the next worst case would
Dialogue: 0,0:36:43.43,0:36:47.66,Default,,0000,0000,0000,,be if there would be another vulnerability\Nin the driver, that you could escape
Dialogue: 0,0:36:47.66,0:36:52.66,Default,,0000,0000,0000,,the firmware. So that would be the next\Nstep. But that really requires an exploit
Dialogue: 0,0:36:52.66,0:36:58.37,Default,,0000,0000,0000,,chain. So the very worst case would be\Nsomething similar. So there has been
Dialogue: 0,0:36:58.37,0:37:03.97,Default,,0000,0000,0000,,vulnerabilities in the Wi-Fi part of\NBroadcom chips where you had the
Dialogue: 0,0:37:03.97,0:37:11.54,Default,,0000,0000,0000,,possibility to really run an exploit chain\Nwhich then rooted a device in the end. But
Dialogue: 0,0:37:11.54,0:37:14.88,Default,,0000,0000,0000,,it's hard to estimate if you can do it\Nwith this or not.
Dialogue: 0,0:37:14.88,0:37:18.28,Default,,0000,0000,0000,,Herald: OK. Now the question from the\NInternet please.
Dialogue: 0,0:37:18.28,0:37:22.94,Default,,0000,0000,0000,,Internet: Do you know if any older but\Nstill supported devices like old MacBooks
Dialogue: 0,0:37:22.94,0:37:28.76,Default,,0000,0000,0000,,are patched and can you actually detect\Nthis in any way other than a chip crash?
Dialogue: 0,0:37:28.76,0:37:38.10,Default,,0000,0000,0000,,Jiska: Not really, so we can try to not\Ncrash the chip by first checking if it is
Dialogue: 0,0:37:38.10,0:37:42.81,Default,,0000,0000,0000,,sending appropriate answers, but typically\Nthe really only thing to be sure is that
Dialogue: 0,0:37:42.81,0:37:48.26,Default,,0000,0000,0000,,it crashes. So that so far is the only\Nway, because I mean obviously, if Broadcom
Dialogue: 0,0:37:48.26,0:37:52.02,Default,,0000,0000,0000,,would tell "the following chips are\Nvulnerable", which they didn't so far,
Dialogue: 0,0:37:52.02,0:37:57.43,Default,,0000,0000,0000,,because that's also to protect themselves\Nprobably, then you could be sure. But yeah
Dialogue: 0,0:37:57.43,0:38:01.98,Default,,0000,0000,0000,,as of now that's the only way to check it.\NHerald: Thank you. Now the question from
Dialogue: 0,0:38:01.98,0:38:06.20,Default,,0000,0000,0000,,microphone number six please.\NSix: Yeah. Would it be possible to
Dialogue: 0,0:38:06.20,0:38:13.12,Default,,0000,0000,0000,,increase the Bluetooth radio transmission\Npower by patching the firmware? So that
Dialogue: 0,0:38:13.12,0:38:18.21,Default,,0000,0000,0000,,Bluetooth works across entire\Nbuildings and not only in a single room?
Dialogue: 0,0:38:18.21,0:38:23.03,Default,,0000,0000,0000,,Dennis: Yeah. So the thing is, we are\Nactually now patching the firmware of the
Dialogue: 0,0:38:23.03,0:38:27.07,Default,,0000,0000,0000,,chip, and the firmware does like all the\Nthe link layer stuff of Bluetooth. The
Dialogue: 0,0:38:27.07,0:38:31.48,Default,,0000,0000,0000,,real physical part is probably done in\Nanother component inside the chip which
Dialogue: 0,0:38:31.48,0:38:36.21,Default,,0000,0000,0000,,may be running another kind of small real-\Ntime firmware and we haven't found that
Dialogue: 0,0:38:36.21,0:38:40.08,Default,,0000,0000,0000,,yet. We are still looking for it because\Nthat must be in there somewhere, like that
Dialogue: 0,0:38:40.08,0:38:44.53,Default,,0000,0000,0000,,Bluetooth modem and maybe we can actually\Nchange the settings for this modem. I
Dialogue: 0,0:38:44.53,0:38:48.76,Default,,0000,0000,0000,,don't think it will be too drastical. But\Nmaybe if you're in different areas of the
Dialogue: 0,0:38:48.76,0:38:52.05,Default,,0000,0000,0000,,world and like your Bluetooth has\Ndifferent strengths in different areas of
Dialogue: 0,0:38:52.05,0:38:56.01,Default,,0000,0000,0000,,the world, you can maybe manipulate that.\NBut we haven't found it yet.
Dialogue: 0,0:38:56.01,0:38:59.09,Default,,0000,0000,0000,,Six: OK. Thank you.\NHerald: Okay. Next question is coming from
Dialogue: 0,0:38:59.09,0:39:03.73,Default,,0000,0000,0000,,microphone number four.\NFour: Does the Bluetooth chipset have
Dialogue: 0,0:39:03.73,0:39:08.60,Default,,0000,0000,0000,,access to system RAM?\NDennis: Sorry I didn't get the last word.
Dialogue: 0,0:39:08.60,0:39:09.92,Default,,0000,0000,0000,,Jiska: The system rights or what do you\Nmean?
Dialogue: 0,0:39:09.92,0:39:13.77,Default,,0000,0000,0000,,Four: The system RAM, memory.\NDennis: You mean the memory of the main
Dialogue: 0,0:39:13.77,0:39:16.50,Default,,0000,0000,0000,,processor like where Android or iOS is\Nrunning on?
Dialogue: 0,0:39:16.50,0:39:19.59,Default,,0000,0000,0000,,Four: Yes.\NDennis: No it's not like as with Wi-Fi
Dialogue: 0,0:39:19.59,0:39:23.94,Default,,0000,0000,0000,,where you have direct memory access. But\NBluetooth, the HCI interface is the only
Dialogue: 0,0:39:23.94,0:39:29.57,Default,,0000,0000,0000,,interface between those two processors.\NAnd this is usually done over either USB
Dialogue: 0,0:39:29.57,0:39:36.33,Default,,0000,0000,0000,,or in the Nexus 5 is actually UART.\NHerald: Next question is coming from
Dialogue: 0,0:39:36.33,0:39:39.93,Default,,0000,0000,0000,,microphone number three.\NThree: Many thanks for the enlightening
Dialogue: 0,0:39:39.93,0:39:43.75,Default,,0000,0000,0000,,and scary talk. I missed a little bit of\Nthe beginning maybe that question was
Dialogue: 0,0:39:43.75,0:39:50.97,Default,,0000,0000,0000,,inside there. Did you or do you considered\Nto disclose this vulnerability for example
Dialogue: 0,0:39:50.97,0:39:56.37,Default,,0000,0000,0000,,to BSI (Bundesamt für Sicherheit in der\NInformationstechnik)? As I would consider
Dialogue: 0,0:39:56.37,0:40:01.93,Default,,0000,0000,0000,,their obligation to inform general public\Nlike put a note on their website saying:
Dialogue: 0,0:40:01.93,0:40:06.90,Default,,0000,0000,0000,,"Look, if you're running a certain\Nsmartphone you're vulnerable to a certain
Dialogue: 0,0:40:06.90,0:40:11.81,Default,,0000,0000,0000,,attack!" And that would put much more\Nstress on the vendors to really look into
Dialogue: 0,0:40:11.81,0:40:14.12,Default,,0000,0000,0000,,this.\NJiska: Yeah that sounds like a good
Dialogue: 0,0:40:14.12,0:40:22.48,Default,,0000,0000,0000,,option. So far we're, so we asked Broadcom\Nwhen we can publish things and at least
Dialogue: 0,0:40:22.48,0:40:26.69,Default,,0000,0000,0000,,they agreed that it's no problem to\Npublish it in summer, then it would be
Dialogue: 0,0:40:26.69,0:40:31.03,Default,,0000,0000,0000,,public for everyone. But yeah, BSI would\Nalso be a nice option.
Dialogue: 0,0:40:31.94,0:40:33.59,Default,,0000,0000,0000,,Three: Thank you.\N
Dialogue: 0,0:40:33.59,0:40:36.44,Default,,0000,0000,0000,,Herald: OK. Is there another question\Nfrom the Internet?
Dialogue: 0,0:40:37.02,0:40:38.62,Default,,0000,0000,0000,,…
Dialogue: 0,0:40:40.41,0:40:45.70,Default,,0000,0000,0000,,Please switch on the\Nmicrophone for the Internet.
Dialogue: 0,0:40:45.70,0:40:50.83,Default,,0000,0000,0000,,Internet: Hello? Hi. So do you know if any\Ndevices have been patched yet, which have
Dialogue: 0,0:40:50.83,0:40:55.23,Default,,0000,0000,0000,,not been released after 2017, or are there\Nno rolled out patches?
Dialogue: 0,0:40:55.23,0:41:01.43,Default,,0000,0000,0000,,Jiska: I don't think so. So, it took\NBroadcom two months to actually confirm
Dialogue: 0,0:41:01.43,0:41:05.70,Default,,0000,0000,0000,,that there is this vulnerability. So on\NDecember 3rd they said, ooops it really
Dialogue: 0,0:41:05.70,0:41:12.28,Default,,0000,0000,0000,,exists. And then on December 9th, they\Nwere like: "Ooh, do you really plan to do
Dialogue: 0,0:41:12.28,0:41:15.43,Default,,0000,0000,0000,,that talk here?!"\N{\i1}Laughter{\i0}
Dialogue: 0,0:41:15.43,0:41:22.43,Default,,0000,0000,0000,,And I did the most recent iOS update on\Nthe iPhone 6 that I just showed you. And
Dialogue: 0,0:41:22.43,0:41:26.49,Default,,0000,0000,0000,,this one is still valuable. I think it\Ntakes some time for testing. So I would
Dialogue: 0,0:41:26.49,0:41:32.31,Default,,0000,0000,0000,,say the first patches will come out maybe\Nin 1, 2 months, but we don't know.
Dialogue: 0,0:41:32.31,0:41:35.67,Default,,0000,0000,0000,,Herald: Okay. One last quick question from\Nmicrophone number one.
Dialogue: 0,0:41:35.67,0:41:40.18,Default,,0000,0000,0000,,One: So is it … do you think it is\Npossible to trace back when was this
Dialogue: 0,0:41:40.18,0:41:44.90,Default,,0000,0000,0000,,vulnerability introduced, so we can go\Nback and try to hack old devices that
Dialogue: 0,0:41:44.90,0:41:49.67,Default,,0000,0000,0000,,probably have the same firmware or\Nfirmware vulnerability? Because they
Dialogue: 0,0:41:49.67,0:41:55.54,Default,,0000,0000,0000,,should be backward compatible, right? So\Nif the same handler is implemented I
Dialogue: 0,0:41:55.54,0:42:00.13,Default,,0000,0000,0000,,know in 2012 first and for the first time\Nthen uh...
Dialogue: 0,0:42:00.13,0:42:02.51,Default,,0000,0000,0000,,Jiska: Yeah.\NOne: Probably the devices can be narrowed
Dialogue: 0,0:42:02.52,0:42:04.83,Default,,0000,0000,0000,,down, right?\NJiska: So at least.. so the Nexus 5 has a
Dialogue: 0,0:42:04.83,0:42:14.99,Default,,0000,0000,0000,,firmware from 2012 actually. So somewhere,\Nso the June 2nd is when it still existed
Dialogue: 0,0:42:14.99,0:42:21.22,Default,,0000,0000,0000,,in 2014. I don't know. So in each firmware\Nthere is a build date and I would then
Dialogue: 0,0:42:21.22,0:42:25.56,Default,,0000,0000,0000,,need to extract the firmware of vulnerable\Ndevices and so on, so it's a long process,
Dialogue: 0,0:42:25.56,0:42:28.69,Default,,0000,0000,0000,,but at least the vulnerability was there\Nfor multiple years.
Dialogue: 0,0:42:30.07,0:42:34.53,Default,,0000,0000,0000,,Herald: Okay now give please a huge round\Nof applause for Jiska Classen
Dialogue: 0,0:42:34.53,0:42:36.54,Default,,0000,0000,0000,,and Dennis Mantz for their talk.\N
Dialogue: 0,0:42:36.54,0:42:37.31,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:42:37.31,0:42:39.29,Default,,0000,0000,0000,,Dennis: Thank you!\N{\i1}Applause{\i0}
Dialogue: 0,0:42:39.29,0:42:45.17,Default,,0000,0000,0000,,{\i1}35C3 outro music{\i0}
Dialogue: 0,0:42:45.17,0:43:03.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2019. Join, and help us!