1 00:00:13,735 --> 00:00:19,410 Herald Angel: This talk is going to be doping your Fitbit. It's gonna be held by 2 00:00:19,410 --> 00:00:27,260 jiska and daniel. In case you have been to any of the smaller CCC events in the past, 3 00:00:27,260 --> 00:00:33,399 I think 3 maybe 4 years, you might know jiska from the, that you're usually where 4 00:00:33,399 --> 00:00:39,120 there is sewing machines. And actually double plus for both of them, because for 5 00:00:39,120 --> 00:00:42,870 daniel it's actually the second shift today as a speaker, which by itself 6 00:00:42,870 --> 00:00:53,600 probably is stressful. Getting back to the smaller events. On the MRMCD this year 7 00:00:53,600 --> 00:00:56,690 they had sort of the first session on the same topic, so if you missed that you 8 00:00:56,690 --> 00:01:01,159 might want to check out the recording of this. There they spoke about decoding the 9 00:01:01,159 --> 00:01:06,310 messages. This time they're gonna talk about the actual firmware of the fitbits. 10 00:01:06,310 --> 00:01:13,969 And with that I give the stage to you. *applause* 11 00:01:13,969 --> 00:01:23,450 DanielAW: Thank you. jiska: Welcome to our talk on doping your 12 00:01:23,450 --> 00:01:27,770 fitbit. We will show you how to modify the firmware so that you don't have to 13 00:01:27,770 --> 00:01:32,000 anything but, well no sports as every nerd... 14 00:01:32,000 --> 00:01:36,500 *laughter* j: Our motivation was when we started 15 00:01:36,500 --> 00:01:43,859 taking fitness trackers, that most of them are not encrypting locally. So you will 16 00:01:43,859 --> 00:01:50,789 always have a chance to get the data from users, which is not nice for privacy. And 17 00:01:50,789 --> 00:01:55,630 most apps require that you upload your data into the cloud. So that's again bad 18 00:01:55,630 --> 00:02:02,710 for privacy. If you look at fitbit they are one of the market leaders, so that's 19 00:02:02,710 --> 00:02:06,920 one thing why we hacked them. And the other thing is that when we compared 20 00:02:06,920 --> 00:02:13,510 vendors, that they had quite reasonable security, which is similar to many IoT 21 00:02:13,510 --> 00:02:19,470 systems. So, what we show today will apply to other systems too. And their security 22 00:02:19,470 --> 00:02:26,450 model is nice, but requires sharing you data to them. So, take the security, but 23 00:02:26,450 --> 00:02:32,091 get your data would be a nice thing. So therefore we hacked them. I will first 24 00:02:32,091 --> 00:02:37,940 explain how the system works in general, which messages are exchanged, and then go 25 00:02:37,940 --> 00:02:46,340 to more technical details.The trackers have a key installed which is symmetric 26 00:02:46,340 --> 00:02:51,791 and it's enrolled during factory rollout. So, it's already on the tracker when you 27 00:02:51,791 --> 00:02:57,800 buy it. And it's used for end-to-end encryption with the server. So, the system 28 00:02:57,800 --> 00:03:02,350 is as secure as end-to-end encryption. As soon as you have a flaw of course no 29 00:03:02,350 --> 00:03:08,600 longer, but that's the idea. And the tracker only has Bluetooth LE, so you need 30 00:03:08,600 --> 00:03:12,480 the smartphone application which is forwarding the traffic. The local 31 00:03:12,480 --> 00:03:18,090 connection is now very secure, but it doesn't matter that much because of the 32 00:03:18,090 --> 00:03:21,780 end-to-end encryption. And now the thing is, can we break the end-to-end 33 00:03:21,780 --> 00:03:28,250 encryption? Well, yes we can. The end-to- end encryption is only used for the recent 34 00:03:28,250 --> 00:03:33,020 trackers, so models before 2015 were not always using encryption and we could look 35 00:03:33,020 --> 00:03:39,300 a bit into the protocol. And there has been a memory readout attack which was not 36 00:03:39,300 --> 00:03:43,990 patched for trackers until recently. So if you buy a tracker now you have a good 37 00:03:43,990 --> 00:03:49,060 chance that you didn't patch the software so far yourself or someone else didn't do 38 00:03:49,060 --> 00:03:56,700 it so far and you can do memory readout. And all these things are somewhat 39 00:03:56,700 --> 00:04:01,820 encryption flaws or connected to encryption. And I'm now going to show you how you 40 00:04:01,820 --> 00:04:09,230 can now break the encryption on the tracker and get your data. If you have the 41 00:04:09,230 --> 00:04:14,080 original smartphone app and a tracker, you have two steps in the beginning. So you 42 00:04:14,080 --> 00:04:19,230 log in into the app, which is, if you make you own app, is not necessarily required 43 00:04:19,230 --> 00:04:24,590 and you do some local pairing, which anyone can do with a tracker. 44 00:04:24,590 --> 00:04:29,000 And then there's an interesting part, which is remote association, and in this 45 00:04:29,000 --> 00:04:32,910 remote association you prove that you are physically owning the tracker, for example 46 00:04:32,910 --> 00:04:39,680 by entering a PIN. And as soon as you have this proof you can get authentication 47 00:04:39,680 --> 00:04:44,960 credentials from the server and use these authentication credentials to run 48 00:04:44,960 --> 00:04:49,100 authenticated commands - and that's now the part that is getting interesting 49 00:04:49,100 --> 00:04:54,460 because these authenticated commands you can execute them as often as you want as 50 00:04:54,460 --> 00:04:58,880 soon as you have those authentication credentials and they are valid forever 51 00:04:58,880 --> 00:05:06,240 because they are bound to the device key. So, another question is first of all how 52 00:05:06,240 --> 00:05:12,160 you get these authentication credentials. And therefore you can associate your 53 00:05:12,160 --> 00:05:16,530 tracker; there are some flaws in it, so you need to prove that you are physically 54 00:05:16,530 --> 00:05:23,040 present, but well, how do you do this? I mean, the first part is of course if you 55 00:05:23,040 --> 00:05:30,010 have a display then you have a PIN. The PIN is displayed on the tracker, and then 56 00:05:30,010 --> 00:05:34,370 you have the smartphone app where you enter the PIN. The PIN is transferred from 57 00:05:34,370 --> 00:05:37,580 the tracker end-to-end encrypted to the server, you compare it on the server with 58 00:05:37,580 --> 00:05:42,220 the thing that you entered in the app. That's okay-ish, but then there are also 59 00:05:42,220 --> 00:05:46,090 those trackers that don't have a display - you just tap them and the tapping 60 00:05:46,090 --> 00:05:52,300 confirmation is a wireless frame which you can easily replay. And there is no 61 00:05:52,300 --> 00:05:57,960 confirmation of freshness of either of those, so you can replay any sniffed 62 00:05:57,960 --> 00:06:04,800 remote association process. And there are those old plain-text trackers and they 63 00:06:04,800 --> 00:06:10,180 have the serial number printed on the packing, and you can just use the serial 64 00:06:10,180 --> 00:06:17,260 number and craft a valid packet from this and do the association if you want. And 65 00:06:17,260 --> 00:06:21,360 since those association credentials are valid forever - well, you just use them as 66 00:06:21,360 --> 00:06:25,470 soon as you have them - you could even resell your tracker and use them again, 67 00:06:25,470 --> 00:06:31,490 and sniff someone else's data. The first thing that we used to break 68 00:06:31,490 --> 00:06:35,790 encryption is an authenticated memory readout. It was already found by Martin 69 00:06:35,790 --> 00:06:42,450 before on the Charge HR firmware. He compared, actually, a firmware update and 70 00:06:42,450 --> 00:06:49,240 found that they removed the command, and Fitbit didn't remove the command on the 71 00:06:49,240 --> 00:06:54,960 Fitbit One and Flex until October, so you could still use this memory readout on the 72 00:06:54,960 --> 00:07:01,010 older trackers and you could just enter any memory address and length and get all 73 00:07:01,010 --> 00:07:07,070 the data that is located at this address. This includes the encryption keys, so with 74 00:07:07,070 --> 00:07:12,940 this encryption key you can then fake any encrypted packet to the tracker or from 75 00:07:12,940 --> 00:07:19,610 the tracker including the dumps which contain the activity data or even 76 00:07:19,610 --> 00:07:25,490 firmware. And then you might ask yourself - well, 77 00:07:25,490 --> 00:07:29,440 why did they do this, the memory readout? Obviously this was not patched, but they 78 00:07:29,440 --> 00:07:35,010 still have authentication and you need authentication for so-called live mode, 79 00:07:35,010 --> 00:07:40,370 for example if you have a heart rate sensor on the Fitbit, then you don't want 80 00:07:40,370 --> 00:07:44,750 to send each time your current heartrate to the server, let the server decrypt your 81 00:07:44,750 --> 00:07:48,690 heartrate, and so on because then it would lag a lot and you would have a high load 82 00:07:48,690 --> 00:07:56,090 on the server. So what they did was more where you can do some strange closing of 83 00:07:56,090 --> 00:07:59,729 airlink, enable some other Bluetooth handles, so it's a bit hidden, so nobody 84 00:07:59,729 --> 00:08:05,070 didn't find it so far, and then you get a very nice thing, which is this live data. 85 00:08:05,070 --> 00:08:12,080 And it is not encrypted and it's a summary of your current data. So, two things about 86 00:08:12,080 --> 00:08:16,340 this - first of all, you can sniff it, it's plain text, everyone could sniff it. 87 00:08:16,340 --> 00:08:22,870 And everyone having authentication credentials can enable it. And, well, 88 00:08:22,870 --> 00:08:27,801 Fitbit fixed this on their last Firmware update in the sense of that you can 89 00:08:27,801 --> 00:08:32,948 disable the live mode if you wish to, but you can still use it on any tracker where 90 00:08:32,948 --> 00:08:43,029 you didn't disable it manually and it's present in the most recent Ionic smartwatch. 91 00:08:43,029 --> 00:08:46,520 Now Daniel is going to tell you more about the firmware and hardware access. 92 00:08:46,520 --> 00:08:48,727 D: Alright. Thank you. 93 00:08:48,727 --> 00:08:54,446 For or some of the stuff which we already told you, and also the dynamic debugging, we 94 00:08:54,446 --> 00:08:59,850 want to have some access to the actual hardware, so the tracker itself. 95 00:08:59,850 --> 00:09:07,850 But first of all let's look at some schematic on how the PCB is structured. So 96 00:09:07,850 --> 00:09:13,360 we have the main system on a chip, which is from STM in our case. Here it's based 97 00:09:13,360 --> 00:09:23,569 on an Cortex M3, and we also have of course BLE chip, which is used for communication 98 00:09:23,569 --> 00:09:28,660 with the smartphone app. And we also have an accelerometer which detects your steps. 99 00:09:28,660 --> 00:09:34,899 And everything is connected via bus. And most interestingly, we also know for some 100 00:09:34,899 --> 00:09:40,379 of the software which runs in the firmware, basically which library they 101 00:09:40,379 --> 00:09:45,320 used. So for example for encryption, we know that they use LibTomCrypt, and for 102 00:09:45,320 --> 00:09:50,379 BLE we at least know that the LibBLEShield is very similar to what they use in the 103 00:09:50,379 --> 00:09:57,589 firmware. So this really helped us in reverse engineering. So this is what the 104 00:09:57,589 --> 00:10:04,880 PCB looks like if you tear it apart and remove it from its casing basically. We 105 00:10:04,880 --> 00:10:12,129 already see that there are lots and lots of testing points, and now this time we 106 00:10:12,129 --> 00:10:19,304 figure out what testing points we need to connect the debugger. And so we figured 107 00:10:19,314 --> 00:10:25,569 out, or some other guys already figured out that you need those four. So, 108 00:10:25,569 --> 00:10:32,350 depending on what protocol you want to use for your debugger you need various amounts 109 00:10:32,350 --> 00:10:40,980 of testing pins, and herefore in our case we use SWD, so we just need four pins. 110 00:10:40,980 --> 00:10:46,850 Namely testing point 8, 9, 10, and then ground pin. And, so you can also see that 111 00:10:46,850 --> 00:10:52,569 we use just the ground pin from the battery which we removed previously, and 112 00:10:52,569 --> 00:10:58,129 on the right hand side is just the connector switch you can use to connect 113 00:10:58,129 --> 00:11:04,930 it, the Fitbit, to your power supply. And so with this we can already dump the 114 00:11:04,930 --> 00:11:10,459 firmware, and we can also modify the stored data. And now that we have the 115 00:11:10,459 --> 00:11:15,079 firmware, let's have a closer look into it. By the way, this on the right hand 116 00:11:15,079 --> 00:11:22,009 side is our test setup It may look kind of crude, but it worked. 117 00:11:22,009 --> 00:11:29,329 And, so yeah, the memory layout is basically split up in 3 parts. We have a 118 00:11:29,329 --> 00:11:34,160 flash which contains the firmware code, and EPROM which contains the data which 119 00:11:34,160 --> 00:11:39,119 should survive an empty battery, so for example your fitness data. And also an 120 00:11:39,119 --> 00:11:44,240 SRAM which is used for, or which provides some space for firmware variables. So if 121 00:11:44,240 --> 00:11:51,239 we look into the flash for example in a more detail, we see that there are 122 00:11:51,239 --> 00:12:01,009 actually 2 independent firmwares or stuff which runs on that. So we have a part 123 00:12:01,009 --> 00:12:05,851 which is called BSL, and a part which is called APP. And the reason for that is you 124 00:12:05,851 --> 00:12:10,350 always want to have some fail safe mode when you update the firmware. So jiska 125 00:12:10,350 --> 00:12:16,829 will talk about more this... about this in more depth, in later slides, but for now 126 00:12:16,829 --> 00:12:21,449 just keep in mind that there are two parts. And on the EPROM we have apart 127 00:12:21,449 --> 00:12:24,370 from this fitness data, we also have everything we need for encryption, so we 128 00:12:24,370 --> 00:12:28,379 have our serial number. We have an encryption key and we have even a switch 129 00:12:28,379 --> 00:12:34,629 which you can use to completely disable encryption. 130 00:12:34,629 --> 00:12:40,889 So what we also wanted to do is enabling GDB access, so to have dynamic debugging 131 00:12:40,889 --> 00:12:47,459 support. But we discovered this in case you set everything up and you connect GDB 132 00:12:47,459 --> 00:12:53,440 to it and then you hit run, your GDB connection will just reset after a certain 133 00:12:53,440 --> 00:12:58,679 point when the firmware boots up. And the problem is that the firmware actually 134 00:12:58,679 --> 00:13:04,379 disables these GPIO ports during the bootup. So it uses this for other stuff, 135 00:13:04,379 --> 00:13:09,489 which is bad for us. And so we decided, so what can we do to reenable them. Yeah, 136 00:13:09,489 --> 00:13:17,389 just we modify the firmware. And so in our group we already developed this nexmon 137 00:13:17,389 --> 00:13:23,920 framework which we use previously to binary patch some wifi firmwares, and now 138 00:13:23,920 --> 00:13:30,850 we just adapted it - [ironically:] just adapted it - for the Fitbit firmware. And now we are able 139 00:13:30,850 --> 00:13:38,149 to modify the firmware in any way we want, and of course we can just reset the GPIO 140 00:13:38,149 --> 00:13:45,799 pins after the bootup to be capable of debugging. So now we have basically GDB 141 00:13:45,799 --> 00:13:51,540 access, can set breakpoints and memory watchpoints. Which really helped us in 142 00:13:51,540 --> 00:13:55,860 reverse engineering. So now jiska will tell you more about 143 00:13:55,860 --> 00:14:00,850 wireless firmware flashing. j: You might have seen our nice setup with 144 00:14:00,850 --> 00:14:06,050 the open Fitbit, but it's quite hard to open a Fitbit. So it's not super hard, but 145 00:14:06,050 --> 00:14:10,529 it's hard to use it again after it's opened. So the idea is now to wirelessly 146 00:14:10,529 --> 00:14:14,579 flash your firmware, which needs some more reverse engineering in the firmware of 147 00:14:14,579 --> 00:14:22,550 this process, and then we were able to do it. The update process is a bit 148 00:14:22,550 --> 00:14:29,970 complicated, so in each activity data that you transmit to the server, you include 149 00:14:29,970 --> 00:14:34,509 the firmware version of the tracker. And the server then knows, well you have maybe 150 00:14:34,509 --> 00:14:39,860 an outdated firmware and in this case in the app there is shown that there is a new 151 00:14:39,860 --> 00:14:44,009 firmware update available. But it's not flashed onto the tracker until the user is 152 00:14:44,009 --> 00:14:52,259 actually tapping this update in the app. But, this is not really a security feature, so 153 00:14:52,259 --> 00:14:57,420 anyone could trigger a firmware update. It's not any user interaction required 154 00:14:57,420 --> 00:15:03,459 normally. As soon as the update is started you get a microdump from the tracker, 155 00:15:03,459 --> 00:15:08,389 which contains tracker metadata including the serial number and the firmware version 156 00:15:08,389 --> 00:15:12,279 once again, which is attached to a firmware request. And the firmware request 157 00:15:12,279 --> 00:15:18,399 is then being replied from the server and contains the BSL and APP firmware parts 158 00:15:18,399 --> 00:15:25,379 which Daniel just showed you. The firmware starts then with the BSL flashing. The BSL 159 00:15:25,379 --> 00:15:31,989 is first validated, then it's written to the flash and then you reboot into this 160 00:15:31,989 --> 00:15:37,779 BSL part. Same thing then for the APP part, which is again validated, written to 161 00:15:37,779 --> 00:15:41,910 flash, and then there's a reboot into the APP. And in the APP you have the normal 162 00:15:41,910 --> 00:15:50,009 functionality back again. This update format ensures that you are 163 00:15:50,009 --> 00:15:55,220 flashing the correct firmware in the correct order to the tracker. So each 164 00:15:55,220 --> 00:16:00,209 chunk in the firmware is starting in the actual tracker model. So each of them has 165 00:16:00,209 --> 00:16:04,199 this hex code depending on the tracker model. Then you have a chunk which is 166 00:16:04,199 --> 00:16:09,260 marked either as BSL, APP, or the reboot action. And depending on which of these 167 00:16:09,260 --> 00:16:15,881 actions you have either some zero bytes or the actual content. And you have also a 168 00:16:15,881 --> 00:16:25,480 size limit of something like 64 kilobytes, depending on the tracker. So you just need 169 00:16:25,480 --> 00:16:31,569 to attach these things together. So if you have an APP firmware update it contains 3 170 00:16:31,569 --> 00:16:39,160 chunks, then 1 empty chunk, and 1 reboot chunk. And all these chunks are attached 171 00:16:39,160 --> 00:16:45,329 to each other and then there's another header. The header's having the encryption 172 00:16:45,329 --> 00:16:52,160 options and if it's encrypted a nonce and the end has another CRC or if it's 173 00:16:52,160 --> 00:16:59,579 encrypted you have a CMAC tag. Now you would say - well, you discovered how the 174 00:16:59,579 --> 00:17:04,631 firmware update works and that's nice, but if you do it like this you will still get 175 00:17:04,631 --> 00:17:07,230 some errors. So, the address range is of course 176 00:17:07,230 --> 00:17:15,030 checked, you could pass this address range check if you would flash one more round 177 00:17:15,030 --> 00:17:21,760 and then disable this address range check. But okay, then you have a bitflip and CRC 178 00:17:21,760 --> 00:17:27,869 somewhere in the middle of the firmware, where you need to flip a bit, calculate 179 00:17:27,869 --> 00:17:32,430 another CRC, include it into the firmware, because otherwise the firmware that you 180 00:17:32,430 --> 00:17:39,510 flash will not boot and show you firmware version 0.0 in all activity dumps which is 181 00:17:39,510 --> 00:17:43,530 not that nice, so you cannot simply replace a string in the firmware for 182 00:17:43,530 --> 00:17:49,360 example without this being to happen. And now Daniel is going to tell you how 183 00:17:49,360 --> 00:17:57,899 the encryption on top of all this works. D: The problem is, so we now know how we 184 00:17:57,899 --> 00:18:06,250 do firmware encryption in plaintext mode, but most of the new trackers basically 185 00:18:06,250 --> 00:18:11,500 have encryption enabeled by default. So what we now need to do is to just build an 186 00:18:11,500 --> 00:18:19,050 encrypted firmware update. What do we need for that? Older models of the trackers use 187 00:18:19,050 --> 00:18:27,080 XTEA for encryption whereas newer models use AES. For this you need basically three 188 00:18:27,080 --> 00:18:34,409 things: 2 byte nonce which is contained in each and every dump you get, a 128 bit encryption 189 00:18:34,409 --> 00:18:39,940 key which you can get with the aforementioned memory readout attack and 190 00:18:39,940 --> 00:18:49,049 also an 8 byte MAC which you can just calculate. For this they use LibTomCrypt 191 00:18:49,049 --> 00:18:55,230 which is a C-library, which we told you before, but you can also use the 192 00:18:55,230 --> 00:19:01,130 spongycastle library which is in Java. This also contains every function you 193 00:19:01,130 --> 00:19:08,211 need. Now we know everything we need. We know how the communication works, we know 194 00:19:08,211 --> 00:19:14,041 how the firmware update is structured and we know how to encrypt it properly. Let's 195 00:19:14,041 --> 00:19:18,680 put it all together. Here are 6 steps which you need to do when 196 00:19:18,680 --> 00:19:28,480 you want to build your own modified Fitbit flags firmware. First you get your 197 00:19:28,480 --> 00:19:35,340 symmetric key, then you get a plaintext dump of your firmware binary. You transfer 198 00:19:35,340 --> 00:19:41,100 everything to a notebook or any PC basically which you can then use to run 199 00:19:41,100 --> 00:19:48,909 our nexmon framework and then you modify the firmware in any way we want. For the 200 00:19:48,909 --> 00:19:57,850 first and last two steps we have an Android app. You can see the URL and the source code 201 00:19:57,850 --> 00:20:03,580 above. And for the nexmon framework, the adapted version, we have also another repo. 202 00:20:03,580 --> 00:20:07,659 The last two steps are: transfer the 203 00:20:07,659 --> 00:20:11,620 firmware back to your smartphone, reencrypt it and flash your tracker with 204 00:20:11,620 --> 00:20:19,210 it. Of course we did this before and now we can show you a nice demo of what you 205 00:20:19,210 --> 00:20:25,690 can do with it. Of course you want to modify your fitness tracker in an 206 00:20:25,690 --> 00:20:32,660 interesting fashion. So for example we just modified it so that each and every 207 00:20:32,660 --> 00:20:45,330 step gets multiplied by 100. Here you can see: I shake the Fitbit and each shake 208 00:20:45,330 --> 00:20:54,909 creates 100 steps. *applause* 209 00:20:54,909 --> 00:21:00,360 And maybe it is good to say that this does not work with the latest firmware update. 210 00:21:00,360 --> 00:21:07,140 It says firmware update is necessary. But this is because we told them that this is 211 00:21:07,140 --> 00:21:17,620 wrong. So this October update which Jiska mentioned came out after our research. 212 00:21:26,870 --> 00:21:33,899 J: These modifications, you can apply them on a Fitbit 1, Flex or Charge HR. For the 213 00:21:33,899 --> 00:21:41,380 1 and Flex the firmware update is not that far ago so you have high chances to modify 214 00:21:41,380 --> 00:21:45,360 your tracker if you now buy one that is in original packing or if you just didn't 215 00:21:45,360 --> 00:21:51,910 update yours because it was lying around. For the live mode it is even nicer because 216 00:21:51,910 --> 00:21:56,169 live mode is there on all trackers so if you are happy with the data you get in 217 00:21:56,169 --> 00:22:00,669 live mode you can just disable the internet connection of your tracker and 218 00:22:00,669 --> 00:22:10,790 extract all your data with this. To sum up our task: Go out and flash your 219 00:22:10,790 --> 00:22:21,043 neighbor's device, keep control of your own data, and run any code on your Fitbit. 220 00:22:21,043 --> 00:22:27,191 *applause* 221 00:22:27,191 --> 00:22:49,000 subtitles created by c3subtitles.de in the year 2017. Join, and help us!