 So we're coming down to the end. We haven't had any kind of internet of things talks in this track before so I'm kind of excited to hear about this. We're going to hear about um speedometers, right? We're going to talk about speedometers and things that you can put on to your put on put on to your bike. This is going to be really cool. Um let's give speaker a give our next speaker a big round of applause. Hi everybody. Uh thank you for being here on a Sunday afternoon. Uh I'm Toma. I'm from Hungary and I work for a small IT security company as a pentester developer the company called PR audit. Uh I'm a regular speaker at uh HackTivity, Central Europe's biggest hacker convention and I also gave a talk uh about uh insecure game scripting engines last year here at Defcon. So the title of my talk is help I've got the end. What are we doing with the end? Uh last year I've targeted one of my hobbies uh flight simulators so I thought it would be appropriate to uh target one of my other hobbies this year mountain biking and uh sorry uh and uh while creating this slide I've just realized that all of my hobbies includes crashing uh so mountain biking, computer security, flight simulators and recently drones. There's a lot of crashing there. I don't know about this. Okay so so mountain biking and the end uh what what does what what do you end have to do with mountain biking? Uh there's a lot of uh gadgets that uh lots of equipment uh involved in sports involved in mountain biking and cycling in general. And uh old school speedometers got replaced by powerful powerful computers. Computers that talk to various sensors like speed sensors, power meters, heart rate monitors, et cetera et cetera. And also uh talk to uh mobile phones or even your PC. And here is where end came in the picture because uh end is a protocol uh that these devices speak. Uh uh I think uh it is not just used by uh sports equipment but uh weight scales but blood pressure monitors or there are even there is even a chat application that uses it to create mesh network on android it's called fire chat. So in this talk uh I will uh introduce you to end and plus and the end to fast protocols and I show you some uh protocol level design errors. And uh after that some implementation errors in various Garmin devices. So uh end. End is a wireless protocol created by Dynastream and uh it is designed for low power devices. Uh you can create uh any kind of network topologies and the participants are called notes. There are slave and master notes uh and these notes are communicating via uh mutually established channels. Uh channels are defined by lots and lots of uh properties like uh frequency uh or um the channel ID. But the most important for us uh from a security standpoint is the network ID because it contains an 8 byte uh long number called network key which according to Dynastream is a security measure. It's a security measure because uh only notes with the same network key can communicate with each other. It sounds good but there are some problems. Uh network keys are managed uh by Dynastream and if you want your uh want a network key for yourself then you have to uh purchase one from Dynastream. Uh and if you use an invalid network s t s uh network key uh then the protocol stack will just default to the public key which is uh public. You can download it from Dynastream's uh web page. There's another problem with the network key. Uh it is being that uh the majority of devices that use and actually use uh and plus or and f s and uh these two protocols have their own uh network key uh and these network keys are also public. They can also be downloaded from Dynastream. So it's uh not much uh security measure because everybody knows those keys. Okay other security measures in the end. There's a pairing bit uh it works like this. Two notes can communicate with each other only if the pairing bit uh is the same for the two notes. So it does not have to be on. It just have to be the same on on two notes. Uh this is fairly easy to circumvent because you can open two channels. One with the pairing bit off and the other with the pairing bit on and one of these channels will succeed. I have first uh noticed that there's something uh fishy with this uh pairing bit when I came home from a mountain bike trip and realized that that uh there are some heart rate uh data on my charts uh despite I don't have a heart rate monitor so it must have picked up picked it up from another cyclist or something like that. Okay I'm gonna show you how easy it is to spoof uh and sensor data. I'm just gonna uh set up my uh Freighton XT to use a power meter and I'm gonna use uh Simulant Plus which is a software released by Dynastream to simulate a power sensor. Just creating the power sensor, setting sensor uh data value that it will transmit, turn it on and the watch should just pick up that signal and display uh that value and yeah it did. So uh without any pairing it is this simple spoof uh and sensor data. Okay back to uh and security measures uh there are these things called inclusion exclusion list and uh white blacklist. They are uh essentially the same uh one for the slave notes, one the other for the uh master notes. Um they could be useful but there's a problem with them. They are uh only available on fairly recent ant chips so uh none of my Garmin devices uh can use these features. Okay another security measure uh ant channels can be encrypted with uh AES CTR but there are some problems with these too. Uh you can't use them with sharp channels uh which makes it uh harder to implement uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh to have for example one by computer with uh multiple sensors and also uh it requires advanced burst data mode which is highly energy efficient and it's kind of problem with low energy devices. So uh these are problems but these have uh another bigger problem too uh encryption can't be used with ant plus. Uh if you use encryption then you are not uh ant plus compliant and you can't interoperate with other uh ant plus devices. Okay so I've mentioned uh this ant plus uh several times already but I did not tell you uh what it is. It's a protocol built on top of ant and it's basically just uh specified so specifies uh so called device profiles. So there's a device profile for uh speed sensors, a device profile for uh heart rate monitors and so on and so on. Uh these device profiles are uh managed by dynastream and they basically uh just govern some characteristics of the ant connection like uh frequency, channel period, and data formats. Uh a few example of uh these device profiles this is a bicycle rear view radar that uses the radar and uh light device profiles. The dropper seat post that uses the seat post device profile. Uh bicycle headlight obviously the light profile and the blood pressure monitor that uses the blood pressure device profile. Okay one of these device profiles uh is called sync and uh it allows you to uh collect and transfer uh sensor data in the form of FIT files. So FIT uh is basically uh a file system uh yep a file system is the file system file format for uh ant fs. Uh the files are fairly simple. They have uh 14 bytes uh header, some data records and the 2 bytes CRC. And all data records have their own uh records header, it's a 1 byte header and some record content. It can be anything really. So uh they store um recorded tracks, your settings, your name, etc. in these uh FIT files. The reason I'm talking about uh FIT files is that my first attempt to uh hack my Fritan XT was to uh try to find some memory corruption uh vulnerabilities in the firmware. And I did that by uh fuzzing the FIT SDK with AFL and uh I did uh get some crashes but they all seemed uh non-exploitable. I've tried to upload them uh to my Fritan XT nevertheless because I was hoping for some uh crash dumps or crash logs or some useful information but I did not get uh either so I I got nothing. Uh the watch did not crash. And uh this got me thinking uh not this uh the ant protocol stack became unavailable for a few minutes and that's got me thinking that maybe the ant protocol stack, the ant fs protocol stack is implemented uh in the ant chip and not the uh actual Garmin firmware. So I have to uh explore this further uh it might be interesting. Okay back to ant fs uh according to dynastream ant fs is uh secure and reliable file transfer protocol built on top of ant. Uh if you google Garmin plus ant then you will uh find some uh rents on various forums about how reliable this stuff is and I do question the security. Uh there are two major security features according to dynastream. One is the built-in encryption. Uh so you can encrypt uh your files and they are also encrypted uh while on the air. It sounds nice but I've seen some ant fs implementations but I did not see anyone that uses uh this encryption feature. The other security uh measure in ant fs is that it employs uh multiple authentication mechanisms. We'll see about them. There are three uh authentication mechanisms. The first being the pass-through mode. It's not really an authentication mechanisms because it works like this. The host just asks the client if it can connect and the client just says yes why not. So uh no information needed to connect. I don't know uh why they did implement this maybe some uh maybe for some testing purposes but the important thing is that it is there and uh you can use it. The second uh authentication mechanism is uh called pairing mode. Uh don't confuse this with the ant uh pairing bit. It's an entirely different uh concept. Uh it requires user interaction. Uh the host sends a serial number and the friendly name to the client. The client device displays this information uh to the user and the user can uh decide if she accepts the connection or not. If the user accepts the connection uh then a pesky is sent from the client to the host. The host stores this pesky and uses it for any further connections. So this pairing has to be uh only once. Okay what's wrong with pairing mode? Uh obviously if you are uh malicious host then you can send any serial numbers or any friendly names to a client so you can maybe get the user to accept the connection. Uh this is one one way to attack pairing mode. The other is that uh after successful pairing the pesky is sent from client to host and it can be sniffed. How do we sniff ant? Uh the ant chips that the majority of these devices use are NRF 24 AP 1 and AP 2 and these are based on the very well known NRF 24 L01 plus chips. So they work in the 2.4 GHz ISM band. They have a 1 megabits per second um uh on our data rate. They use uh GFS key uh modulation. But the actual packet format is not really clear from the documentations. One of the papers mention uh enhanced shock burst so I just went with that. But I only had an RTL SDR which is not capable of uh sniffing 2.4 GHz. But uh luckily I found this uh block post where this guy sniffs NRF 24 L01 packets with uh an RTL SDR and an MMDS down converter. So I uh ordered an MMDS down converter uh said this all up and tried to decode RTL FM output as enhanced shock burst packet. It seemed to almost work. But every byte was the double of the expected. So either they are uh very dumb and they use a brand new highly sophisticated encryption algorithm where the crypt uh where they just multiply the plain text with 2. Uh I've seen some pretty dumb shit from developers but this would have been a bit much of a stretch. So I just went with another idea that the documentation slide and uh the packet format is not really enhanced shock burst. Uh I started reading about uh enhanced shock burst and uh surprise surprise it turned out that there is a shock burst protocol. The 2 uh the difference between the 2 uh is a 9 bit field called uh packet control field. Uh and it's being 9 bits. So it can happen that if you try to interpret a shock burst packet as an enhanced shock burst packet that there is a 1 bit left shift which is uh multiplying with 2. So uh it seemed uh reasonable uh solution. So I've uh implemented shock burst decoding. I've implemented it as a C uh program and uh which uh outputs um hex pairs. And I've also written an NT3.py which interprets these uh hex pairs as NTFS packet. This worked nicely uh as a proof of concept but I wanted something uh cleaner. So I've implemented these uh functionalities in uh Potosfer as uh 2 Potosfer blocks. Uh if you don't know Potosfer it's uh very similar to uh GNU radio com- companion. I just uh like to use it more. Okay I have video of these 2. So this is the hardware. The MMDsDun converter. The RTL-SDR. And I'm using a virtual machine with 2 NTFS sticks here. Uh one for the NTFS host and the other for the NTFS client. So there will be a host and the client on the same machine and they will talk to each other. And we are going to sniff them uh using these Potos uh blocks. Yeah it's starting. Uh so this one is the shock burst decoder and the NTFS decoder I'm opening the uh client channel. The client beacons. We can already see the client beacons. And I will just try to search uh for the client on the host. And uh when the host finds the client uh it sends a link command which changes the uh communication frequency. Uh and this is why this uh feedback from the NTFS decoder to the SDR source is there uh so it can change the uh SDR source's frequency. Okay uh there are some serial number request uh responses. Some more beacons. And when we try to download the directory uh listing it's also file. Uh there's download request response. Pack it. And uh this is actually the uh directory listing. It's not uh yet parsed. And this is where my uh USB stack failed me. It did not uh like all those data. Okay so we've talked uh about two uh authentication data. Uh and uh mechanisms so far. Uh the last one is the pass key mode. Uh pass keys are up to 255 bytes long. Uh so brute forcing them is uh impractical. But uh as I've told you earlier after successful pairing the host remembers the pass key. Uh and the pass keys are stored in a directory structure. So uh there's a client serial number and the corresponding uh pass key. Another serial number. Another pass key and so on and so on. And when the the host encounters uh client with a known serial then it tries to uh authenticate uh with the stored pass key. This whole process could be uh managed in the middle uh by first posing uh as an interface host uh acquiring the client serial number. Then spoofing the serial number. Acting as a client uh the host will send us the pass key. And we can then use this pass key to authenticate to the client. Uh I've tried to use interface PC tools for this uh and I've expected to use to find the pass key in the debug logs. But the actual pass key algorithm made it impossible because the host checks the uh pass key lines. Uh and if it does not match the stored uh lines then it aborts the authentication process. But since uh we are the host in step two uh we can patch these uh functionality uh and and still get the pass key. I found out that uh the ant uh wrapped lib.dlr contains the code pass uh for for this functionality. I've almost uh started to binary patch it but uh I noticed just in time that uh uh Dynastream actually released the source codes so I just have to modify the C code and recompile the uh DLL to do this attack. So as first step we are going to uh pose as a host and get the client serial number. And just setting up some things here. Okay. And I've also used used my free Tonext for this. The host is searching for the client. And we should get the client information soon. Yeah it's not the uh not the fastest protocol but we yeah we we've got the uh device ID which will be needed. So the with that device ID we can start an NFSPC client and impersonate that client. Okay I'm just skipping some parts. Yep. So uh started the client and I'm starting Garmin Express on my other computer uh where this uh free Tonext is already registered. And because Garmin Express thinks that this NFSPC client is this watch uh it will send the pass key to it. And we can see it in the debug logs. Opening the log files. And uh these lines with uh starting with the HCK. Those are the uh patched in uh stuff. That's the pass key length and the pass key itself. And now we can use that pass key uh to authenticate to the watch and download the files from it. Uh yeah I'm just uh copy pasting that pass key. Starting with the channel. Starting searching for the client. And uh you can see that uh there is no user interaction on the client's side. It's pass key it succeeded and we can download the directory structure uh without uh any user interaction from the client's side. So this how uh this money in the middle attack works. Okay so uh this was the part about the uh design errors the protocol level errors. So I just uh recap it uh and ask the question is it all crap? And yeah I have to say it uh pretty much is uh it is possible to uh create uh secure and connection. But you have to purchase your own uh network key from dynastream. You can't use uh and plus so you won't be able to interoperate with uh other and plus devices. And also you have to use uh fairly recent ant chips. So uh moving on to uh implementation errors. I'm going to show you uh implementation errors in Garmin devices uh simply because I have those Garmin devices because of mountain biking. So I don't have anything against Garmin. I just use their stuff. Okay uh the first authentication method was uh the pass through mode. And I've uh assumed that it is only used for uh testing or something like that. But of course I've implemented it uh in a little proof of concept script called hackant.py. And I've tried it uh with both my Garmin uh free 10xt and with my Vivo fit uh and it worked. So it means that you can uh access all the files on these devices without any authentication. We're just using the pass through mode. Uh I'm showing showing you this by downloading the directory structure uh from a Vivo fit using this pass through mode. And uh yeah it succeeded. Uh if this was not enough there's another mode uh with you can access uh I assume all Garmin devices. I could access uh every Garmin devices I've tried with this. Uh and it works like uh this. Mmm. And I am sorry. Okay so uh I just confused the uh slides. Okay uh so uh there's a feature called uh OTA firmware updates. There are lots and lots of uh devices that uh don't even have any other uh communication um method and end. So firmware updates have to be done via end. Uh the firmware update method is uh pretty well documented by by dine stream. But of course Garmin does not use this method. So I've started to uh reverse engineer the Garmin Express services to learn how it actually works. But I've got distracted. I've got distracted by these two uh methods. The first being compute factory part uh device pass key. And the other being has factory part device pass key. I've assumed that uh they are using these for uh bundled uh devices so you you can uh buy uh watch and heart rate monitor together and they are factory uh paired. So you don't have to do that. But of course I've implemented uh this compute factory part device pass key method in hack and dot by two. And I've tried it with the Frit and XT and Vivo FIT. And it worked in both cases. So it basically computes a pass key from the device's serial number and uses it for connection. The serial number as I've shown you earlier can be uh obtained by uh posing as a host. And we are posing as a host because we are trying to uh download files from a client. And it worked. Uh you can see that uh here's the uh device ID, the serial number, and the computed pass key. So this is another method to access uh Garmin devices. Uh one more thing about it. This uh is that you uh don't have to pose as a host to get the serial number uh because they are printed on the device itself and also on the packaging. So you can just walk into bus buy write down a lot of uh serial numbers and then hack the devices later. Okay so I've started talking about uh over the firmware updates. Uh and uh it works like this with uh Garmin uh gadgets. The firmware updates are uh RGN files, which uh which are so called region wrapped uh firmware files. They have to be unwrapped and these unwrapped firmware file has to be uploaded to the NTFS directory uh to the first index of the NTFS directory. Uh it's that simple. Of course I've tried to uh upload uh firmware's that are modified but at first I did not succeed. So uh it was clear that there is some uh firmware checking algorithm. And uh in the VivoFit firmware I found uh two CRC 16 tables and two CRC 16 functions. But it turned out that uh these were not used for uh firmware integrity checking. But finding them was uh still useful. And I loved this about hacking that uh there's a lot of scenarios where you go down one row uh one row and you expect some result. Uh and you don't get that result but what you get is still useful. So what, what was useful about this is uh these functions used direct addresses uh to the uh CRC 16 tables which made it possible to deduce uh on what address the firmware is actually loaded in memory. So it was useful for me. But the actual uh firmware integrity checking algorithm was much much simpler than CRC 16. Uh it was uh there's just a requirement that the sum of all bytes have to be zero. It's fairly easy to calculate. So I've also uh implemented this feature in Hackant.py. And I show you this by upgrading the VivoFit firmware after slightly modifying it. So first uh unwrapping the uh firmware file uh modifying it uh I'm just gonna replace the string sleep with uh another string uh hacked. Okay saving the file uh fixing the CRC and uh uploading uh it to the device using Hackant.py. Uploading it to the first index as a device file type. And uh as you can see uh in the case of the VivoFit it actually requires uh user interaction because uh the ant protocol stack is uh off by default uh for the reason of preserving battery. But uh you can do this with the free Tanax T and uh it requires no user interaction. I'm using the VivoFit for this demo because it's uh much simpler device and much cheaper device so it's uh not that much pain if I uh break it somehow. Okay so the firmware update succeeded and uh now we try to enter sleep mode and it should display hacked instead of sleep. And yeah it does. So thanks. Thanks. Oh. Stop, stop, stop. Okay so it was uh uh very little modification but uh you can imagine that uh there's a lot of stuff that can be done uh with this. Okay I have one other thing to uh show you. Uh and it it is not strictly ant related but I found this issue while doing this research. Uh in the VivoFit firmware I have found an XMS string uh which kinda looked like uh some kind of device descriptor file. And I've tried to reverse engineer the Garmin Connect uh Android application to see uh what this file is. And I have found some functions that download this file and process this file uh um from the device. A few years ago I've reported uh some XXC vulnerabilities to Garmin. At least I try to report them. Uh got no response. So the first thought was that maybe this is XXC able to. Uh I was thinking about uh uh attacking my phone via a modified firmware VivoFit using XXC. So I've just uh replaced the XML string with an XXC stub that uh uses a uh external parameter entity to connect back to one of my servers. Uh uploaded this firmware to the uh VivoFit and try to connect it to my phone. Okay. Uh and yeah it's uh I'm going to disappoint you guys here because I don't have a video or a live demo of this. I just had the have these uh uh screenshots but the important thing is that uh when I try to uh connect my VivoFit to my uh mobile phone, a connection came to my server. But the connection did not came from my mobile phone. It was not my IP address but uh after looking it up it was a Garmin IP address. So what's happened is the mobile phone downloaded the XML file from the uh VivoFit and uh sent it to directly without any modifications to a Garmin service. And the Garmin service was susceptible to XXC. Uh and you can see it's even Java so you can uh do directory listings and stuff like that. And I think it's uh really complicated but it's a really nice way to find uh a vulnerability like this in a major renders uh internet accessible services. Okay so um this was the last thing I uh wanted to show you guys. Uh small summary and it's bad. Uh I'm using it because I I I have these devices but it's really easy to sniff, really easy to uh man in the middle. The security features are not really security features. They they are fairly easy to circumvent. Uh so it is really easy to steal your track data, your settings data, all your files uh that are on these devices. Uh or even it is even possible to update to replace uh the firmware on your device without your knowledge uh remotely. Okay so uh if you have uh any questions you can contact me in uh these channels and the uh scripts and uh tools I've mentioned that I have written uh will be available on my github uh later today. Uh thank you very much for uh listening to this talk. Bye bye.