 Hello, thank you all for joining us at another wonderful car hacking village courtesy of Defcon 30 recovery mode. My name is come out. And today I'm going to be talking a little bit about Bluetooth and the RF com protocol in particular, and why you should consider it next time you go on a car hacking adventure. Before we just get started, I just want to give a quick basic disclaimer. All the views shared in this presentation are my own and do not represent the views of my employer or any other third parties, or she got to get that out of the way. So, starting off with a very simple, who am I, so I'm an automotive cybersecurity technology architect at white motion, which is a subsidiary of the international automotive tier one supplier Morelle. The motion is a special team within Morelle that specializes in automotive cyber security, carrying out penetration tests for our parent company and external companies alike, and contributing to the automotive security industry. Overall by providing car hacking training and legislation or standards compliance. I'm a member of the automotive security research group or ASRG. And I love participating in car hacking communities, so on and so forth, even outside of my professional duties. So I volunteer a little bit here and there. Among my recent areas of interest when it comes to security work. We've got, you know, Bluetooth, which I'll be talking a little bit about today, the USB protocol general RF stuff and reverse engineering the firmware update process for some really obscure Taiwanese controllers but thankfully that's over I don't have to do that anymore. But besides the technical stuff outside the office or garage I suppose I enjoy playing fighting games and cooking. And I also love exploring new places so whenever I get the chance to go somewhere, I always make sure I get lost on surprise before I go home. Let's go over very briefly, the table of contents for today's talk. So, I'd like to say that the overall objective of the talk is, isn't only to talk about the RF com protocol to say but to familiarize you with the complexity of the Bluetooth specification as a technology and highlight how many different ways it can be viewed from a security perspective. To that effect, I'm going to start off with a short recap of what exactly Bluetooth is, including a look at how it's used in vehicles, and talk a little bit about some scenarios or cases, very, very short case studies where Bluetooth has been used to targets vehicles in the past from a security perspective so we'll look over some some past research by other individuals, not myself, that have been more or less prominent parts of our Bluetooth history in the automotive security landscape. After that, we're going to take a closer look at the star of the show, the RF com protocol. And then I'm going to introduce a very simple tool that I made called the RF comrad that you might be able to use yourself in your own RF com testing in the future. And finally, I'm going to talk a little bit about the Bluetooth CTF that will be featuring at the car hacking village this year at Defcon. Excuse me, just a disclaimer, I haven't hidden any flags in the presentation itself. So, don't feel like you'll be missing out on anything if you're not like pink super close attention and taking notes on everything screen shining every every every slide that there won't be anything like that so feel free to just relax and enjoy the talk. Right, so let's get started. You probably already know what Bluetooth is entirely independently of any technical understanding of how it works, and that should be a testament to how widely used it is and that's really great, you know, all end user technologies should be easy to use, even if you don't understand the technical details behind them and Bluetooth is pretty widely used to that effect. It's in your phone it's in your headphones. Maybe it's in your fridge your microwave, probably not your microwave. It's in your coffee maker, and it's almost certainly in your car. But what exactly is Bluetooth so the official definition is that Bluetooth is a common cable replacement technology, right, found in virtually all smartphones computers and many wireless iot accessory devices worldwide. It is designed to simplify short range wireless communications by providing a uniform framework for connecting devices to one another. It operates in the 2.4 gigahertz frequency range which is the same as Wi-Fi and as a result you will get a lot of Wi-Fi chips that are actually bundled together with Bluetooth functionality just because they can use the same radio frequency pan. Of course, like we mentioned, no Bluetooth is using a lot of devices wireless headphones medical equipment sensors interactive lighting, you know even used for basic data transfers between devices you can do file transfer protocol over Bluetooth or so on so forth we'll see a little bit more about that later. And then since Bluetooth low energy came out, especially it's been very popular with things that you would set up in a outside environment something like a, like a environmental temperature sensor or a humidity device to stay on for long periods of time maybe doesn't have access to direct power supply but runs on a battery and you want to save our over long periods of time that's when things like Bluetooth low energy come into play and are very helpful. And obviously, you know, as we mentioned, Bluetooth is pretty common in cars today if it wasn't I wouldn't be giving this presentation here I'd be trying to give it somewhere else. In a vehicle, Bluetooth is usually used by the infotainment system or the head unit or whatever you want to call it right the thing that has all the cool flashy buttons that you can play with and play your music through. Bluetooth is used primarily originally in cars for making hands free phone calls so while you're driving the car you can answer answer a phone call and play it through your your car speakers and microphone. And it's also used to import your phone book from a phone for quality of life you can see you know have all your contacts listed so you can know who's calling you. And some cars will actually even let you import your entire text message history. So you can have all your text messages stored on your car so you can go back and look through them through your cars console. I've even seen some phones that or excuse me some vehicles that do a Bluetooth connection can actually let your phone send out a text message right so essentially, you know if I'm driving obviously I'm driving I'm not trying to answer a phone call if I don't have the opportunity you know if it's, especially if I'm going you know down the highway or something I can push a button that will tell my phone to respond to the caller with a text message saying sorry I can't pick up I'm driving right now. And so it's it's you can get very creative with how this seemingly simple application you know just an extension of your phone can actually be used. Right. More recently though Bluetooth and Bluetooth low energy or BLE have been used for more advanced functions and cars so ranging from things like updating the firmware on key fobs there's been some research on the Tesla key fobs and they're from the process over Bluetooth to things like passive keyless entry systems and excuse me we'll look at a case where this was a big target for a security research group in just a second. But before we go into the full technical details, like I said, I do want to go over some of the more notable pieces of research that have come out regarding Bluetooth security vehicles over the last few years so got to, I'm not going to talk specifically about them just kind of kind of run through them real quick, these are very well thought out research pieces and I definitely recommend you go and find the original source material by whoever published them to get the full details on what exactly they were doing but I'll just be quickly summarizing for the sake of this talk. So the first example I want to touch on is some research disclosed by Tencent keen labs in 2020. So the researchers at keen were able to fully compromise the head unit of a Lexus vehicle by using Bluetooth the vulnerable a Bluetooth vulnerability as the initial factor. So the first thing they were able to do is exploit the Bluetooth stack on the vehicle to get some remote code execution. And from there they were then able to, you know, expand their reach of influence throughout the vehicles in the system to establish a Wi Fi based backdoor. The reason for this was Wi Fi is generally, you know, a longer range technology than Bluetooth so this gave them the ability to get their reverse shell as you might say on the car from a farther away range and then they could continue their, their exploration of the vehicle at that point. So they had set up a essentially, you know, some persistence in the vehicle where when it booted up it would actually phone home it would actually connect back to the researchers PC and they could then open a shell and continue exploration and exploitation. So, due to the fact that there were no firmware checks in place to prevent anyone from, you know, flashing unauthorized firmware to other parts of this infotainment system. The researchers were actually able to flash other components inside that unit, and essentially unlock canvas access the canvas was obviously available on the device. However, it was intended to be kind of filtered or locked off so that you couldn't just send and send arbitrary messages at your whim. But because of the ability to rewrite the firmware, due to the lack of firmware checks they're actually able to bypass this, and they were able to kind of expand their reach a bit further. At this point, there are further possibilities to pivot within the vehicle system. There are some diagnostics to potentially reprogram other parts of the car, but the researchers didn't quite go that far in the publication they released of course this will be linked in the references section at the end you're free to encourage to read up their full write up it is incredibly educational. And I think anybody could benefit from giving it a look at the last tech I want to talk about is much more a little bit more recent. It came out earlier this year in May of 2022. So this was some research that was disclosed by the NCC group, after they found out that the passive keyless entry system using Tesla models three and models why I believe are susceptible to relay attacks right. A relay attack is not something new to vehicles right the idea that you can pass the signal from a key fob on to a car and unlock it without having the key fob within the intended range is kind of a theoretical attack that's existed for a while, but these researchers were able to perform this over to do flow energy. So the challenge to getting the attack to work on the Tesla's PKE system was that the key exchange had to be done within a given timeframe there's a good time out in place that's designed to kind of prevent against this kind of really problem because the communications have to happen there's cryptographic information exchanged, and the idea is that all right if there's someone sitting in between these two devices the actual car and the, and the intended users key, right their phone, the added latency of passing the information between several devices may, you know, exceed that minimum timeframe that you have to actually perform these operations and would make it much harder, but the researchers were actually able to figure out a way to do that they would use one cell phone to kind of go near the target human being right the person with the actual phone to unlock the car. They could then sniff this Bluetooth low energy signal over the air and then pass it through over the internet like an IP network just like anything else to another phone that was close to the car. They could actually perform these cryptographic chain checks over the internet, and this you know very close range communication between the two attacker cell phones in a timeframe that allowed them to bypass the latency bounding in place. So this essentially gave them the ability to unlock the car and then the car thinks well I've got the key inside me I should unlock all functionality. So the next step obviously is going to be a room room right so you can break off at the car, and all of a sudden, you know you come back from your shopping trip and your car is missing and what happened. Right, so, again, the link to the actual publication for this research will be in the references section again so I encourage you to go ahead and give it a full look. This is going to be the Bluetooth breakdown I'm going to give a brief explanation of how the different protocols that make up Bluetooth work so this picture is pretty ugly so bear with me for one moment. And it represents a visual representation of some of the different protocols that make up what we know is Bluetooth. And this is important because you know the way I see it Bluetooth is not one protocol it's a bunch of smaller protocols standing on one another shoulders all wearing a big big coat right pretending to be just a one one protocol. But it's actually a technology standard for short range wireless communication. And each of these sub protocols has its own specification. All of these, you know, of which are managed by the Bluetooth special interest group or the Bluetooth sig as it's easier to call it. So this is a group of companies and representatives of these companies that manage the Bluetooth specification make edits to it manage security bulletins etc so on and so forth. And the specification itself is you can actually read it for free it's available online. All the specification itself is managed by the Bluetooth sg the actual implementations of these are not. Right, so this is the source of one level of Bluetooth complexity as a protocol right each of these protocols can be implemented differently. And many of these protocols are implemented on the chip the controller they're entirely invisible to the end user. And so sometimes makes them hard to analyze from a security perspective. And that will give you a better idea of what I'm talking about. So, hopefully things look a little bit nicer now. You can see here let me pull out the laser pointer. We have the bottom part here which is the red protocols these are what we call the controller layer protocols, and up here on top, you have the the bluish ones these are the host layer right. So, the lower layer represents the protocols that are controlled by the actual controller. This means that these functions are controlled by the firmware on the Bluetooth chip itself. And the operating system that's using this Bluetooth chip has close to no visibility into what's going on down there. This is why low level protocols such as the hardware focus baseband and radio layers operate. And as well as the link management protocol have such a bit of like a mystery around them because it's not easy to see what they're doing right because the firmware will be implemented differently based on different vendors of these chips. These manufacturers each their own unique compositions, sometimes different architectures they use special, you know, commands, we'll talk about HCI in a second, I can be quite complicated if you wanted to like first engineer these for example. You know, example companies that make Bluetooth chips, you got Broadcom, you got Qualcomm, Cambridge Intel, these are all different manufacturers you could find that implemented their own, you know, version of the Bluetooth specification on this chip. The middle layer here this purple one because of, you know, as a mix of like the blue and the red is the host controller interface layer. This is a protocol that's used to allow the hopes to communicate with the controller. There is some standardization around how HCI commands are implemented but there can also be vendor specific instructions based on the vendor of the Bluetooth chip again a lot of the stuff is going to be different from vendor to vendor which is another one of the reasons a little bit complicated. I've never used Bluetooth with Linux before, for example, you know you might Google, okay how to use Bluetooth on Linux and one of the first commands they'll tell you to run is HCI config, and that's a pretty standard Linux Bluetooth tool and it stands for you know, post controller interface configuration this will give you information about the Bluetooth controller that you're using right any Bluetooth controllers that are registered on your system, you can see information about them with this command right. The other one is HCI tool, a couple of really useful tools implemented with the HCI protocol right to read or write information on your Bluetooth controller run scans, lots of things you can do with it. These tools work by sending standardized messages from the operating system to the controller to the controller will say oh you're asking for this piece of data okay let me get that for you, and then it'll feed it back up to the operating system. Finally the protocols on the top half of the screen are what we call the host layer protocols these are controlled by your operating system right so the host in this kind of equation is your computer your operating system and the controller is the chip running the other firmware implemented by the vendor right. Depending on the system you're using they'll be implemented a little bit differently so for example there is the blue Z stack right blue Z is the official Bluetooth stack for Linux, but it's not the only one that that that being said. It's used so widely that you'd have to have a really specific you know use case to bother with coming up with your own Bluetooth stack for Linux environment, and it's not seem very commonly so it's not a an exaggeration to say bluesy is on like you know 98% plus of Linux systems that run Bluetooth in the first place. So yeah bluesy is great and then I'll talk a little bit more about that in a bit. In the host protocol pool, we find the logical link control and adaptation protocol I'm not going to say this acronym again because L2 cap is just much easier to say. This is the base protocol in the host protocol pool side and everything else is more or less built on top of it. This you know out of cap is developed to be a generic multiplexing layer of the host protocol stack. It receives information from the higher up protocols, and then passes them on through to the HCI the host control interface which then processes the information to be sent to the controller side of things. Right. Let's take a look at some of the different protocols we have here very briefly. We have on the right we have the SDP right the service discovery protocol. SDP is used to allow Bluetooth devices to learn more about one another someone to devices connect. They kind of ask each other are so what can you do you know you're a you're a phone book server I'm a phone book client I might ask you for some questions. Right. Oh you can play audio well let me see if I can you know street some audio through you this communication and establishment of what devices are capable of is done through SDP. Right. So it's in a very important part of blue communication, because it also give you information about Oh, this service I'm interested in this which RF com channel is it using and we'll talk about our RF com channels that a bit because that's kind of what this talk is about. But again this all ties back to SDP. Interestingly enough, SDP is always unencrypted. It's just supposed to be freely available and you can usually query any Bluetooth device or SDP information so no matter like what the security settings on your Bluetooth device are SDP will usually be, you know, unencrypted communication because it's not supposed to be secret you're supposed to share it with anyone that asks. Interesting. But, and then RF com as you can see here on the left of this of the screen has a lot of different applications or protocols built on top of it you have things like point to point which, you know, can can go into things like IP and TCP so you get like your basic traditional networking architecture built through Bluetooth and then, you know, on top of RF com. You have serial port profile this is the the SPP one right here. You've got Pbap this is the phone book access profile. You have object exchange or Obex vcard FTP. We'll talk a little bit more about these. A little bit more detail, but there's a lot of stuff that can be built on RF com because RF com is built to be very flexible. And a quick look RF com is designed to emulate an RS 232 serial port over the L2 cap protocol as literally as possible. It actually includes features to emulate all nine pins of an RS 232 serial port which is really interesting. And this is true to the extent of the RF com protocol actually specifies this outright so if you open up the RF com protocol you'll see in like the introduction section. Like I say, this document does not contain a complete specification instead references are made to the relevant parts of the gsm 07.10 standard. So they really just telling you like, we just wanted to make you know, gsm 7.10 serial ports available over the communication so RF com is literally, you know, a radio frequency comport is kind of what they designed it to be. So it was designed to allow devices that already had RS 232 capability to be easily ported to wireless applications by simplifying the process of adding a wireless network interface you didn't have to change all that much. And you know, readjust which interface it's talking to and the RF com channel would take all the information that would be sent to a regular serial port and move that over the, you know, the unguided medium that is the wireless communication and that 2.4. It hurts frequency band. So, in a practical sense though, right, the practicality of RF com right don't don't worry too much about the specification yet right that's if you want to read it, it'll be linked in the end right but RF com channels work pretty similarly to TCP boards. So, like TCP RF com provides some basic guarantees for reliability. And it's a point to point connection, you know, communication style right the contrast to this would be something like L2 cap and UDP, where UDP is usually you know, considered connection less but you know L2 cap can be connection based or connection less it actually supports both both types. RF com has way fewer ports available with their, you know they work like ports but we call them channels. I'm not the one who came up with this right it's just the way it is. But whereas TCP has you know like 65,000 different ports are calm only supports 30 channels. The specification states that up to 60 simultaneous connections between two devices are possible, but with only 30 ports to work with you need to kind of be careful. When you allocate RF com channels to your application so when you're writing an application you might say, Alright specify to use this RF com channel or random first available RF com channel these are both options you can use. And just, you know, may want to keep in mind how many you have left to when you're writing a book with applications. I've linked both here and later in my references of course you can see the link here in old. It's pretty dated. It's like I think from like 2000 like the early 2000s like before 2010. It's a guide, it's a very helpful guide to programming with bluesy. You may remember I mentioned bluesy is the Linux stack for the Bluetooth stack for Linux, excuse me. But it is a little bit dated, but it's a great introduction to programming with Bluetooth and I would suggest anyone looking to make their own Bluetooth applications either for testing purposes or just to learn more about how the protocols work to give it a look. Take it with a grain of salt it is quite old so you might have to change things to fit, you know, more modern, you know, Python packages or versions that are available, right. But then one final, you know, useful parallel between RF com and TCP is that much how you might use and map or something to do a port scan right kind of see what services are running on a device or the IP network. So you can use the STP right service discovery protocol to do more or less the same thing over Bluetooth and this is a RF com specific this is a Bluetooth thing overall, but let's take a look here. So since the service discovery protocol is designed to let the Bluetooth devices understand the capabilities of the other remote devices. It makes sense that there would be in a way to see right ask a device hey, what do you do. How can we communicate let's find something we can do together. The STP tool, for example is a basic Linux tool that allows you to browse the STP servers of remote Bluetooth devices it can do a lot more but browsing is kind of the easiest way to use it for starting off. It lets you add services to your own devices as well for example or you can, you know, search for a specific Bluetooth service on a target device if you have something in mind. shown here on the right is part of the output from STP tool when browsing my Samsung Galaxy phone I use my own personal device for this I didn't want to get in trouble by by posting some some customers STP tool outputs right that would that would that would be bad. But you can see here that there are a couple of applications running on my phone that are tied to RF com channels with information on the type of application and which RF com channel is in use. So for example, on phones obviously phone book access is something you would expect to see because my phone is used to sharing my contact book. If I if I if I wanted to I usually don't but when you connect to a car, you can import your contacts to the vehicle right so that you have access to your phone book you can use calls or IDs on so forth. Obex right I talked about object exchange earlier. Obex is a communication protocol used for sharing files between devices and a lot of like the things like the ftp in the phone book access, sometimes are built on top of Obex. Interestingly, Obex was originally developed for infrared communications right and it's actually managed by the infrared data association, but it's just kind of been adopted by the Bluetooth sg and it's just you know very common defined Obex in Bluetooth devices to the point where you would assume a lot of people assume Obex is initially made for Bluetooth when it's actually you know it was originally made for the infrared stuff. And then like I said, things like ftp and phone back access can be built on top of Obex, but they don't necessarily have to be right this goes back to the idea that a bunch of pieces to Bluetooth and you can kind of with some degree of flexibility, you know assemble them, however you like, right. Just kind of like visualize this you know with a very simple example. Let's just say you have you know an IP network to devices connected to the same IP network you can see we've got IP addresses associated on the left. We have a host user you know a computer. On the right side we've got a server or something. Maybe they're running some ftp service on on port 21. Well, when you want to use this service, you would address the server you want to talk to bytes IP address and you'd specify the port on that server that you want to communicate with right in this case you know we know the standard socket notation is shown up here. You've got the IP address colon port number right pretty simple. Similarly, when using Bluetooth, you would address the device used to use. You wish to talk to with the RF com channel that it's using for that particular service. I've got to dummy IP or Bluetooth addresses here please don't look these up and not going to give you any interesting results. One, two, three, four, five, six, seven, eight ABCDFG. Right. But one thing I would like to know is the convention I'm using here, by the way, and you can see here you have the Bluetooth address, and then you have the RF com channel this is by no means like a standard convention for kind of displaying a Bluetooth socket. I just wrote it like this. So if this is not this is not there's no standard here for like like you would have in the IP network for a common way to designate a socket, you don't have that. I just came up with it but it more or less works almost the same way and so you could have a similar service running over Bluetooth, and likewise you'd communicate targeting that Bluetooth address and the RF com channel that is hosting that the host is tied to that application. And lastly, you know, before we move on, just wanted to share that the RF com specification has not been updated since November 2012 and maybe that's a testament to how well put together it is that it has received, you know, no updates in the last 10 years. But I always find it interesting to see something that's still so widely used everywhere, you know, in different industries not just cars like I said medical, you know, other iot industries hasn't changed at all in the last 10 years and granted it is an underlying transport layer protocol so it doesn't maybe doesn't get that much attention but it's always worth you know poking through this specification seeing if you can find anything you might be able to use reviews. On to the next part of the talk, I'm going to introduce RF comrad. So, what exactly is RF comrad so RF comrad is a tool to assist in the testing of RF com protocol on remote Bluetooth devices. I built it in Python, and it uses the PI bluesy library, which makes it very easy to get set up on any Linux system. The PI bluesy is a Python implementation of the bluesy software stack for Linux. It's main feature is the ability to connect to an RF com channel on a remote device, and basically flood it with a user defined payload, you set up a payload, you say hey, I want to target that RF com channel on that Bluetooth device. I just want to hammer it with as much data as possible it's very very simple it's not it's nothing like like a guided fuzzer anything I'm hoping to improve it in the future. But what I started with was just a basic flooding attack. But, you know, it can essentially work as a DOS attack or a denial of service on devices that don't have fail safes in place to deal with volumes of large data large volumes of data. Then they're then they're prepared to expect. Right. If the RF com channels and use on the target are not known. There's also a basic service discovery feature I added to the tool that will actually you can say okay I know the Bluetooth address but I didn't run STP tool I didn't feel like browsing it. So let's run it with a Bluetooth address and no RF com ports specified it'll actually return to you which RF com ports are, you know, up on the machine that you're targeting, and some information on what applications are tied to them. Why would I make this tool so the motivation for putting this tool together is as often as it is because I couldn't find another way to do the same thing with someone else's tool I'm not a very good programmer I'm not a developer I don't particularly like the program so I try to avoid it when I can. Sometimes you know, you, you force your hand right. So, during a penetration test of an automotive navigation unit. We wanted to test the devices Bluetooth implementation and its resilience against receiving large amounts of unexpected data. This isn't the only test we performed at Harding the Bluetooth technology on the device, but we wanted to test it from a bunch of different perspectives so it made sense to do just some you know brute forcing of the data flooding. In our research we found that this kind of remote flooding test has been done in the past, but the only publicly available tools I could find weren't exactly what I was hoping to find some older tools like L2 ping, for example, which is usually installed bluesy by default only works with the L2 cap layer, and it had a lot of flexibility on the content of the data that you sent it's just it'll send pings and you can you know enable it to flood the opponent opponent, excuse me remote target device with data. We can exactly control the contents of the payload you really can't do much about that and because it is only you know target at the L2 cap protocol, I felt there might be some benefit in targeting other protocols on the device. There are other tools, such as a tool called a Bluetooth stack smasher that allows you to fuzzer mobile Bluetooth device with random data. But again this one also only targets the L2 cap protocol and it doesn't have the features you would like in a modern protocol fuzzer so it wasn't quite what I was hoping to find. So if you give it a shot if you like though it's freely available on the internet. There isn't much control over what data gets sent and when and sometimes recreating crashes or other issues can be difficult. I found. So, we wanted a tool that could interact more directly with the RF com channels themselves, and the applications operating behind them. So, I use the pie bluesy library to cook up a simple script that would let us connect formal targets RF com channels, and just toss a bunch of data at it. Right, just like I explained. The idea was, we could identify any applications that were tied to RF com channels that weren't set up to handle large volumes of random data, and might, you know be able to invoke a crash of the Bluetooth stack see how the target device response. Excuse me I'm going to take a quick water break. All right, let's go on, almost done. And so did it work. Alright that's the next obvious question and to my surprise. Yeah, kind of did. I was able to reliably crash the Bluetooth stack on a target device by connecting to one of the services hosted on the RF com channel and flooding it with a very simple payload right just a just I didn't want to do anything complicated just wanted to test it out for about five seconds. I couldn't confirm this because the target device would actually display an error message saying no Bluetooth stack or started like the Bluetooth function that essentially just entirely crashed and then had to boot up again from zero. So, any devices that were already connected to the target over Bluetooth say my cell phone or another target you know testing device would be disconnected and whatever Bluetooth operations they were carrying out at that time would be interrupted. The application connected afterwards by us revealed that the function wasn't properly handling the large volume unexpected inputs, and it actually resulted in a buffer overflow that would cause the, the application running on that RF com channel to crash. And it ended up you know causing the Bluetooth stack to have to restart. So I'm here for a further exploitation of the application right if you have a crafted payload if you actually reverse engineer the firmware running on the device find out how you can, you know, further compromise this target. There's a lot of potential for for more wrongdoing in the place here. So, we didn't really feel need to go that far but maybe someday I'll take another look at it. I felt that since the dual said did something kind of useful. Others might find some benefit from having access to it and that's what motivated me to apply this. This little tool of mine to the call for papers here at Def Con. And just keep in mind, at the end of the day it is just a very simple Python script. Like I said I'm not a very, not a very good programmer. So, forgive me if it looks really ugly like why didn't you do this why didn't you do that. This is my best right. So, you know, even even my my own little efforts might be helpful to somebody somewhere out there, because, and you know, even outside of the automotive industry, because bluetooth by no means automotive specific technology. There's a lot of, excuse me, a lot of other devices out there that maybe could use a good rattling. Right. So, where it's publicly available you can find it here at this. You can download it publicly, go ahead and download it, give it a shot see if you like it, you don't like it criticisms comments, etc. Always welcome. I do hope on making improvements to it in the future actually. So, as with any project you know I want to take it somewhere higher maybe improve on it. The next step to that is hopefully to add meaningful fuzzing. How should I say fuzzing capability and I want to increase the scope to other protocols to obviously we can't call other protocol fuzzers or flutters RF com read because they're not our company more, but we'll figure something out right. So when it comes to the fuzzing, I've been looking at escapee for a little while to kind of get ideas for how to fuzz the Bluetooth properly but my experience there's not as much documentation on using the Bluetooth functions in escapee. As I would like I just haven't had enough time to kind of dig through them little by little so that's kind of the first step is to see if that's a viable next step. So that's just to find more next steps right that's kind of how how this goes when you don't really know what you're doing. But I'm happy to hear any suggestions or criticisms of my little project, you know I'm all yours I'm always happy to listen. So if you have any feedback by all means please in the up. And then finally, the last part of this talk, we're just going to talk very briefly about the CTF. So, the CTF isn't meant to be incredibly challenging it's a Bluetooth CTF, but it's mostly designed to force you to learn a little bit about the tools that are available as a Bluetooth security researcher. These are ones that are, it can everything can be done with free tools you don't need a special Bluetooth adapter you don't need an Ubertooth one you can put that away it's not going to be any help I promise. It's just basically Bluetooth stuff, but there is a bit of a challenge in some of the later challenges so most of the challenges can be solved by simply downloading a tool that's available for free online, and simply reading the documentation to learn how to use them and how to read the data from the data you received from the target. It's all running on one Raspberry Pi, you just ask it for information and it'll give it to you and you find the right information and put that into your CTF portal. Right. So, the only flag I would really consider a challenge is the last one for which you're going to need to have a program that can send Bluetooth data to the target device right and then be ready to receive data, because you will find the first piece of data you have to send as one of the other challenges. Then your task is to send that data to my device successfully and prepare your device to receive data in response, because the data you received, excuse me, the data you receive in response will be the last flag and that's the one that I think is the only really challenging one, you will have to write some code to get this to work. You know, even if you haven't coded in Bluetooth with Bluetooth before, if you've done any Python work, I think you'll be able to figure it out. I would recommend that anyone, you know, especially if you're having trouble with that last one. Take a look at the examples that Pi Blue Z provides. They're very useful and there were a lot of help for me when I was first figuring out how to customize applications for sending and receiving Bluetooth data. Hopefully that's enough of a hint or a tip to have you staying here with us worth your time for the CTF. I know it gets very competitive sometimes. But yeah, that is the end of the presentation. Here's a quick look at some of the references. Everything here should be, you know, pretty easy to see. I will be uploading these slides to the GitHub as well. So if you want to just remember and go back to that GitHub page, there's the link. The slides should be available there soon. But yeah, I am all out of clever things to say. So thank you so much for your time and I will be on the floor at the car hacking village throughout the entire event. So if you see me and you have any questions or you want to call me some call me names or something by all means come through. I'm always happy to answer questions over email as well or if you want to look me up on LinkedIn. That's fine too. Searching come out golly will usually lead you my way but you know like I said my email address is there. Feel free to reach out at any time. So thank you so much. And yeah, y'all be easy. Keep on hacking. Hack the world. Yeah.