Doping your Fitbit
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 167 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/34791 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
34th Chaos Communication Congress163 / 167
1
2
3
4
5
6
7
10
11
12
14
15
25
26
29
30
31
33
34
39
40
42
43
45
46
49
50
53
58
59
61
63
65
68
69
71
73
77
78
79
81
82
83
85
86
87
88
91
92
94
99
100
101
102
108
109
110
113
114
115
116
118
119
122
124
125
126
127
129
130
131
132
133
134
136
138
139
140
141
145
147
148
150
151
152
153
154
157
159
160
161
163
164
165
166
167
00:00
Mobile WebComputer networkComputerMiniDiscSound effectMessage passingEvent horizonVirtual machineShift operatorCASE <Informatik>Residual (numerical analysis)Stress (mechanics)FirmwareMultiplication sign2 (number)Row (database)QuicksortComputer animationLecture/Conference
01:13
Fitness function
01:34
Point cloudEncryptionData modelInformation securitySystem programmingFitness functionPhysical systemInternet der DingeMobile appInformation securityEndliche ModelltheorieInformation privacyComputer animation
02:30
Symmetric matrixLatent heatMobile appServer (computing)TelecommunicationProgramming paradigmPhysical systemMessage passingEncryptionFactory (trading post)Connected spaceMobile appEndliche ModelltheorieBitServer (computing)Computer animation
03:31
Read-only memoryFirmwareFirmwareBitPatch (Unix)Semiconductor memoryCommunications protocolAttractorLecture/Conference
03:56
Associative propertyAuthenticationCodeLocal ringServer (computing)Pairwise comparisonPersonal identification numberEncryptionMereologyPersonal identification numberFrame problemMobile appAuthenticationServer (computing)Electronic visual displayProof theoryAssociative propertySlide rulePrice indexRemote procedure callJSONComputer animation
05:48
Local ringProcess (computing)Associative propertyRemote procedure callNumberSerial portLecture/Conference
06:08
AuthenticationRead-only memoryReading (process)Function (mathematics)Binary fileEncryptionIndependence (probability theory)Server (computing)Address spaceAsynchronous Transfer ModeBlogPlastikkarteChemical equationElectric currentLocal ringClosed setNormal (geometry)TimestampServer (computing)NumberAddress spaceClosed setAuthenticationStructural loadSemiconductor memoryMultiplication signEncryptionEndliche ModelltheorieSpeicheradresseLink (knot theory)Source codeQuicksortPrice indexKey (cryptography)Video gamePatch (Unix)Order (biology)State of matterAssociative propertyFirmwareOcean currentAsynchronous Transfer ModeBit rateCore dumpPlastikkarteCryptographyBit
08:41
Computer hardwareFirmwareComputer animationLecture/Conference
09:01
FirmwareEncryptionSystem on a chipMetreComputer hardwareSoftwareArmReverse engineeringDebuggerSoftware testingEmoticonBus (computing)Personal identification numberLipschitz-StetigkeitReverse engineeringSmartphoneCommunications protocolSoftware testingLibrary (computing)TelecommunicationPoint (geometry)Physical systemMultiplication signFirmwareSoftwareMaxima and minimaPower (physics)DebuggerRight angleFigurate numberFamilyEncryptionContext awarenessCASE <Informatik>MetreComputer fontField (computer science)Computer animation
10:53
Static random-access memoryFlash memoryFirmwareCodeEEPROMInformationVariable (mathematics)Read-only memoryMobile appFunction (mathematics)Serial portEncryptionFitness functionContent (media)DebuggerPoint (geometry)Fitness functionSummierbarkeitFlash memoryMereologyNumberSlide ruleKey (cryptography)CASE <Informatik>State of matterSemiconductor memoryEncryptionAsynchronous Transfer ModeGreatest elementSet (mathematics)MultilaterationConnected spaceVariable (mathematics)Dynamical systemRight angleEndliche ModelltheorieFirmwareStatic random-access memorySpacetimeBootingComputer animation
13:00
FirmwareSoftware frameworkBinary fileDebuggerWhiteboardPhysical systemFirmwareBootingPatch (Unix)Group actionSoftware frameworkWell-formed formulaLecture/ConferenceComputer animation
13:41
Point (geometry)Semiconductor memoryReverse engineeringCovering spaceSet (mathematics)Flash memoryFirmwareWireless LANSummierbarkeitComputer animation
13:58
Process (computing)Open setReverse engineeringFirmwareBitInheritance (object-oriented programming)Goodness of fitFitness functionFisher's exact testLecture/Conference
14:21
Process (computing)Revision controlInformation securityInteractive televisionCASE <Informatik>Server (computing)FirmwareMobile app
15:02
WritingMobile appCyclic redundancy checkFile formatLengthRead-only memoryAddress spaceConstraint (mathematics)Core dumpFirmwareComputer configurationEncryptionRevision controlRange (statistics)EncryptionEmailMobile appFirmwareRange (statistics)Server (computing)CodeAddress spaceRoundness (object)Revision controlBootingFile formatGroup actionBitString (computer science)MereologyHexagonLimit (category theory)Functional (mathematics)Flash memoryOrder (biology)Computer configurationMultiplication signContent (media)Endliche ModelltheorieWordTrailCopyright infringementMetadataFraction (mathematics)IterationNumberComputer animation
17:53
EncryptionFirmwareCore dumpDefault (computer science)Asynchronous Transfer ModeAdvanced Encryption StandardRead-only memoryEEPROMAuthenticationFunction (mathematics)Java appletFlash memoryEncryptionAsynchronous Transfer ModeFirmwareDefault (computer science)Library (computing)BitKey (cryptography)Endliche ModelltheorieTelecommunicationRow (database)Multiplication signFunctional (mathematics)Semiconductor memoryCore dumpComputer animation
19:24
Fitness functionBinary fileHeat transferFile formatFlash memoryFirmwareDemo (music)VideoconferencingFirmwareSoftware frameworkCore dumpDemo (music)Fitness functionSource codeSoftware repositoryForm (programming)Group actionReading (process)QuicksortWärmestrahlungSmartphoneComputer animation
20:29
State of matterComputer animation
20:47
FirmwareLecture/Conference
21:19
FirmwareRevision controlEndliche ModelltheorieComputer configurationInformation securityAsynchronous Transfer ModeEncryptionRead-only memoryWireless LANMathematicsLecture/Conference
21:37
Asynchronous Transfer ModeInternetworkingConnected spaceAttractorVideo gameComputer animation
22:05
CodeGame controllerCodeComputer animation
22:22
MedianSystem programmingHypermedia
Transcript: English(auto-generated)
00:02
This talk is going to be doping your Fitbit. It's going to be held by Isker and by Daniel.
00:23
In case you have been to any of these smaller CCC events in the past, I think, three, maybe four years, you might not discover that you're usually at the assembly with the steering machines. And actually, double the plus for both of them, because Daniel is actually the second shift today as a speaker, which by itself probably is
00:45
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
01:00
about decoding the messages. This time they're going to talk about the firmware of the Fitbit. With that, I leave it to you. So, welcome to our talk on doping your Fitbit. We will show you how to modify the
01:26
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
01:40
good enough, and 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
02:01
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
02:22
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 messages are exchanged, and then go to more technical details.
02:42
The trackers have a key installed which is symmetric, and it's enrolled during factory roll-out, 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,
03:02
it's not as secure as the end-to-end encryption, so it's no longer, but that's the idea. 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. Now, the thing is, can we break the end-to-end
03:21
encryption? Yes, we can. The end-to-end encryption is only used for the recent tracker, so models before 2015 were not always using encryption, and we could look a bit into the protocol, and there has been a memory read-out attack which was not patched for
03:40
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 read-out. All these things are somewhat encryption flaws or connected to encryption, and I'm now going to show you how you
04:02
can now break the encryption on the tracker and get your data. If you have the original smartphone app and a tracker, you have two steps in the beginning, so 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
04:23
the tracker, and then there is an interesting part which is remote association, and in this remote association, you prove that you are physically owning the tracker, for example, by entering a pin. As soon as you have this proof, you can get authentication credentials from the server and use these
04:42
authentication credentials to run authenticated commands, and that's now the part that is getting interesting, because you can use 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.
05:04
So, now the question is, first of all, how you get this 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,
05:23
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, entered and encrypted to the server, you compare it on the server with the thing that you entered in the app. That's okay-ish, but then there are also those
05:42
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
06:04
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
06:22
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 charge HR firmware. He compared actually a firmware update and found
06:43
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 all the trackers, and you can just enter any memory address and length, and
07:00
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 server, and you can send it to the server from the tracker or from the tracker, including the dumps which contain your activity data, or even firmware. And then you might
07:24
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 heart rate sensor on the Fitbit, then you don't want to send each
07:41
time your current heart rate to the server, let the server decrypt your heart 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 Air Link, enable some other Bluetooth handles, so it's a bit hidden, so nobody didn't find it so far,
08:01
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 the last
08:25
firmware update in the sense 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 present in the most recent IONIQ smart watch.
08:43
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
09:02
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 a Cortex M3, and we also have, of course, a BLE chip which is used for the
09:23
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
09:41
example, for encryption, we know that they used lip tomcrip, and for BLE, we at least know that the lip BLE shield is very similar to what they use in the firmware. So this really helped us in reverse engineering. So this is what the PCP looks like if you tear it
10:00
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
10:21
already figured out, that you need those four. So if 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 8, 9, 10, and
10:43
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
11:04
our 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,
11:24
the memory layout is basically split up in three parts. We have a flash which contains the firmware code, an EEPROM which contains the data which should survive an empty battery, so for example your fitness data, and also an SRAM which is used
11:40
for, or which provides some space for firmware variables. So if we look into the flash, for example, in more detail, we see that there are actually two independent firmwares or, yeah, stuff which runs on that. So you have an part which
12:01
is called BSL and you have a part which is called app. And the reason for that is you always want to have some failsafe mode when you update the firmware. So Jiska will talk about this in depth in later slides, but for now, just keep in mind that there are two parts. And on the EEPROM, we have, apart from this fitness
12:22
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
12:41
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 boots up. And the problem is that the firmware actually disables these GPIO ports during the
13:02
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 modify the firmware. And so in our group, we already developed this Nexmon framework which we used previously to binary patch some Wi-Fi
13:23
firmwares. And now we just adapted it, just adapted it for the Fitbit firmware. And now we are able to modify the firmware any way we want. And of course, we can just reset the GPI opens after the boot up to be capable of
13:42
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 Jiska will tell you more about wireless firmware flashing. You might have seen our nice setup with the open Fitbit, but it's quite
14:03
hard to open a Fitbit. 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.
14:24
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's a new firmware update
14:40
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
15:00
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
15:23
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
15:41
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
16:01
hex code depending on the tracker model, and 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,
16:20
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
16:40
there's another header. The header is having the encryption options, and if it's encrypted or not, and the end has another CRC, or if it's encrypted, you have a CMEK tag. Now you would say, well, you discovered how the firmware update works, and that's nice, but if
17:03
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 okay, and then you have a bit flip and CRC somewhere
17:22
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 you firmware version 0.0 in all activity dumps, which is not that nice, so you
17:41
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
18:02
trackers already come in, 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,
18:21
where newer models use AES, and you also need, and for this you need basically three things, 2-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 attack, and also an 8-byte MAC, which you
18:42
can just calculate. And for this, they basically use the libtomcrypt, which is a C library, which we already told you before, but you can also use the spongycastle library, which is written in Java, and this also contains every function you need.
19:02
So now we know basically everything 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
19:23
Fitbit Flex firmware. And so you first get basically your symmetric key, then you get a plain text dump of your firmware binary, then you transfer everything to a notebook, which you then, or any PC basically, which you can then use
19:41
to run our next month 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
20:01
have also another repo. And then the last two steps are basically transfer the firmware back to your smartphone, re-encrypt it, and flash your tracker with it. So of course we did this before, and now we can show you a nice demo what you can do with it.
20:20
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
20:42
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.
21:00
You can see it says 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 for after our research. Okay.
21:25
So these modifications, you can apply them on a Fitbit 1, Flex or Charge HR, and for 1 and Flex, the firmware update is not that far ago, so you have high chances to modify
21:41
your tracker if you now buy one that is in 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
22:01
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.