 Good. Okay. Welcome to our talk. The main part is a repetition of what we did at Congress, but we have some additions and some more technical details. And the important part is we have a workshop afterwards. So if you want to bring your own Fitbit or if you want to hack one of those that we brought, this is going to be a session that is much more interactive than at Congress. So the motivation. When publishing our first paper, we had some stuff in the press where they said, well, you can hack Fitbits. And so the fun part was dear hackers, please update my Fitbit so that I can run 10K every day and you can see my weight either way. So people want to have those stats and they don't want to do any sports. And I mean, it's quite good to have those stats. I mean, you can even get some points at your health insurance and so on. And in Germany right now, so better have some good stats somewhere. And the question is how to produce them. So if you look at the system of Fitbit, they have end-to-end encryption. So every tracker has a key that is rolled out in factory and you cannot really access it except from opening the hardware. And the same key is on the server. So it looks quite nice. And you have on top the limitation, so the tracker itself, it just has Bluetooth. So it cannot directly talk to the server, but you have an app that is relaying the traffic but not modifying. So even for the Bluetooth connection, it's not really secure. It doesn't really matter. It's just end-to-end encrypted. And they did a lot of things right. So this end-to-end encryption, so in the old trackers, it's some exterior encryption, but the new trackers, they have AES encryption and they use an IV and everything. So they do things properly. If you use the hardware, the standard configuration is that during boot, the debug interfaces are disabled, so you cannot see anything in the debugger. And it's almost impossible to break your tracker during the up-to-date process because it's separated in BSL and AppPyde and you boot into one or the other. So it seems to be a very solid system, even though we found some things, of course. And during responsible disclosure, they have a complete security team that is really responding fast. They gave us back a list of the things that they understood and said, like, how severe is it and so on. So they really have a good process for this. But yeah, we found something, so far it might not be that good. So when we started, we didn't have any clue what is happening. So I mean, you can see some stuff in Bluetooth, but it's still a bit strange. So we started dissecting the smartphone app. The smartphone app itself is quite nice because if you can modify it, then you can easily see how the protocol works and confirm your protocol assumptions. So you just say, there's some authentication and I want to exchange something in there and you don't need to understand the complete workflow or web API or something. And you can start this by enabling some debug flag. Then you will also have a nice output in your ADB lock hat. So you will just see every step, every function that is called, all debug messages and see what is happening in there. And from that, you get the class names and then you can modify all the things that you want. I don't know if it still works for the most recent app, but yeah, like some weeks ago it was still working for the app that was back then out there. So you can just modify it and confirm everything or modify everything. And then we found out if you have this debug or developer options, then some more options appear in the menu under the help, whatever thing. And you can configure additional settings. And those settings are quite nice. So some of them were pretty useful when we did our dissecting of the protocol. For example, you can enable a proxy server, which we just used for men in the middle because that's much easier than you don't see the traffic of all the other things happening on your smartphone, just the Fitbit app. And then we found out you don't even need to recompile the app for this because there is some configuration settings in the files. So you can just run even an unmodified app and change those settings. Yeah, so far it still seems kind of good. I mean, you can just modify and sniff things, but there's encryption. So to actually break something, you need to check the encryption flaws or if encryption is working properly. So if you look into the program flow, you have a very special pairing process, so it's not using some standard Bluetooth pairing, but you just connect to a tracker and then you do a special pairing that seems to be a standard Bluetooth pairing. So you see on your displays normally some code that is displayed and that you need to copy. So that's the third step. So after just connecting, you have this copying of the pin on your tracker and so on. And this is sent to the server and the server verifies the pin, actually. So it's an end-to-end authentication and association with the tracker. And by this, you prove that you own the tracker physically. So you can only know the pin if you have the tracker itself and see the pin on the display. And then the server has some special stuff, so the server can give you back something that is called authentication credentials. And those authentication credentials are stored in the app and the app can then do some special actions, which are authenticated commands. So the special actions you will see later, because we need to use them for some funny stuff. So the thing is that this is not really secure. So there's those old Fitbit Flex that don't have a display and they don't have a pin that they display. So you can just pretend that you tapped the display by sending a local command, for example. And even on the newer trackers, so if they operate and play text and you didn't update them properly, you can exchange, of course, the pin or replace stuff. And so it's somewhat secure. So on the newest trackers, it is so to say secure because there's the encryption and so on. But on older trackers, don't trust this too much. And now the fun part is if you have authentic credentials, you just get them once from the app or from overhearing some other pairing or something like this, they stay valid forever because they are bound to the encryption key that is stored on the tracker. So you cannot exchange something there. So forever valid authentication credentials is the big flaw here. And then you can have fun. So the fun part, the first part is you have some authenticated memory readout in the app. You just send a command after authentication, and you say, please give me all memory contents from here until there. If the range is somewhat invalid, like too long or something, then it stops putting out data at a certain point. But until then, it just replies everything that is there. And you can read out all memory parts. So you can read out the eProm or the flash that is, then you're going to explain later. And with this, so the fun part is you can even read out this encryption key. So authentication key means on those trackers that are vulnerable to this, that you also have the encryption key later. And then you can do things without the server at all. So just do everything the server does because you can do encryption. And then there is something that even works on the newest Ionic smartwatch with the authentication credentials because you can do something that is called live mode. So normally, if you have data on the tracker, you have the problem that you need to transfer it down to the server. The server is decrypting everything and so on. So if you have something like hard rate data, it would really take long to see the hard rate life. And it would also cause a very high load on the server. So what they do instead is this live mode that is plain text and just has authentication before and then so you close the standard session, open a new session and then you see this live data. So this contains a timestamp, the distance traveled, the step calories and also the hard rate. My timestamp is a Unix timestamp in second. So it's just the data in this specific second. You don't get statistics that were collected by the smartwatch or a tracker or something. You just get the average data or the data of this specific timestamp. But you can get things without the server that's at least something. So if you don't want to use the server at all and establish a Bluetooth connection and run live mode all the time, you could use your smartwatch without the server. Okay, now this is all a bit limited. So we started with the hardware access, which is now Daniel's part. Yep, so what Jessica told us up until now was mainly the part about the app and what the app talks about with the server. So ended the Bluetooth connection, of course. But to have a complete picture of how the system works, we also need to look into the firmware of the tracker itself. So this is a broad overview what is inside the Fitbit Flex. So we have the main system on a chip. So it's an ST microcontroller here and it's in Cortex M3. And of course, there's also the Bluetooth chip and the accelerometer. So, and apart from this, so we also know a few libraries they used in the firmware. We don't know the operating system they used, but we've, for example, we know that they use LipTomcript for the encryption stuff. And we also know that they use some kind of library which is very similar to this LipBLE Shield library, which are just, and both of them are just freely available on the internet. And with this knowledge, you can really improve your reverse engineering or at least it gets easier. So the next step is that we took apart the Fitbit. And so this is what comes out. Ours looked a bit better. So here the guy from iFixit broke some antenna stuff over here, but it's a very nice picture. And for us, the most interesting thing was the SWD protocol. So with SWD, you have full access to the microcontroller and also the complete memory. So if you want to know what's inside the firmware, we want to get SWD access. And for SWD, we need essentially three ports. So TP89 and 10 mainly. TP10 is for resetting the Fitbit, but this is not really necessary, but really handy to have. And for ground, we can just use the ground pin from the battery. And also, if you want to power the whole thing, you can just use the default connectors for the Fitbit. So with this, we are able to dump the complete firmware and we are also able to see what data is actually stored inside your firmware or inside your Fitbit flex. Also important to note, we will talk here about the Fitbit one. So this hardware is about the Fitbit one. So in case you download the firmware from the tracker, so this is our setup, so it looks kind of crude, but it worked for us. And I also have it on the workshop place. So if you want to see it, I think it still works. And yeah, right. The firmware consists of mainly three parts. So a flash, an EEPROM and an SRAM. The flash contains the firmware code, of course, and the EEPROM is used to store values which should survive on an empty battery. And the SRAM is used for the firmware variables. If we have a closer look into the firmware, we will see that the flash contains of two main parts, which Jescar mentioned earlier. And so this BSL part consists of about 500 functions and the app part of about 1,000 functions. And they use these kind, these two partitions, so you can call them partitions, to always have something which is still capable of booting in case something goes wrong during flashing. And of course, both can run independently from each other. So this was the flash regarding the EEPROM. This contains everything which is necessary for encryption. So your serial number, the encryption key, there's a metric key which we saw earlier and also an encryption switch which you can just use to completely disable encryption. But then the Fitbit will not talk with the serve anymore. This is another story. And also your fitness data, of course. So what we also wanted to do, so Jescar told you that the debug access is disabled by default. This is right, but the thing is, right after resetting the Fitbit, you can access via the debugger, the Fitbit, and download, for example, the whole flash. This is no problem. But if you want to have, for example, GDB access, so to have the possibility to also act rate points or memory watchdogs, you can, this is not possible. So what happens is that you start your debugger, you connect it to the Fitbit after reset, and then you hit continue and the software runs. And after a certain point in time during execution, the GPIO ports got reconfigured to something else. So this means that your connection to your debugger gets disconnected. And so we thought about what can we do about that? And from a previous project, we also had, have this next month framework. And this allows you to binary patch arbitrary code basically. So especially is this good for ARM code. And what we did is to, so with the flash, with the debugger, we can read and write arbitrary flash, but we can not do live debugging. So what we did is to read the whole firmware, patch it and write it back. So just to enable these GPIO ports. I'm also, I do not really know where they got disabled. I do not care, but I know up until a certain point in execution, okay, so now they are disabled. And then I just built a small patch with, which re-enables them. So when I connect, then with my patch firmware, my debugger, it connects and then after reset, then I hit continue. The firmware runs, I get quickly disconnected when the software hits the point in time where it reconfigures the GPIO ports and then my patch comes again and reconfigure it again to be able to debug. And so this works fine. And with this, we are able to have dynamic debugging, which is really handy if you want to do further, further reverse engineering. I can also show you this setup in our workshop if you want. So, okay. And now Yuske will tell you more about wireless hacking, firmware hacking. Yeah, so the fun part is if you have the firmware, then you can also obtain the firmware update process. So I had some assembler code, of course, but at least something to know how the firmware is flashed and then flash my own firmware wirelessly without opening a tracker. Because it's much easier if you have a closed tracker that does something special in addition, and then, but everything else just behaves normal if you want to fake data, for example. So if you look into the update process in every dump, there is a firmware version. So the server knows always which firmware version you are running on your Fitbit. And if there is an update, it just tells the user via the app that there is a new update. But the update process itself is always triggered by the user so you cannot, normally you should not be able to just trigger an update because the tracker needs to be charged and so on. So that this is ensured, you just updated yourself. So you just tell the tracker, well, I want you to update and the app also requests a firmware update from the server then and it just gets a binary and this binary is then flashed. The binary contains first the BSL part, the BSL part on the tracker itself is first validated by some steps and afterwards only flashed. So if you don't pass a certain amount of checks, it's not even going to be flashed. And in the end you reboot into the BSL and then from the BSL you flash the app which has the same steps and in the end you should just reboot into the app so you don't do this actively by the tracker does and everything should work then. So this is this failsafe part. If you break the BSL, you cannot reboot into the BSL but your app is still valid. So this is very stable compared to other possibilities that you normally have. But so we could do a lot of experiments without pricking the trackers that was very nice. Okay, so the update format, it's a bit complicated. First you have the tracker ID but only the first byte which means you cannot flash like something like a Fitbit 1 firmware onto a Fitbit Flex or something at least not if it's not on purpose. And then you select if it's the BSL or the app or if you want to reboot into app or BSL and if it's a BSL or app part then you also have the memory address, the length which is there twice, I don't know, a CRC and then the actual data. The data has an upper bound in size so you will normally just add multiple of them so if you have the app firmware then you have three data chunks or three of these, it's Flex, it's app, it's memory address, blah, blah, blah. And then you have one empty chunk to say it's finished and then one reboot chunk which is then rebooting this thing into the app. And this complete thing again has then header and the trailer. The header tells you if it's encrypted or not has again a length field for whatever reason of the firmware but also the frame has a length field here and the trailer itself either has again a CRC, I mean there's lots of CRCs in between here for the chunks but it also has a CRC again or if it is encrypted then you have this exterior encryption with Mac authentication code. So the firmware checks so if you would just draft the firmware from this, it would still not run so you get nice error messages but it will not be flashed so the additional checks are the address range must stay within BSL if it's a BSL update or within app if it's an app update so far so good. And then within the firmware they do somewhere flip a bit to zero and then they have a CRC that is not CRC itself but the rest of the firmware and then written somewhere. And if something fails in this process then all the dumps that you will get in the future from the tracker will have the version 0.0 in the dumps so you will just see okay the app or the BSL update failed and it has the version zero even though things in between were okayish but not okay enough. Yeah so if you modify the firmware so that it passes those checks you can just update the tracker but you also need to understand encryption so that's another part. If encryption is enabled on the tracker the tracker update must be encrypted and there has been some code by Martin Shavis but the code didn't contain the CMAC and if you don't have the CMAC in there you will get the error message that there's a missing trailer signature or something. So we have it's two byte nonce in each header. We use the encryption key and then importantly in the end we need to add this eight byte authentication MAC that's everything of this is in this EAX mode you can just use the liptom crypt and you will have it. And the encryption library that is used by the app this Spongy Castle or Bousy Castle libraries they also have all those functions so you don't need to think a lot you can just use the libraries that they already use and use some other calls. Yeah, so that's it. Then you have the encrypted firmware that you can flash and since this is all a bit complicated I mean I had some Python scripts running this and it worked for me and for my encryption key and for my tracker but we decided to publish a complete framework that is capable of doing all those things. Yep, so now we have basically everything to patch our own firmware so we can download the complete firmware we understand how it is composed so what we need to do to create a firmware update and we also know where the key is and how we can get it from the tracker. So what we build is the following on the right hand side is your tracker then this is a smartphone app which we vote by ourselves and a PC which runs our modified next one framework. So in the first step you would get the key from your tracker then get the plain text firmware transfer the firmware to your PC modify it with the next one framework and then basically transfer it back to our app and then again you can use the app to create a valid firmware update and also encrypt it and then you can also use the app to flash the modified firmware back on the tracker and for both the app and our modified next one framework everything is online on these two links these two links should also be available on the description of this talk and that's it you can arbitrarily modify the Fitbit firmware and this can look like this so this is a default Fitbit flex and this is the original Fitbit app and this is basically the firmware part which is not fixed yet so this is again I think at the beginning of October or something like that release the firmware update which fixes the problems which we told Fitbit right? Yeah, so that's the version 88 so 7.88 and I just downloaded it I had the encryption key because I mean it had an old firmware before so I just modified the 7.88 with the step counts by 100 and it has some funny side effects so you can, there's a reset pin for the tracker so that it's resetting even if it's in the original casing and if you reset the tracker then for some reasons the steps by 100 is applied two times and then you have something like the total steps count by 1000 and you can do this multiple times and then some counters also running over at some point but so after synchronizing my tracker the first time with the server I just got some funny emails like you have the New Zealand badge you just walk the whole distance of New Zealand and all these kind of things it was pretty funny because I really had like five emails like this special badges or something in my inbox like oh you ran 100k in one day and everything just at once yeah so that's, so if you have this patch and if you just reset the tracker so it has, in the charger it has a small hole where it just can, that you can press and then you have this reset and the super high steps don't do it too often because if it's more than two by 31 it just resets to zero again and then you need to count up again so there's integer overflow yeah yeah there's integer overflow okay so I guess we have fulfilled the wish of this comment in the very first slide yeah so there's more to come do you want to talk about it? yeah so we know roughly where the accelerator data is stored in the memory so we can just put this out in live mode which is pretty nice because you can just see the raw readings then the limitation is that it's, I mean it's just Bluetooth and the accelerator runs faster so it just gets a value every now and then and it's not as fast as the tracker of course but you could also process the data locally and then you could do things that the tracker does not do yet and another fun part is so for this modification it only increases the steps so you might notice that except from live mode so if it goes back from live mode to the normal mode and then back again into live mode it has this super high step count but the distance in miles is still accurate so you run like 100 meters or something with 10,000 steps so this is still something we should need to do and then also at congress there was a nice hacker that contacted us he's called Hugo and he he wrote some Python stuff around the Unicorn radar 2 framework and we can now also simulate the firmware or emulate the firmware and do some funny things so currently we started fuzzing frames into the Bluetooth stack and other things like this if you have some feature requests please tell us so that we know what to do or what to modify not just the 10k a day but we can do everything so there's some limitations so the problem is that you can only read out the encryption key on old trackers so don't update your firmware but if you buy a new one I just bought some weeks ago a brand new tracker it still had an old firmware version so no problem for me so if you just buy something new they didn't patch to ones that are in stock in whatever store and the live mode I mean it's still available for the Fitbit Ionic I don't know, they tell you that you can disable it somewhere I don't use the original app that often so maybe you can, I don't know they told us so in summary yeah go out and you can even flash your neighbors devices if they are still on plaintext no user interaction required actually you can keep control of your own data so if you interpret the dumps and so on and have the encryption key you don't need to transfer it to Fitbit anymore that's something where piles in the app are still missing to actually interpret the dumps so we roughly know how they work but we don't do it yet and you can also run any other code on your Fitbit like if you want to do I don't know, draw motions in the air and then do something in the app for example you could do this if you want to program that but okay and yeah then let's order some more trackers for the workshop yeah so this was the initial idea so we just ordered two of these packs so 44 of these broken fitness trackers and the idea was to just throw them into the people but yeah unfortunately they did not arrive in time which also means we now have 44 broken trackers in the next few days arriving yeah mine will arrive on Monday it says cool, two days yeah but there is always a next CCC event I guess yeah and also typically those broken trackers I mean we ordered some of them before so we have some trackers on our workshop don't worry, the battery is typically a bit broken but if you tear them down that's not a problem so it's still a very nice source for research debugging whatever or you're just a soldier in a new battery and reassemble, it's also possible okay any questions about what we presented, any feature requests, something that you want to do with your tracker that was not possible yet yeah oh sorry just a microphone arriving please repeat your questions for the recording my question was if somebody is working on an app replacement or feature for your app so you can use the tracker as a normal tracker without any interaction with the server or even an account yeah so for this authenticated commands you need an account once so that's what our current app does you log in and you then get the authentication credentials and then it's working without the server anymore currently this is just live mode not the normal dumps for the normal dumps I try to get some students working on this so I mean the new semester starts in two weeks and hopefully I will get students on this because I'm a bit limited in time but I would know how it works so I can tell you this is the format and this is roughly what you need to do I'm just if anybody wants to work on this and they don't find students you can also do this but there is currently no one working on this yeah but in two weeks probably I mean I plan to do this okay and the key you get from the server is what you also need for the encryption no it's an authentication key but with this authentication key you can get on all trackers the encryption key but they patched out the read memory commands so they can't do it and they know you are firmware yeah but if you buy a new one that is not talking to the server yet it works because the firmware update they are still shipped with this with the 64 or 81 firmware and not with the 88 so if it flex so how does the app get the key for the newer not at all we don't have so I mean maybe we will find some buffer overflow or something but we didn't find how does the app works then so how the update process works or what or does it work from the server if the app doesn't get the key anymore where does it get the key has never been on the official smartphone app it's always between the server and the okay yeah so this is not a standard feature thanks no more questions who wants to join the workshop yeah that's great because we have some to tear down if you want to tear down one and look into it you can just do this okay it's in the room C-ball that's if you walk this floor down and then cross the hex center and then walk up again okay thanks