BLE Sniffing 101
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Cauquil, Damien (virtualabs )
Sniffing and attacking Bluetooth Low Energy devices has always been a real pain. Proprietary tools do the job but cannot be tuned to fit our offensive needs, while opensource tools work sometimes, but are not reliable and efficient. Even the recently released Man-in-the-Middle BLE attack tools have their limits, like their complexity and lack of features to analyze encrypted or short connections. Furthermore, as vendors do not seem inclined to improve the security of their devices by following the best practices, we decided to create a tool to lower the ticket: BtleJack. BtleJack not only provides an affordable and reliable way to sniff and analyze Bluetooth Low Energy devices and their protocol stacks, but also implements a brand new attack dubbed "BtleJacking" that provides a way to take control of any already connected BLE device. We will demonstrate how this attack works on various devices, how to protect them and avoid hijacking and of course release the source code of the tool. Vendors, be warned: BLE hijacking is real and should be considered in your threat model.
 So, please just give a warm welcome to Virtual Labs. Thank you very much. So, today I'm going to talk again about Bluetooth low energy protocol and about also new vulnerabilities I found in this protocol. So, who am I? I'm the head of research and development at Econocom Digital Security, not the Digital Security in Russia, obviously. I've been studying Bluetooth low energy about four years now, three years now, and I'm the developer and maintainer of BetaJuice. Maybe you have heard about it. This is one of the framework I worked on, and I'm having a lot of fun with Nordic semiconductor system on chips. So, let's start with the agenda. So, we are going to go through the BLE sniffing one-on-one for those of you who don't know how to perform BLE sniffing. Then, I'm going to present BetaJuice, which is my new tool for BLE sniffing and much more. We are going to see what is inside this tool, why this tool, and in the next last part of the talk, I'm going to disclose a new attack on BLE. All right, so, let's start with some BLE sniffing, just wait a minute. So, BLE sniffing one-on-one. So, basically, if you nowadays want to sniff BLE connections and BLE communications between two devices, you need some tools. And you're lucky there are a lot of chip tools out there. So, you may want to sniff with Ubatus one, BLE connections, or you may want to use the other Fruits BlueFoot Addy Sniffer, which is also a nifty tool, or you may want to do it the SDO way with the GNU Audio software suite. So, let's start with the first one, the Ubatus one. So, this is a tool that allows anyone to sniff existing and new BLE connections. I mean, if you use this tool, you can find existing connections between devices and also listen for new connections that happen on the target device. It did not support channel map updates. So, it did not, because obviously, the updated firmware yesterday through the DevCon release. And, yeah. So, it's updated the firmware and it's not supported by the Ubatus tool. So, this is cool. If you have one, just use this new firmware and try it by, you know, sniffing some BLE stuff. But the fact is that even with the new firmware, the Ubatus one has some issues sniffing on existing connections. And, last but not least, it costs 120 bucks. So, it's cheap, but not so cheap. The Blue Food Addy Sniffer made by Adafruit, so it's based on a specific software written by Nordic Semiconductor. So, it's a proprietary firmware that is used here. It was last, it was updated November last year, so it's quite maintained. But this sniffer only allows new connections sniffing. You cannot sniff an existing connection between two devices. I already established connection, I mean. So, this is very interesting for, you know, security analysis. But if you want to hack into existing devices or already connected devices, you cannot do this with the Blue Food Addy Sniffer. It costs around 30 or 14 bucks, so it's affordable. And if you want to do the SDR-Ware, you are going to have some issues because the SDR modules existing with GNU Audio are only able to get the BLE advertisements sent by the devices. So, you cannot follow any BLE connection with this approach. The reason is very simple because of the latency. There is some kind of latency between the GNU Audio software and the SDR device you are using. And it do not allow to jump very quickly over all the channels used in the BLE connection. And that's what Nordic is. It requires 2.4 GHz compatible SDR device that costs some hundred dollars. So, it's again affordable but it's more expensive than the two previous ones I talked about. So, just to summarize this BLE sniffing one-on-one part of my talk, BLE basically is designed to make sniffing difficult. And it's working. It's not so easy to sniff BLE connections. Simply because this protocol uses three separate advertising channels spread across the bandwidth. So, you cannot listen to these three channels at the same time. You got to be listening on each channel one after the other to get all the information or maybe to use three devices to listen to these three channels at the same time. This protocol also uses some kind of frequency-hopping mechanism. So, channel. But what you can also call channel-hopping. So, this channel-hopping mechanism makes also sniffing very difficult because once a connection is created between two devices, these two devices are going to jump from one channel to another. And then you need to get the pattern they are using to synchronize with this connection and get all the packets. So, this is not very easy when you are dealing with existing BLE connections. And both devices can also renegotiate some parameters at any time. So, when you are trying to figure out what these parameters are in order to sniff an existing connection, they might change between the, what you are measuring, what you are trying to recover these parameters. So, this will mess your sniffing. So, two cases here. You may have a lot of money and you can afford a lot of devices and make a sniffing on the all 40 channels, for instance. Or if you want to do it the cheaper way, you have to struggle with the BLE sniffing. You won't be able to sniff very easily a connection for the first time, for instance. You have to wait for multiple connections to get your data. So, two years ago, I took another approach for capturing BLE packets. I tried some kind of mandemidal approach. The idea of this mandemidal approach was to have some kind of device in between your phone, for instance, and a device it's connected to, and then capture the packets. It's basically the same approach that we all do when we are going to perform some TCP mandemidal, for instance. So, how it works. First, you have to discover the BLE packet. You get to find a target device. Obviously, this device is advertising itself. There is nothing connected to this device. So, it's advertising and it's present and so on. You can connect to it, get all the information, all the services, characteristics and so on, in a way that you can then impersonate this device. You connect to this device, it's not advertising anymore because of the specifications. For BLE version 4, once a device is connected to something, it only supports one connection at a time. Most of them do this. There are a few devices out there that only accepts multiple connections. But it's very difficult for the system on chips that under all the other radio parts to handle two or three connections at a time. Because it requires to jump on different channels and different set up, different parameters. So, this is not very easy. Well, you are connected to this device. It's not advertising anymore. So, you can create a clone device with the exact same parameters, exact same services, characteristics, even the exact same Bluetooth address. So, you can just spoof the device in order to say this. And you wait for connections. Once your phone is connected to your fake device, all you have to do is just to follow forward the data between your connection with the device and the connection with the phone. So, you are in between and you capture everything. So, this approach has been implemented in BitAdjust, one of the tools I was talking about in the introduction. And also in another tool called Gattaker, written by SlavoMir Jazeck. And these two tools implement the mandemodel approach. Well, so, it was working pretty well until the last few years. And it has a lot of advantages because you can get rid of the three advertising channel problem. I mean, if you are using this mandemodel approach, you are controlling the advertising of your device. So, you are quite sure to get the connection and not miss it. You can see every video person performed. If there is some kind of characteristic write or read or discovery, you can get all of this and you see everything. And also you can make, you can tamper the data on the file. Since we are in between the two devices, we can just change data on the file, making, changing some bytes and causing some troubles in the security point of view. But there are a lot of issues too. One year after having developed the BitAdjust software, I got a lot of issues on GitHub with people saying, I cannot use your tool. It's quite complex to install because it requires one virtual machine and what else computer and some kind of network setup to make these machines communicate with each other. So, it was a quite complex setup and a lot of people had a lot of issues putting all of this software on their computers and making it working. The other problem we have is that we only capture HCI events because we work at the adapter level where we don't get any link layer BLE packets. So, we cannot get all the information and especially all the pairing packets. So, this approach, the manual approach does not support all types of pairing and this causes a lot of trouble when you are trying to intercept encrypted connections. Obviously, it's also compatible only with 4.0 adapters. Maybe you have heard about the Cambridge Silicon radio USB adapters that allows some kind of Bluetooth device and with spoofing. Well, we got some troubles too with the latest version of the USB adapters or even the adapters provided within the motherboard of your computer. So, the stock adapter of your computer may cause trouble with these software. So, these are the counts of the manual approach. So, basically we are doing it wrong. Okay, it works but there are still some limitations even with the firmware update released yesterday. Notix microducter is closed source and maybe discontinued. So, we don't know if this software is going to be maintained and we don't know if what will happen if Nordic microducter decides to not to continue the development of this software. So, maybe a problem. And the manual approach is great but it's too much difficult to use and causes a lot of trouble for users. And also, it cannot get all these link layer packets because we are limited by the solution we opted for. So, it's time to improve the BAD arsenal. So, basically what would be the ideal tool to sniff BAD connections? Well, we need a tool able to sniff both existing and new connections. We also need a tool that uses cheap hardware in order to make it affordable, you know, to lower the ticket for BLE sniffing. And of course, we need open source software to be able to maintain it, to contribute for allowing other researchers to push new features for instance. So, this is something very important here. This tool needs to sniff new connections. I'm going to go deeper at the protocol just to show you how it works in the internals very quickly. For new connections, the goal is very easy. We need to get the connection request PDU which is in fact a dedicated packet sent by your phone for instance when you're trying to connect to a BLE enabled device. And in this packet, there is everything we need to monitor or to follow the BLE connection. We got the CRT need value, we got also the channel map and so on. So, if we capture this packet, we are able to follow the connection and then to sniff the packets. But for sniffing this packet, we have to be at a very specific moment listening on the specific channel when this packet is sent. And as we saw this previously, there are three advertising channels. So, you must just listen on one channel to another hoping that this packet will arrive at a specific moment. Or you may want to sniff on these three advertising channels at the same time in order to get this packet. So, in order for this to work, we need this situation. We need to listen at the same time to these three advertising channels. So, this one is quite easy to sniff new connections. The trickiest part is the active connection sniffing process. So, in order to see active connections, you don't have all of these parameters. You don't know the connection parameters. So, you have to get them. And in order to get these parameters, we are going to make some measures. Magrayan, the author of the book, I cited just before, created his own technique to recover these parameters. And his technique is the following. First, he tries to identify what the protocol calls an access address. An access address is a thought-ative-bit value used to identify a link between two devices. So, this access address is used to identify a specific connection. Once the access address is known, we can recover the CRC in-eat value that is used to compute CRC. This is some kind of seed used to compute the CRC value for every packet. And this can be done very easily. Then we need to get the hop interval. The hop interval is basically the time the device we spent on each channel. So, how do we do that? Very easily. We just sit on a specific channel. We are measuring the time between two consecutive packets on this channel. And we divide it by 37, since there are 37 data channels used for the channel-hopping pattern. And of course, we can also recover the hop increment, which is a number of channels added to the channel index each time the connection jumps from one channel to another, by using some kind of lookup table. So, Mike Ryan designed a pre-computed lookup table. And the Uber 2 BTD, for instance, measured the time between two consecutive packets on channels of zero and one. By using this technique and the lookup table, we are able to recover the hop increment value. So, this is Mag Ryan's technique, as it was implemented in the Uber 2 BTD software. And it's still the case, even with the update made yesterday. And of course, Mike made some assumptions back in 2013. He made the assumption that all the 37 data channels are used. But it's not the case. Now in 2018, most of the BLE devices don't use all of these 37 data channels. And the change that determines this data channel by using some kind of channel map. This is a parameter sent in the connection request PDU that specifies which channel is going to be used and which will not. So, if not all the data channels are used, you have to keep a 37 channel sequence. And to do that, some of these channels will be remapped, will be reused if you prefer. So, if you have a look at the hopping sequence in this specific case, you will see for instance that the channel four is used twice in the sequence. But normally, you would, you will find only, it will be fine only once in the normal sequence if it's not reused. So, by modifying the sequence order and making these channels appear twice, if you just measure the time between two consecutive packets on the channel four, we will get two values, two different values. And this makes MaxTechnique useless. This does not work anymore. So, how to deduce all of this based on this new behavior? Well, first thing to do is to deduce the channel map. So, it's very easy to deduce. We just iterate over all the channels. We are looking for packets. And if we see some packets sent by the device, okay, the channel is used. If we don't see any packet, it's not used. So, there will be some kind of time that you have to implement to get these values. And context, sometimes, for instance, four times 37 seconds to complete. Well, this is a, this is a limitation of this approach. Once you get the channel map, you can deduce the hop interval by finding a unique channel that is not repeated in the hopping sequence. And then you measure the time between two packets and you divide it by 37. And you divide the time spent on each channel. And then deduce the hop increment based on this. But we don't use a pre-computed lookup table. We are going to generate it based on the channel map. And then we are going to measure and deduce the hop increment. So, this is basically the more generic version of Mike's technique. But it works pretty well. There are a lot more details in the proof of concept or get the fuck out number 17. We are writing a paper with all the algorithms and the, you know, the math between behind this technique. Well, and all of this is going to be implemented in the little jack. There is also another, another trick here for sniffing this connection. In the specification, there is a parameter called the instant. You know, when a device updates on the, some parameters, say the channel map for instance, it's in the packet, telling the device that the channel map will be updated at a specific moment in the connection. But not now, later on. But we don't know this value. We don't know this instant value when we are attacking existing connections. So this might be a problem since it's used for updating the channel map. And if the channel map is updated, we may lose our synchronization. We may lose the signal and lose packets. So the fact is that, really, we don't really care. We don't really care because once a channel map update packet is issued by a device, oops, sorry. So once a channel map packet is sent by the device, at a specific instant, we don't know the hoping sequence will change. And then we are going to sniff on channel 11 in this case, while the sequence will go to channel 1. So obviously, we won't get any packet on channel 11. So this may be an indicator that the channel map has been updated. And we can deduce the new open sequence and re-synchronize with the communication. So by using this little trick, we can just follow any connection and support the channel map update process, even if we don't know the instant value for this pre-sets connection. So all of this is implemented in BetaJAC. So I decided to create this new tool. And I'm very proud to present it at DEF CON this year. This is a brand new tool based on microbit. Again, this is a tiny device, some kind of Arduino sponsored by the British broadcasting company. The original goal of this device was to help UK students to learn how to code. But in fact, we can turn it into some kind of factor tool. And it's pretty cool. It costs only 15 bucks, so it's quite affordable. And you can buy more of them, three of them, four of them for the exact same price for like the other fruit, blue-front, Sniper for instance. You can also stack them and create some sniffing rig. She wanted to do this. So basically, I modified the cluster art for Raspberry Pi. This is just a USB to USB hub. But it's quite useful. I had to find a name obviously, so since I'm not a very creative person, you know, you see, it's a bit of a jag, because of the new availability I'm going to present in the next section. But anyway, this tool is quite useful. But I won't do any live demo because I know you first. I know if I put some kind of Bilibili device, you are going to connect to it and I won't be able to do my demo. And of course, this is a very noisy environment at ER at DEF CON. I made some sniffing during some talks yesterday and it was very noisy. So I got videos. So the first video shows that the sniffing of a new connection. So I specify the Bluetooth device address in the parameter and as you can see, we are able to intercept this connection and get all the link layer packets. We also get the access address, the CRC need value and so on. So sniffing new connection, no problem. Sniffing an existing connection for a specific device, first you have to identify an existing valid access address. So there is an option in the tool to scan and identify this address. I pick a target here with the specific access address and then Beetlejack will recover all the required parameters to be able to follow the connection and then to sniff packets. So it recovers the CRC need value, the channel map obviously, and then it deduces the hop interval and hop increment. And it's synchronized and if I do some read or write on various characteristics and get all the packets. So again, existing connection, not really a problem with Beetlejack. And to offer some other features, there is a pickup export possible. So if you're interested in packets with Beetlejack, you can export these files into a pickup file. Obviously it was expected for this kind of tool. But it also supports the specific format for the pickup file that makes it able to use with Quackity. Quackity is a tool designed by Mike Ryan to break the encryption keys when some kind of pairing is used between two BLE devices. So this may also be useful if you want to break encryption keys or pairing codes for BLE. So when I was developing this tool, this new sniffer, I read the specifications a lot. I went in all the details of the specifications and I stumbled upon a very specific, you know, not a weakness but something, you know, mainly feel bad. I don't know what it was but I found I was waiting the section about the supervision timeout in this specifications. And just to summarize it a bit, so the supervision timeout is provided by a device in the connection request PDU. So this is a parameter sent in the connection request PDU and basically it defines the time after which a connection should consider a connection lost. So basically if you try to connect your phone with a smartwatch, your phone is going to tell the smartwatch that if nobody is received or is received after 20 seconds, then your smartwatch and your phone should consider the connection lost. And so this supervision timeout is done for both devices. I had quite an idea about it. What if we jam some specific packets or specific times? Let's see. So there is three lines in my slides, the central, peripheral and attacker. Central is your phone, the central device, the initiator of the connection. The peripheral is obviously your smartwatch or your medical device anyway. So your phone sends regularly packets to the device and there are some kind of a keep-alive packets that are sent just to be sure that the connection is still alive. So many packets and we decide to jam the packet sent by the peripheral to the central device. And since then the central device considered the connection not lost but with no data. So it starts a timer and we do this sometimes until the supervision timer is reached. And then the central device considered the connection as lost. But the fun fact here is that the peripheral still gets packets from the master for the central device. So it's not disconnected and then we can have some fun. By impersonating the central device we can get the connection. So it's based on jamming. First of all I implemented the jamming feature in the beetle jack. So this is just a short video. I don't know how many times I'm doing this. So I'm connected to a specific device and I'm using beetle jack to jam the connection. I don't know if it's going to be all right. So in order to jam the connection you get to recover all the required parameters and all these CRC-N8 channel map, hop-interval, hop- increment and so on. And once the beetle jack is synchronized with the connection it starts jamming by sending bad packets. And this will cause some CRC errors on the phone side and the phone is disconnected. I don't know if it's really easy to see but here it's disconnected. So jamming works pretty well. So the idea of this attack which I call it beetle jacking because of the tool but anyway, this attack abuses BAD Supergent Timeout to take over a connection. So basically we get our hands on an ex- sorry. We get our hands on an existing connection. So without changing the internal state of the device itself there is no disconnection at all. So it avoids some troubles. It works on all versions of the Bluetooth low energy protocol. Versions 4.0, 1, 2 and 5. But it requires proximity because you need to be close to the target to jam it. If you are not close, about 5 meters from the final, 5 meters is good. You can jam the target. And I read the model of this attack with some example devices. We are going to start with something everybody loves, drones. So I found a drone on Amazon and this drone uses BAD for the communication between the small application you install on your phone and the drone. So I decided to test it in my test bed. It's too loud I guess. So as you can see it's difficult to keep it in the, you know, video. But anyway, I'll start with the jack. And I'm going to hijack the connection by using this tool. So we got to recover the CRC and map and so on. Then we are jamming the smartphone to disconnect the smartphone and it gets disconnected quite soon. So yeah, the smartphone is disconnected. The owner of the drone cannot pilot anymore the drone. But I have the control over the connection and I can make it land. Well, I know this is not impressive. So I made another video. So this, in this video I triggered the emergency mode. That is a cut off of the model. So, yeah. But basically the same attack with two payloads. And I also played with some other devices and especially sex toys. I'm not a very great fan of sex toys. But anyway, why sex toys? Because Pentas partners made some research last year. They called it unscrew driving. They were performing some kind of driving and found this, this, this, this, this, this, this, this, this, this, this, this, this, these kinds of things. So not a very acheive, but also with some peopleHow to earn money on this, using an e-mail and he wrote a著 secure and so on. Obviously the vendor of this sex toy saw this article, saw this post and unfurled back. They issued a statement saying that if your sex toy is on but if your smartphone is connected to your sex toy, you're okay. Since it's not advertising anymore, nobody can connect to this sex toy. I guess you know what will happen in the next slide. So the sex toy is connected to my smartphone. Just to make the video short, I had to cut it a bit. But in fact, I disconnected the smartphone by taking over the connection with Beta Jack. There is a little pop up on the smartphone. Yeah, this is disconnected. So the smartphone has no more control of the sex toy. And since it's UART over BLE, it's quite easy to make it vibrate. There is no sound here. But it's still visual. I found the characteristic and I wrote to this characteristic a special string vibrate semicolon two. There are ten levels. So I don't know if some of you wear this kind of stuff. Yeah, maybe, yeah, turn it off. So what are the impacts of this vulnerability? So you get unauthorized access to a device. So obviously this was the case for the sex toy. Even if it's already connected, of course, if there is some kind of authentication performed at the start of the connection, then you can bypass it. So this might be cool for some smart work and so on. And also since there is absolutely no modification of the internal state, since there is no disconnection of the device, this may leak valuable information. If some characteristics are available in, you know, in for read and write, you can may get back some data that are, that have been written to this, to this characteristics. So this may be interesting. How to avoid this? Well, the BLE specification provide, uh, provide some kind of secure connections by using pairing. So if you're using the pairing mechanism and the encryption mechanism provided by the Bluetooth, Bluetooth specifications should be okay. There is some kind of injection protection. There is a message integrated code added to the other packets that avoid this kind of manipulation of this kind of, you know, consequences. But the fact is that the keeper of packets don't have this message integrated code. So basically you can take over the connection even if you are using this, this, uh, this secure BLE connection. Well, can do some kind of dinner service or I don't know. Uh, or you can do it at the application level by using some kind of HMAC, uh, some kind of, uh, authentication, uh, for the data you're going to exchange. So there are some countermeasures but, uh, yeah, it's up to you to use them correctly. So the 2DV is available online. Uh, it's, uh, it has been, uh, released this morning on GitHub. Uh, can also install it with a pip if you want. It's also disponible, uh, disponible. Oh yeah, I'm French. Uh, it's also available on, uh, on pip. So this bit of Jack tool is able to sniff already established connection and new BLE connections. Uh, it's also able to jam connections to perform a takeover, hijacking, uh, like we saw. And, uh, it's able to export in pick up and there is also a multi sniff for support. I mean, if you connect two of them or three bit micro bits to your computer, it will use them to parallelize some tasks. Uh, the channel memory recovery, um, is, uh, sped up if you are using a lot of micro bits with your computer. You know, we got the 37 channels split in four, for instance, if you are using four of them and it, uh, speeds things a lot. So to conclude, bit of Jack, well, maybe a not in one solution for BLE sniffing. Uh, if you want to, to have a look at this tool or to try it, you're more than one come. Uh, also if you want to, to, to post some issues or show fine bugs and so on, uh, I read, uh, under the, under them. Uh, so it performs BLE sniffing jamming and hijacking. Hijacking works on all versions of BLE. Uh, insecure BLE connections as we may all know, uh, our printer sniffing and hijacking. So it might get worse with further version of BLE because the Bluetooth is trying to extend the range of the Bluetooth low energy protocol. So, um, the Bluetooth 5 version of the protocol is available. Yeah. Um, is capable of, uh, um, about 800 meters connections. Uh, you can, it's, it's, it's quite impressive and then they might, um, you know, extend this range in the future version of this protocol. So if you're some kind of BLE device vendor, you're more than welcome to secure your BLE connections. Yeah, do it. Thank you very much. Thank you.
 So, please just give a warm welcome to Virtual Labs.  Thank you very much.  So, today I'm going to talk again about Bluetooth low energy protocol and about also new  vulnerabilities I found in this protocol. So, who am I? I'm the head of research and development  at Econocom Digital Security, not the Digital Security in Russia, obviously.  I've been studying Bluetooth low energy about four years now, three years now, and I'm the  developer and maintainer of BetaJuice. Maybe you have heard about it. This is one of the  framework I worked on, and I'm having a lot of fun with Nordic semiconductor system on  chips. So, let's start with the agenda. So, we are going to go through the BLE sniffing  one-on-one for those of you who don't know how to perform BLE sniffing. Then, I'm going to  present BetaJuice, which is my new tool for BLE sniffing and much more. We are going to see  what is inside this tool, why this tool, and in the next last part of the talk, I'm going to  disclose a new attack on BLE. All right, so, let's start with some BLE sniffing, just  wait a minute. So, BLE sniffing one-on-one. So, basically, if you nowadays want to sniff BLE  connections and BLE communications between two devices, you need some tools. And you're  lucky there are a lot of chip tools out there. So, you may want to sniff with Ubatus one,  BLE connections, or you may want to use the other Fruits BlueFoot Addy Sniffer, which is also  a nifty tool, or you may want to do it the SDO way with the GNU Audio software suite. So, let's  start with the first one, the Ubatus one. So, this is a tool that allows anyone to sniff  existing and new BLE connections. I mean, if you use this tool, you can find existing  connections between devices and also listen for new connections that happen on the target  device. It did not support channel map updates. So, it did not, because obviously, the  updated firmware yesterday through the DevCon release. And, yeah. So, it's updated the  firmware and it's not supported by the Ubatus tool. So, this is cool. If you have one, just  use this new firmware and try it by, you know, sniffing some BLE stuff. But the fact is that  even with the new firmware, the Ubatus one has some issues sniffing on existing connections.  And, last but not least, it costs 120 bucks. So, it's cheap, but not so cheap. The Blue  Food Addy Sniffer made by Adafruit, so it's based on a specific software written by Nordic  Semiconductor. So, it's a proprietary firmware that is used here. It was last, it was updated  November last year, so it's quite maintained. But this sniffer only allows new connections  sniffing. You cannot sniff an existing connection between two devices. I already established  connection, I mean. So, this is very interesting for, you know, security analysis. But if you  want to hack into existing devices or already connected devices, you cannot do this with  the Blue Food Addy Sniffer. It costs around 30 or 14 bucks, so it's affordable. And if  you want to do the SDR-Ware, you are going to have some issues because the SDR modules  existing with GNU Audio are only able to get the BLE advertisements sent by the devices.  So, you cannot follow any BLE connection with this approach. The reason is very simple  because of the latency. There is some kind of latency between the GNU Audio software  and the SDR device you are using. And it do not allow to jump very quickly over all the  channels used in the BLE connection. And that's what Nordic is. It requires 2.4 GHz compatible  SDR device that costs some hundred dollars. So, it's again affordable but it's more  expensive than the two previous ones I talked about. So, just to summarize this BLE sniffing  one-on-one part of my talk, BLE basically is designed to make sniffing difficult. And  it's working. It's not so easy to sniff BLE connections. Simply because this protocol uses  three separate advertising channels spread across the bandwidth. So, you cannot listen to  these three channels at the same time. You got to be listening on each channel one after  the other to get all the information or maybe to use three devices to listen to these three  channels at the same time. This protocol also uses some kind of frequency-hopping mechanism.  So, channel. But what you can also call channel-hopping. So, this channel-hopping mechanism  makes also sniffing very difficult because once a connection is created between two devices,  these two devices are going to jump from one channel to another. And then you need to get  the pattern they are using to synchronize with this connection and get all the packets. So,  this is not very easy when you are dealing with existing BLE connections. And both devices can  also renegotiate some parameters at any time. So, when you are trying to figure out what these  parameters are in order to sniff an existing connection, they might change between the, what  you are measuring, what you are trying to recover these parameters. So, this will mess your  sniffing. So, two cases here. You may have a lot of money and you can afford a lot of devices  and make a sniffing on the all 40 channels, for instance. Or if you want to do it the cheaper  way, you have to struggle with the BLE sniffing. You won't be able to sniff very easily a connection  for the first time, for instance. You have to wait for multiple connections to get your data.  So, two years ago, I took another approach for capturing BLE packets. I tried some kind of  mandemidal approach. The idea of this mandemidal approach was to have some kind of device in  between your phone, for instance, and a device it's connected to, and then capture the packets.  It's basically the same approach that we all do when we are going to perform some TCP  mandemidal, for instance. So, how it works. First, you have to discover the BLE  packet. You get to find a target device. Obviously, this device is advertising itself.  There is nothing connected to this device. So, it's advertising and it's present and so on.  You can connect to it, get all the information, all the services, characteristics and so on,  in a way that you can then impersonate this device. You connect to this device, it's not  advertising anymore because of the specifications. For BLE version 4, once a device is connected to  something, it only supports one connection at a time. Most of them do this. There are a few devices  out there that only accepts multiple connections. But it's very difficult for the system on  chips that under all the other radio parts to handle two or three connections at a time.  Because it requires to jump on different channels and different set up, different parameters. So,  this is not very easy. Well, you are connected to this device. It's not advertising anymore. So,  you can create a clone device with the exact same parameters, exact same services,  characteristics, even the exact same Bluetooth address. So, you can just spoof the device in order  to say this. And you wait for connections. Once your phone is connected to your fake device,  all you have to do is just to follow forward the data between your connection with the device  and the connection with the phone. So, you are in between and you capture everything. So,  this approach has been implemented in BitAdjust, one of the tools I was talking about in the  introduction. And also in another tool called Gattaker, written by SlavoMir Jazeck. And these  two tools implement the mandemodel approach. Well, so, it was working pretty well until the  last few years. And it has a lot of advantages because you can get rid of the three advertising  channel problem. I mean, if you are using this mandemodel approach, you are controlling the  advertising of your device. So, you are quite sure to get the connection and not miss it. You  can see every video person performed. If there is some kind of characteristic write or read or  discovery, you can get all of this and you see everything. And also you can make, you can  tamper the data on the file. Since we are in between the two devices, we can just change data on  the file, making, changing some bytes and causing some troubles in the security point of  view. But there are a lot of issues too. One year after having developed the BitAdjust  software, I got a lot of issues on GitHub with people saying, I cannot use your tool. It's  quite complex to install because it requires one virtual machine and what else computer and  some kind of network setup to make these machines communicate with each other. So, it was a  quite complex setup and a lot of people had a lot of issues putting all of this software on  their computers and making it working. The other problem we have is that we only capture HCI  events because we work at the adapter level where we don't get any link layer BLE packets. So, we  cannot get all the information and especially all the pairing packets. So, this approach, the  manual approach does not support all types of pairing and this causes a lot of trouble when  you are trying to intercept encrypted connections. Obviously, it's also compatible only with  4.0 adapters. Maybe you have heard about the Cambridge Silicon radio USB adapters that  allows some kind of Bluetooth device and with spoofing. Well, we got some troubles too with  the latest version of the USB adapters or even the adapters provided within the motherboard  of your computer. So, the stock adapter of your computer may cause trouble with these  software. So, these are the counts of the manual approach. So, basically we are doing it  wrong. Okay, it works but there are still some limitations even with the firmware update  released yesterday. Notix microducter is closed source and maybe discontinued. So, we don't  know if this software is going to be maintained and we don't know if what will happen if  Nordic microducter decides to not to continue the development of this software. So, maybe  a problem. And the manual approach is great but it's too much difficult to use and causes  a lot of trouble for users. And also, it cannot get all these link layer packets because we  are limited by the solution we opted for. So, it's time to improve the BAD arsenal. So,  basically what would be the ideal tool to sniff BAD connections? Well, we need a tool able to  sniff both existing and new connections. We also need a tool that uses cheap hardware in  order to make it affordable, you know, to lower the ticket for BLE sniffing. And of course, we  need open source software to be able to maintain it, to contribute for allowing other researchers  to push new features for instance. So, this is something very important here. This tool needs to  sniff new connections. I'm going to go deeper at the protocol just to show you how it works in the  internals very quickly. For new connections, the goal is very easy. We need to get the  connection request PDU which is in fact a dedicated packet sent by your phone for instance when  you're trying to connect to a BLE enabled device. And in this packet, there is everything we need to  monitor or to follow the BLE connection. We got the CRT need value, we got also the channel map  and so on. So, if we capture this packet, we are able to follow the connection and then to sniff the  packets. But for sniffing this packet, we have to be at a very specific moment listening on the  specific channel when this packet is sent. And as we saw this previously, there are three  advertising channels. So, you must just listen on one channel to another hoping that this packet  will arrive at a specific moment. Or you may want to sniff on these three advertising channels at the  same time in order to get this packet. So, in order for this to work, we need this situation. We need  to listen at the same time to these three advertising channels. So, this one is quite easy to  sniff new connections. The trickiest part is the active connection sniffing process. So, in order to  see active connections, you don't have all of these parameters. You don't know the connection  parameters. So, you have to get them. And in order to get these parameters, we are going to make  some measures. Magrayan, the author of the book, I cited just before, created his own technique to  recover these parameters. And his technique is the following. First, he tries to identify what the  protocol calls an access address. An access address is a thought-ative-bit value used to identify a  link between two devices. So, this access address is used to identify a specific connection. Once the  access address is known, we can recover the CRC in-eat value that is used to compute CRC. This is  some kind of seed used to compute the CRC value for every packet. And this can be done very easily. Then  we need to get the hop interval. The hop interval is basically the time the device we spent on each  channel. So, how do we do that? Very easily. We just sit on a specific channel. We are measuring the time  between two consecutive packets on this channel. And we divide it by 37, since there are 37 data  channels used for the channel-hopping pattern. And of course, we can also recover the hop increment, which is a  number of channels added to the channel index each time the connection jumps from one channel to another, by using  some kind of lookup table. So, Mike Ryan designed a pre-computed lookup table. And the Uber 2 BTD, for  instance, measured the time between two consecutive packets on channels of zero and one. By using this  technique and the lookup table, we are able to recover the hop increment value. So, this is  Mag Ryan's technique, as it was implemented in the Uber 2 BTD software. And it's still the case, even with  the update made yesterday. And of course, Mike made some assumptions back in 2013. He made the  assumption that all the 37 data channels are used. But it's not the case. Now in 2018, most of the  BLE devices don't use all of these 37 data channels. And the change that determines this data  channel by using some kind of channel map. This is a parameter sent in the connection request  PDU that specifies which channel is going to be used and which will not. So, if not all the data channels are  used, you have to keep a 37 channel sequence. And to do that, some of these channels will be remapped, will be  reused if you prefer. So, if you have a look at the hopping sequence in this specific case, you will see  for instance that the channel four is used twice in the sequence. But normally, you would, you  will find only, it will be fine only once in the normal sequence if it's not reused. So, by modifying the  sequence order and making these channels appear twice, if you just measure the time between two  consecutive packets on the channel four, we will get two values, two different values. And this makes  MaxTechnique useless. This does not work anymore. So, how to deduce all of this based on this new  behavior? Well, first thing to do is to deduce the channel map. So, it's very easy to deduce. We just  iterate over all the channels. We are looking for packets. And if we see some packets sent by the  device, okay, the channel is used. If we don't see any packet, it's not used. So, there will be some kind  of time that you have to implement to get these values. And context, sometimes, for instance, four  times 37 seconds to complete. Well, this is a, this is a limitation of this approach. Once you get the  channel map, you can deduce the hop interval by finding a unique channel that is not repeated in the  hopping sequence. And then you measure the time between two packets and you divide it by 37. And you  divide the time spent on each channel. And then deduce the hop increment based on this. But we  don't use a pre-computed lookup table. We are going to generate it based on the channel map. And  then we are going to measure and deduce the hop increment. So, this is basically the more  generic version of Mike's technique. But it works pretty well. There are a lot more details in the  proof of concept or get the fuck out number 17. We are writing a paper with all the algorithms and  the, you know, the math between behind this technique. Well, and all of this is going to be  implemented in the little jack. There is also another, another trick here for sniffing this  connection. In the specification, there is a parameter called the instant. You know, when a device  updates on the, some parameters, say the channel map for instance, it's in the packet, telling the  device that the channel map will be updated at a specific moment in the connection. But not now,  later on. But we don't know this value. We don't know this instant value when we are attacking  existing connections. So this might be a problem since it's used for updating the channel map. And  if the channel map is updated, we may lose our synchronization. We may lose the signal and  lose packets. So the fact is that, really, we don't really care. We don't really care because  once a channel map update packet is issued by a device, oops, sorry. So once a channel map packet  is sent by the device, at a specific instant, we don't know the hoping sequence will change. And  then we are going to sniff on channel 11 in this case, while the sequence will go to channel 1. So  obviously, we won't get any packet on channel 11. So this may be an indicator that the channel  map has been updated. And we can deduce the new open sequence and re-synchronize with the  communication. So by using this little trick, we can just follow any connection and support the  channel map update process, even if we don't know the instant value for this  pre-sets connection. So all of this is implemented in BetaJAC. So I decided to create this new tool. And  I'm very proud to present it at DEF CON this year. This is a brand new tool based on microbit. Again,  this is a tiny device, some kind of Arduino sponsored by the British broadcasting company. The  original goal of this device was to help UK students to learn how to code. But in fact, we can  turn it into some kind of factor tool. And it's pretty cool. It costs only 15 bucks, so it's quite  affordable. And you can buy more of them, three of them, four of them for the exact same price for  like the other fruit, blue-front, Sniper for instance. You can also stack them and create some  sniffing rig. She wanted to do this. So basically, I modified the cluster art for Raspberry Pi. This  is just a USB to USB hub. But it's quite useful. I had to find a name obviously, so since I'm not a  very creative person, you know, you see, it's a bit of a jag, because of the new availability I'm going to  present in the next section. But anyway, this tool is quite useful. But I won't do any live demo  because I know you first. I know if I put some kind of Bilibili device, you are going to connect to it  and I won't be able to do my demo. And of course, this is a very noisy environment at ER at DEF CON. I  made some sniffing during some talks yesterday and it was very noisy. So I got videos. So the first  video shows that the sniffing of a new connection. So I specify the Bluetooth device address in the  parameter and as you can see, we are able to intercept this connection and get all the link layer  packets. We also get the access address, the CRC need value and so on. So sniffing new connection, no  problem. Sniffing an existing connection for a specific device, first you have to identify an  existing valid access address. So there is an option in the tool to scan and identify this address. I  pick a target here with the specific access address and then Beetlejack will recover all the required  parameters to be able to follow the connection and then to sniff packets. So it recovers the CRC need  value, the channel map obviously, and then it deduces the hop interval and hop increment. And it's  synchronized and if I do some read or write on various characteristics and get all the packets. So  again, existing connection, not really a problem with Beetlejack. And to offer some other features, there  is a pickup export possible. So if you're interested in packets with Beetlejack, you can export these  files into a pickup file. Obviously it was expected for this kind of tool. But it also supports the  specific format for the pickup file that makes it able to use with Quackity. Quackity is a tool  designed by Mike Ryan to break the encryption keys when some kind of pairing is used between two  BLE devices. So this may also be useful if you want to break encryption keys or pairing codes for  BLE. So when I was developing this tool, this new sniffer, I read the specifications a lot. I went  in all the details of the specifications and I stumbled upon a very specific, you know, not a  weakness but something, you know, mainly feel bad. I don't know what it was but I found I was waiting  the section about the supervision timeout in this specifications. And just to summarize it a bit, so  the supervision timeout is provided by a device in the connection request PDU. So this is a parameter  sent in the connection request PDU and basically it defines the time after which a connection should  consider a connection lost. So basically if you try to connect your phone with a smartwatch, your  phone is going to tell the smartwatch that if nobody is received or is received after 20 seconds,  then your smartwatch and your phone should consider the connection lost. And so this supervision  timeout is done for both devices. I had quite an idea about it. What if we jam some specific packets or  specific times? Let's see. So there is three lines in my slides, the central, peripheral and  attacker. Central is your phone, the central device, the initiator of the connection. The  peripheral is obviously your smartwatch or your medical device anyway. So your phone sends  regularly packets to the device and there are some kind of a keep-alive packets that are sent  just to be sure that the connection is still alive. So many packets and we decide to jam the packet  sent by the peripheral to the central device. And since then the central device considered the  connection not lost but with no data. So it starts a timer and we do this sometimes until the  supervision timer is reached. And then the central device considered the connection as lost. But  the fun fact here is that the peripheral still gets packets from the master for the central  device. So it's not disconnected and then we can have some fun. By impersonating the central  device we can get the connection. So it's based on jamming. First of all I implemented the jamming  feature in the beetle jack. So this is just a short video. I don't know how many times I'm  doing this. So I'm connected to a specific device and I'm using beetle jack to jam the  connection. I don't know if it's going to be all right. So in order to jam the connection you  get to recover all the required parameters and all these CRC-N8 channel map, hop-interval, hop-  increment and so on. And once the beetle jack is synchronized with the connection it starts jamming  by sending bad packets. And this will cause some CRC errors on the phone side and the phone is  disconnected. I don't know if it's really easy to see but here it's disconnected. So jamming works  pretty well. So the idea of this attack which I call it beetle jacking because of the tool but  anyway, this attack abuses BAD Supergent Timeout to take over a connection. So basically we get our  hands on an ex- sorry. We get our hands on an existing connection. So without changing the  internal state of the device itself there is no disconnection at all. So it avoids some  troubles. It works on all versions of the Bluetooth low energy protocol. Versions 4.0, 1, 2 and 5. But it  requires proximity because you need to be close to the target to jam it. If you are not close, about  5 meters from the final, 5 meters is good. You can jam the target. And I read the  model of this attack with some example devices. We are going to start with something everybody  loves, drones. So I found a drone on Amazon and this drone uses BAD for the communication  between the small application you install on your phone and the drone. So I decided to test it  in my test bed. It's too loud I guess. So as you can see it's difficult to keep it in the, you know,  video. But anyway, I'll start with the jack. And I'm going to hijack the connection by using  this tool. So we got to recover the CRC and map and so on. Then we are jamming the smartphone to  disconnect the smartphone and it gets disconnected quite soon. So yeah, the smartphone is  disconnected. The owner of the drone cannot pilot anymore the drone. But I have the control over the  connection and I can make it land. Well, I know this is not impressive. So I made another video. So  this, in this video I triggered the emergency mode. That is a cut off of the model. So, yeah. But  basically the same attack with two payloads. And I also played with some other devices and  especially sex toys. I'm not a very great fan of sex toys. But anyway, why sex toys? Because  Pentas partners made some research last year. They called it unscrew driving. They were performing  some kind of driving and found this, this, this, this, this, this, this, this, this, this,  this, this, this, these kinds of things. So not a very acheive, but also with some people How to earn money on this, using an e-mail and he wrote a著  secure and so on. Obviously the vendor of this sex toy saw this article, saw this post and  unfurled back. They issued a statement saying that if your sex toy is on but if your smartphone  is connected to your sex toy, you're okay. Since it's not advertising anymore, nobody can  connect to this sex toy.  I guess you know what will happen in the next slide. So the sex toy is connected to my  smartphone. Just to make the video short, I had to cut it a bit. But in fact, I disconnected  the smartphone by taking over the connection with Beta Jack. There is a little pop up on the  smartphone. Yeah, this is disconnected. So the smartphone has no more control of the sex  toy. And since it's UART over BLE, it's quite easy to make it vibrate. There is no sound  here. But it's still visual. I found the characteristic and I wrote to this characteristic  a special string vibrate semicolon two. There are ten levels. So I don't know if some of you  wear this kind of stuff. Yeah, maybe, yeah, turn it off. So what are the impacts of this  vulnerability? So you get unauthorized access to a device. So obviously this was the case  for the sex toy. Even if it's already connected, of course, if there is some kind of authentication  performed at the start of the connection, then you can bypass it. So this might be cool for  some smart work and so on. And also since there is absolutely no modification of the  internal state, since there is no disconnection of the device, this may leak valuable  information. If some characteristics are available in, you know, in for read and write, you  can may get back some data that are, that have been written to this, to this characteristics.  So this may be interesting. How to avoid this? Well, the BLE specification provide, uh,  provide some kind of secure connections by using pairing. So if you're using the pairing  mechanism and the encryption mechanism provided by the Bluetooth, Bluetooth specifications  should be okay. There is some kind of injection protection. There is a message integrated  code added to the other packets that avoid this kind of manipulation of this kind of, you  know, consequences. But the fact is that the keeper of packets don't have this message  integrated code. So basically you can take over the connection even if you are using this,  this, uh, this secure BLE connection. Well, can do some kind of dinner service or I don't  know. Uh, or you can do it at the application level by using some kind of HMAC, uh, some  kind of, uh, authentication, uh, for the data you're going to exchange. So there are some  countermeasures but, uh, yeah, it's up to you to use them correctly. So the 2DV is available  online. Uh, it's, uh, it has been, uh, released this morning on GitHub. Uh, can also install it  with a pip if you want. It's also disponible, uh, disponible. Oh yeah, I'm French. Uh, it's  also available on, uh, on pip. So this bit of Jack tool is able to sniff already established  connection and new BLE connections. Uh, it's also able to jam connections to perform a takeover,  hijacking, uh, like we saw. And, uh, it's able to export in pick up and there is also a multi  sniff for support. I mean, if you connect two of them or three bit micro bits to your computer,  it will use them to parallelize some tasks. Uh, the channel memory recovery, um, is, uh, sped up if you  are using a lot of micro bits with your computer. You know, we got the 37 channels split in four,  for instance, if you are using four of them and it, uh, speeds things a lot. So to conclude, bit of  Jack, well, maybe a not in one solution for BLE sniffing. Uh, if you want to, to have a look at  this tool or to try it, you're more than one come. Uh, also if you want to, to, to post some  issues or show fine bugs and so on, uh, I read, uh, under the, under them. Uh, so it  performs BLE sniffing jamming and hijacking. Hijacking works on all versions of BLE. Uh,  insecure BLE connections as we may all know, uh, our printer sniffing and hijacking. So it  might get worse with further version of BLE because the Bluetooth is trying to extend the  range of the Bluetooth low energy protocol. So, um, the Bluetooth 5 version of the protocol is  available. Yeah. Um, is capable of, uh, um, about 800 meters connections. Uh, you can, it's, it's,  it's quite impressive and then they might, um, you know, extend this range in the future  version of this protocol. So if you're some kind of BLE device vendor, you're more than  welcome to secure your BLE connections. Yeah, do it. Thank you very much.  Thank you.
DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_0_2027.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_2028_2291.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_2292_7523.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_7524_10967.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_10968_11303.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_11304_14315.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_14316_14387.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_14388_14687.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_14688_14735.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_14736_18863.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_18864_20195.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_20196_21527.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_21528_23219.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_23220_24059.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_24060_27431.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_27432_27743.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_27744_29879.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_29880_33707.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_33708_33971.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_33972_34031.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_34032_35303.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_35304_35411.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_35412_35471.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_35472_35639.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_35640_37571.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_37572_38315.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_38316_38375.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_38376_38447.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_38448_38507.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_38508_38567.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_38568_38819.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_38820_39983.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_39984_40115.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_40116_41195.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_41196_43571.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_43572_46139.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_46140_47471.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_47472_47543.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_47544_50711.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_50712_50819.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_50820_51323.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_51324_51935.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_51936_52247.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_52248_53651.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_53652_53723.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_53724_54695.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_54696_54743.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_54744_55067.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_55068_55115.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_55116_55187.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_55188_55655.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_55656_55703.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_55704_58787.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_58788_62171.png DEF_CON_26_-_Damien_virtualabs_Cauquil_-_You_had_better_secure_your_BLE_devices_VHJfd9h6G2s_62172_62476.png