[00:02.140 --> 00:07.520]  Hello everyone and welcome to the talk Spectra, which is about new wireless escalation targets.
[00:07.620 --> 00:13.580]  This is a joint work by me, Jeska and Francesco, who has been working a lot with Wi-Fi while I
[00:13.580 --> 00:19.180]  have been working with Bluetooth in the past. And in this work, we join our abilities to build a
[00:19.180 --> 00:27.020]  new attack scheme. So the motivation of this is as simple as this. I found a partial Bluetooth RCE
[00:27.860 --> 00:32.460]  a while ago. And then a bit later, a student of mine, Jan, built a fuzzer Frankenstein,
[00:32.460 --> 00:38.540]  which emulates the Bluetooth chips. And he also found a couple of more remote code executions.
[00:38.820 --> 00:43.340]  And with this, I said like, yeah, that's a great chance. Now we can tour the world,
[00:43.340 --> 00:49.020]  tell everyone like we have Bluetooth remote code execution, take my unicorn, travel with it,
[00:49.020 --> 00:54.760]  and just show everyone. But the thing is that people said they are not too surprised about
[00:54.760 --> 00:59.280]  Bluetooth remote code execution because, you know, Bluetooth after 22 years is
[00:59.280 --> 01:04.220]  really indistinguishable from magic. And they kind of expected that it is broken.
[01:05.960 --> 01:10.900]  And then people also told me, you know, there is Bluetooth RCE, there's Wi-Fi RCE.
[01:10.900 --> 01:16.840]  And Wi-Fi RCE is much cooler because, first of all, Bluetooth, it's connected via UART,
[01:16.840 --> 01:23.220]  and Wi-Fi is connected with PCI Express. That is just nicer for exploitation. And also,
[01:23.220 --> 01:28.940]  if you can pop KALC, it's a nice attack. But if you cannot pop KALC,
[01:28.940 --> 01:32.680]  then what kind of attack is a Bluetooth on-chip remote code execution?
[01:33.880 --> 01:40.220]  So I was thinking, because now the idea is, of course, like I could try to like take the
[01:40.220 --> 01:45.280]  Bluetooth RCE and then break into the operating system all the way up. But another funny attack
[01:45.280 --> 01:51.820]  would be to instead attack the Wi-Fi chip or maybe even the LTE chip. So to break the interchip
[01:51.820 --> 01:57.040]  separation instead of doing the same thing again of breaking into the operating system.
[01:58.560 --> 02:04.300]  And then I called Francesco and said like, hey, let's build speculative transmission.
[02:04.640 --> 02:10.780]  And the idea of the attack was that in a smartphone, you have the same frequency used
[02:10.780 --> 02:16.420]  by Wi-Fi and Bluetooth and LTE has harmonics in the same spectrum. And they cause interference
[02:16.420 --> 02:23.220]  and in such a small device. So they need to arbitrate the channel access, which means they
[02:23.220 --> 02:28.540]  need to actually tell I'm sending a packet. Can you please not send a packet right now and so on
[02:28.540 --> 02:34.220]  and also need to tell priorities and so on. And this is called a coexistence mechanism,
[02:34.220 --> 02:38.460]  and it's a performance optimization. And of course, you could now also instead
[02:39.260 --> 02:45.140]  speculatively transmit a packet and use this to infer what the other cores are doing. So this
[02:45.140 --> 02:51.280]  was the initial attack idea. In the end, it turned out to be a bit more of a spectrum transmission,
[02:51.280 --> 02:58.460]  but this is the attack scheme. Of course, it requires a lot of expectation before. So it
[02:58.460 --> 03:03.120]  requires the Bluetooth remote code execution or Wi-Fi remote code execution to then escalate
[03:03.120 --> 03:08.460]  into the other chip. But the interesting part here is, as this is a connection directly between
[03:08.460 --> 03:15.000]  the chips, you cannot block it with the operating system. So there is a very nice attack vector that
[03:15.000 --> 03:22.540]  is hard to prevent. And if you look into a modern iPhone, this is what it roughly looks like. So you
[03:22.540 --> 03:28.840]  have the Bluetooth and the Wi-Fi chip, which are within a combo chip, but they still run on different
[03:28.840 --> 03:34.140]  ARM cores. And they are connected via the serial enhanced coexistence interface. This is what we
[03:34.140 --> 03:41.940]  are going to attack. The combo chip is also interconnected with an LTE chip, and this is
[03:41.940 --> 03:47.300]  using mobile wireless standards. And then you can also see that the Bluetooth daemon has fewer
[03:47.300 --> 03:53.620]  writes than the Wi-Fi daemon. And the Bluetooth chip is usually connected with UI, the newer iPhones
[03:53.620 --> 03:59.220]  use PCI Express here. And now, if you could escalate between the chips, you have new attack paths
[03:59.220 --> 04:06.000]  that become possible. So for example, I could now start from Bluetooth over the air and then escalate
[04:06.000 --> 04:11.920]  into Wi-Fi and then go all the way up. Or I could also try to infer timings in between those
[04:11.920 --> 04:19.920]  chips and so on. The spectral impact can be very different depending on how this coexistence
[04:19.920 --> 04:25.380]  interface is implemented. So first of all, the most obvious one is the denial of service, if one
[04:25.380 --> 04:30.780]  core denies transmission to another core. But it could also be information disclosure via timings
[04:30.780 --> 04:36.600]  or packet types and so on. And the worst case would be code execution. And for this one, you really
[04:36.600 --> 04:42.160]  need to screw up your implementation. When this attack has been first on the internet because of
[04:42.160 --> 04:47.060]  the blackhead abstract, someone started tweeting and giving it other names. And I have to say,
[04:47.060 --> 04:53.980]  I also like the queer ghost attack, but spectra is like the original name. Of course, it's harder
[04:53.980 --> 04:58.420]  to find this on the internet because spectra is just a very generic word.
[05:00.860 --> 05:06.440]  And now let's go for the Broadcom coexistence interface, which we are now going to exploit.
[05:06.600 --> 05:13.280]  This is also present in a couple of Cypress chips because Cypress acquired parts of Broadcom in 2016.
[05:13.520 --> 05:19.440]  So it's synonymous to be used here. So don't be confused if I mix up Broadcom and Cypress,
[05:19.440 --> 05:26.580]  it's all the same. Actually, Broadcom is a very nice target because they don't do any firmware
[05:26.580 --> 05:32.980]  checks. And no firmware checks means that if we are able to reverse engineer certain parts of the
[05:32.980 --> 05:39.220]  firmware, then we can also patch it within Wi-Fi and within Bluetooth. And there are no further
[05:39.220 --> 05:45.420]  checks, which means that there is no secure boot, no signature checking, etc. So you still need to
[05:45.420 --> 05:52.540]  understand what is going on to patch such a chip, but then there are no further security measures
[05:52.540 --> 05:58.640]  to prevent this. And those chips are in many, many, many devices. So for example, all iPhones,
[05:58.640 --> 06:02.920]  MacBooks, iMacs and also the older Apple Watches, the newest ones have a different one,
[06:02.920 --> 06:08.160]  the Samsung Galaxy S series, the older Google Nexus phones or Raspberry Pis, a couple of IoT
[06:08.160 --> 06:14.060]  devices and so on. So this is a very nice prototyping platform for all kinds of attacks.
[06:16.280 --> 06:21.240]  If you look into the older data sheets, you can also find a couple of details, still not everything,
[06:21.720 --> 06:26.200]  but the newer data sheets just don't exist. So we need to live with what is there, what is
[06:26.200 --> 06:31.500]  documented. And what you can see here, there's this Bluetooth chip, there is a Wi-Fi chip,
[06:31.500 --> 06:38.080]  they share an antenna, so they need to arbitrate access onto this one. And then there is a lot of
[06:38.080 --> 06:43.180]  stuff going on between those chips, which we are going to attack in the following. Nonetheless,
[06:43.180 --> 06:47.460]  they have different ARM cores. So this one has an ARM Cortex-M3, there's the Cortex-R4
[06:48.040 --> 06:51.980]  and so on. So this is still separated in some ways.
[06:55.170 --> 07:00.590]  For understanding the attacks now, we need to understand the Serial Enhanced Coexistence
[07:00.590 --> 07:05.430]  Interface, which is used between Wi-Fi and Bluetooth. It's also called ECI, so without
[07:05.430 --> 07:10.870]  the serial, and GCI, which might be Global or Generic Coexistence Interface, but it's all used
[07:10.870 --> 07:19.870]  in the same way in the data sheets. To understand it, the best way is to actually separate Bluetooth
[07:19.870 --> 07:25.250]  and Wi-Fi. And in this setup, you can see that there is a Bluetooth and a Wi-Fi board by Cypress.
[07:25.310 --> 07:29.830]  They don't have a shared antenna, so everything is separate, there are no side effects, and the
[07:29.830 --> 07:34.790]  only connection that they have is the Serial Enhanced Coexistence Interface, which we can
[07:34.790 --> 07:41.110]  now also intercept. So that means that we are actually able to observe each and every signal
[07:41.110 --> 07:47.590]  that is sent between those two boards, and there is nothing else that is going on that could block
[07:47.730 --> 07:55.510]  a transmission. If you look into this in detail, first of all we did the experiments of streaming
[07:55.510 --> 08:01.470]  just some music over Bluetooth, and then on the Wi-Fi chip we did a scan for other Wi-Fis. You can
[08:01.470 --> 08:06.850]  see a peak when you start the scan, actually it's two peaks, and then there are a couple of other
[08:06.850 --> 08:13.070]  peaks when you get the scan results, and the end of the scan. And what is very interesting about
[08:13.070 --> 08:18.590]  this protocol already at this level is that the Bluetooth and Wi-Fi are sending with three
[08:18.590 --> 08:24.150]  megabytes over the Serial Interface, and three megabytes is also the same amount of data that is
[08:24.150 --> 08:28.850]  sent from the Bluetooth chip to the host to send the actual music of the stream. So you can imagine
[08:28.850 --> 08:35.730]  how much data there is within the Coexistence Interface. And now you can see that Bluetooth is
[08:35.730 --> 08:42.930]  within each peak actually sending some data that is annotated in hex here, and also Wi-Fi
[08:42.930 --> 08:49.190]  is sending some data. So each tiny peak there really has some information about the task that
[08:49.190 --> 08:55.670]  is running and other stuff that tells priorities of packets. And in the last example you can also
[08:55.670 --> 09:02.070]  see a Bluetooth keyboard which has regular peaks that is then being sent while Wi-Fi is idle. So
[09:02.070 --> 09:07.030]  this is roughly what it looks like just to give you some idea about this protocol.
[09:09.380 --> 09:16.100]  In the first attack we didn't even need to understand all the details of this. It's just a
[09:16.100 --> 09:23.380]  simple reconfiguration of this interface. So there are a lot, a lot, a lot of registers that are mapped
[09:23.380 --> 09:30.700]  into the Bluetooth ARM core that you can write into or read from. And actually I tried to understand
[09:30.700 --> 09:36.360]  all of them in the very beginning, and you can also do fancy stuff with this, but I didn't
[09:36.360 --> 09:41.440]  understand all of them. And then Francesco just told me, well if you don't understand it, just try
[09:41.440 --> 09:46.640]  breaking it. Just write something in all those registers and see what breaks. And I found out
[09:46.640 --> 09:53.620]  when I write just apps into the GCI chip control, this crashes Wi-Fi. And more interestingly in this
[09:53.620 --> 09:58.400]  evaluation board setup I could even see some voltage drop on the logic analyzer. This was
[09:58.400 --> 10:05.940]  very weird. And on some devices this even causes a kernel panic, because upon writing to the GCI
[10:05.940 --> 10:12.520]  chip control within Bluetooth, Wi-Fi might stop or even spam stuff over PCI Express and so on. And
[10:12.520 --> 10:19.420]  then there are very weird effects from this. I tested it on a couple of devices, so starting
[10:19.420 --> 10:25.640]  from the Nexus 5, but then also going all the way up to the newest MacBooks and iPhones and so on,
[10:25.640 --> 10:31.940]  and the Samsung Galaxy S10, S20. And what you can see here is that first of all, depending on the
[10:31.940 --> 10:36.560]  date of the chip you have a slightly different scheme, but on the newest ones you just write apps
[10:36.560 --> 10:43.640]  into one address. And already this is sufficient to have a kernel panic on a lot of those devices.
[10:43.640 --> 10:50.560]  On some of them it's also just Wi-Fi that restarts and that's it. Now this already looks very promising
[10:50.560 --> 10:56.520]  for such a simple attack, and because of this we tried to build more fancy attacks with this primitive.
[10:56.780 --> 11:00.040]  And this is what Francesco is now going to tell you about.
[11:04.890 --> 11:10.370]  Thanks Gisca for introducing this part of the talk. Let's start describing the Broadcom Wi-Fi
[11:10.370 --> 11:15.510]  chipset. In the last two decades it evolved from a soft Mac to a full Mac implementation,
[11:15.510 --> 11:20.990]  and functions that were originally running on the Linux host at the top are today offloaded by an
[11:20.990 --> 11:26.510]  intermediate ARM core. Interestingly, low-level operations are always managed by the same piece
[11:26.510 --> 11:32.230]  of hardware that did not change much in 70 years. No matter which Wi-Fi chipset we are using,
[11:32.230 --> 11:37.430]  critical operations are managed by the same D11 microcontroller that coordinates
[11:37.430 --> 11:43.350]  PHY, radiofrequency and VMA operations. Let's have a closer look to the low-level. The D11
[11:43.350 --> 11:49.410]  microcontroller runs the microcode, a short piece of software that keeps checking hardware conditions
[11:49.410 --> 11:55.110]  and triggers specific operations. We see here some code from the main loop that checks if the PHY
[11:55.110 --> 12:00.830]  started receiving a PLCP preamble, or if the current reception is terminated. In such cases
[12:00.830 --> 12:06.050]  it will execute the corresponding handlers that will decide what to do with the current PHY. This
[12:06.050 --> 12:11.410]  other piece of code is extracted from the part that schedules the transmission of an acknowledgement.
[12:11.410 --> 12:17.270]  We see the preparation of the reply frame that starts with D4 as usual. The D11 toolchain was
[12:17.270 --> 12:24.050]  created by Michael Buech in 2007. We incorporated it inside our Netman project and we periodically
[12:24.050 --> 12:29.850]  update it by adding new instructions when a new chipset is introduced. As spotting the new code
[12:29.850 --> 12:36.250]  in the ARM binary blob is easy, we can modify it adding customized parts, as we will see later.
[12:36.250 --> 12:41.810]  The D11 CPU coordinates many blocks. First of all, it controls the transmission and reception
[12:41.810 --> 12:47.890]  engines, it manages channels access by scheduling transmissions, and the sides which received frames
[12:47.890 --> 12:53.510]  should be pushed to the ARM core. It can configure the PHY and the radio, and it does so by running
[12:53.510 --> 12:58.990]  the U-code that is loaded into the U-code memory by the ARM firmware during initialization.
[12:58.990 --> 13:05.670]  The D11 has access to an 8 kilobyte shared memory where it keeps its configuration and state variables,
[13:05.670 --> 13:11.190]  and it also accesses indirectly the ARM memory where packets ready for transmissions are queued
[13:11.190 --> 13:16.310]  for deciding which packets can be transmitted or aggregated. The D11 is equipped with general
[13:16.310 --> 13:21.490]  purpose timers and with many different interfaces for talking to other parts of the chipset,
[13:21.490 --> 13:26.470]  like the Secchi interface. During the years it turned out to be a pretty flexible architecture
[13:26.470 --> 13:31.230]  and we used it as a research platform for showcasing operations like jamming,
[13:31.230 --> 13:35.650]  piggybacking schemes, and time-of-flight measurements. Let's now talk about the D11
[13:35.650 --> 13:41.630]  coexistence interface. It includes quite a number of registers and a 64-bit buffer for receiving
[13:41.630 --> 13:47.890]  messages from the Bluetooth. Such messages are transmitted by Bluetooth every 1.25 milliseconds,
[13:47.890 --> 13:53.290]  that is the minimum Bluetooth connection interval. They report to Wi-Fi the timing and type of all
[13:53.290 --> 13:58.950]  Bluetooth operations. Wi-Fi copies this information inside dedicated Secchi countdown
[13:58.950 --> 14:04.890]  timers that defer Wi-Fi operations and prevent collisions. On the opposite direction,
[14:04.890 --> 14:10.470]  Wi-Fi uses the Bluetooth transmission control register, in red, for granting Bluetooth access
[14:10.470 --> 14:16.630]  to the chip. The flow of messages in the two directions builds a grant-reject scheme. As we
[14:16.630 --> 14:21.970]  will see, in our attacks we used the knowledge we collected on such registers for breaking such
[14:21.970 --> 14:28.550]  scheme. According to our analysis, more than 10% of the U-code is dedicated to coexistence. As in
[14:28.550 --> 14:34.930]  general many other operations take much less code, we understand how much complex is the coexistence
[14:34.930 --> 14:40.610]  interface. Finally, by programming two boards for transmitting Secchi messages when receiving the
[14:40.610 --> 14:46.830]  same Wi-Fi beacon, we measured, with the help of an external FPGA, the jitter of the Secchi line.
[14:46.830 --> 14:52.410]  It turned out to be Gaussian with 200 nanosecond deviation, which is perfect for this application.
[14:52.410 --> 14:58.530]  So let's see how we broke the grant-reject scheme. We did that to see the effects when watching a
[14:58.530 --> 15:05.030]  movie that requires to download content over the Wi-Fi and send audio to a Bluetooth headset.
[15:05.030 --> 15:10.810]  At the bottom, in green, we see Secchi grant messages transmitted by the Wi-Fi. Bluetooth
[15:10.810 --> 15:15.890]  uses them for understanding when it can transmit audio to the headset. We introduce it into the
[15:15.890 --> 15:21.690]  U-code a few lines for configuring the Wi-Fi chipset remotely from the air interface. We can
[15:21.690 --> 15:28.130]  hence prevent the Wi-Fi from sending Secchi grant messages to Bluetooth. You see this happens between
[15:28.130 --> 15:35.230]  2.6 and 3.5 seconds. During this interval no more Secchi messages are transmitted and, in fact,
[15:35.230 --> 15:40.170]  we cannot hear any sound from the headset. We tested this both on a Nexus 5 and on
[15:40.170 --> 15:45.950]  development boards from Cypress. This experiment clearly demonstrates that a denial-of-service
[15:45.950 --> 15:51.610]  attack from the Wi-Fi side against Bluetooth is possible. Let's take a closer look now at
[15:51.610 --> 15:57.250]  the messages that Bluetooth sends to Wi-Fi and if we can use such information for an attack.
[15:57.250 --> 16:02.630]  These are the Secchi time diagrams when we have a keyboard connected over Bluetooth. Depending
[16:02.630 --> 16:08.970]  on the keyboard, we can observe Secchi messages transmitted every 15 or 30 milliseconds. Bluetooth
[16:08.970 --> 16:15.310]  sends these Secchi messages to inform Wi-Fi that it is going to poll the keyboard so that Wi-Fi
[16:15.310 --> 16:21.810]  defers channel access meanwhile. In this diagram Wi-Fi is idle, so Wi-Fi always grants access to
[16:21.810 --> 16:27.650]  Bluetooth. This is what happens when somebody is actually typing on a keyboard. At the bottom we
[16:27.650 --> 16:33.570]  have the periodic sequence of Secchi messages. On top we have the key presses sniffed by Wireshark
[16:33.570 --> 16:38.770]  when capturing from the Bluetooth interface. As we are typing with moderate speed, each key press
[16:38.770 --> 16:43.950]  is separate from the others and we can also see the Bluetooth message with key release following
[16:43.950 --> 16:50.350]  each key press. In between we can see the HID data captured by Wireshark with a specific event ID
[16:50.350 --> 16:55.990]  that represents a key press. Below we see Secchi messages that we filtered on the Wi-Fi chipset by
[16:55.990 --> 17:01.730]  selecting the same message type. This demonstrates that at the Wi-Fi side we can easily distinguish
[17:01.730 --> 17:07.370]  Secchi messages related to key presses. This clearly demonstrates that having access to the
[17:07.370 --> 17:12.710]  Wi-Fi chipset is enough for measuring key press timings with very accurate resolution and we know
[17:12.710 --> 17:18.010]  that in some cases with the help of some artificial intelligence or classification technique this is
[17:18.010 --> 17:23.210]  enough for guessing what a user is typing. We hence believe that without any further protection
[17:23.210 --> 17:28.930]  the Secchi interface can be used for mounting side channel attacks and we requested the CVE
[17:28.930 --> 17:34.010]  for reporting the associated vulnerability. Francesca, the ground is yours again.
[17:36.050 --> 17:41.430]  Thank you Francesco for the very detailed explanations about the serial enhanced coexistence
[17:41.430 --> 17:46.710]  interface and attacks on it. There is still one thing mentioned in the data sheet which was clearly
[17:46.710 --> 17:52.630]  missing which is the WLAN RAM sharing and in the following we are also going to attack this.
[17:53.290 --> 17:57.850]  I would call this effect when you spend too much time looking for very fancy side channels
[17:57.850 --> 18:03.770]  and dig deeper into all of this and try to explore them while there is the one obvious thing in a
[18:03.770 --> 18:08.470]  data sheet that you just couldn't find within the serial enhanced coexistence interface and for us
[18:08.470 --> 18:14.310]  this was this WLAN RAM sharing so it must be somewhere it's in the data sheet errors just go
[18:14.310 --> 18:20.390]  into one direction here from Bluetooth to Wi-Fi and we just didn't understand where it is and
[18:20.390 --> 18:28.730]  couldn't find it for quite a long time. And the reason for this is that the Cypress boards come
[18:28.730 --> 18:35.470]  with some development kit and within this there are some symbol leaks but the problem here is
[18:35.470 --> 18:41.770]  there's nothing mentioned with WLAN and so there probably is no WLAN RAM sharing I thought maybe
[18:41.770 --> 18:48.550]  it's just another word for the enhanced coexistence mappings but then there was also another part of
[18:48.550 --> 18:53.570]  symbols and I was able to obtain a ROM image and it's not from a development board but actually
[18:53.570 --> 19:23.550]  A little pause... and we are back...
[19:23.570 --> 19:30.390]  The beginning of the section, I actually saw, wow, there is a string 802.11 something on
[19:30.390 --> 19:34.950]  the device where I did this. And then I was like, probably I'm already in there. Still,
[19:34.950 --> 19:40.770]  to confirm it, I instead write writing to it. And when I write to this, what happens
[19:40.770 --> 19:46.030]  is that quite often the Wi-Fi crashes. So within Bluetooth, I write into those registers
[19:46.030 --> 19:51.230]  and suddenly Wi-Fi crashes. And the nice part about a Wi-Fi crash is that on a couple of
[19:51.230 --> 19:58.190]  devices, this is causing a crash dump. And this crash dump actually contains parts of
[19:58.190 --> 20:02.790]  the RAM image. So I could write data that I know and try to find the same data again
[20:02.790 --> 20:07.530]  to make the mapping and find like how Wi-Fi and Bluetooth are wrapped into each other.
[20:07.820 --> 20:13.550]  And also it revealed a couple of pointers, function pointers. So within the function
[20:13.550 --> 20:18.550]  pointer table, I was just overwriting a couple of pointers. And it turned out that if in
[20:18.550 --> 20:22.190]  this position, there is a pointer table. And when I write to this, I can get the program
[20:22.190 --> 20:27.030]  counter under control. So I can write to RAM, I can set the program counter. So I can have
[20:27.030 --> 20:33.490]  code execution. And that was really amazing. I have a demo video for this on a MacBook.
[20:33.550 --> 20:37.710]  The mapping is slightly different. So on the left hand side, I use internal glue to write
[20:38.410 --> 20:42.570]  assembly instructions, because I'm just writing within a function and not within a function
[20:43.150 --> 20:48.190]  pointer. And then on the right hand side, you see the Wi-Fi crash logs on macOS. And
[20:48.190 --> 20:52.770]  you can see that I can get a program counter under control. And this is how fast this attack
[20:52.770 --> 20:57.130]  works. So just within Bluetooth, I can get code execution in Wi-Fi.
[20:59.550 --> 21:05.090]  The interesting part here is that I couldn't find this area on the Nexus 5. So either it's
[21:05.090 --> 21:09.710]  not mapped at all, or it's mapped to a different region. Even though this was the one that
[21:09.710 --> 21:15.590]  I initially had as the idea, like from this data sheet, there must be this Wi-Fi RAM sharing.
[21:15.590 --> 21:21.770]  So this one, I didn't find it. Then there are a couple of devices where within the ROM dump,
[21:21.770 --> 21:28.750]  you can even find the 680000 and so on. So you know that within the firmware, this is used.
[21:28.750 --> 21:34.190]  And on those, also the attack works. The fun part here is that the MacBook, I don't have it with me.
[21:34.190 --> 21:40.310]  I just have this dump. So I couldn't try it on my own on this MacBook. But at least I know it
[21:40.310 --> 21:47.430]  should work because the symbol is there. And in the newest devices, this register is never ever
[21:47.430 --> 21:53.630]  mentioned in the firmware, but still the attack works. So it's probably a feature that has been
[21:53.630 --> 21:58.910]  abandoned, and it's no longer used. But still, we can use it for this type of attack on all those
[21:58.910 --> 22:09.220]  devices. The even more fun part is that sometimes I got again issues with PCI Express. So why is
[22:09.220 --> 22:16.440]  that? On all those chips, I had no idea what exactly I was doing. So I mean, yes, there is the
[22:16.440 --> 22:21.760]  mapping, but I first of all need to get the chip to crash to get this ROM image. And then I need to
[22:21.760 --> 22:27.920]  load it into IDA and analyze it and somehow find a place to get code execution for each chip.
[22:28.240 --> 22:32.520]  And so I was just writing certain things. And then again, like sometimes finding a pattern again. And
[22:32.520 --> 22:37.340]  when I find the pattern like in the program counter, then I probably have code execution.
[22:37.340 --> 22:44.200]  So this was roughly my approach. And then on a couple of devices, this turned out to be a very
[22:44.200 --> 22:50.220]  efficient puzzle. So just flipping a couple of bytes somewhere in the shared memory between Wi-Fi
[22:50.220 --> 22:57.200]  and Bluetooth was sufficient to get kernel panics on a couple of devices. So sometimes just Wi-Fi
[22:57.200 --> 23:02.860]  crashes, but sometimes even kernel panics. And this is interesting because there are of course also
[23:02.860 --> 23:09.060]  some memory areas that are used for the PCI express queue between the Wi-Fi chip and the
[23:09.060 --> 23:13.920]  host and so on. Or it might just simply block something within the communication between the
[23:13.920 --> 23:19.680]  Wi-Fi chip and the host. And depending on this, it can already cause a reboot. So with the super
[23:19.680 --> 23:27.500]  simple fuzzer of just flipping some bytes or like exchanging some bytes, you can reboot devices.
[23:27.500 --> 23:33.540]  This is a capture of this. I just use an iPhone 6 because on this one it's very fast. It also
[23:33.540 --> 23:39.060]  works on a couple of other devices. And you can see first of all Wi-Fi is switched off. So that's
[23:39.060 --> 23:49.100]  on the left hand side and then the device is already rebooting. Now you might wonder what
[23:49.100 --> 23:54.700]  the patch looks like. And I mean a lot of this is in hardware, so you cannot really patch it.
[23:54.700 --> 24:00.900]  But what I have seen in a couple of devices is that they are now blocking the communication. So
[24:00.900 --> 24:06.860]  after the Bluetooth chip is initialized by the Bluetooth daemon, the Bluetooth chip is then
[24:06.860 --> 24:13.960]  blocking any write RAM, read RAM commands or at least writing. The reading is only blocked
[24:13.960 --> 24:20.400]  on a few devices, but writing is blocked on all newer chips as far as I've seen.
[24:20.400 --> 24:27.300]  And now the thing is that this prevents at least attacks where the Bluetooth daemon would try to
[24:27.300 --> 24:32.880]  get code execution within Wi-Fi. So that's like this path. But what is not prevented by this is
[24:32.880 --> 24:40.120]  if you have remote code execution over the air and then escalate into Wi-Fi. Or if you just know
[24:40.120 --> 24:46.280]  that the timing between Wi-Fi and Bluetooth is a fixed one by now and use the known timing, which
[24:46.280 --> 24:51.660]  is not random because of something sent over the air, but actually like predictable because of
[24:51.660 --> 24:57.800]  coexistence schemes, this might also be a thing that's exploitable here. But at least they added
[24:57.800 --> 25:03.340]  this to the attack model that suddenly Bluetooth might be able to attack Wi-Fi. And because of this,
[25:03.340 --> 25:16.260]  this part is now blocked because you can block this quite easily. And now I mentioned in the
[25:16.260 --> 25:23.900]  chips. If you look into the Bluetooth specification and read it backwards, because I mean I'm a reverse
[25:23.900 --> 25:29.120]  engineer, so I also read the specification backwards obviously, what you can see on the
[25:29.120 --> 25:33.560]  last page is the Bluetooth logo. And on the second last page, it already starts with the mobile
[25:33.560 --> 25:42.240]  wireless standards. And this is another serial protocol which is used between Wi-Fi and Bluetooth
[25:42.240 --> 25:49.820]  chips or Bluetooth chips and LTE. And they are also sending activity information and so on over
[25:49.820 --> 25:54.020]  UART. And then there is another thing that goes via the operating system to initially
[25:55.100 --> 26:01.320]  configure it. And this one is also used on iPhones. So I saw it on an iPhone, so it probably is also
[26:01.320 --> 26:08.520]  attackable on them. And because everyone has some proprietary coexistence features, we asked Broadcom
[26:08.520 --> 26:13.700]  if we can also include other manufacturers in the response disclosure process. And they said yes,
[26:13.700 --> 26:19.620]  we can. And so we informed a couple of those who at least mentioned that they have coexistence in
[26:19.620 --> 26:24.540]  their data sheets and so on. And some of their responses were like that this doesn't really
[26:24.540 --> 26:31.820]  apply to them because there are some chips that have just one core that handles multiple wireless
[26:31.820 --> 26:38.800]  protocols. So by definition, that wouldn't be attackable in the sense of you already have code
[26:38.800 --> 26:43.320]  execution either way. So Bluetooth remote code execution is automatically a Wi-Fi remote code
[26:43.320 --> 26:50.180]  execution. But of course, there might be other side channels like I can now from the timing of
[26:50.180 --> 26:58.900]  Wi-Fi frames that I sent on an upper layer, maybe predict how the typing on a keyboard or something
[26:58.900 --> 27:04.260]  was, for example, or how the activity was on the other wireless core. And this might be something
[27:04.260 --> 27:09.880]  that could still be possible even though the code execution is kind of by design and cannot be
[27:09.880 --> 27:17.560]  prevented, there might be further attacks. And as a summary, so what we reached is if you have a
[27:17.560 --> 27:22.580]  Bluetooth remote code execution on a Broadcom chip, you can now cause driver kernel panics,
[27:22.580 --> 27:27.580]  get information disclosure about Wi-Fi, and even code execution within Wi-Fi. And the other way
[27:27.580 --> 27:32.180]  around, if you have a Wi-Fi remote code execution, you can now do denial of service against Bluetooth
[27:32.180 --> 27:39.000]  and also get information disclosure within Bluetooth. If you have further questions, there
[27:39.000 --> 27:43.700]  will be a Q&A session. And you can, of course, also reach me on Twitter, or you can write an email
[27:43.700 --> 27:46.840]  to Francesco and me. Thanks for listening.