We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Doping your Fitbit

00:00

Formal Metadata

Title
Doping your Fitbit
Subtitle
Firmware modifications faking you fitter
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Security architectures for wearables are challenging. We take a deeper look into the widely-used Fitbit fitness trackers. The Fitbit ecosystem is interesting to analyze, because Fitbit employs security measures such as end-to-end encryption and authentication to protect user data (and the Fitbit business model). Even though this goes beyond security mechanisms offered by other fitness tracker vendors, reverse-engineering the trackers enables us to launch practical attacks against Fitbit. In our talk, we demonstrate new attacks including wireless malware flashing on trackers as well as “unlocking” the trackers to work independent from the Fitbit cloud.
Keywords
7
Thumbnail
30:34
12
Thumbnail
55:26
43
61
Thumbnail
1:05:55
78
Thumbnail
1:01:42
83
92
Thumbnail
33:27
110
Thumbnail
31:25
141
Thumbnail
31:11
147
Thumbnail
31:30
Mobile WebComputer networkComputerMiniDiscSound effectMessage passingEvent horizonVirtual machineShift operatorCASE <Informatik>Residual (numerical analysis)Stress (mechanics)FirmwareMultiplication sign2 (number)Row (database)QuicksortComputer animationLecture/Conference
Fitness function
Point cloudEncryptionData modelInformation securitySystem programmingFitness functionPhysical systemInternet der DingeMobile appInformation securityEndliche ModelltheorieInformation privacyComputer animation
Symmetric matrixLatent heatMobile appServer (computing)TelecommunicationProgramming paradigmPhysical systemMessage passingEncryptionFactory (trading post)Connected spaceMobile appEndliche ModelltheorieBitServer (computing)Computer animation
Read-only memoryFirmwareFirmwareBitPatch (Unix)Semiconductor memoryCommunications protocolAttractorLecture/Conference
Associative propertyAuthenticationCodeLocal ringServer (computing)Pairwise comparisonPersonal identification numberEncryptionMereologyPersonal identification numberFrame problemMobile appAuthenticationServer (computing)Electronic visual displayProof theoryAssociative propertySlide rulePrice indexRemote procedure callJSONComputer animation
Local ringProcess (computing)Associative propertyRemote procedure callNumberSerial portLecture/Conference
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
Computer hardwareFirmwareComputer animationLecture/Conference
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
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
FirmwareSoftware frameworkBinary fileDebuggerWhiteboardPhysical systemFirmwareBootingPatch (Unix)Group actionSoftware frameworkWell-formed formulaLecture/ConferenceComputer animation
Point (geometry)Semiconductor memoryReverse engineeringCovering spaceSet (mathematics)Flash memoryFirmwareWireless LANSummierbarkeitComputer animation
Process (computing)Open setReverse engineeringFirmwareBitInheritance (object-oriented programming)Goodness of fitFitness functionFisher's exact testLecture/Conference
Process (computing)Revision controlInformation securityInteractive televisionCASE <Informatik>Server (computing)FirmwareMobile app
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
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
Fitness functionBinary fileHeat transferFile formatFlash memoryFirmwareDemo (music)VideoconferencingFirmwareSoftware frameworkCore dumpDemo (music)Fitness functionSource codeSoftware repositoryForm (programming)Group actionReading (process)QuicksortWärmestrahlungSmartphoneComputer animation
State of matterComputer animation
FirmwareLecture/Conference
FirmwareRevision controlEndliche ModelltheorieComputer configurationInformation securityAsynchronous Transfer ModeEncryptionRead-only memoryWireless LANMathematicsLecture/Conference
Asynchronous Transfer ModeInternetworkingConnected spaceAttractorVideo gameComputer animation
CodeGame controllerCodeComputer animation
MedianSystem programmingHypermedia
Transcript: English(auto-generated)
This talk is going to be doping your Fitbit. It's going to be held by Isker 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 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
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 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
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
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
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 messages are exchanged, and then go to more technical details.
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,
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
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
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
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
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
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.
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,
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
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 charge HR 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 all the 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 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
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
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,
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
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.
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 a Cortex M3, and we also have, of course, a 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 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
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 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
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
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,
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
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
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
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 boots 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 modify the firmware. And so in our group, we already developed this Nexmon framework which we used previously to binary patch some Wi-Fi
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
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
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.
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
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, 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,
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'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
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
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
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, 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, 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
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.
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
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
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
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.
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 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.
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
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
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.