 This talk is going to be doping your Fitbit. It's going to be held by Ysger and by Daniel. In case you have been to any of these smaller CCC events in the past, I think, three, maybe four years, you might not discuss that you're usually visiting the assembly with the sewing machines. And actually, double the plus for both of them, because for Daniel, it's actually the second shift today as a speaker, which by itself probably is stressful. Yeah. And getting back to the smaller events, on the MRMCD this year, they had sort of the first session on the same topic, so if you missed that, you might want to check out the recording for this. There, they spoke about decoding the messages. This time, they're going to talk about the extra firmware of the Fitbits. With that, I give stage to you. Thank you. So welcome to our talk on doping your Fitbit. We will show you how to modify the firmware so that you don't have to do anything but, well, no sports as every nerd. Our motivation was when we started taking fitness trackers, that most of them are not encrypting locally. So you will always have a chance to get the data from users, which is not nice for privacy. And most apps require that you upload your data into the cloud. So that's, again, bad for privacy. If you look at Fitbit, they are one of the market leaders. So that's one thing why we hacked them. And the other thing is that when we compared vendors that they had quite reasonable security, which is similar to many IoT systems. So what we show today will apply to other systems too. And their security model is nice, but requires sharing your data to them. So take the security, but get your data would be a nice thing, and therefore we hacked them. I will first explain how the system works in general, which methods are exchanged, and then go to more technical details. The trackers have a key installed, which is symmetric. And it's enrolled during factory rollout. So it's already on the tracker when you buy it. And it's used for end-to-end encryption with the server. So the system is as secure as the end-to-end encryption as soon as you have a flaw, of course, no longer. But that's the idea. And the tracker only has Bluetooth LE. So you need a smartphone application, which is forwarding the traffic. The local connection is not very secure, but it doesn't matter that much because of the end-to-end encryption. And now the thing is, can we break the end-to-end encryption? Well, yes, we can. The end-to-end encryption is only used for the recent trackers. So models before 2015 were not always using encryption, and we could look a bit into the protocol. And there has been a memory readout attack, which was not patched for trackers until recently. So if you buy a tracker now, you have a good chance that you didn't patch the firmware so far yourself or someone else didn't do it so far, and you can do memory readout. And all these things are somewhat encryption flaws or connected to encryption. And I'm now going to show you how you can now break the encryption on the tracker and get your data. If you have the original smartphone app and the tracker, you have two steps in the beginning. You log in into the app, which is, if you make your own app, it's not necessarily required. And you do some local pairing, which anyone can do with a tracker. And then there is an interesting part, which is a remote association. And in this remote association, you prove that you are physically owning the tracker, for example, by entering a pin. And as soon as you have this proof, you can get authentication credentials from the server and use these authentication credentials to run authenticated commands. And that's now the part that is getting interesting, because these authenticated commands, you can execute them as often as you want, as soon as you have those authentication credentials. And they are valid forever because they are bound to the device key. So now the question is, first of all, how you get these authentication credentials. And therefore, you can associate your tracker. There are some flaws in it, so you need to prove that you're physically present. But well, how do you do this? I mean, the first part is, of course, if you have a display, then you have a pin. The pin is displayed on the tracker. And then you have the smartphone app where you enter the pin. The pin is transferred from the tracker, enter in the crypto server. You compare it on the server with the thing that you entered in the app. That's OK-ish, but then there are also those trackers which don't have a display. You just tap them, and the tapping confirmation is a wireless frame, which you can easily replay. And there is no confirmation of freshness of either of those. So you can just replay any sniffed remote association process. And then there are those old plain text trackers, and they had the serial number being printed on the packing. And you can just use the serial number and craft a valid packet from this and do the association if you want. And since those authentication credentials are valid forever, well, you just use them as soon as you have them. You could even resell your tracker and use them again and sniff someone else's data. The first thing that we used to break encryption is an authenticated memory readout, which was already found by Martin before on the ChargeHR firmware. He compared, actually, a firmware update and found that they removed the command. And Fitbit didn't remove the command on the Fitbit 1 and Flex until October. So you could still use this memory readout on the older trackers. And you can just enter any memory address and length, and then you get all the data which is located at this address. This includes the encryption key. So with this encryption key, you can then take any encrypted packet to the tracker or from the tracker, including the dumps which contain your activity data or even firmware. And then you might ask yourself, well, why did they do this? So the memory readout, obviously, this was not patched, but they still have authentication. And you need authentication for a so-called live mode. For example, if you have a hard rate sensor on the Fitbit, then you don't want to send each time your current hard rate to the server, let the server decrypt the hard rate, and so on, because then it would lag a lot and you would have a high load on the server. So what they did was a mode where you can do some strange closing of AirLink, enable some other Bluetooth handles. So it's a bit hidden, so nobody didn't find it so far. And then you get a very nice thing, which is this live data. And it is not encrypted. And it's a summary of your current data. So two things about this. First of all, you can sniff it. It's plain text. Everyone could sniff it. And everyone having authentication credentials can enable it. And, well, Fitbit fixed this on their last firmware update in the sense of that you can disable the live mode if you wish to, but you can still use it on any tracker where you didn't. Disable it manually, and it's even there present in the most recent Ionic smartwatch. Now, Daniel is going to tell you more about the firmware and hardware access. All right. Thank you. For some of the stuff which we already told you and also for dynamic debugging, we want to have some access to the actual hardware, so the tracker itself. But first of all, let's look at some schematic on how the PCP is structured. So we have the main system on the chip, which is from STM in our case. Here it is based on Cortex M3. And we also have, of course, on BLE chip, which is used for the communication with the smartphone app. And we also have an accelerometer, which detects your steps. And everything is connected via bus. And most interestingly, we also know for some of the software which runs in the firmware basically which library they use. So for example, for encryption, we know that they used LipTomCrypt. And for BLE, we at least know that the LipBLE shield is very similar to what they used in the firmware. So this really helped us in reverse engineering. So this is what the PCB looks like if you tear it apart and remove it from its casing, basically. We already see that there are lots and lots of testing points. And now it is time to figure out, basically, what testing points do we need to connect the debugger. And so we figured out, or some other guys already figured out, that you need those four. So depending on what protocol you want to use for your debugger, you need various amounts of testing pins. And here for in our case, we use SWD. So we just need four pins, namely testing point eight, nine, 10, and then ground pin. And so you can also see that we use just a ground pin from the battery which we removed previously. And on the right-hand side is just the connectors which you can use to connect it to your power supply. And so with this, we already can dump the firmware. And we also can modify the stored data. So now that we have the firmware, so let's have a closer look into it. By the way, this is on the right-hand side is our test setup. It may look some kind of crude, but it worked. And so yeah, the memory layout is basically split up in three parts. We have a flash, which contains the firmware code. An eProm, which contains the data which should survive an empty battery. So for example, your fitness data. And also an SRM, which is used for or which provides some space for firmware variables. So if we look into the flash, for example, in a more detail, we see that there are actually two independent firmwares or stuff which runs on that. So you have a part which is called BSL, and you have a part which is called app. And the reason for that is you always want to have some fail-safe mode when you update the firmware. So Yiska will talk about this in depth in later slides, but for now, just keep in mind that there are two parts. And on the eProm, we have, apart from this fitness data, we also have everything we need for encryption. So we have our serial number. We have an encryption key. And we have even a switch which you can use to completely disable encryption. So what we also wanted to do is enabling GDB access, so to have dynamic debugging support. But what we discovered is in case you set everything up and you connect GDB to it, and then you hit Run, your GDB connection will just reset after a certain point when the firmware puts up. And the problem is that the firmware actually disables these GPIO ports during the boot up. So it uses this for other stuff, which is bad for us. And so we decided, so what can we do to re-enable them? Just we modified the firmware. And so in our group, we already developed this next month framework, which we used previously to binary patch some Wi-Fi firmware. And now we just adapted it for the fit bit firmware. And now we are able to modify the firmware any way we want. And of course, we can just reset the GPIO pins after the boot up to be capable of debugging. So now we have basically GDB access can set breakpoints and memory watch points, which really helped us by in reverse engineering. So now Yiskar will tell you more about wireless firmware flashing. You might have seen our nice setup with the open fit bit, but it's quite hard to open a fit bit. So I mean, it's not super hard, but it's hard to use it again after it's open. And the idea is now to wirelessly flash your firmware, which needs some more reverse engineering in the firmware of this process. And then we were able to do it. The update process is a bit complicated. So in each activity data that you transmit to the server, you include your firmware version of the tracker. And the server then knows, well, you have maybe an outdated firmware. And in this case, in the app, there is shown that there is a new firmware update available. But it is not flashed onto the tracker until the user is actually tapping this update in the app. But this is not really a security feature. So anyone could trigger a firmware update. It's not any user interaction required normally. As soon as the update is started, you get a microdump from the tracker, which contains tracker metadata, including the serial number and the firmware version once again, which is attached to a firmware request. And the firmware request is then being replied from the server and contains the BSL and app firmware parts that Daniel just showed you. The firmware starts then with the BSL flashing. The BSL is first validated. Then it's written to the flash. And then you reboot into this BSL part. Same thing then for the app part, which is again validated, written to flash. And then there's a reboot into the app. And with the app, you have the normal functionality back again. This update format ensures that you are flashing the correct firmware in the correct order to the tracker. So each chunk of the firmware is starting with the actual tracker model. So each of them has this hex code, depending on the tracker model. Then you have a chunk, which is marked either as BSL, app, or the reboot action. And depending on which of these actions, you have either some zero bytes or the actual content. And you have also a size limit of something like 64 kilobytes, depending on the tracker. So you just need to attach these things together. So if you have an app firmware update, it contains three chunks, then one empty chunk and one reboot chunk. And all these chunks are attached to each other. And then there is another header. The header is having the encryption options. And if it's encrypted, announce. And the end has another CAC. Or if it's encrypted, you have a CMAC tag. Now you would say, well, you discovered how the firmware update works. And that's nice. But if you do it like this, you will still get some errors. So the address range is, of course, checked. You could pass this address range check if you would flash one more round and then disable this address range check. But OK. And then you have a bit flip and CRC somewhere in the middle of the firmware where you need to flip a bit, calculate another CRC, include it into the firmware. Because otherwise, the firmware that you flash will not boot and show your firmware version 0.0 in all activity dumps, which is not that nice. So you cannot simply replace a string in the firmware, for example, without this being to happen. And now Daniel is going to tell you how the encryption on top of all this works. Yep. So the problem is, so we now know how we do firmware encryption in plain text mode. But most of the newer trackers already come in by, so basically have encryption enabled by default. So what we now need to do is just build an encrypted firmware update. So what do we need for that? So trackers as older models of the trackers use XTIS for encryption, where newer models use AES. And you also need, and for this, you need basically three things, two byte nonce, which is contained in each and every dump you get. And 128-bit encryption key, which you can get with the aforementioned memory readout tag, and also an 8-byte MAC, which you can just calculate. And for this, they basically use the Loptim lib tomcrypt, which is a C library, which we already told you before. But you can also use the spongy castle library, which is written in Java. And this also contains every function you need. So now we know basically everything we need. We need, we know how the communication works. We know how the firmware update is structured. And we know how to encrypt it properly. So let's put it all together. So here are six steps which you need to do when you want to basically build your own modified Fitbit Flex firmware. And so you first get basically your symmetric key. Then you get a plaintext dump of your firmware binary. Then you would transfer everything to a notebook, which you then, or any PC, basically, which you can then use to run our next one framework. And then you modify the firmware in any way we want. And then you, so for these first two steps and for the last two steps, we have an Android app for that. You can see the URL and the source code above. And for the next one framework for adapted version, we have also another repo. And then the last two steps are basically transfer the firmware back to your smartphone, re-encrypted, and flash your tracker with it. So of course we did this before. And now we can show you a nice demo of what you can do with it. So of course you want to modify your fitness tracker in an interesting fashion. So for example, we just modified it here so that each and every step gets multiplied by 100. And so here you can see, I shake the Fitbit. And each shake creates 100 steps. And maybe it's good to say. So this does not work with the latest firmware update. You can see the firmware update is necessary. But this is because we told them that this is wrong. So this October update, which Jiska mentioned, was basically came out after our research. OK. So these modifications, you can apply them on a Fitbit One Flex or change charge HR. And for the One Flex, the firmware update is not that far ago. So you have high chances to modify your tracker if you now buy one that is an original packing, or if you just didn't update yours because it was lying around. For the live mode, it's even nicer because live mode is there on all trackers. So if you're happy with the data that you get in live mode, you can just disable the internet connection of your tracker and extract all your data with this. So to sum up our talk, go out and flash your neighbor's device, keep control of your own data. That's, of course, what you want to do, and run any code on your Fitbit.