00:00:00.000,00:00:04.538 >>So we're coming down to the end. We haven't had any kind of internet of things talks in this 00:00:04.538,00:00:09.610 track before so I'm kind of excited to hear about this. Uh we're gonna hear about um 00:00:09.610,00:00:13.614 speedometers. Right? >>Sorry? >>We're gonna talk about speedometers and and things that 00:00:13.614,00:00:17.518 you can put on to your onto your put on put onto your bike. This is gonna be really cool. Um 00:00:17.518,00:00:23.924 let's give speaker uh give our next speaker a big round of applause. [applause] Have a good 00:00:23.924,00:00:28.929 time. [applause] >>Thank you [applause] Hi everybody. Thank you for being here on a Sunday 00:00:31.231,00:00:36.236 afternoon. Uh I'm Tom, I'm from Hungary and I work for a small IT security company as a pen 00:00:39.139,00:00:45.746 tester developer to a company called PRAudit. Uh I'm regular speaker at uh Hacktivity central 00:00:45.746,00:00:51.551 Europe's biggest hacker convention. And I also gave a talk uh about uh insecure games 00:00:51.551,00:00:56.556 scripting engines last year here at Defcon. So the title of my talk is Help I've Got ANTS! What 00:01:00.560,00:01:07.234 are we doing with ants? Uh last year I've targeted one of my hobbies. Uh flight simulators so 00:01:07.234,00:01:12.472 I thought it would be appropriate to uh target one of my other hobbies this year, 00:01:12.472,00:01:17.477 mountain biking and [coughs] sorry uh and uh while creating this slide I just realized that 00:01:19.780,00:01:26.286 all of my hobbies includes crashing. [laughter] Uh, so moutain biking, computer 00:01:26.286,00:01:31.191 security, flight simulators, and recently drones. There's a lot of crashing there I didn't know 00:01:31.191,00:01:36.196 'bout this. [laughs] Okay so so mountain biking and ants uh what what does what what do ant have 00:01:42.235,00:01:47.574 to do with mountain biking? Uh there's lots of uh a gadgets there's uh lots of equipments uh 00:01:47.574,00:01:53.547 involved in sports involved in mountain biking and in cycling in general and uh old school 00:01:53.547,00:01:59.987 speedometers got replaced by powerful folic powerful computers. Computers that talk 00:01:59.987,00:02:04.992 to various sensors uh like speed sensors, uh power meters heart rate monitors etc. etc. and also 00:02:07.661,00:02:12.666 uh talk to uh mobile phones or even your PC and here is where ant came in the picture because 00:02:15.736,00:02:20.741 uh ant is a protocol uh that these devices speak. Uh it is not just used by uh sports 00:02:26.313,00:02:31.318 equipment but uh weight scales, bluh blood pressure monitors or eh there are even there is even 00:02:33.487,00:02:38.492 a jet application that uses it to create mesh network on Android it's called Firechat. So 00:02:41.495,00:02:46.500 in this talk uh I will uh introduce you to ant, ant plus and the interface protocols and 00:02:48.535,00:02:55.175 I show you some uh protocol level uh designers and uh after that some implementation errors 00:02:55.175,00:03:00.113 in various Garmin devices. So uh ant. Ant is a wireless protocol created by Dynastream and uh it 00:03:05.752,00:03:10.757 is designed for low powered devices. Uh you can create uh any kind of network topologies 00:03:12.926,00:03:18.765 and the participants are called nodes. There are slave and master nodes uh and these nodes 00:03:18.765,00:03:23.770 uh com communicating via a mutually es established channels. Uh channels are 00:03:26.273,00:03:31.278 defined by lots and lots of uh properties like uh frequency uh or mm da channel ID but the most 00:03:37.617,00:03:43.723 important for us uh from a security standpoint is the network ID because it contains 00:03:43.723,00:03:48.728 an 8 byte uh long number called network key. Which according to Dynastream is a security 00:03:52.466,00:03:59.339 measure. It's a security measure because uh only nodes with the same network key can communicate 00:03:59.339,00:04:04.277 with each other. It sounds good but there are some problems. Uh network keys are matched uh by 00:04:07.280,00:04:13.854 Dynastream and if you want your uh want want a network key for yourself then you have to uh 00:04:13.854,00:04:18.859 purchase one from Dynastream uh and if you use an invalid network stree uh network key uh 00:04:22.295,00:04:28.068 then the protocol stack will just default to the public key which is uh public. You can 00:04:28.068,00:04:33.073 download this from uh Dynastreams uh webpage. There's another problem with the network 00:04:35.142,00:04:40.147 key uh it is being that uh the maturity of devices that use Ant actually use uh Ant Plus or Ant 00:04:43.316,00:04:48.321 FS and uh these 2 protocols have their own uh network key uh and these network keys are also 00:04:51.691,00:04:58.098 public they can also be downloaded from Dynastream. So it's uh not much of a security 00:04:58.098,00:05:03.036 measure because everybody everybody knows those keys. Okay other security measures in Ant 00:05:06.540,00:05:12.679 there's a pattern bit uh it works like this 2 nodes can communicate with each other only 00:05:12.679,00:05:18.952 if the pattern bit uh is the same for the 2 nodes. So it does not have to be on it just have 00:05:18.952,00:05:23.957 to be the same on on 2 nodes uh this fairly easy to circumvent because you can open 2 channels. 00:05:25.959,00:05:31.464 One with the pattern bit off and the other with the pattern bit on and one of these channels 00:05:31.464,00:05:36.469 will succeed. I have first uh notice that there's something uh fishy with this uh pattern bit 00:05:39.873,00:05:46.613 when I came home from a mountain bike trip and realized that that uh there are some heart rate uh 00:05:46.613,00:05:51.618 data on my charts uh despite I don't have a heart rate monitor so [laughs] It must've picked up 00:05:54.688,00:06:00.193 picked it up from another cycling store or something like that. Okay I'm gonna show you 00:06:00.193,00:06:05.198 how easy it is to spoof uh and sensor data. I'm just gonna uh set up my uh Freedom XD to use a 00:06:13.139,00:06:18.144 power meter and I'm gonna use uh Simulant Plus which is a software released by Dynastream 00:06:22.282,00:06:27.287 to simulate a power sensor. Just creating the power sensor, setting sensor uh data, value 00:06:35.195,00:06:40.200 that it will transmit. Turn it on and the watch will just pick up that signal and display uh 00:06:43.303,00:06:48.308 that value and ya it did so uh without any pairing it is this simple to spoof uh and sensor 00:06:51.211,00:06:56.216 data. Okay back to uh Ant security measures uh there are these things called inclusion 00:07:05.492,00:07:10.497 exclusion list and uh white black list they are um essentially the same. Uh one for 00:07:12.699,00:07:17.704 the slave nodes one the other for the uh master nodes. Mmm they could be useful but there's 00:07:20.807,00:07:27.681 a problem with them they are uh only available on fairly recent Ant chips so uh none of my 00:07:27.681,00:07:32.686 Garmin devices uh can use these features. Okay another security measure uh Ant channels can be 00:07:36.756,00:07:41.761 encrypted with uh A uh AES-CTR but there are some problems with this too. Uh you can't use them 00:07:45.999,00:07:51.004 with shared channels uh which makes it uh harder to implement uh sss uh implemented to to have 00:07:56.209,00:08:01.147 for example one by computer with uh multiple sensors and also uh it requires advanced burst data 00:08:04.651,00:08:09.723 mode which is highly energy inefficient and it's kind of problem with low energy devices 00:08:09.723,00:08:15.195 so uh these are problems but these have uh another bigger problem too. Uh encryption can't 00:08:15.195,00:08:17.197 be used with Ant Plus. Uh if you use encryption then you are not uh Ant Plus compliant and you 00:08:17.197,00:08:22.202 can't interoperate with other uh Ant Plus devices. Okay so I've mentioned uh this Ant Plus uh 00:08:35.648,00:08:40.653 several times already but I did not tell you uh what it is. It's a protocol built on top of Ant 00:08:43.857,00:08:49.963 and it's basically just a specified soak specifies uh so-called device profiles. So 00:08:49.963,00:08:54.968 that's a device profile for uh speed sensors a device profile for uh heart rate monitors and 00:08:57.170,00:09:02.108 so on and so on. Uh these device profiles are uh managed by Dynastream and they basically uh 00:09:04.744,00:09:10.650 just govern some characteristics of the Ant connection like uh frequency, channel period, and 00:09:10.650,00:09:15.655 data format. Uh a few example of uh these device profiles this is uh bicycle rear view radar that 00:09:20.093,00:09:26.466 uses the radar and uh light device profiles. The dropper seat post that uses the seat 00:09:26.466,00:09:31.471 post device profile uh bicycle headlight obviously the light profile and the blood pressure 00:09:33.940,00:09:38.945 monitor uh that uses the blood pressure device profile. Okay one of these device profiles uh 00:09:41.981,00:09:46.986 is called Sync and the it allows you to uh collect and transfer uh sensor data in the form of 00:09:50.924,00:09:55.929 FIT files. So FIT uh is basically a file system uh mm yep a file system. Recent file 00:10:01.000,00:10:06.005 file system file format for uh Ant FS. Uh the file side is fairly simple they have a 14 00:10:08.274,00:10:13.279 bytes uh header some data records and the 2 byte CRC and all data records have their own 00:10:15.381,00:10:20.386 uh records header it's a 1 byte header and some records content. It it can be anything really so 00:10:24.290,00:10:29.295 uh they store mm recorded tracks your settings your name etc in in these uh FIT files. The 00:10:33.199,00:10:38.204 reason I'm talking about uh FIT files is that my first attempt to uh hack my Freedom XD was to 00:10:40.940,00:10:45.945 uh try to find some memory corruption uh vulnerabilities in the firmware and I did it by uh 00:10:49.215,00:10:54.220 fuzzing the FIT STK with AFL and uh I did uh get some crashes. But they all seemed uh non 00:10:59.125,00:11:04.063 exploitable. I've tried to upload them uh to my Freedom XD nevertheless because I was 00:11:06.499,00:11:11.504 hoping for some uh crash dams or crash locks or some useful information but I did not get uh 00:11:13.773,00:11:18.778 either so I I got nothing uh the watch did not crash and uh this got me thinking uh not this uh 00:11:23.917,00:11:28.922 the Ant protocol stack became unavailable for a few minutes and that got me think thinking 00:11:31.324,00:11:37.564 that maybe the Ant protocol study Ant FS protocol stack is implemented uh in the Ant chip 00:11:37.564,00:11:42.569 and not in the uh actual Garmin firmware. So I have to uh explore this further uh it might 00:11:49.342,00:11:54.347 be interesting. Okay back to Ant FS uh according to Dynastream Ant FS is a secure and reliable 00:11:59.152,00:12:04.090 file transfer protocol built on top of Ant. Uh if you Google Garmin plus Ant then you will uh 00:12:07.193,00:12:12.198 find some uh rants on various forums about how reliable this stuff is and I do question the 00:12:15.335,00:12:20.340 security. Uh there are 2 major security features according to Dynastream. One is the built in 00:12:23.810,00:12:28.815 encryption uh so you can encrypt uh your files and they are also encrypted uh while on the app. 00:12:31.751,00:12:36.756 It sounds nice but I've seen some Ant FS implementations but I did not see anyone that uses 00:12:40.393,00:12:45.398 uh this encryption feature. The other security uh measure in Ant FS is that it employs uh 00:12:50.803,00:12:57.810 multiple authentication mechanisms. We'll see about them. There are 3 uh 00:12:57.810,00:13:02.749 authentication mechanisms. The first being the pass-through mode. It's not really an 00:13:02.749,00:13:08.588 authentication mechanisms because it works like this. The host just asks the client if it 00:13:08.588,00:13:13.593 can connect and the client just says yes why not. So uh no information needed to to 00:13:15.595,00:13:20.600 connect. I dunno uh why they did implement this maybe some uh maybe for some testing purposes 00:13:23.302,00:13:28.307 but the important thing is that it is there and uh you can use it. The second uh authentication 00:13:32.311,00:13:37.316 mechanism is uh called pairing mode. Uh don't confuse this with the Ant uh pairing beat. It's an 00:13:39.952,00:13:46.726 entirely different uh concept. Uh it requires user interaction. Uh the host sends a serial 00:13:46.726,00:13:53.299 number and a friendly name to the client. The client device displays this information uh to 00:13:53.299,00:13:59.972 the user and the user can uh decide if she accepts the connection or not. If the user 00:13:59.972,00:14:06.879 accepts the connection uh then a pass key is sent from the client to the host. The host stores 00:14:06.879,00:14:11.884 this pass key and uses it for any further connections so this pairing has to be uh only once. 00:14:15.021,00:14:20.026 Okay what wrong with pairing mode? Uh obviously if you are a malicious host then you can send 00:14:22.395,00:14:29.102 any serial numbers or any friendly names to a client so you can maybe get the user to 00:14:29.102,00:14:34.107 accept the connection. Uh this is one one way to attack pairing mode. The other is that uh after 00:14:37.443,00:14:42.448 successful pairing the pass key is sent from client to host and it can be sniffed. How do we 00:14:45.852,00:14:50.857 sniff Ant? Uh [coughs] the Ant chips that the maturity of these devices use are NRF24AP1 and AP2 00:14:54.827,00:14:59.832 and uh these are based on the very well known NRF24 uh 0 1 plus chips so they work in the 2 00:15:02.835,00:15:07.840 point 4 Euro sized armband. They have a one megabits per second oom uh on our data rate. They 00:15:10.276,00:15:15.281 use a GFS key uh modulation but the actual package form it is not really clear from the 00:15:17.316,00:15:23.322 documentations. One of the papers mentioned uh enhanced shockburst so I just went with 00:15:23.322,00:15:28.327 that but I only had an RTL-SDR which is not capable of uh sniffing 2 point 4 gigahertz but 00:15:33.132,00:15:38.137 uh luckily I found this uh blog post where this guy sniffs uh NRF 24 uh 0 1 packets with uh an 00:15:42.175,00:15:47.180 RTL-SDR and MMDS down converter. So I uh ordered an MMDS down con converter uh set this all up and 00:15:51.884,00:15:56.889 tried to decode RTL FM output as enhanced shockburst packets. It seemed to almost work but every 00:16:00.493,00:16:04.263 byte was the double of the ex expected. So 8 of their their uh [inaudible word] and the user 00:16:04.263,00:16:06.265 brand new highly sophisticated encryption algorithm will decrypt uh well they just uh 00:16:06.265,00:16:11.270 multiply the plain text with 2. Uh I've seen some pretty dumb shit from developers but this 00:16:19.679,00:16:25.184 would have been a bit much for stretch so I just went with another idea that the 00:16:25.184,00:16:32.058 documentation slide and the the packet formities not really enhanced short burst. Uh I 00:16:32.058,00:16:36.596 started reading about uh enhanced short burst and uh surprise surprise it turned out 00:16:36.596,00:16:41.601 that [cough] there is a shock burst protocol. The 2 uh the difference between the 2 uh is a 00:16:43.903,00:16:48.908 9 bit field call called uh package control field. Uh and it's being 9 bits so it can 00:16:53.079,00:16:58.084 happen that if you try to interpret a shock burst packet as an enhanced shockburst packet 00:17:02.188,00:17:07.193 that there is 1 bit left shift which is uh multiplying with 2. So uh it seemed a reasonable uh 00:17:11.564,00:17:16.569 solution so I've uh implemented shock burst decoding. I've implemented it as a C uh program 00:17:20.373,00:17:25.378 and uh reacher outputs mmm hacks sparse and I've also written an anteater sot py which interprets 00:17:28.014,00:17:33.019 this uh hack sparse S and FS packets Um this worked nice nicely uh as a proof of concept 00:17:36.088,00:17:41.894 but I wanted something uh cleaner so I've implemented these uh functionalities in a 00:17:41.894,00:17:46.899 Pothosware FS 2 Pothosware blocks. Uh if you don't know Pothosware it's uh very similar 00:17:49.135,00:17:54.140 too uh a new radio com companion I just uh like to use it more. Okay I have a video but this 00:17:58.678,00:18:03.616 too. So this is the hardware, the MMDS down converter, the RTL-SDR and I'm using a virtual 00:18:06.519,00:18:13.025 machine with 2 Ant USB sticks here. Uh one for the Ant FS host and the other for the Ant FS 00:18:13.025,00:18:19.832 client so there will be a host and a client on the same machine and they will talk to each other 00:18:19.832,00:18:24.837 and we are going to sniff them uh using these pothos uh blocks. Ya its starting uh so this one 00:18:29.308,00:18:34.313 is the shock burst decoder and the an Ant FS uh decoder. I'm opening the uh client channel uh 00:18:44.090,00:18:49.095 the client beacons. We can already see the client beacons and I will just try to search uh 00:18:52.865,00:18:57.870 for the client and the host and uh when the host finds the client uh it sends a link 00:19:02.441,00:19:07.446 command which changes the uh communication frequency uh and this is why this uh feedback 00:19:11.684,00:19:16.689 from the Ant FS decoder to the SDR sources there uh so it can change the uh SDR sources 00:19:21.160,00:19:26.165 frequency. Okay uh there are some serial number request uh responses some more beacons and 00:19:28.501,00:19:33.506 when we try to download the directory uh listing its also file uh theres download request 00:19:37.510,00:19:42.515 response packet and uh this is actually the uh directory listing it's not uh yet parsed 00:19:46.152,00:19:51.157 and this is where my uh USB stick failed me uh it did not uh like all those data. Okay so 00:20:03.235,00:20:08.240 we've talked uh about 2 uh authentication mechanisms so far. Uh the last one is the pass 00:20:11.644,00:20:16.649 key mode. Uh pass keys are up to 255 bytes long uh so brute forcing them is uh impractical 00:20:20.986,00:20:25.991 but uh as I've told you earlier uh after successful pairing the host remembers the pass key uh 00:20:28.561,00:20:35.334 and the pass keys are stored in a directory structure so uh there's a client serial number 00:20:35.334,00:20:41.874 and the corresponding uh um passkey another serial number another pass key and so on and 00:20:41.874,00:20:46.879 so on. And when the the host encounters a client with no serial then it tries to uh 00:20:52.051,00:20:57.056 authenticate uh read the storage passkey. This whole process could be uh man in the middled 00:20:59.525,00:21:04.463 uh by first posing uh as Ant FS host uh acquiring the client serial number then spoofing the 00:21:08.200,00:21:13.205 serial number acting as client uh the host here sent us the passkey and we can then use this 00:21:16.108,00:21:21.113 passkey to authenticate to the client. Uh I've tried to use Ant FS PC tools for this uh and I've 00:21:26.218,00:21:31.223 expected to sss to to find the passkey in the debug logs but the actual pass key algorithm 00:21:33.359,00:21:38.364 made it impossible because the host checks the uh pass key length uh and if it does not 00:21:42.134,00:21:48.307 match the stored uh length then it aborts the authentication process. But since uh we are the 00:21:48.307,00:21:53.312 host in step 2 uh we can patch these uh functionality uh and and and still get the pass key. 00:21:59.852,00:22:04.790 I found out that uh the Ant uh Wrapped Lib dot DLL contains the code pass uh for for this 00:22:07.393,00:22:12.398 functionality. I've almost uh started to binary patch it but notice just in time that uh uh 00:22:16.135,00:22:23.075 Dynastream actually released the source code so I just have to modify the C code and recompile 00:22:23.075,00:22:28.080 the DLL to do this attack. So as first stop we are going to uh pose as a host and get the 00:22:37.623,00:22:42.628 client's serial number. I'm just setting up some things here okay. And uh I've also use used 00:22:49.635,00:22:54.640 my Freedom XD for this. The host is searching for the client and we should get the client 00:22:58.477,00:23:03.415 information soon. Ya it's not the uh not the fastest protocol but we ya we've we've got the uh 00:23:09.388,00:23:14.393 the right ID which will be needed. So with that device ID we can start an interface PC 00:23:18.297,00:23:23.302 client and impersonate that client. Okay I'm just skipping some parts. Yep so uh started 00:23:34.847,00:23:39.852 the client and I'm starting Garmin Express on my other computer uh where this uh 00:23:42.121,00:23:47.126 Freedom XT's already registered and because the Garmin Express thinks that this interface PC 00:23:50.062,00:23:55.067 client is this watch uh it will send the pass key to it and we can see it in the the back logs. 00:23:59.738,00:24:04.677 Okay opening the log files and uh these lines with uh starting with HCK mm those are the all 00:24:17.256,00:24:22.795 patched in uh stuff there's the pass key length and the pass key itself and now we can use that 00:24:22.795,00:24:27.800 pass key uh to authenticate to the watch and download the files from it. Uh ya I'm just a copy 00:24:34.640,00:24:39.645 pasting that pass key and starting the uh channel starting searching for the client and uh 00:24:52.758,00:24:57.763 you can see that uh there is no user interaction on the client side. This pass key it succeeded 00:25:04.069,00:25:09.575 and we can download the directory structure uh without uh any user interaction from the 00:25:09.575,00:25:14.580 client side. So this how uh this man in the middle attack works. Okay so uh this was the part 00:25:26.392,00:25:31.397 about the uh design RO's the protocol level RO's so I I just uh recap it uh and ask the 00:25:35.100,00:25:40.105 question is it all crap and ya I have to say it uh pretty much is. Uh it is possible to uh 00:25:42.608,00:25:47.613 create a secure end connection but you have to purchase your own uh network key from 00:25:49.715,00:25:56.188 Dynastream. You can't use uh Ant Plus so you won't be able to interoperate with uh other Ant 00:25:56.188,00:26:01.126 Plus devices. And also you have to use uh fairly recent Ant chips. So uh moving on to uh 00:26:05.964,00:26:12.070 implementation errors. I'm going to show you uh implementation errors in Garmin devices uh 00:26:12.070,00:26:18.477 simply because I have those mm Garmin devices because of mountain biking so. I don't have 00:26:18.477,00:26:23.482 anything against Garmin, I just use their stuff. Okay uh the first authentication method was 00:26:29.621,00:26:34.626 uh the pass through mode and I've uh assumed that it is only used for uh testing or something 00:26:38.130,00:26:43.135 like that but of course I've implemented it uh in a little proof of concept script called 00:26:47.272,00:26:52.277 hack ant dot buy and I've tried it uh with both my Garmin uh Freedom XD and with my Vivofit 00:26:54.413,00:26:59.418 uh and it worked. So it means that you can uh access all the files on these devices without 00:27:05.457,00:27:12.231 any authentication with just using the pass through mode. Uh I'm showing showing you this by 00:27:12.231,00:27:17.236 downloading the directory structure uh from a Vivofit using this pass through mode and 00:27:21.373,00:27:26.378 uh ya it succeeded. Okay uh sorry. Uh if this is not enough there's an other mode uh which 00:27:39.958,00:27:44.963 you can access uh I assume all Garmin devices. I could access uh every Garmin devices I've 00:27:47.099,00:27:49.101 tried with this uh and it works like uh this mm I'm sorry. Okay so [laughs] uh I've just 00:28:08.053,00:28:13.058 confused the uh slides. Okay uh so uh there's a feature called uh OTA firmware updates. There 00:28:15.994,00:28:20.999 are lots and lots of uh devices that uh don't even have any other uh communication mm method 00:28:24.670,00:28:29.675 with an Ant. So firmware updates have to be done via Ant uh the firmware updates matter with 00:28:32.244,00:28:38.383 these uh pretty well documented by the by Dynastream but of course Garmin does not use these 00:28:38.383,00:28:43.388 method so I've started to uh reverse engineer the Garmin express services to learn how it 00:28:46.124,00:28:51.129 actually works but I've got distracted. I've got distracted by these 2 uh methods. The first 00:28:54.132,00:28:59.471 being compute factory paired uh device passkey and the other being house factory paired 00:28:59.471,00:29:04.409 device passkey. I've assumed that uh they are using these for uh bundled uh devices so you you 00:29:06.945,00:29:11.950 can uh buy a watch and heart rate monitor together and they are factory uh paired so you 00:29:15.020,00:29:21.793 don't have to do that. But of course I've implemented uh this compute factory paired device 00:29:21.793,00:29:26.798 passkey method in hack ant dot py 2 and I've tried it with the Freedom XT and Vivofit and it 00:29:29.601,00:29:34.606 worked in both cases. So it basically computes a pass key from the device's serial number 00:29:41.880,00:29:46.885 and uses it for connection. The serial number as I've shown you earlier can be uh obtained by uh 00:29:51.823,00:29:58.664 posing as a host and we are posing as a host because we are trying to uhh download files 00:29:58.664,00:30:03.669 from a client and it worked. Uh you can see that uh here's the uh device ID the serial number 00:30:07.673,00:30:12.678 and the computed passkey. So this is another method through access uh Garmin devices. Uh one 00:30:21.687,00:30:26.692 more thing about it this uh is that you uh don't have to pose as a host to get the serial 00:30:29.494,00:30:35.567 number uh because they are uh printed on the device itself and also on the packaging so you can 00:30:35.567,00:30:40.572 just walk into Best Buy write down lot of uh serial numbers and then hack the devices later. 00:30:43.508,00:30:48.513 So. Okay so I've started talking about uh over the our firmware update uh and uh it works like 00:30:52.951,00:30:57.956 this with uh Garmin uh gadgets. The firmware updates are uh RGN files with uh which are uh 00:31:01.359,00:31:06.364 so-called region wrapped uh firmware files. They have to be unwrapped and these unwrapped 00:31:08.667,00:31:15.240 firmware file has to be uploaded to the interface directory uh to the first index of the interface 00:31:15.240,00:31:20.245 directory uh it's that simple. Of Course I've tried to uh upload uh firmwares that arent 00:31:24.416,00:31:29.421 modified but first I did not succeed. So uh it was clear that there is some uh firmware 00:31:33.225,00:31:39.231 checking algorithm and uh in the Vivofit firmware I found uh 2 CRC16 tables and 2 CRC16 00:31:39.231,00:31:43.435 functions. But it turned out that uh these were not used for uh firmware integrity checking 00:31:43.435,00:31:48.440 but finding them was uh still useful. And I love this about hacking that uh there there's a 00:31:58.817,00:32:05.524 lot of scenarios where you go down one road uh one road and you expect some result uh and 00:32:05.524,00:32:10.529 you don't get that result but what you get is still useful. So what what was useful about this 00:32:12.831,00:32:17.836 is uh these functions used direct addresses uh to the uh CRC16 tables which made it 00:32:20.438,00:32:25.443 possible to deduce uh on what address the firmware is actually loaded in memory. So it was 00:32:29.881,00:32:34.886 useful for me but the actual uh firmware integrity checking algorithm was much more simple 00:32:38.757,00:32:43.762 than CRC16. Uh it was the there's just a requirement that the sum of all bytes have to be 00:32:50.368,00:32:55.373 0. It's fairly easy to calculate. So I've also uh implemented this feature uh here 00:33:00.378,00:33:05.383 in Hack Ants dot 5 and I show you this by upgrading the Vivofit firmware after slightly 00:33:09.054,00:33:14.059 modifying it. So first uh unwrapping the uh firmware file uh modifying it. Uh I'm just 00:33:20.165,00:33:25.170 gonna replace the string sleep with uh another string uh hacked. Okay saving the file uh 00:33:33.612,00:33:38.617 fixing the CRC and uh uploading uh it to the device using hack ant dot 5. Uploading it to the 00:33:45.223,00:33:50.228 first index as a device file type and uh as you can see uh in the case of the Vivofit it 00:33:57.569,00:34:04.342 actually requires a user interaction because uh [clears throat] the ant protocol stack 00:34:04.342,00:34:09.347 is uh off by default uh for the reason of preserving battery but you can do this with the Freedom 00:34:13.018,00:34:18.023 XT and uh it requires no user interaction. I'm using the Vevo Fit for this demo because it's 00:34:20.025,00:34:25.030 uh a much simpler device and a much cheaper device so uh it's not that much pain if I uh break 00:34:28.266,00:34:33.271 it somehow. Okay so the firmware update succeeded and uh now we try to enter a sleep mode and it 00:34:40.312,00:34:45.317 should display hacked instead of sleep. And ya it does. [laugher] So [applause] thanks thanks 00:34:54.426,00:34:59.431 [applause] oh stop stop stop. Okay so it was a a very little modification but uh you can 00:35:03.368,00:35:08.373 imagine that uh there's a lot of stuff that can be done uh with this. Okay I have one other 00:35:12.711,00:35:17.716 thing to uh show you uh and it's it is not uh strictly Ant related but I found this issue 00:35:21.953,00:35:26.958 while doing this research. Uh in the Vivofit firmware I have found an XML string uh which 00:35:30.028,00:35:35.033 kinda looks like uh some kind of device descriptor file and I've tried to reverse engineer the 00:35:39.137,00:35:44.142 Garmin connect uh Android application to see see uh what this file is and I have found 00:35:46.811,00:35:51.816 some functions that download this file and process this file uh eh from the device. A few 00:35:57.288,00:36:02.227 years ago I've reported uh some XXC vulnerabilities to Garmin at least I tried to report them. I 00:36:05.363,00:36:10.368 got no response so the first thought was that maybe this is XXC able to uh I was thinking 00:36:13.605,00:36:18.610 about uh uh attacking my phone via a modified firmware Vevo fit using XXC. So I've just uh 00:36:24.315,00:36:29.320 replaced the XML string with an XXC stab that uh uses a uh external parameter entity to 00:36:34.459,00:36:39.464 connect back to one of my servers uh uploaded this firmware to the uh Vevo Fit and 00:36:42.901,00:36:47.906 tried to connect it to my phone. K uh and ya it's uh I I I'm going to disappoint you guys 00:36:51.576,00:36:56.581 here because I don't have a video or a live demo of this. I just had the have these uh uh 00:36:59.350,00:37:04.289 screenshots but the important thing is that uh when I tried to uh connect my Vivofit to my uh 00:37:09.994,00:37:14.999 mobile phone the connection came to my server but the connection did not came from my mobile 00:37:17.135,00:37:23.808 phone. It was not my IP address but uh after looking it up it was a Garmin IP address. 00:37:23.808,00:37:28.813 [laughter] so what's happened is the mobile phone downloaded the XML file from the uh Vevo Fit 00:37:31.182,00:37:36.187 and uh sent it directly without any modifications to a Garmin service and the Garmin service 00:37:38.756,00:37:43.761 was susceptible to XXC. uh and you can see it even java so you you can uh do direct release 00:37:47.098,00:37:52.837 things and stuff like that and the I think it's a really complicated but really nice way 00:37:52.837,00:37:57.842 to find uh a vulnerability like this in in a major endorsed uh internet accessible services. 00:38:03.181,00:38:08.186 Okay so this was the last thing I uh wanted to show you guys. A small summary Ant is bad uh I'm 00:38:13.291,00:38:20.131 using it because I I'm I have these devices but it's really easy to sniff really easy to uh 00:38:20.131,00:38:26.337 man in the middle. The security features are not really security features. They they are fairly 00:38:26.337,00:38:31.342 easy to circumvent uh so it is really easy to steal your track data your settings data or your 00:38:35.246,00:38:40.251 files uh that are on these devices. Or or even it is even possible to update to replace uh 00:38:42.954,00:38:47.959 the firmware on your device without your knowledge uh remotely. Okay so uh if you have 00:38:51.596,00:38:56.601 uh any questions you can contact me in uh these channels and the uh scripts and the tools I've 00:39:00.972,00:39:05.977 mentioned that I have written uh will be available on my my Github uh later today. Uh thank 00:39:09.480,00:39:14.485 you very much for uh listening to this talk bye bye. [applause]