WEBVTT
00:00:13.735 --> 00:00:19.410
Herald Angel: This talk is going to be
doping your Fitbit. It's gonna be held by
00:00:19.410 --> 00:00:27.260
jiska and daniel. In case you have been to
any of the smaller CCC events in the past,
00:00:27.260 --> 00:00:33.399
I think 3 maybe 4 years, you might know
jiska from the, that you're usually where
00:00:33.399 --> 00:00:39.120
there is sewing machines. And actually
double plus for both of them, because for
00:00:39.120 --> 00:00:42.870
daniel it's actually the second shift
today as a speaker, which by itself
00:00:42.870 --> 00:00:53.600
probably is stressful. Getting back to the
smaller events. On the MRMCD this year
00:00:53.600 --> 00:00:56.690
they had sort of the first session on the
same topic, so if you missed that you
00:00:56.690 --> 00:01:01.159
might want to check out the recording of
this. There they spoke about decoding the
00:01:01.159 --> 00:01:06.310
messages. This time they're gonna talk
about the actual firmware of the fitbits.
00:01:06.310 --> 00:01:13.969
And with that I give the stage to you.
applause
00:01:13.969 --> 00:01:23.450
DanielAW: Thank you.
jiska: Welcome to our talk on doping your
00:01:23.450 --> 00:01:27.770
fitbit. We will show you how to modify the
firmware so that you don't have to
00:01:27.770 --> 00:01:32.000
anything but, well no sports as every
nerd...
00:01:32.000 --> 00:01:36.500
laughter
j: Our motivation was when we started
00:01:36.500 --> 00:01:43.859
taking fitness trackers, that most of them
are not encrypting locally. So you will
00:01:43.859 --> 00:01:50.789
always have a chance to get the data from
users, which is not nice for privacy. And
00:01:50.789 --> 00:01:55.630
most apps require that you upload your
data into the cloud. So that's again bad
00:01:55.630 --> 00:02:02.710
for privacy. If you look at fitbit they
are one of the market leaders, so that's
00:02:02.710 --> 00:02:06.920
one thing why we hacked them. And the
other thing is that when we compared
00:02:06.920 --> 00:02:13.510
vendors, that they had quite reasonable
security, which is similar to many IoT
00:02:13.510 --> 00:02:19.470
systems. So, what we show today will apply
to other systems too. And their security
00:02:19.470 --> 00:02:26.450
model is nice, but requires sharing you
data to them. So, take the security, but
00:02:26.450 --> 00:02:32.091
get your data would be a nice thing. So
therefore we hacked them. I will first
00:02:32.091 --> 00:02:37.940
explain how the system works in general,
which messages are exchanged, and then go
00:02:37.940 --> 00:02:46.340
to more technical details.The trackers
have a key installed which is symmetric
00:02:46.340 --> 00:02:51.791
and it's enrolled during factory rollout.
So, it's already on the tracker when you
00:02:51.791 --> 00:02:57.800
buy it. And it's used for end-to-end
encryption with the server. So, the system
00:02:57.800 --> 00:03:02.350
is as secure as end-to-end encryption. As
soon as you have a flaw of course no
00:03:02.350 --> 00:03:08.600
longer, but that's the idea. And the
tracker only has Bluetooth LE, so you need
00:03:08.600 --> 00:03:12.480
the smartphone application which is
forwarding the traffic. The local
00:03:12.480 --> 00:03:18.090
connection is now very secure, but it
doesn't matter that much because of the
00:03:18.090 --> 00:03:21.780
end-to-end encryption. And now the thing
is, can we break the end-to-end
00:03:21.780 --> 00:03:28.250
encryption? Well, yes we can. The end-to-
end encryption is only used for the recent
00:03:28.250 --> 00:03:33.020
trackers, so models before 2015 were not
always using encryption and we could look
00:03:33.020 --> 00:03:39.300
a bit into the protocol. And there has
been a memory readout attack which was not
00:03:39.300 --> 00:03:43.990
patched for trackers until recently. So if
you buy a tracker now you have a good
00:03:43.990 --> 00:03:49.060
chance that you didn't patch the software
so far yourself or someone else didn't do
00:03:49.060 --> 00:03:56.700
it so far and you can do memory readout.
And all these things are somewhat
00:03:56.700 --> 00:04:01.820
encryption flaws or connected to encryption.
And I'm now going to show you how you
00:04:01.820 --> 00:04:09.230
can now break the encryption on the
tracker and get your data. If you have the
00:04:09.230 --> 00:04:14.080
original smartphone app and a tracker, you
have two steps in the beginning. So you
00:04:14.080 --> 00:04:19.230
log in into the app, which is, if you make
you own app, is not necessarily required
00:04:19.230 --> 00:04:24.590
and you do some local pairing, which
anyone can do with a tracker.
00:04:24.590 --> 00:04:29.000
And then there's an interesting part,
which is remote association, and in this
00:04:29.000 --> 00:04:32.910
remote association you prove that you are
physically owning the tracker, for example
00:04:32.910 --> 00:04:39.680
by entering a PIN. And as soon as you have
this proof you can get authentication
00:04:39.680 --> 00:04:44.960
credentials from the server and use these
authentication credentials to run
00:04:44.960 --> 00:04:49.100
authenticated commands - and that's now
the part that is getting interesting
00:04:49.100 --> 00:04:54.460
because these authenticated commands you
can execute them as often as you want as
00:04:54.460 --> 00:04:58.880
soon as you have those authentication
credentials and they are valid forever
00:04:58.880 --> 00:05:06.240
because they are bound to the device key.
So, another question is first of all how
00:05:06.240 --> 00:05:12.160
you get these authentication credentials.
And therefore you can associate your
00:05:12.160 --> 00:05:16.530
tracker; there are some flaws in it, so
you need to prove that you are physically
00:05:16.530 --> 00:05:23.040
present, but well, how do you do this? I
mean, the first part is of course if you
00:05:23.040 --> 00:05:30.010
have a display then you have a PIN. The
PIN is displayed on the tracker, and then
00:05:30.010 --> 00:05:34.370
you have the smartphone app where you
enter the PIN. The PIN is transferred from
00:05:34.370 --> 00:05:37.580
the tracker end-to-end encrypted to the
server, you compare it on the server with
00:05:37.580 --> 00:05:42.220
the thing that you entered in the app.
That's okay-ish, but then there are also
00:05:42.220 --> 00:05:46.090
those trackers that don't have a display -
you just tap them and the tapping
00:05:46.090 --> 00:05:52.300
confirmation is a wireless frame which you
can easily replay. And there is no
00:05:52.300 --> 00:05:57.960
confirmation of freshness of either of
those, so you can replay any sniffed
00:05:57.960 --> 00:06:04.800
remote association process. And there are
those old plain-text trackers and they
00:06:04.800 --> 00:06:10.180
have the serial number printed on the
packing, and you can just use the serial
00:06:10.180 --> 00:06:17.260
number and craft a valid packet from this
and do the association if you want. And
00:06:17.260 --> 00:06:21.360
since those association credentials are
valid forever - well, you just use them as
00:06:21.360 --> 00:06:25.470
soon as you have them - you could even
resell your tracker and use them again,
00:06:25.470 --> 00:06:31.490
and sniff someone else's data.
The first thing that we used to break
00:06:31.490 --> 00:06:35.790
encryption is an authenticated memory
readout. It was already found by Martin
00:06:35.790 --> 00:06:42.450
before on the Charge HR firmware. He
compared, actually, a firmware update and
00:06:42.450 --> 00:06:49.240
found that they removed the command, and
Fitbit didn't remove the command on the
00:06:49.240 --> 00:06:54.960
Fitbit One and Flex until October, so you
could still use this memory readout on the
00:06:54.960 --> 00:07:01.010
older trackers and you could just enter
any memory address and length and get all
00:07:01.010 --> 00:07:07.070
the data that is located at this address.
This includes the encryption keys, so with
00:07:07.070 --> 00:07:12.940
this encryption key you can then fake any
encrypted packet to the tracker or from
00:07:12.940 --> 00:07:19.610
the tracker including the dumps which
contain the activity data or even
00:07:19.610 --> 00:07:25.490
firmware.
And then you might ask yourself - well,
00:07:25.490 --> 00:07:29.440
why did they do this, the memory readout?
Obviously this was not patched, but they
00:07:29.440 --> 00:07:35.010
still have authentication and you need
authentication for so-called live mode,
00:07:35.010 --> 00:07:40.370
for example if you have a heart rate
sensor on the Fitbit, then you don't want
00:07:40.370 --> 00:07:44.750
to send each time your current heartrate
to the server, let the server decrypt your
00:07:44.750 --> 00:07:48.690
heartrate, and so on because then it would
lag a lot and you would have a high load
00:07:48.690 --> 00:07:56.090
on the server. So what they did was more
where you can do some strange closing of
00:07:56.090 --> 00:07:59.729
airlink, enable some other Bluetooth
handles, so it's a bit hidden, so nobody
00:07:59.729 --> 00:08:05.070
didn't find it so far, and then you get a
very nice thing, which is this live data.
00:08:05.070 --> 00:08:12.080
And it is not encrypted and it's a summary
of your current data. So, two things about
00:08:12.080 --> 00:08:16.340
this - first of all, you can sniff it,
it's plain text, everyone could sniff it.
00:08:16.340 --> 00:08:22.870
And everyone having authentication
credentials can enable it. And, well,
00:08:22.870 --> 00:08:27.801
Fitbit fixed this on their last Firmware
update in the sense of that you can
00:08:27.801 --> 00:08:32.948
disable the live mode if you wish to, but
you can still use it on any tracker where
00:08:32.948 --> 00:08:43.029
you didn't disable it manually and it's
present in the most recent Ionic smartwatch.
00:08:43.029 --> 00:08:46.520
Now Daniel is going to tell you more about
the firmware and hardware access.
00:08:46.520 --> 00:08:48.727
D: Alright. Thank you.
00:08:48.727 --> 00:08:54.446
For or some of the stuff which we already
told you, and also the dynamic debugging, we
00:08:54.446 --> 00:08:59.850
want to have some access to the
actual hardware, so the tracker itself.
00:08:59.850 --> 00:09:07.850
But first of all let's look at some
schematic on how the PCB is structured. So
00:09:07.850 --> 00:09:13.360
we have the main system on a chip, which
is from STM in our case. Here it's based
00:09:13.360 --> 00:09:23.569
on an Cortex M3, and we also have of course
BLE chip, which is used for communication
00:09:23.569 --> 00:09:28.660
with the smartphone app. And we also have
an accelerometer which detects your steps.
00:09:28.660 --> 00:09:34.899
And everything is connected via bus. And
most interestingly, we also know for some
00:09:34.899 --> 00:09:40.379
of the software which runs in the
firmware, basically which library they
00:09:40.379 --> 00:09:45.320
used. So for example for encryption, we
know that they use LibTomCrypt, and for
00:09:45.320 --> 00:09:50.379
BLE we at least know that the LibBLEShield
is very similar to what they use in the
00:09:50.379 --> 00:09:57.589
firmware. So this really helped us in
reverse engineering. So this is what the
00:09:57.589 --> 00:10:04.880
PCB looks like if you tear it apart and
remove it from its casing basically. We
00:10:04.880 --> 00:10:12.129
already see that there are lots and lots
of testing points, and now this time we
00:10:12.129 --> 00:10:19.304
figure out what testing points we need to
connect the debugger. And so we figured
00:10:19.314 --> 00:10:25.569
out, or some other guys already figured
out that you need those four. So,
00:10:25.569 --> 00:10:32.350
depending on what protocol you want to use
for your debugger you need various amounts
00:10:32.350 --> 00:10:40.980
of testing pins, and herefore in our case
we use SWD, so we just need four pins.
00:10:40.980 --> 00:10:46.850
Namely testing point 8, 9, 10, and then
ground pin. And, so you can also see that
00:10:46.850 --> 00:10:52.569
we use just the ground pin from the
battery which we removed previously, and
00:10:52.569 --> 00:10:58.129
on the right hand side is just the
connector switch you can use to connect
00:10:58.129 --> 00:11:04.930
it, the Fitbit, to your power supply. And
so with this we can already dump the
00:11:04.930 --> 00:11:10.459
firmware, and we can also modify the
stored data. And now that we have the
00:11:10.459 --> 00:11:15.079
firmware, let's have a closer look into
it. By the way, this on the right hand
00:11:15.079 --> 00:11:22.009
side is our test setup It may look kind of
crude, but it worked.
00:11:22.009 --> 00:11:29.329
And, so yeah, the memory layout is
basically split up in 3 parts. We have a
00:11:29.329 --> 00:11:34.160
flash which contains the firmware code,
and EPROM which contains the data which
00:11:34.160 --> 00:11:39.119
should survive an empty battery, so for
example your fitness data. And also an
00:11:39.119 --> 00:11:44.240
SRAM which is used for, or which provides
some space for firmware variables. So if
00:11:44.240 --> 00:11:51.239
we look into the flash for example in a
more detail, we see that there are
00:11:51.239 --> 00:12:01.009
actually 2 independent firmwares or stuff
which runs on that. So we have a part
00:12:01.009 --> 00:12:05.851
which is called BSL, and a part which is
called APP. And the reason for that is you
00:12:05.851 --> 00:12:10.350
always want to have some fail safe mode
when you update the firmware. So jiska
00:12:10.350 --> 00:12:16.829
will talk about more this... about this in
more depth, in later slides, but for now
00:12:16.829 --> 00:12:21.449
just keep in mind that there are two
parts. And on the EPROM we have apart
00:12:21.449 --> 00:12:24.370
from this fitness data, we also have
everything we need for encryption, so we
00:12:24.370 --> 00:12:28.379
have our serial number. We have an
encryption key and we have even a switch
00:12:28.379 --> 00:12:34.629
which you can use to completely disable
encryption.
00:12:34.629 --> 00:12:40.889
So what we also wanted to do is enabling
GDB access, so to have dynamic debugging
00:12:40.889 --> 00:12:47.459
support. But we discovered this in case
you set everything up and you connect GDB
00:12:47.459 --> 00:12:53.440
to it and then you hit run, your GDB
connection will just reset after a certain
00:12:53.440 --> 00:12:58.679
point when the firmware boots up. And the
problem is that the firmware actually
00:12:58.679 --> 00:13:04.379
disables these GPIO ports during the
bootup. So it uses this for other stuff,
00:13:04.379 --> 00:13:09.489
which is bad for us. And so we decided, so
what can we do to reenable them. Yeah,
00:13:09.489 --> 00:13:17.389
just we modify the firmware. And so in our
group we already developed this nexmon
00:13:17.389 --> 00:13:23.920
framework which we use previously to
binary patch some wifi firmwares, and now
00:13:23.920 --> 00:13:30.850
we just adapted it - [ironically:] just adapted it - for
the Fitbit firmware. And now we are able
00:13:30.850 --> 00:13:38.149
to modify the firmware in any way we want,
and of course we can just reset the GPIO
00:13:38.149 --> 00:13:45.799
pins after the bootup to be capable of
debugging. So now we have basically GDB
00:13:45.799 --> 00:13:51.540
access, can set breakpoints and memory
watchpoints. Which really helped us in
00:13:51.540 --> 00:13:55.860
reverse engineering.
So now jiska will tell you more about
00:13:55.860 --> 00:14:00.850
wireless firmware flashing.
j: You might have seen our nice setup with
00:14:00.850 --> 00:14:06.050
the open Fitbit, but it's quite hard to
open a Fitbit. So it's not super hard, but
00:14:06.050 --> 00:14:10.529
it's hard to use it again after it's
opened. So the idea is now to wirelessly
00:14:10.529 --> 00:14:14.579
flash your firmware, which needs some more
reverse engineering in the firmware of
00:14:14.579 --> 00:14:22.550
this process, and then we were able to do
it. The update process is a bit
00:14:22.550 --> 00:14:29.970
complicated, so in each activity data that
you transmit to the server, you include
00:14:29.970 --> 00:14:34.509
the firmware version of the tracker. And
the server then knows, well you have maybe
00:14:34.509 --> 00:14:39.860
an outdated firmware and in this case in
the app there is shown that there is a new
00:14:39.860 --> 00:14:44.009
firmware update available. But it's not
flashed onto the tracker until the user is
00:14:44.009 --> 00:14:52.259
actually tapping this update in the app.
But, this is not really a security feature, so
00:14:52.259 --> 00:14:57.420
anyone could trigger a firmware update.
It's not any user interaction required
00:14:57.420 --> 00:15:03.459
normally. As soon as the update is started
you get a microdump from the tracker,
00:15:03.459 --> 00:15:08.389
which contains tracker metadata including
the serial number and the firmware version
00:15:08.389 --> 00:15:12.279
once again, which is attached to a
firmware request. And the firmware request
00:15:12.279 --> 00:15:18.399
is then being replied from the server and
contains the BSL and APP firmware parts
00:15:18.399 --> 00:15:25.379
which Daniel just showed you. The firmware
starts then with the BSL flashing. The BSL
00:15:25.379 --> 00:15:31.989
is first validated, then it's written to
the flash and then you reboot into this
00:15:31.989 --> 00:15:37.779
BSL part. Same thing then for the APP
part, which is again validated, written to
00:15:37.779 --> 00:15:41.910
flash, and then there's a reboot into the
APP. And in the APP you have the normal
00:15:41.910 --> 00:15:50.009
functionality back again.
This update format ensures that you are
00:15:50.009 --> 00:15:55.220
flashing the correct firmware in the
correct order to the tracker. So each
00:15:55.220 --> 00:16:00.209
chunk in the firmware is starting in the
actual tracker model. So each of them has
00:16:00.209 --> 00:16:04.199
this hex code depending on the tracker
model. Then you have a chunk which is
00:16:04.199 --> 00:16:09.260
marked either as BSL, APP, or the reboot
action. And depending on which of these
00:16:09.260 --> 00:16:15.881
actions you have either some zero bytes or
the actual content. And you have also a
00:16:15.881 --> 00:16:25.480
size limit of something like 64 kilobytes,
depending on the tracker. So you just need
00:16:25.480 --> 00:16:31.569
to attach these things together. So if you
have an APP firmware update it contains 3
00:16:31.569 --> 00:16:39.160
chunks, then 1 empty chunk, and 1 reboot
chunk. And all these chunks are attached
00:16:39.160 --> 00:16:45.329
to each other and then there's another
header. The header's having the encryption
00:16:45.329 --> 00:16:52.160
options and if it's encrypted a nonce and
the end has another CRC or if it's
00:16:52.160 --> 00:16:59.579
encrypted you have a CMAC tag. Now you
would say - well, you discovered how the
00:16:59.579 --> 00:17:04.631
firmware update works and that's nice, but
if you do it like this you will still get
00:17:04.631 --> 00:17:07.230
some errors.
So, the address range is of course
00:17:07.230 --> 00:17:15.030
checked, you could pass this address range
check if you would flash one more round
00:17:15.030 --> 00:17:21.760
and then disable this address range check.
But okay, then you have a bitflip and CRC
00:17:21.760 --> 00:17:27.869
somewhere in the middle of the firmware,
where you need to flip a bit, calculate
00:17:27.869 --> 00:17:32.430
another CRC, include it into the firmware,
because otherwise the firmware that you
00:17:32.430 --> 00:17:39.510
flash will not boot and show you firmware
version 0.0 in all activity dumps which is
00:17:39.510 --> 00:17:43.530
not that nice, so you cannot simply
replace a string in the firmware for
00:17:43.530 --> 00:17:49.360
example without this being to happen.
And now Daniel is going to tell you how
00:17:49.360 --> 00:17:57.899
the encryption on top of all this works.
D: The problem is, so we now know how we
00:17:57.899 --> 00:18:06.250
do firmware encryption in plaintext mode,
but most of the new trackers basically
00:18:06.250 --> 00:18:11.500
have encryption enabeled by default. So
what we now need to do is to just build an
00:18:11.500 --> 00:18:19.050
encrypted firmware update. What do we need
for that? Older models of the trackers use
NOTE Paragraph
00:18:19.050 --> 00:18:27.080
XTEA for encryption whereas newer models
use AES. For this you need basically three
00:18:27.080 --> 00:18:34.409
things: 2 byte nonce which is contained in
each and every dump you get, a 128 bit encryption
00:18:34.409 --> 00:18:39.940
key which you can get with the
aforementioned memory readout attack and
00:18:39.940 --> 00:18:49.049
also an 8 byte MAC which you can just
calculate. For this they use LibTomCrypt
00:18:49.049 --> 00:18:55.230
which is a C-library, which we told you
before, but you can also use the
00:18:55.230 --> 00:19:01.130
spongycastle library which is in Java.
This also contains every function you
00:19:01.130 --> 00:19:08.211
need. Now we know everything we need. We
know how the communication works, we know
00:19:08.211 --> 00:19:14.041
how the firmware update is structured and
we know how to encrypt it properly. Let's
00:19:14.041 --> 00:19:18.680
put it all together.
Here are 6 steps which you need to do when
00:19:18.680 --> 00:19:28.480
you want to build your own modified Fitbit
flags firmware. First you get your
00:19:28.480 --> 00:19:35.340
symmetric key, then you get a plaintext
dump of your firmware binary. You transfer
00:19:35.340 --> 00:19:41.100
everything to a notebook or any PC
basically which you can then use to run
00:19:41.100 --> 00:19:48.909
our nexmon framework and then you modify
the firmware in any way we want. For the
00:19:48.909 --> 00:19:57.850
first and last two steps we have an Android app.
You can see the URL and the source code
00:19:57.850 --> 00:20:03.580
above. And for the nexmon framework, the
adapted version, we have also another repo.
00:20:03.580 --> 00:20:07.659
The last two steps are: transfer the
00:20:07.659 --> 00:20:11.620
firmware back to your smartphone,
reencrypt it and flash your tracker with
00:20:11.620 --> 00:20:19.210
it. Of course we did this before and now
we can show you a nice demo of what you
00:20:19.210 --> 00:20:25.690
can do with it. Of course you want to
modify your fitness tracker in an
00:20:25.690 --> 00:20:32.660
interesting fashion. So for example we
just modified it so that each and every
00:20:32.660 --> 00:20:45.330
step gets multiplied by 100. Here you can
see: I shake the Fitbit and each shake
00:20:45.330 --> 00:20:54.909
creates 100 steps.
applause
00:20:54.909 --> 00:21:00.360
And maybe it is good to say that this does
not work with the latest firmware update.
00:21:00.360 --> 00:21:07.140
It says firmware update is necessary. But
this is because we told them that this is
NOTE Paragraph
00:21:07.140 --> 00:21:17.620
wrong. So this October update which Jiska
mentioned came out after our research.
00:21:26.870 --> 00:21:33.899
J: These modifications, you can apply them
on a Fitbit 1, Flex or Charge HR. For the
00:21:33.899 --> 00:21:41.380
1 and Flex the firmware update is not that
far ago so you have high chances to modify
00:21:41.380 --> 00:21:45.360
your tracker if you now buy one that is in
original packing or if you just didn't
00:21:45.360 --> 00:21:51.910
update yours because it was lying around.
For the live mode it is even nicer because
00:21:51.910 --> 00:21:56.169
live mode is there on all trackers so if
you are happy with the data you get in
00:21:56.169 --> 00:22:00.669
live mode you can just disable the
internet connection of your tracker and
00:22:00.669 --> 00:22:10.790
extract all your data with this.
To sum up our task: Go out and flash your
00:22:10.790 --> 00:22:21.043
neighbor's device, keep control of your
own data, and run any code on your Fitbit.
00:22:21.043 --> 00:22:27.191
applause
00:22:27.191 --> 00:22:49.000
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!