Wireless Village - The Basics Of Breaking BLE v3
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.
FreqyXin
Evolving over the past twenty-two years, Bluetooth, especially Bluetooth Low Energy (BLE), has become the ubiquitous backbone modern devices use to perform low energy communications. From mobile, to IoT, to Auto, most smart devices now support Bluetooth connections, meaning that the attack vector is becoming an increasingly important aspect of security testing. This talk will breakdown the various phases of testing Bluetooth devices with an emphasis on sniffing BLE connections, spoofing devices, and exploiting GATT services. We will cover key components of the Bluetooth protocol stack, and the tools required to start testing BLE in your home, or as part of a Bluetooth pentest. This talk will also demonstrate that all you need to start testing BLE is an Android or iOS device, and a bit of curiosity.
 Hey everyone, welcome to the basics of breaking BLE. I'm Freaky Sun. I want to thank you for joining me and I want to thank the wireless village for featuring me today. Also I want to thank Defcon for going into safe mode and allowing us the space to interact and learn with each other. I've got a few things planned for us today. We've got some just going over the basics of what BLE is as far as the technology, just how expansive it is. Some kind of tools and techniques that you can use for pen testing or just exploring Bluetooth low energy devices around you. So as you can see here on the desk I have a few devices. We have the bomb badge from DC 27 Team Einds. We have HACNAR's BLE CTF. If any of you have seen any of my in-person talks, I usually try to feature this piece a lot. I feel like it's a very easy entry point for people to learn how to interact with GAT services on Bluetooth devices. So going on we also have a Thingy 52. This is a development tool and learning tool from Nordic. This has its own application that you can interact with sound and different gyroscopes and LEDs and all sorts of fun things. And then of course we have NODXOR's DC 27 badge that has a Bluetooth mesh network on it. We'll look at some of this and some interesting things that I found on the badge poking around looking for demonstration items for today. We actually also have the LG Phoenix LG 150. This phone is important because it's the only one that I have found so far that allows for live capture of the BT Snoop file from an Android device into Wireshark. I feel that the live capture is important when you're auditing devices because you can actually see the command interactions between devices and the changes in real time. If I hit this button and this command comes across the wire then it's probably pretty obvious but that is the command that's controlling that. And if you can see a difference in the variables then you have an easier time in reversing the commands and actually being able to find meaningful exploits or meaningful ways of interacting with devices. So going on the last item that we have is the Adafruit Bluefruit LE. This has some services that I built on it for DC 27 actually. So we will look at actually cloning this device and spoofing it against a target. So just a short introduction to who I am. My name is Maxine Filtcher. I also go by Freaky Zinn online. Security consultant with IOActive, Sarmie Veteran, graduated class 2020 with the BS in Info Assurance and Cyber Security. I also have a minor in Law and Policy. I'm also a member of the Sands Women's Academy 2018 cohort where I earned the GSEC, the GCIH, and the G-PEN. I am also in the process of studying for the GAWN. So just a small disclaimer, I'm not a Bluetooth developer by any means. But I have been teaching about Bluetooth hacking and just general Bluetooth concepts for a couple of years now. So I feel like I am fairly well-versed in this topic. So in any of my demonstrations, I always like to frame wireless security as greater than just Wi-Fi or just Bluetooth. In PIN testing, when we see companies talk about wireless PIN tests, generally they are talking about their Wi-Fi. And they are completely ignoring a lot of other vectors that could occur with wireless. So I always like to bring up this definition, I guess this contrast in definition. This weak definition from Wikipedia where it's wireless networks, which I mean I guess could be broadly interpreted. But I much prefer the NIST, which I believe is still current, it may have been updated. But the NIST definition of wireless enabled technologies, I feel it's more encompassing of everything that you could encounter. So we talk about wireless, just kind of continuing that discussion. And many different technologies, we have Bluetooth, Wi-Fi, ZigBee, RFID, NFC, Cell, SAT. And these come into a number of different industries. So medical is one that is growing pretty rapidly as far as Bluetooth low energy. And then of course IoT, the things around us, all these smart devices that really rely heavily on Bluetooth low energy to communicate. Then Industry 4.0, Bluetooth is starting to get more into automated systems within factories and smart buildings. And also smart automated HVAC systems or just building control systems. So Bluetooth is really starting to make its way into these important and sometimes high risk systems. So Bluetooth is becoming more of an important research topic and target for actually pen testing as we go and as the technology develops. So just a few basics about Bluetooth. You'll find it within the ISN band. So 2.4 to 2.485 gigahertz in this case for Bluetooth low energy. It comes in a few different flavors, you could kind of call them. Although the protocol stacks are different in some ways and similar in some ways. The original Bluetooth that came out, we refer to as Bluetooth classic or enhanced data rate. Any more you will find that in things like wireless headsets. So your Bluetooth headsets, anything where you're streaming data that needs larger packets and maybe higher throughput. That will generally go through on Bluetooth classic or BREDR is what it's known as now. Bluetooth low energy is what it is described as, it's a low energy protocol. It's intended to be used in devices that could run on a coin cell battery for up to a year. So that's a pretty heavy design specification for something that is low touch. You can put it somewhere and it's supposed to be able to work and you're not supposed to worry about the power and you can interact with it all day long. Something new that's emerging and I mentioned it with the Nodexor badge is Bluetooth mesh. Bluetooth mesh is actually, you can kind of think of it as a hat that goes on top of Bluetooth low energy. It uses some of the underlying components but it adds things like provisional keys and application keys. It's a mini to mini connection and it's very interesting. It can use pathways across other devices instead of nodes. It's a very interesting portion of the protocol but we aren't really going to get into Bluetooth mesh too much. So just some other numbers of course, you know, Bluetooth low energy is blowing up still all across the world. All these different technologies, I'm sure you have more than a few Bluetooth low energy devices around you right now. I also love to throw in little tidbits of history about Bluetooth. I think it's got kind of a fun origin with the name and kind of the intentions behind it. So you can see that if you've ever wondered where the Bluetooth symbol comes from, it's actually a mixture of two runic symbols, one for H and one for B. And this is actually for Harold Bluetooth who was the king of Norway and Denmark. He was seen as a great unifier of these countries and brought together these nations. If you've watched Vikings, the History Channel series, you might recognize the guy whose picture I've pasted up there but yes, it's loosely based on the same person, on the same historical character or figure. Another person that I really love that is integral to the development in Bluetooth but not really in sort of a direct creating of the protocol or anything like that. But Hedy Lamar, I love the story of Hedy Lamar. I love the story of her totally being just underestimated but being so brilliant. And for those who aren't familiar, she was an actress in the early part of the 20th century. And she came from Austria, fairly scandalous kind of background, had left her husband who had decided to supply arms to the Nazi party. She came to the United States and she befriended a man named George Anthle. And together they worked on a concept for creating a torpedo that was basically protected against jamming or the interruption of the signal, whether that was intentional or unintentional for torpedoes that were fired from either submarines or allied ships. A lot of times these torpedoes, when they were fired, they would either get jammed or they would lose connection and sometimes they could actually backtrack around and hit the ship that fired the torpedo originally. So this at the time was actually a fairly large concern and it was something that was kind of an operational hazard that you had to put up with. And together they came up with this concept of frequency hopping spread spectrum. And this is where two devices, two transceivers would have the set channel hopping or would have channel set within them that they would hop across at a set interval and at a set rate. So once these were loaded in, they would hop across the frequency spectrum in a way that would skip just pinpoint jamming or just any kind of natural interference since it was skipping across frequencies. So this was actually a fairly unique idea at the time. It was based on player pianos, as seen to player pianos, which is kind of cool. If you have more interest about the story, there is an amazing documentary on Netflix called the Hedy Lamar, or Bombshell the Hedy Lamar story. Highly recommend that you check it out. It's a little bit sad, but if you're curious about the background, it's a really amazing story. So let's get into a little bit of terminology. So as far as devices within Bluetooth connections, we can think about devices in two ways, central and peripheral. So your central devices are generally going to be your phone or the device that the user is actually interacting with. So whether that's a tablet or a laptop or a TV or something like that, where it's actually initiating the connection to whatever peripheral device, any kind of device that you're going to connect to that's a peripheral device. It's not something that you are directly interacting with with an application on your phone. That's generally going to be a peripheral. So connections are also something that's important in Bluetooth, obviously. It's a wireless protocol, so there has to be some sort of way the connections are handled. Bluetooth Low Energy, just like Bluetooth, has set channels where it advertises itself on or to central devices that may be looking to connect to it. So it has three set channels. The Bluetooth Low Energy has three set channels that it will broadcast across 37, 38, and 39. And there are also four advertising PDU types. I won't go over those, you can look them up. They don't really have too much impact on what we're going to talk about today. So we also have 36 channels for Bluetooth Low Energy, separated by two megahertz across the spectrum. And when we're also speaking about connections, we think about them in two phases, sort of. Once you see the advertising of a device that you want to connect to, say, from your phone, you will initiate the pairing process. I'm fairly confident that most people are familiar with the pairing process. But it's where you initiate a wireless connection. And these come in kind of two phases. So you have your basic pairing session where you're unbonded or you've passed your short term keys between the devices. So they have established a connection, but it's not trusted on certain levels. And it's not been placed into the devices that have been placed into each other, sort of trusted devices list. So once you create a bonded connection, that will actually, those devices are actually transferring long term key information between each other. In most cases, they'll go into a trusted device list, so that either the short term key pairing process can be skipped, or there's no need to even initialize the pairing process again at all. You can just, you know, whenever you're in proximity of the device, it will just automatically connect to you. So that's one of the benefits of bonding. Another benefit of bonding is you will oftentimes have greater leeway in the amount of kind of tolerance for fuzzing on a device. So if you just have a short term key pair with a device, and you try to start fuzzing GAT services, there's a good likelihood that that device will end that pair. Once you've bonded with a device, there is a greater chance that that connection will survive any kind of fuzzing that you do onto the GAT services. So we can talk a little bit about sort of the evolution of the Bluetooth protocol stack. We talked about how it kind of comes in multiple flavors, and you can see that we have classic BREDR there. And then you can see the hybrid version of smart ready, and now Bluetooth smart, which most new Bluetooth low energy devices coming out should be Bluetooth smart. Although most phones will have the ability to use BREDR in the case of, say, Bluetooth headphones or that sort of thing. There is also a new audio protocol that is coming out, a new Bluetooth low energy audio protocol. It was announced earlier this year. I haven't personally seen a lot of specifications on it, but I'm sure that there are people that can answer lots of questions about it already. But it's interesting. I'm excited from a security researcher perspective to get my hands on some of the devices, just because it sounds like it might have some issues, but we'll have to see. So yeah, just some of the basic components of the protocol stack that we're going to really pay attention on today is GAT. I've already mentioned it a couple of times, but it's the generic attribute profile. These are where the profiles of the services that a device can offer are stored. So you can think about this as sort of a catalog of things that a device can do. Whether that's measuring heart rate or giving temperature or measuring humidity levels, there's a GAT service and there's a way for that information or that service to be interacted with. So there is a way to retrieve that temperature or that humidity measurement through the GAT services. Primarily, we're going to be interested in GAT services today. Okay, so we've already talked about that. So when I talk about GAT hacking, what I'm really talking about is the abuse of read or write privileges on a device over their GAT services. So in the case of iOS, read privileges can be abused fairly easily and you can do things like retrieve the cell phone username, the battery level, the OS version, which may not be such an issue on the surface, but once you start poking lower into the protocol or into this vulnerability, especially with the proof of concept called Apple BLEEE, you can see that there are some significant interactions that are available over GAT and there are some very significant information disclosures from iOS. So a few simple write privilege abuses that I have seen in devices that I've pen tested are just sending simple codes. So picking out of a GAT service and I just start fuzzing codes. In some of the real world cases that I've seen, writing the hex value 0x08, and that enables me to set up a new pin between the devices. So now I'm defeating one of the very few security measures that you have for controlling Bluetooth connections. Further still, I've been able to achieve over the firmware update mode. So writing 0x01 to a GAT service will actually allow you to push firmware to a device. I mean, you obviously could get lower interactions than potentially placement malicious firmware onto a device and then who knows, you'd own that device then. Other devices I've seen like write 0x02 to a GAT service, a specific GAT service, and it would start a heating cycle on a device. So potentially there is danger there. So Bluetooth low energy does have security. It's developed through the years, mainly in response to security research that's been done, where a big set of vulnerabilities comes out and the technology has to respond to that in kind of a dynamic way or they risk really losing their customer base. So Bluetooth SIG has done a fairly decent job of responding to security researchers and trying to get chip manufacturers and developers on board with everything. But yeah, so there's a lot of space for growing and there's also a lot of space for research. So Bluetooth low energy has currently, I would say the standard would be 4.2, although BLE 5.0, the new standard that came out has some pieces that strengthen the just works pairing by introducing some nonce values. The more entropy, the better. We have protections against man in the middle. We have protections against eavesdropping and theoretically there's authentication via pairing and bonding, but we can see that oftentimes it's not the case and that can be abused pretty easily. So some of the Bluetooth vulnerabilities that have come out in the past, once I started getting into Bluetooth pretty heavily, BlueBorne was pretty fresh. It was fairly new and it seemed to scare a lot of people. That's when I noticed Bluetooth security research really kind of starting to kick up again. It seemed like it had died off before that. And since then there have been major vulnerabilities that's released every year. I think there were two, well SvinTooth was released earlier this year and then there was a new set that they released, a new vulnerability set that they released just a couple of weeks ago for SvinTooth. So interesting piece about or interesting trivia piece about SvinTooth. It's actually named after the son of Harold Bluetooth. So kind of cool marketing piece that they did in there. So SvinTooth, since it's brand new we'll talk about that, really starts to attack the protocol in ways that I personally haven't been testing it and just fuzzing the header values and fuzzing the protocol in a way that just makes things stop working. There are a lot of denial of service vulnerabilities within this, a lot of deadlock security bypasses that are included within this. And it's fairly expansive. There are a lot of vendors that are impacted by SvinTooth. So a pretty cool piece of research. I personally haven't had a lot of time to jump into it but I have read through it quite a bit and it's pretty interesting. These are just a few of the Bluetooth tools out there that you can use. Some of these are proof of concepts but they have neat scripts that you could either alter or actually just use as they are. So the first tool that we're going to look at is the UberTooth 1. Let me switch over here and so I have one right here. So older device, it's a few years old, but it's still probably the best way to ingest externally viewed Bluetooth packets into Wireshark. And I say externally because this is what I consider to be looking from the outside in to a Bluetooth connection between devices. So generally you won't see a lot because things should be encrypted. Although I have seen some devices that say they are doing things but they aren't actually encrypting things so you're able to pull commands out of the air. But this is still probably the best tool that you can use for that use case for trying to check encryption or trying to check a device connection for its strength against eavesdropping and passive sniffing. So the GreatFet 1 is a tool that's still currently in development I would consider. The Quincy was announced as the first sort of hat that was going to be added to this add-on hat and it would allow for full spectrum sniffing of Bluetooth low energy. So instead of having to use an Ubertooth which is locked into one advertisement channel at a time you would be able to sniff all 36 channels at a time and be able to see basically all the Bluetooth information that's going on. So much easier to kind of manage as far as mass sniffing operations. But as of yet today there's still no release date and I haven't heard anything about a price. Maybe that'll change with DEF CON coming up so this is being recorded beforehand so maybe there's already been an announcement and if that's the case then disregard this portion. So another tool that you probably won't get to use or probably won't see unless you have a lot of money or you work for a bigger employer is the ELISIS system which relies on SDR and it's the same kind of concept as the Quincy in that it's looking to do a mass spectrum capture. So it's trying to capture all of the Bluetooth packets that it possibly can and then you can go through there and sort it by connection and see everything. This system will go even further and in some cases will strip the encryption off of the packet so the software is actually pretty cool. I've had the chance to use one of these systems and yeah it's a very powerful tool that you can do a lot of really meaningful research with but there is a huge price tag associated with it. So that brings us to NRF Connect. NRF Connect is what I generally use on engagements first so I will exhaust every avenue possible with NRF Connect because it's free and it installs on any smart device so or well you know Android or iOS. So it's highly available it's extremely simple to use it allows for abuse of GAT services it also allows for cloning and spoofing so it's a fairly useful tool. So that's where I like to start all of my engagements with because if I can prove that there is impact from this free and highly available tool then the chances are then you probably have larger problems and someone with more technical ability or more powerful tools is likely going to be able to have even greater impact on your systems. So you know let's take a sort of low hanging fruit first approach. So I always start with NRF Connect you know it was intended for debugging but it works wonderful for the purposes that I need. One of the great things that you can do with this is record macros so sometimes devices will only allow for momentary connections just long enough for two devices to basically pass short-term keys and decide that one device say that I don't want to talk to you because I don't know who you are. Well it's still in that period of time there may be two seconds three seconds where you have the window to actually send GAT commands in and if you can capture that and potentially send a command to a device you may actually get interaction with it even though you're not establishing a long-term paired session bonded session you're just that momentary connection so I really enjoy the macro feature and of course you can also export the logs which you know help for reporting. NRF stiffer we won't actually talk about so BetterCat is a tool capable of interacting or allowing you to interact with GAT services of a device but from a Linux machine using a BLE dongle. So Kismet has the ability to do this too but I feel like BetterCat has a slightly better UI for this but it can be a little bit difficult to install but yeah you have the ability to send requests and commands over GAT so it's still a very powerful tool if you're interested in in doing this from a laptop or you know a desktop rather than a mobile device. Another powerful tool from a desktop machine is Scapi. So Scapi actually will allow you the ability to script and this is very powerful once you start looking at these deeper interactions so if you wanted to follow along with the SvenTooth vulnerabilities you could actually craft packets using the Scapi library to attack those specific pieces of the protocol and you know push different kinds of data to them and potentially push them over so if you're looking to do that deeper kind of penetration testing or research on Bluetooth energy low energy Scapi the Scapi library is definitely something you'll want to check out. Another essential tool that I use on just about every one of my pentests for Bluetooth low energy devices is Android debug bridge. For those of you who might not be familiar with this this allows you to create a PC interface to your Android device over USB. Generally most phones won't allow you to do the live capture of BT snoop logs which is where Bluetooth low energy connections and data is logged to. So in the case of the LG phone that I have here the LG M150 that will allow for us to do a live capture into Wireshark and we'll actually look at this here shortly. So just some basic installation instructions if you're not familiar with ADB very simple to set up very easy to get going and use. So I mentioned Kismet earlier if you're not familiar with Kismet it also supports Bluetooth low energy but it has some limited functionality but they may be increasing that as we speak. So that that that tool is definitely growing in its functionality and its capabilities every day. And we've mentioned Apple BLEE a wonderful proof of concept for the security issues that are really inherent within iOS Bluetooth low energy stack. This is a lot of fun. I've done some private talks where I've actually attacked entire rooms full of people and AirPods are popping up on everyone's phone. So it's a lot of fun. But it can also be scary for Apple users to see that you can get that much interaction with their devices just through Bluetooth low energy. The Blueborn scanner it was deprecated but I've actually seen it back on the store or on the Play Store and I can still download it and still use it. But the likelihood that you're going to find a device that is actually still vulnerable or pops up as vulnerable is going to be highly unlikely at this point. Most manufacturers have patched or updated things against this. So it used to be a couple years ago you could walk into a Best Buy, run this Blueborn scanner and almost every TV, every display TV that they had on smart display TV would pop up on the on your Blueborn scanner and would give you all kinds of information. And then from there you could actually use proof of concept scripts to actually attack these TVs. But you know, that's those are different stories. But as far as I know, Blueborn is pretty much patched up and is no longer a risk. So a few challenges that we run into in Bluetooth low energy as far as you know, security researcher challenges. Most of the modern connections are encrypted. So they're hard to see from the outside. So unless there is a companion application on Android that I can use the Android debug bridge on, it's very hard to reverse commands. You know, the Uber truth can follow connections, but I can't see inside of those connections that are encrypted. Crackle is largely ineffective anymore for breaking pins. So, you know, good luck breaking pins. I know that there has been some research done in, in attacking the entropy levels of the pins that are generated. So that's kind of been a potential. But as far as I know, there isn't a reliable way of breaking pairing pins at this point. Commercial sniffers are also really expensive. And the cheaper cheaper alternatives really don't outperform the Uber tooth. So a few approaches to BLE. Sniff the broadcast traffic. So look from the outside in first. Is it encrypted? What can you see basically? What are they leaking? What could you potentially do without any kind of interaction with the device? Is there any kind of information leak? Are there any issues with configuration? Yeah, that sort of thing. The next step would be to look from the inside out using something like Android debug bridge and looking at the unencrypted packets that are coming in. So Android debug bridge allows you to look at the Bluetooth low energy packets once they've crossed over the HCI threshold. So they've been stripped of the, of the encryption layer and you can actually see the commands that are getting sent over the wire. Attempt out of app connection. So just try to, you know, use nrf connect, connect to a device, see if you can create a paired or a bonded session, and then just start buzzing values and see what interaction you get. Sometimes, you know, you'll get devices to lock out. Sometimes you'll get devices to actually do what they're supposed to. Sometimes you hit the trigger. And then the next thing is to spoof a device or check for cloning protections within the application itself. So these are kind of the four things that I really look for in a pen test. So hopefully that helps you kind of frame and contextualize what we're going to look at here in a second. So let's get into some hands-on stuff. So short list of equipment. The Nordic thingy 52, Bluefruit LE, the LG M150, the Samsung S20 I'll be using as the victim. But I will also be showing you the screens that the attacker would see on that phone. It's just kind of a technology and display matter at this point. So, and then we'll of course be using InterfConnect. We'll be using the thingy app, then the Bluefruit Connect application will also be using ADB and Wireshark. For an external scan, we're going to start with Uber tooth. And we're going to go through the basic setup. I just set this up on my computer. If you go to the the GitHub page and go to their wiki for the Uber tooth, there are really good setup instructions. You just go line by line. I didn't have any issues on the newest version of Cali, so hopefully you don't. But yeah, you never know. This is where we will be using ADB to do a live capture of the BT Snoop file on our LG M150. So, let me get the phone hooked up here. We are going to launch ADB. So, we would launch by using ADB start server. Mine's already started, but we'll just hit it again. And then we use ADB devices. And you can see our LG M150 is right there. So, I plugged a different phone in. And we can see the device that I'm using here to capture the BT Snoop file on. We go over to Wireshark, which I already have started. And we can see that we have this BT Snoop interface that's opened up here. Now, it's important to note that the LG M150 has to be running Android version 7. So, I just tried this a second ago with a different LG that I have, and it's running version 6. And it does not open up the BT Snoop. So, you'll have to actually update the version of Android. Luckily, we have pre-recorded videos this time, so I can go in and actually edit out some of that stuff. So, we have our BT Snoop file here. Let's go ahead and start the sniffer. So, our sniffer is now running from our phone. So, I have the phone connected here. And what we can do is start trying to connect to devices. So, for instance, I have this thingy52 on the desk here. I can turn this on, and I can open up Interf Connect. And you'll see the packets are starting to come in here. So, we can see I'm going to connect to the thingy device here, and you'll see the packets start to change. We can create a connection to our thingy52 using the thingy connect app. And now that I'm connected, I'm actually reading data from this device, from the thingy52 onto my phone. So, I can do things like play sounds. Now, that's as I'm pressing here. You hear the sound on the thingy52? So, those commands are coming through the GAT services. Commands are being written from our phone to the GAT services that are being offered on the thingy52. So, since we have this hooked up in an internal fashion, and we can see these packets, we can actually see what commands are controlling what. So, if I hit this tone, we can see that there are packets coming across. Send right here. And this is the value that's being written to that GAT service. So, let's try a different key. Okay. Let's see if that value has changed. You can see it's changed to an 8, from a 5 to an 8. I would also suspect that 1 is the on and off, right? So, the first right is the on, the second right is the off. You can see all f's in the middle there, and then we see all 0's in the middle. All f's, all 0's. Okay. So, that's a pretty basic look at how we see commands, and we're able to reverse command values that come across the wire internally. So, how do we actually then interact with or take this information and use it to then test if there is any unauthorized access to the GAT services, or if we can get any interaction to the device from an unauthenticated source? So, let me bring up the screen here, and I'm going to use my victim device here, or in this case, my attacking device, to actually seek out the thingy52 here over nrf connect. So, this would constitute an out of application connection. Since the thingy52 has an application that controls all of the interactions, using an application like nrf connect to directly interact with the GAT services would be considered an out of app interaction. So, let me scan. So, we have this thing here, that's my thingy52. We'll go ahead and connect to that. So, you can see right off the bat, we have a connection, but it's not bonded. You'll also notice up here in the right hand corner is the DFU button. That will actually allow us to push firmware updates over the air. So, not all devices, and most consumer devices will be locked down from this, but not all devices will have this. But if you do see this, this would constitute a fairly major vulnerability in this device, especially since we have a short-term connection, since there hasn't been long-term key information passed. Let's go ahead and open up our sound services. So, when we were looking at the other screen here, let me go to Kelly and phone. So, when we were looking at the other commands that we captured from the internal, from the ADB capture, we saw our read and write commands. So, those were being written to the handle 005B, and that was in the sound service. So, let's look in the sound here. So, if we open up the handle, we can see the full UUID there. Okay, so the thingy speaker data characteristic is what we saw being written to. So, we can actually use this upload command. So, we have write permissions to it, and we can use this value that we have here. So, we have 8701FFF5A. So, let's try and push this. This was a write command. So, let's make sure that it's placed in command. You have the option between request or command, and this was sent as command X52. So, we'll send it as a command, and we'll see if we can get any interaction here between our device and our attacking device. There it is. There it is. So, we're now attacking from there, and just like I thought, so the all F command is the on command. So, when we saw the write, that was the F. So, we've sent it the option to be on. So, it's on right now, and you can hear it in that tone. So, now let's write the off command. So, that was 8701 0005A, and we send that as a command, and now it's off. So, that is a very robust look at your basic GAT hacking. We abused an unauthenticated out-of-application connection to a device, our thingy52 in this case, and we used a command that we reversed from other information into getting this interaction from an attacking device. So, say this was something else. Say this was, I don't know, I don't know what kind of user device you would have, but say it had some purpose, and you had this in your pocket, but it also made noise like that. And say somebody had reversed these commands and knew that these devices were vulnerable, or that you could just arbitrarily write these commands to GAT services. So, if you could walk around, identify that these devices were, or when they were in proximity, you could automatically attack these devices so that everybody was walking around that had one of these in their pockets, they would automatically get this tone just going off in their pocket, and they would have to shut the device off. So, you can see where there is user impact, and there's also a circumventing of protections that are in place for Bluetooth low energy. So, successful GAT hacking there. Let's switch over to some more slides here. But we used the internal scan to reverse the Bluetooth commands that we saw coming across the wire, and then we used that in an out-of-application attack. So, let's move into cloning some services. So, this will enable us to really attack the application. Generally, there isn't a lot of value in spoofing against a peripheral, say like spoofing a user device. Although, I have seen that be, you know, a valid find where you can impersonate a legitimate user's phone, and then there is some interaction with the device. But without the long-term keys that have been passed, there's a really, you have an uphill battle basically in trying to spoof a user device against a peripheral. So, what we are going to do is spoof a peripheral device, and we are going to watch the victim attach to it from their application, and basically see all of the interactions that you normally would, and you don't even know that you haven't connected to your device. Meanwhile, if we were to push this further, what that would enable me to do is get a bonded session with my target. So, I would have those long-term keys exchanged with my target and be able to then exploit that further. So, I could either use some sort of proof of concept or, you know, have that deeper interaction with that user's device. So, what we're going to do is we are going to be spoofing the the blue fruit LE. I'm going to push some of this other stuff out of the way here for a second. I'm going to be spoofing the blue fruit LE. It's a real simple development tool. Adafruit has all these kinds of kits that you can use. This is intended for development. It's intended to learn with and to explore how Bluetooth development works. But why we're using it is because it has its own application and one that does not have spoofing protections in it. So, it's easy to basically prove this cloning concept. So, let me plug things in. You can see we've got power now there. Okay, so you can see that we have power there. The blue fruit module is on. So, what I'll be doing on my device is leveraging the scanner. So, I'm going to scan for devices right now. Hopefully we see this blue fruit pop up somewhere. Oh, there we go. Freaky Zen Sinister Sun Hat was a project that I had for Defconn last year, but it didn't quite make it all the way. What we're going to do is we're going to clone here this clone button. So, what I'm doing is I'm cloning the advertisement data now. So, basically, I'll be able to impersonate the adafruit unit on the advertisement channels. So, now that we've cloned it, what we can do is we can actually connect to the device. And we connect to it to get a return on the GAT services that are available. So, now that we've connected to, we can go here up into the upper right hand corner and we can go to clone device services. And you can see the little box popped up there and we've cloned the GAT services now. So, we've cloned the advertisement profiles and we've cloned the GAT profiles. So, now if we're able to turn these on, we're basically impersonating that device. So, what we have to do is then go to the GAT server and we have to turn on the GAT server to mimic the sun hat. So, there we have the GAT services turned on. And what we also have to do is go to go to our advertiser and we turn on the advertisement for the Freaky Zinn Sinister Sun Hat. So, now we are impersonating this device and hopefully we will get a connection to our target device. So, now that we've cloned all of the GAT services, what we have to do is go into the advertiser, turn on the advertiser for the Sinister Sun Hat, and then we also have to go in and change the name of the device. We're now advertising as a spoofed sun hat. So, we will update our scan here on the Adafruit LE app. And we can see the Phoenix 3. This is actually the name of the phone. So, the name didn't update on the phone. So, let's try and connect to it. And it allows us to connect to it as if it were the sun hat. So, the Phoenix 3 is this phone. This is my attacker phone. So, I've created a spoof from this phone and I've now got a connection in the application, in the Blue Fruit Low Energy application. And from there, it's not giving us the right information because we're not getting returns on that. However, if I go to the server information here on my attacker, I can change things like my manufacturer string. This is an attacker. We can set that. Now, we should be able to see that pop up there. You see it. Now, we've provided information on our attacker on the GAT service for the manufacturer name. So, now the end user is seeing that if we had a device that had more functionality, we could potentially send information from this device. Say we spoofed a thingy 52 and we spoofed or we sent temperature data out from there and this red temperature data. So, think about that in a real world example where say a building is relying on BlueTooth Low Energy sensors to control HVAC. Say we are able to impersonate one of those sensors and then provide fake information to whatever is reading that temperature and then making the judgments on what should be done about that temperature. If we can then create a scenario where it thinks maybe the temperature is rising uncontrollably, maybe there's cooling systems or maybe it kicks on the fire suppression systems or something. So, there is the risk of spoofing something and then providing information from that spoof. But I also have a connection now, a bonded connection to my target device that I could potentially exploit even further. So, we just went through the basic pieces. We cloned the advertisement data. We changed our device name. We cloned the device services. We went through and turned on the advertiser and then we actually connected through and provided a spoof that our victim connected to. So, I do want to introduce HackNAR's BLE CTF that it runs on ESP32. Like I said, if you've ever been to any of my in-person training sessions, I generally give these out to as many people as I can. So, I have maybe 10 or 20 of these that I give out. But obviously, since we are all safe mode and social distancing, then I can't really give a bunch of these out. But they're like $10 and you can upload all the information yourself. And you can actually go through a BLE CTF and it's more of just interacting on GAT services. So, what we went through earlier where we were doing the abusing of right privileges. So, there are a bunch of challenges on there. Some of them are decoding MD5 or following certain instructions that you get back from the services. So, if you have interest in exploring more on the GAT side, then I would definitely recommend checking out HackNAR's BLE CTF. And of course, if you need help, feel free to reach out to me on Twitter or wherever. So, a few recommendations for just kind of the individual BLE CTF user or your consumer. Keep your BLE CTF turned off unless you really need it. I know with the prevalence of BLE low energy devices, I find my BLE is being turned on more and more and kept on for longer and longer. So, this might not be valid information in a few years. We may just always have to just deal with BLE being on. Choose low traffic areas to do pin pairing sessions with. While it is fairly unlikely that there will be significant kind of leakage of keys or pins, there is the chance that that could happen. So, you're better off to choose sort of a controlled RF space where you know there aren't going to be a lot of people eavesdropping. Generally, your home is a good option or you know, an uninhabited part of your office maybe. Also, be aware that like we saw with the Blue Fruit LE app, a lot of apps don't have spoofing protection. So, you could very well be connecting to something that is not what you thought it was. And you've allowed an attacker to either provide you with false information or gain a bond of connection to your phone that they could then further abuse. And then I would also say that you know there are enough free tools out there that you could actually just start auditing all the Bluetooth devices around you and see can I abuse GAT services? Can I create a spoof of this device? How does the application handle that? You might need two phones for that but yeah. And then of course if you want to get deeper into that, you know, maybe pick up a dedicated testing phone like an LG M150, make sure it's running Android 7. So, yeah, those are a few of my recommendations for consumers. As far as developers, I'd like to push out of band pairing options just because it pushes some of that very privileged and important information away from the channel that is being used for data. So, using something like NFC to actually pass long-term keys will increase the security of the Bluetooth data because or the integrity of it because you don't have the risk of using basically an unprotected channel to pass keys to them protect it. So, you're using out of band practices. Don't focus solely on device security. You know, does your application have good spoofing protections? Is your app just basically looking for devices on name alone or is it looking, you know, for something deeper? What I like to, you know, dream and recommend is that, you know, that there be a remote server where you can actually validate the keys of a device before you ever connect to it through the cloud. So, say your cloud application would actually or your application on your phone would have a connection to a cloud server somewhere. So, before you actually even start a connection with a device, that advertising data and that key or short-term key would be passed to your cloud and then validated and if it's not valid then obviously you wouldn't connect or you could blacklisted or something like that. So, that's what I tend to recommend. As far as further study, there are a number of blue-teeth researchers but probably the one that I follow the most and the most enthusiastic is Jiska. I think I'm saying that right but she is a security researcher and yeah, RF kind of wizard out of Europe. So, yeah, follow her on Twitter. She does a lot of talks all over the place. So, if you're looking for books, Hacking Exposed Wireless is amazing. I just went through the coursework for the GAWN and it's very, very similar. Obviously, written by the same people so of course there's going to be knowledge kind of overlap there. And if you're looking to get more on the hands-on side then the Adafruit Bluefruit LE, the Thingy 52 ESP32s and the UD100 Bluetooth USB Adapter which we didn't cover in this talk but is capable of doing more long-range stuff. So, that's definitely something you'll want to pick up if you have an interest in taking this further. Okay, so with the badge just on, if you just turn it on, you can see the Bluetooth Mesh pop up in an NF Connect. But I'm not able to connect to it. So, I'm able to see the Anodexor badge within NF Connect. The Bluetooth Mesh you see there is listed as such. And I can try to connect to it. And I have a connection to it and it's giving me certain options. I've done some poking around on this side but I haven't found a lot. This SMP characteristic might be fun to poke around with. But what I have seen is within the SMP characteristic you can actually do some interesting commands that have these bright values here. But OS Echo commands, so you can echo commands through Bluetooth into the operating system. I haven't got much interaction from that. I've tried the Bender commands but it hasn't really worked. But the one that I have seen that works very well is the Reset command. So, I will switch over here. So, as soon as I hit the Reset command, you'll see the badge turns off. And then the badge turns off. Last year, if you were at Def Con and they were talking about the Bluetooth Mesh where you could attack other people's devices, you could connect to the badges and then you could send these commands. Turn people's badges off or make it do different things and different commands. So, very cool puzzle and interaction and tool for learning. So, if you have one of these badges, one of these Anonix or DC27 badges, or I believe the one before that also had a Bluetooth Mesh on it. But if you have one of these badges, they would be awesome to hack on. Yeah, so they have that Bluetooth component. That's going to wrap up my presentation. And I just want to thank you for spending the time with me today and learning about Bluetooth Low Energy Hacking. Hopefully you learned something. Hopefully you found something that maybe caught your interest and you're ready to explore the Bluetooth Low Energy devices around you. Don't forget the further study that I pushed out in one of the last slides. And if you have any questions, feel free to reach out on me on Twitter or LinkedIn or anywhere really. And I will try my best to get in touch with you. I know sometimes I don't do a great job, but yeah, so thank you so much for joining me. And I hope you have a wonderful, wonderful DEF CON safe mode.
 Hey everyone, welcome to the basics of breaking BLE.  I'm Freaky Sun.  I want to thank you for joining me and I want to thank the wireless village for featuring me today.  Also I want to thank Defcon for going into safe mode and allowing us the space to interact and learn with each other.  I've got a few things planned for us today. We've got some just going over the basics of what BLE is as far as the technology, just how expansive it is.  Some kind of tools and techniques that you can use for pen testing or just exploring Bluetooth low energy devices around you.  So as you can see here on the desk I have a few devices. We have the bomb badge from DC 27 Team Einds.  We have HACNAR's BLE CTF. If any of you have seen any of my in-person talks, I usually try to feature this piece a lot.  I feel like it's a very easy entry point for people to learn how to interact with GAT services on Bluetooth devices.  So going on we also have a Thingy 52. This is a development tool and learning tool from Nordic.  This has its own application that you can interact with sound and different gyroscopes and LEDs and all sorts of fun things.  And then of course we have NODXOR's DC 27 badge that has a Bluetooth mesh network on it.  We'll look at some of this and some interesting things that I found on the badge poking around looking for demonstration items for today.  We actually also have the LG Phoenix LG 150. This phone is important because it's the only one that I have found so far that allows for live capture of the BT Snoop file from an Android device  into Wireshark. I feel that the live capture is important when you're auditing devices because you can actually see the command interactions between devices  and the changes in real time. If I hit this button and this command comes across the wire then it's probably pretty obvious but that is the command that's controlling that.  And if you can see a difference in the variables then you have an easier time in reversing the commands and actually being able to find meaningful exploits or meaningful ways of interacting with devices.  So going on the last item that we have is the Adafruit Bluefruit LE. This has some services that I built on it for DC 27 actually.  So we will look at actually cloning this device and spoofing it against a target.  So just a short introduction to who I am. My name is Maxine Filtcher. I also go by Freaky Zinn online.  Security consultant with IOActive, Sarmie Veteran, graduated class 2020 with the BS in Info Assurance and Cyber Security.  I also have a minor in Law and Policy. I'm also a member of the Sands Women's Academy 2018 cohort where I earned the GSEC, the GCIH, and the G-PEN.  I am also in the process of studying for the GAWN. So just a small disclaimer, I'm not a Bluetooth developer by any means.  But I have been teaching about Bluetooth hacking and just general Bluetooth concepts for a couple of years now.  So I feel like I am fairly well-versed in this topic.  So in any of my demonstrations, I always like to frame wireless security as greater than just Wi-Fi or just Bluetooth.  In PIN testing, when we see companies talk about wireless PIN tests, generally they are talking about their Wi-Fi.  And they are completely ignoring a lot of other vectors that could occur with wireless.  So I always like to bring up this definition, I guess this contrast in definition.  This weak definition from Wikipedia where it's wireless networks, which I mean I guess could be broadly interpreted.  But I much prefer the NIST, which I believe is still current, it may have been updated.  But the NIST definition of wireless enabled technologies, I feel it's more encompassing of everything that you could encounter.  So we talk about wireless, just kind of continuing that discussion.  And many different technologies, we have Bluetooth, Wi-Fi, ZigBee, RFID, NFC, Cell, SAT.  And these come into a number of different industries.  So medical is one that is growing pretty rapidly as far as Bluetooth low energy.  And then of course IoT, the things around us, all these smart devices that really rely heavily on Bluetooth low energy to communicate.  Then Industry 4.0, Bluetooth is starting to get more into automated systems within factories and smart buildings.  And also smart automated HVAC systems or just building control systems.  So Bluetooth is really starting to make its way into these important and sometimes high risk systems.  So Bluetooth is becoming more of an important research topic and target for actually pen testing as we go and as the technology develops.  So just a few basics about Bluetooth.  You'll find it within the ISN band.  So 2.4 to 2.485 gigahertz in this case for Bluetooth low energy.  It comes in a few different flavors, you could kind of call them.  Although the protocol stacks are different in some ways and similar in some ways.  The original Bluetooth that came out, we refer to as Bluetooth classic or enhanced data rate.  Any more you will find that in things like wireless headsets.  So your Bluetooth headsets, anything where you're streaming data that needs larger packets and maybe higher throughput.  That will generally go through on Bluetooth classic or BREDR is what it's known as now.  Bluetooth low energy is what it is described as, it's a low energy protocol.  It's intended to be used in devices that could run on a coin cell battery for up to a year.  So that's a pretty heavy design specification for something that is low touch.  You can put it somewhere and it's supposed to be able to work and you're not supposed to worry about the power and you can interact with it all day long.  Something new that's emerging and I mentioned it with the Nodexor badge is Bluetooth mesh.  Bluetooth mesh is actually, you can kind of think of it as a hat that goes on top of Bluetooth low energy.  It uses some of the underlying components but it adds things like provisional keys and application keys.  It's a mini to mini connection and it's very interesting.  It can use pathways across other devices instead of nodes.  It's a very interesting portion of the protocol but we aren't really going to get into Bluetooth mesh too much.  So just some other numbers of course, you know, Bluetooth low energy is blowing up still all across the world.  All these different technologies, I'm sure you have more than a few Bluetooth low energy devices around you right now.  I also love to throw in little tidbits of history about Bluetooth.  I think it's got kind of a fun origin with the name and kind of the intentions behind it.  So you can see that if you've ever wondered where the Bluetooth symbol comes from,  it's actually a mixture of two runic symbols, one for H and one for B.  And this is actually for Harold Bluetooth who was the king of Norway and Denmark.  He was seen as a great unifier of these countries and brought together these nations.  If you've watched Vikings, the History Channel series, you might recognize  the guy whose picture I've pasted up there but yes, it's loosely based on the same person,  on the same historical character or figure.  Another person that I really love that is integral to the development in Bluetooth  but not really in sort of a direct creating of the protocol or anything like that.  But Hedy Lamar, I love the story of Hedy Lamar.  I love the story of her totally being just underestimated but being so brilliant.  And for those who aren't familiar, she was an actress in the early part of the 20th century.  And she came from Austria, fairly scandalous kind of background, had left her husband  who had decided to supply arms to the Nazi party.  She came to the United States and she befriended a man named George Anthle.  And together they worked on a concept for creating a torpedo that was basically protected against jamming  or the interruption of the signal, whether that was intentional or unintentional for torpedoes  that were fired from either submarines or allied ships.  A lot of times these torpedoes, when they were fired, they would either get jammed  or they would lose connection and sometimes they could actually backtrack around  and hit the ship that fired the torpedo originally.  So this at the time was actually a fairly large concern and it was something that was  kind of an operational hazard that you had to put up with.  And together they came up with this concept of frequency hopping spread spectrum.  And this is where two devices, two transceivers would have the set channel hopping  or would have channel set within them that they would hop across at a set interval and at a set rate.  So once these were loaded in, they would hop across the frequency spectrum in a way that would skip  just pinpoint jamming or just any kind of natural interference since it was skipping across frequencies.  So this was actually a fairly unique idea at the time.  It was based on player pianos, as seen to player pianos, which is kind of cool.  If you have more interest about the story, there is an amazing documentary on Netflix called  the Hedy Lamar, or Bombshell the Hedy Lamar story.  Highly recommend that you check it out.  It's a little bit sad, but if you're curious about the background, it's a really amazing story.  So let's get into a little bit of terminology.  So as far as devices within Bluetooth connections, we can think about devices in two ways,  central and peripheral. So your central devices are generally going to be your phone or the device  that the user is actually interacting with. So whether that's a tablet or a laptop or a TV  or something like that, where it's actually initiating the connection to whatever peripheral  device, any kind of device that you're going to connect to that's a peripheral device.  It's not something that you are directly interacting with with an application on your  phone. That's generally going to be a peripheral. So connections are also something that's important  in Bluetooth, obviously. It's a wireless protocol, so there has to be some sort of  way the connections are handled. Bluetooth Low Energy, just like Bluetooth, has set channels where  it advertises itself on or to central devices that may be looking to connect to it. So it has  three set channels. The Bluetooth Low Energy has three set channels that it will broadcast across  37, 38, and 39. And there are also four advertising PDU types. I won't go over those,  you can look them up. They don't really have too much impact on what we're going to talk about today.  So we also have 36 channels for Bluetooth Low Energy, separated by two megahertz across the  spectrum. And when we're also speaking about connections, we think about them in two phases,  sort of. Once you see the advertising of a device that you want to connect to, say, from your phone,  you will initiate the pairing process. I'm fairly confident that most people are familiar with the  pairing process. But it's where you initiate a wireless connection. And these come in kind of  two phases. So you have your basic pairing session where you're unbonded or you've passed your short  term keys between the devices. So they have established a connection, but it's not trusted on  certain levels. And it's not been placed into the devices that have been placed into each other,  sort of trusted devices list. So once you create a bonded connection, that will actually, those  devices are actually transferring long term key information between each other. In most cases,  they'll go into a trusted device list, so that either the short term key pairing process can be  skipped, or there's no need to even initialize the pairing process again at all. You can just,  you know, whenever you're in proximity of the device, it will just automatically connect to you.  So that's one of the benefits of bonding. Another benefit of bonding is you will oftentimes have  greater leeway in the amount of kind of tolerance for fuzzing on a device. So if you just have a  short term key pair with a device, and you try to start fuzzing GAT services, there's a good  likelihood that that device will end that pair. Once you've bonded with a device, there is a  greater chance that that connection will survive any kind of fuzzing that you do onto the GAT services.  So we can talk a little bit about sort of the evolution of the Bluetooth protocol stack.  We talked about how it kind of comes in multiple flavors, and you can see that we have classic  BREDR there. And then you can see the hybrid version of smart ready, and now Bluetooth smart,  which most new Bluetooth low energy devices coming out should be Bluetooth smart. Although  most phones will have the ability to use BREDR in the case of, say, Bluetooth headphones or  that sort of thing. There is also a new audio protocol that is coming out, a new Bluetooth  low energy audio protocol. It was announced earlier this year. I haven't personally seen a lot of  specifications on it, but I'm sure that there are people that can answer lots of questions about it  already. But it's interesting. I'm excited from a security researcher perspective to get my hands  on some of the devices, just because it sounds like it might have some issues, but we'll have to see.  So yeah, just some of the basic components of the protocol stack that we're going to really pay  attention on today is GAT. I've already mentioned it a couple of times, but it's the generic attribute  profile. These are where the profiles of the services that a device can offer are stored. So  you can think about this as sort of a catalog of things that a device can do. Whether that's  measuring heart rate or giving temperature or measuring humidity levels, there's a GAT service  and there's a way for that information or that service to be interacted with. So there is a way  to retrieve that temperature or that humidity measurement through the GAT services. Primarily,  we're going to be interested in GAT services today. Okay, so we've already talked about that.  So when I talk about GAT hacking, what I'm really talking about is the abuse of read or write privileges  on a device over their GAT services. So in the case of iOS, read privileges can be abused  fairly easily and you can do things like retrieve the cell phone username, the battery level, the  OS version, which may not be such an issue on the surface, but once you start poking lower into  the protocol or into this vulnerability, especially with the proof of concept called Apple BLEEE,  you can see that there are some significant interactions that are available over GAT and  there are some very significant information disclosures from iOS. So a few simple write privilege  abuses that I have seen in devices that I've pen tested are just sending simple codes. So picking  out of a GAT service and I just start fuzzing codes. In some of the real world cases that I've  seen, writing the hex value 0x08, and that enables me to set up a new pin between the devices. So now  I'm defeating one of the very few security measures that you have for controlling Bluetooth  connections. Further still, I've been able to achieve over the firmware update mode. So writing  0x01 to a GAT service will actually allow you to push firmware to a device. I mean, you obviously  could get lower interactions than potentially placement malicious firmware onto a device and then  who knows, you'd own that device then. Other devices I've seen like write 0x02 to a GAT service,  a specific GAT service, and it would start a heating cycle on a device. So potentially there  is danger there. So Bluetooth low energy does have security. It's developed through the years,  mainly in response to security research that's been done, where a big set of vulnerabilities  comes out and the technology has to respond to that in kind of a dynamic way or they risk  really losing their customer base. So Bluetooth SIG has done a fairly decent job of responding to  security researchers and trying to get chip manufacturers and developers on board with  everything. But yeah, so there's a lot of space for growing and there's also a lot of space for  research. So Bluetooth low energy has currently, I would say the standard would be 4.2, although  BLE 5.0, the new standard that came out has some pieces that strengthen the just works pairing  by introducing some nonce values. The more entropy, the better. We have protections against man in  the middle. We have protections against eavesdropping and theoretically there's authentication  via pairing and bonding, but we can see that oftentimes it's not the case and that can be abused  pretty easily. So some of the Bluetooth vulnerabilities that have come out in the past,  once I started getting into Bluetooth pretty heavily, BlueBorne was pretty fresh. It was  fairly new and it seemed to scare a lot of people. That's when I noticed Bluetooth security  research really kind of starting to kick up again. It seemed like it had died off before that.  And since then there have been major vulnerabilities that's released every year. I think there were  two, well SvinTooth was released earlier this year and then there was a new set that they released,  a new vulnerability set that they released just a couple of weeks ago for SvinTooth.  So interesting piece about or interesting trivia piece about SvinTooth. It's actually  named after the son of Harold Bluetooth. So kind of cool marketing piece that they did in there.  So SvinTooth, since it's brand new we'll talk about that, really starts to attack the protocol  in ways that I personally haven't been testing it and just fuzzing the header values and fuzzing  the protocol in a way that just makes things stop working. There are a lot of denial of service  vulnerabilities within this, a lot of deadlock security bypasses that are included within this.  And it's fairly expansive. There are a lot of vendors that are impacted by SvinTooth. So a pretty  cool piece of research. I personally haven't had a lot of time to jump into it but I have read through  it quite a bit and it's pretty interesting. These are just a few of the Bluetooth tools out there  that you can use. Some of these are proof of concepts but they have neat scripts that you could  either alter or actually just use as they are. So the first tool that we're going to look at is  the UberTooth 1. Let me switch over here and so I have one right here. So older device, it's a few  years old, but it's still probably the best way to ingest externally viewed Bluetooth packets  into Wireshark. And I say externally because this is what I consider to be looking from the outside  in to a Bluetooth connection between devices. So generally you won't see a lot because things should  be encrypted. Although I have seen some devices that say they are doing things but they aren't  actually encrypting things so you're able to pull commands out of the air. But this is still  probably the best tool that you can use for that use case for trying to check encryption or trying  to check a device connection for its strength against eavesdropping and passive sniffing.  So the GreatFet 1 is a tool that's still currently in development I would consider.  The Quincy was announced as the first sort of hat that was going to be added to this add-on hat  and it would allow for full spectrum sniffing of Bluetooth low energy. So instead of having to use  an Ubertooth which is locked into one advertisement channel at a time you would be able to sniff  all 36 channels at a time and be able to see basically all the Bluetooth information that's  going on. So much easier to kind of manage as far as mass sniffing operations. But as of yet  today there's still no release date and I haven't heard anything about a price. Maybe that'll change  with DEF CON coming up so this is being recorded beforehand so maybe there's already been an  announcement and if that's the case then disregard this portion. So another tool that you probably  won't get to use or probably won't see unless you have a lot of money or you work for a bigger  employer is the ELISIS system which relies on SDR and it's the same kind of concept as the Quincy  in that it's looking to do a mass spectrum capture. So it's trying to capture all of the  Bluetooth packets that it possibly can and then you can go through there and sort it by  connection and see everything. This system will go even further and in some cases will strip  the encryption off of the packet so the software is actually pretty cool. I've had the chance to  use one of these systems and yeah it's a very powerful tool that you can do a lot of really  meaningful research with but there is a huge price tag associated with it. So that brings us to  NRF Connect. NRF Connect is what I generally use on engagements first so I will exhaust every avenue  possible with NRF Connect because it's free and it installs on any smart device so or well you know  Android or iOS. So it's highly available it's extremely simple to use it allows for abuse  of GAT services it also allows for cloning and spoofing so it's a fairly useful tool.  So that's where I like to start all of my engagements with because if I can prove that there  is impact from this free and highly available tool then the chances are then you probably have  larger problems and someone with more technical ability or more powerful tools is likely going  to be able to have even greater impact on your systems. So you know let's take a sort of low  hanging fruit first approach. So I always start with NRF Connect you know it was intended for  debugging but it works wonderful for the purposes that I need. One of the great things that you  can do with this is record macros so sometimes devices will only allow for momentary connections  just long enough for two devices to basically pass short-term keys and decide that one device  say that I don't want to talk to you because I don't know who you are. Well it's still in that  period of time there may be two seconds three seconds where you have the window to actually  send GAT commands in and if you can capture that and potentially send a command to a device you  may actually get interaction with it even though you're not establishing a long-term paired session  bonded session you're just that momentary connection so I really enjoy the macro feature  and of course you can also export the logs which you know help for reporting. NRF stiffer we won't  actually talk about so BetterCat is a tool capable of interacting or allowing you to interact with  GAT services of a device but from a Linux machine using a BLE dongle. So Kismet has the ability to  do this too but I feel like BetterCat has a slightly better UI for this but it can be a  little bit difficult to install but yeah you have the ability to send requests and commands over GAT  so it's still a very powerful tool if you're interested in in doing this from a laptop or you  know a desktop rather than a mobile device. Another powerful tool from a desktop machine  is Scapi. So Scapi actually will allow you the ability to script and this is very powerful once  you start looking at these deeper interactions so if you wanted to follow along with the SvenTooth  vulnerabilities you could actually craft packets using the Scapi library to attack those specific  pieces of the protocol and you know push different kinds of data to them and potentially push them  over so if you're looking to do that deeper kind of penetration testing or research on Bluetooth  energy low energy Scapi the Scapi library is definitely something you'll want to check out.  Another essential tool that I use on just about every one of my pentests for Bluetooth  low energy devices is Android debug bridge. For those of you who might not be familiar with this  this allows you to create a PC interface to your Android device over USB. Generally most phones  won't allow you to do the live capture of BT snoop logs which is where Bluetooth low energy  connections and data is logged to. So in the case of the LG phone that I have here the LG M150  that will allow for us to do a live capture into Wireshark and we'll actually look at this here  shortly. So just some basic installation instructions if you're not familiar with ADB  very simple to set up very easy to get going and use. So I mentioned Kismet earlier if you're not  familiar with Kismet it also supports Bluetooth low energy but it has some limited functionality  but they may be increasing that as we speak. So that that that tool is definitely growing in  its functionality and its capabilities every day. And we've mentioned Apple BLEE a wonderful proof  of concept for the security issues that are really inherent within iOS Bluetooth low energy stack.  This is a lot of fun. I've done some private talks where I've actually attacked entire rooms  full of people and AirPods are popping up on everyone's phone. So it's a lot of fun. But it  can also be scary for Apple users to see that you can get that much interaction with their devices  just through Bluetooth low energy. The Blueborn scanner it was deprecated but I've actually seen  it back on the store or on the Play Store and I can still download it and still use it. But the  likelihood that you're going to find a device that is actually still vulnerable or pops up as  vulnerable is going to be highly unlikely at this point. Most manufacturers have patched or  updated things against this. So it used to be a couple years ago you could walk into a Best Buy,  run this Blueborn scanner and almost every TV, every display TV that they had on smart display TV  would pop up on the on your Blueborn scanner and would give you all kinds of information. And then  from there you could actually use proof of concept scripts to actually attack these TVs. But you  know, that's those are different stories. But as far as I know, Blueborn is pretty much patched up  and is no longer a risk. So a few challenges that we run into in Bluetooth low energy as far as  you know, security researcher challenges. Most of the modern connections are encrypted. So they're  hard to see from the outside. So unless there is a companion application on Android that I can use  the Android debug bridge on, it's very hard to reverse commands. You know, the Uber truth can  follow connections, but I can't see inside of those connections that are encrypted. Crackle is  largely ineffective anymore for breaking pins. So, you know, good luck breaking pins. I know that  there has been some research done in, in attacking the entropy levels of the pins that are generated.  So that's kind of been a potential. But as far as I know, there isn't a reliable way of breaking  pairing pins at this point. Commercial sniffers are also really expensive. And the cheaper  cheaper alternatives really don't outperform the Uber tooth. So a few approaches to BLE.  Sniff the broadcast traffic. So look from the outside in first. Is it encrypted? What can you  see basically? What are they leaking? What could you potentially do without any kind of  interaction with the device? Is there any kind of information leak? Are there any issues with  configuration? Yeah, that sort of thing. The next step would be to look from the inside out using  something like Android debug bridge and looking at the unencrypted packets that are coming in.  So Android debug bridge allows you to look at the Bluetooth low energy packets once they've crossed  over the HCI threshold. So they've been stripped of the, of the encryption layer and you can  actually see the commands that are getting sent over the wire. Attempt out of app connection.  So just try to, you know, use nrf connect, connect to a device, see if you can create a paired  or a bonded session, and then just start buzzing values and see what interaction you get. Sometimes,  you know, you'll get devices to lock out. Sometimes you'll get devices to actually  do what they're supposed to. Sometimes you hit the trigger. And then the next thing is to spoof  a device or check for cloning protections within the application itself. So these are kind of the  four things that I really look for in a pen test. So hopefully that helps you kind of frame and  contextualize what we're going to look at here in a second. So let's get into some hands-on stuff.  So short list of equipment. The Nordic thingy 52, Bluefruit LE, the LG M150, the Samsung S20 I'll  be using as the victim. But I will also be showing you the screens that the attacker would see on  that phone. It's just kind of a technology and display matter at this point. So, and then we'll  of course be using InterfConnect. We'll be using the thingy app, then the Bluefruit Connect application  will also be using ADB and Wireshark. For an external scan, we're going to start with Uber  tooth. And we're going to go through the basic setup. I just set this up on my computer. If you go to  the the GitHub page and go to their wiki for the Uber tooth, there are really good setup  instructions. You just go line by line. I didn't have any issues on the newest version of Cali,  so hopefully you don't. But yeah, you never know. This is where we will be using ADB to do a live  capture of the BT Snoop file on our LG M150. So, let me get the phone hooked up here. We are going  to launch ADB. So, we would launch by using ADB start server. Mine's already started, but we'll  just hit it again. And then we use ADB devices. And you can see our LG M150 is right there.  So, I plugged a different phone in. And we can see the device that I'm using here to capture the BT  Snoop file on. We go over to Wireshark, which I already have started. And we can see that  we have this BT Snoop interface that's opened up here. Now, it's important to note that  the LG M150 has to be running Android version 7. So, I just tried this a second ago with a different  LG that I have, and it's running version 6. And it does not open up the BT Snoop. So, you'll have to  actually update the version of Android. Luckily, we have pre-recorded videos this time, so I can go  in and actually edit out some of that stuff. So, we have our BT Snoop file here. Let's go ahead  and start the sniffer. So, our sniffer is now running from our phone. So, I have the phone  connected here. And what we can do is start trying to connect to devices. So, for instance, I have  this thingy52 on the desk here. I can turn this on, and I can open up Interf Connect.  And you'll see the packets are starting to come in here.  So, we can see I'm going to connect to the thingy device here, and you'll see the packets start to  change. We can create a connection to our thingy52 using the thingy connect app.  And now that I'm connected, I'm actually reading data from this device, from the thingy52  onto my phone. So, I can do things like play sounds. Now, that's as I'm pressing here.  You hear the sound on the thingy52? So, those commands are coming through the GAT services.  Commands are being written from our phone to the GAT services that are being offered on the thingy52.  So, since we have this hooked up in an internal fashion, and we can see these packets, we can  actually see what commands are controlling what. So, if I hit this tone, we can see that there  are packets coming across. Send right here. And this is the value that's being written  to that GAT service. So, let's try a different key.  Okay. Let's see if that value has changed. You can see it's changed to an 8, from a 5 to an 8.  I would also suspect that 1 is the on and off, right? So, the first right is the on,  the second right is the off. You can see all f's in the middle there, and then we see all 0's in the  middle. All f's, all 0's. Okay. So, that's a pretty basic look at how we see commands, and we're able  to reverse command values that come across the wire internally. So, how do we actually then  interact with or take this information and use it to then test if there is any unauthorized  access to the GAT services, or if we can get any interaction to the device from an unauthenticated  source? So, let me bring up the screen here, and I'm going to use my victim device here,  or in this case, my attacking device, to actually seek out the thingy52 here over nrf connect.  So, this would constitute an out of application connection. Since the thingy52 has an application  that controls all of the interactions, using an application like nrf connect to directly interact  with the GAT services would be considered an out of app interaction. So, let me scan.  So, we have this thing here, that's my thingy52. We'll go ahead and connect to that.  So, you can see right off the bat, we have a connection, but it's not bonded. You'll also  notice up here in the right hand corner is the DFU button. That will actually allow us to push  firmware updates over the air. So, not all devices, and most consumer devices will be locked down  from this, but not all devices will have this. But if you do see this, this would constitute a  fairly major vulnerability in this device, especially since we have a short-term connection,  since there hasn't been long-term key information passed.  Let's go ahead and open up our sound services. So, when we were looking at the other  screen here, let me go to Kelly and phone. So, when we were looking at the other  commands that we captured from the internal, from the ADB capture, we saw our read and  write commands. So, those were being written to the handle 005B, and that was in the sound  service. So, let's look in the sound here. So, if we open up the handle, we can see the full  UUID there. Okay, so the thingy speaker data characteristic is what we saw being written to.  So, we can actually use this upload command. So, we have write permissions to it, and we can use  this value that we have here. So, we have 8701FFF5A. So, let's try and push this. This was a write  command. So, let's make sure that it's placed in command. You have the option between request or  command, and this was sent as command X52. So, we'll send it as a command, and we'll see if we can get  any interaction here between our device and our attacking device.  There it is. There it is. So, we're now attacking from there, and just like I thought, so the  all F command is the on command. So, when we saw the write, that was the F. So, we've sent it the  option to be on. So, it's on right now, and you can hear it in that tone. So, now let's write the  off command. So, that was 8701 0005A, and we send that as a command, and now it's off. So, that is  a very robust look at your basic GAT hacking. We abused an unauthenticated out-of-application  connection to a device, our thingy52 in this case, and we used a command that we reversed from other  information into getting this interaction from an attacking device. So, say this was something else.  Say this was, I don't know, I don't know what kind of user device you would have, but say it had some  purpose, and you had this in your pocket, but it also made noise like that. And say somebody had  reversed these commands and knew that these devices were vulnerable, or that you could just  arbitrarily write these commands to GAT services. So, if you could walk around, identify that these  devices were, or when they were in proximity, you could automatically attack these devices so that  everybody was walking around that had one of these in their pockets, they would automatically get this  tone just going off in their pocket, and they would have to shut the device off. So, you can see  where there is user impact, and there's also a circumventing of protections that are in place  for Bluetooth low energy. So, successful GAT hacking there. Let's switch over to some more slides here.  But we used the internal scan to reverse the Bluetooth commands that we saw coming across  the wire, and then we used that in an out-of-application attack. So, let's move into cloning some services.  So, this will enable us to really attack the application. Generally, there isn't a lot of value  in spoofing against a peripheral, say like spoofing a user device. Although, I have seen that be,  you know, a valid find where you can impersonate a legitimate user's phone, and then there is some  interaction with the device. But without the long-term keys that have been passed, there's a really,  you have an uphill battle basically in trying to spoof a user device against a peripheral. So,  what we are going to do is spoof a peripheral device, and we are going to watch the victim  attach to it from their application, and basically see all of the interactions that you normally would,  and you don't even know that you haven't connected to your device. Meanwhile, if we were to push this  further, what that would enable me to do is get a bonded session with my target. So, I would have  those long-term keys exchanged with my target and be able to then exploit that further. So, I could  either use some sort of proof of concept or, you know, have that deeper interaction with that user's  device. So, what we're going to do is we are going to be spoofing the  the blue fruit LE. I'm going to push some of this other stuff out of the way here for a second.  I'm going to be spoofing the blue fruit LE. It's a real simple development tool.  Adafruit has all these kinds of kits that you can use. This is intended for development. It's  intended to learn with and to explore how Bluetooth development works. But why we're using it is because  it has its own application and one that does not have spoofing protections in it. So, it's easy to  basically prove this cloning concept. So, let me plug things in. You can see we've got power now there.  Okay, so you can see that we have power there. The blue fruit module is on.  So, what I'll be doing on my device is leveraging the scanner. So, I'm going to scan for devices right  now. Hopefully we see this blue fruit pop up somewhere. Oh, there we go. Freaky Zen Sinister  Sun Hat was a project that I had for Defconn last year, but it didn't quite make it all the way.  What we're going to do is we're going to clone here this clone button. So, what I'm doing is  I'm cloning the advertisement data now. So, basically, I'll be able to impersonate the  adafruit unit on the advertisement channels. So, now that we've cloned it, what we can do is we can  actually connect to the device. And we connect to it to get a return on the GAT services that  are available. So, now that we've connected to, we can go here up into the upper right hand corner  and we can go to clone device services. And you can see the little box popped up there and we've  cloned the GAT services now. So, we've cloned the advertisement profiles and we've cloned the GAT  profiles. So, now if we're able to turn these on, we're basically impersonating that device. So,  what we have to do is then go to the GAT server and we have to turn on the GAT server to mimic  the sun hat. So, there we have the GAT services turned on. And what we also have to do is go to  go to our advertiser and we turn on the advertisement for the Freaky Zinn Sinister  Sun Hat. So, now we are impersonating this device and hopefully we will get a connection  to our target device. So, now that we've cloned all of the GAT services, what we have to do is go  into the advertiser, turn on the advertiser for the Sinister Sun Hat, and then we also have to go  in and change the name of the device. We're now advertising as a spoofed sun hat. So,  we will update our scan here on the Adafruit LE app.  And we can see the Phoenix 3. This is actually the name of the phone. So, the name didn't update on  the phone. So, let's try and connect to it. And it allows us to connect to it as if it were the  sun hat. So, the Phoenix 3 is this phone. This is my attacker phone. So, I've created a spoof from  this phone and I've now got a connection in the application, in the Blue Fruit Low Energy application.  And from there, it's not giving us the right information because we're not getting returns on  that. However, if I go to the server information here on my attacker, I can change things like  my manufacturer string. This is an attacker. We can set that.  Now, we should be able to see that pop up there. You see it. Now, we've provided information on  our attacker on the GAT service for the manufacturer name. So, now the end user is seeing that if we  had a device that had more functionality, we could potentially send information from this device.  Say we spoofed a thingy 52 and we spoofed or we sent temperature data out from there and this  red temperature data. So, think about that in a real world example where say a building is relying  on BlueTooth Low Energy sensors to control HVAC. Say we are able to impersonate one of those sensors  and then provide fake information to whatever is reading that temperature and then making  the judgments on what should be done about that temperature. If we can then create a scenario  where it thinks maybe the temperature is rising uncontrollably, maybe there's cooling systems  or maybe it kicks on the fire suppression systems or something. So, there is the risk of spoofing  something and then providing information from that spoof. But I also have a connection now,  a bonded connection to my target device that I could potentially exploit even further.  So, we just went through the basic pieces. We cloned the advertisement data. We changed our  device name. We cloned the device services. We went through and turned on the advertiser  and then we actually connected through and provided a spoof that our victim connected to.  So, I do want to introduce HackNAR's BLE CTF that it runs on ESP32. Like I said,  if you've ever been to any of my in-person training sessions, I generally give these out  to as many people as I can. So, I have maybe 10 or 20 of these that I give out.  But obviously, since we are all safe mode and social distancing, then I can't really give a  bunch of these out. But they're like $10 and you can upload all the information yourself.  And you can actually go through a BLE CTF and it's more of just interacting on GAT services.  So, what we went through earlier where we were doing the abusing of right privileges. So,  there are a bunch of challenges on there. Some of them are decoding MD5 or following  certain instructions that you get back from the services. So, if you have interest in exploring  more on the GAT side, then I would definitely recommend checking out HackNAR's BLE CTF.  And of course, if you need help, feel free to reach out to me on Twitter or wherever.  So, a few recommendations for just kind of the individual BLE CTF user or your consumer.  Keep your BLE CTF turned off unless you really need it. I know with the prevalence of BLE  low energy devices, I find my BLE is being turned on more and more and kept on for longer and longer.  So, this might not be valid information in a few years. We may just always have to just  deal with BLE being on. Choose low traffic areas to do pin pairing sessions with. While it is  fairly unlikely that there will be significant kind of leakage of keys or pins, there is the  chance that that could happen. So, you're better off to choose sort of a controlled RF space where  you know there aren't going to be a lot of people eavesdropping. Generally, your home is a good  option or you know, an uninhabited part of your office maybe. Also, be aware that like we saw  with the Blue Fruit LE app, a lot of apps don't have spoofing protection. So, you could very well  be connecting to something that is not what you thought it was. And you've allowed an attacker  to either provide you with false information or gain a bond of connection to your phone that they  could then further abuse. And then I would also say that you know there are enough free tools out  there that you could actually just start auditing all the Bluetooth devices around you and see can  I abuse GAT services? Can I create a spoof of this device? How does the application handle that?  You might need two phones for that but yeah. And then of course if you want to get deeper into that,  you know, maybe pick up a dedicated testing phone like an LG M150, make sure it's running Android 7.  So, yeah, those are a few of my recommendations for consumers. As far as developers, I'd like to push  out of band pairing options just because it pushes some of that very privileged and important  information away from the channel that is being used for data. So, using something like NFC to  actually pass long-term keys will increase the security of the Bluetooth data because or the  integrity of it because you don't have the risk of using basically an unprotected channel to  pass keys to them protect it. So, you're using out of band practices. Don't focus solely on device  security. You know, does your application have good spoofing protections? Is your app just  basically looking for devices on name alone or is it looking, you know, for something deeper?  What I like to, you know, dream and recommend is that, you know, that there be a remote server  where you can actually validate the keys of a device before you ever connect to it through the  cloud. So, say your cloud application would actually or your application on your phone would have a  connection to a cloud server somewhere. So, before you actually even start a connection with a device,  that advertising data and that key or short-term key would be passed to your cloud and then  validated and if it's not valid then obviously you wouldn't connect or you could blacklisted or  something like that. So, that's what I tend to recommend. As far as further study, there are  a number of blue-teeth researchers but probably the one that I follow the most and the most  enthusiastic is Jiska. I think I'm saying that right but she is a security researcher and yeah,  RF kind of wizard out of Europe. So, yeah, follow her on Twitter. She does a lot of talks  all over the place. So, if you're looking for books, Hacking Exposed Wireless is amazing.  I just went through the coursework for the GAWN and it's very, very similar. Obviously,  written by the same people so of course there's going to be knowledge kind of overlap there.  And if you're looking to get more on the hands-on side then the Adafruit Bluefruit LE,  the Thingy 52 ESP32s and the UD100 Bluetooth USB Adapter which we didn't cover in this talk but  is capable of doing more long-range stuff. So, that's definitely something you'll want to pick  up if you have an interest in taking this further. Okay, so with the badge just  on, if you just turn it on, you can see the Bluetooth Mesh pop up in an NF Connect.  But I'm not able to connect to it.  So, I'm able to see the Anodexor badge within NF Connect.  The Bluetooth Mesh you see there is listed as such. And I can try to connect to it.  And I have a connection to it and it's giving me certain options. I've done some poking around on  this side but I haven't found a lot. This SMP characteristic might be fun to poke around with.  But what I have seen is  within the SMP characteristic you can actually do some interesting commands that have these  bright values here. But OS Echo commands, so you can echo commands through Bluetooth into  the operating system. I haven't got much interaction from that. I've tried the Bender  commands but it hasn't really worked. But the one that I have seen that works very well is the  Reset command. So, I will switch over here. So, as soon as I hit the Reset command,  you'll see the badge turns off.  And then the badge turns off.  Last year, if you were at Def Con and they were talking about the Bluetooth Mesh where you could  attack other people's devices, you could connect to the badges and then you could send these commands.  Turn people's badges off or make it do different things and different commands. So,  very cool puzzle and interaction and tool for learning. So, if you have one of these badges,  one of these Anonix or DC27 badges, or I believe the one before that also had a Bluetooth Mesh on it.  But if you have one of these badges, they would be awesome to hack on.  Yeah, so they have that Bluetooth component. That's going to wrap up my presentation.  And I just want to thank you for spending the time with me today and learning about  Bluetooth Low Energy Hacking. Hopefully you learned something. Hopefully you found something that  maybe caught your interest and you're ready to explore the Bluetooth Low Energy devices around you.  Don't forget the further study that I pushed out in one of the last slides. And if you have  any questions, feel free to reach out on me on Twitter or LinkedIn or anywhere really.  And I will try my best to get in touch with you. I know sometimes I don't do a great job, but  yeah, so thank you so much for joining me. And I hope you have a wonderful, wonderful DEF CON safe mode.
DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_0_383.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_384_455.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_456_2843.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_2844_4175.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_4176_5303.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_5304_5915.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_5916_7379.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_7380_7439.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_7440_29663.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_29664_38147.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_38148_38351.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_38352_38603.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_38604_40079.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_40080_58259.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_58260_58355.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_58356_59975.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_59976_60023.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_60024_60539.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_60540_60923.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_60924_61103.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_61104_64079.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_64080_66035.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_66036_66707.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_66708_67295.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_67296_67367.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_67368_67523.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_67524_67691.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_67692_68651.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_68652_69803.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_69804_70055.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_70056_70151.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_70152_72431.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_72432_73211.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_73212_73451.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_73452_74075.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_74076_74423.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_74424_74639.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_74640_75431.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_75432_75563.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_75564_75779.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_75780_75839.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_75840_76055.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_76056_78911.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_78912_78971.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_78972_79055.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_79056_80051.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_80052_80099.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_80100_80255.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_80256_80483.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_80484_80699.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_80700_80939.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_80940_81251.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_81252_81599.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_81600_82319.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_82320_82451.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_82452_82919.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_82920_84071.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_84072_84563.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_84564_84731.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_84732_84995.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_84996_85331.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_85332_85535.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_85536_85595.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_85596_85715.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_85716_85871.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_85872_85919.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_85920_86351.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_86352_86867.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_86868_88547.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_88548_88739.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_88740_89399.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_89400_89459.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_89460_89627.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_89628_89867.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_89868_90083.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_90084_90971.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_90972_91043.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_91044_91211.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_91212_99359.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_99360_99467.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_99468_99515.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_99516_99875.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_99876_99971.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_99972_101987.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_101988_102671.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_102672_104111.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_104112_104999.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_105000_105323.png DEF_CON_Safe_Mode_Wireless_Village_-_FreqyXin_-_Th_X2ARyfjzxhY_105324_105464.png