Herald Angel: This talk is going to be doping your Fitbit. It's gonna be held by
jiska and daniel. In case you have been to any of the smaller CCC events in the past,
I think 3 maybe 4 years, you might know jiska from the, that you're usually where
there is sewing machines. And actually double plus for both of them, because for
daniel it's actually the second shift today as a speaker, which by itself
probably is stressful. 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 of this. There they spoke about decoding the
messages. This time they're gonna talk about the actual firmware of the fitbits.
And with that I give the stage to you. *applause*
DanielAW: Thank you. jiska: Welcome to our talk on doping your
fitbit. We will show you how to modify the firmware so that you don't have to
anything but, well no sports as every nerd...
*laughter* j: 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 you data to them. So, take the security, but
get your data would be a nice thing. So 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 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 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
the smartphone application which is forwarding the traffic. The local
connection is now 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 software 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 a tracker, you have two steps in the beginning. So you
log in into the app, which is, if you make you own app, is not necessarily required
and you do some local pairing, which anyone can do with a tracker.
And then there's 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. 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, another 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 are 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 end-to-end 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 that 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 replay any sniffed
remote association process. And there are those old plain-text trackers and they
have the serial number 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 association 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. It 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 One and Flex until October, so you could still use this memory readout on the
older trackers and you could just enter any memory address and length and get all
the data that is located at this address. This includes the encryption keys, so with
this encryption key you can then fake any encrypted packet to the tracker or from
the tracker including the dumps which contain the activity data or even
firmware. And then you might ask yourself - well,
why did they do this, the memory readout? Obviously this was not patched, but they
still have authentication and you need authentication for 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 heartrate to the server, let the server decrypt your
heartrate, 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 more 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 present in the most recent Ionic smartwatch.
Now Daniel is going to tell you more about the firmware and hardware access.
D: Alright. Thank you.
For or some of the stuff which we already told you, and also the 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 PCB is structured. So
we have the main system on a chip, which is from STM in our case. Here it's based
on an Cortex M3, and we also have of course BLE chip, which is used for 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
used. So for example for encryption, we know that they use LibTomCrypt, and for
BLE we at least know that the LibBLEShield is very similar to what they use 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 this time we
figure out what testing points 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 herefore 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 the ground pin from the battery which we removed previously, and
on the right hand side is just the connector switch you can use to connect
it, the Fitbit, to your power supply. And so with this we can already dump the
firmware, and we can also modify the stored data. And now that we have the
firmware, let's have a closer look into it. By the way, this on the right hand
side is our test setup It may look kind of crude, but it worked.
And, so yeah, the memory layout is basically split up in 3 parts. We have a
flash which contains the firmware code, and EPROM 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 a more detail, we see that there are
actually 2 independent firmwares or stuff which runs on that. So we have a part
which is called BSL, and 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 jiska
will talk about more this... about this in more 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 we discovered this 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 bootup. So it uses this for other stuff,
which is bad for us. And so we decided, so what can we do to reenable them. Yeah,
just we modify the firmware. And so in our group we already developed this nexmon
framework which we use previously to binary patch some wifi firmwares, and now
we just adapted it - [ironically:] just adapted it - for the Fitbit firmware. And now we are able
to modify the firmware in any way we want, and of course we can just reset the GPIO
pins after the bootup to be capable of debugging. So now we have basically GDB
access, can set breakpoints and memory watchpoints. Which really helped us in
reverse engineering. So now jiska will tell you more about
wireless firmware flashing. j: You might have seen our nice setup with
the open Fitbit, but it's quite hard to open a Fitbit. So it's not super hard, but
it's hard to use it again after it's opened. So 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
the 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's 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
which 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 in 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 in the firmware is starting in 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 3
chunks, then 1 empty chunk, and 1 reboot chunk. And all these chunks are attached
to each other and then there's another header. The header's having the encryption
options and if it's encrypted a nonce and the end has another CRC 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 okay, then you have a bitflip 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. D: The problem is, so we now know how we
do firmware encryption in plaintext mode, but most of the new trackers basically
have encryption enabeled by default. So what we now need to do is to just build an
encrypted firmware update. What do we need for that? Older models of the trackers use
XTEA for encryption whereas newer models use AES. For this you need basically three
things: 2 byte nonce which is contained in each and every dump you get, a 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. For this they use LibTomCrypt
which is a C-library, which we told you before, but you can also use the
spongycastle library which is in Java. This also contains every function you
need. Now we know 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. Let's
put it all together. Here are 6 steps which you need to do when
you want to build your own modified Fitbit flags firmware. First you get your
symmetric key, then you get a plaintext dump of your firmware binary. You transfer
everything to a notebook or any PC basically which you can then use to run
our nexmon framework and then you modify the firmware in any way we want. For the
first and last two steps we have an Android app. You can see the URL and the source code
above. And for the nexmon framework, the adapted version, we have also another repo.
The last two steps are: transfer the
firmware back to your smartphone, reencrypt it and flash your tracker with
it. Of course we did this before and now we can show you a nice demo of what you
can do with it. Of course you want to modify your fitness tracker in an
interesting fashion. So for example we just modified it so that each and every
step gets multiplied by 100. Here you can see: I shake the Fitbit and each shake
creates 100 steps. *applause*
And maybe it is good to say that this does not work with the latest firmware update.
It says firmware update is necessary. But this is because we told them that this is
wrong. So this October update which Jiska mentioned came out after our research.
J: These modifications, you can apply them on a Fitbit 1, Flex or Charge HR. For the
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 is even nicer because
live mode is there on all trackers so if you are happy with the data you get in
live mode you can just disable the internet connection of your tracker and
extract all your data with this. To sum up our task: Go out and flash your
neighbor's device, keep control of your own data, and run any code on your Fitbit.
*applause*