1
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
2
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,
3
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
4
00:00:33,399 --> 00:00:39,120
there is sewing machines. And actually
double plus for both of them, because for
5
00:00:39,120 --> 00:00:42,870
daniel it's actually the second shift
today as a speaker, which by itself
6
00:00:42,870 --> 00:00:53,600
probably is stressful. Getting back to the
smaller events. On the MRMCD this year
7
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
8
00:00:56,690 --> 00:01:01,159
might want to check out the recording of
this. There they spoke about decoding the
9
00:01:01,159 --> 00:01:06,310
messages. This time they're gonna talk
about the actual firmware of the fitbits.
10
00:01:06,310 --> 00:01:13,969
And with that I give the stage to you.
applause
11
00:01:13,969 --> 00:01:23,450
DanielAW: Thank you.
jiska: Welcome to our talk on doping your
12
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
13
00:01:27,770 --> 00:01:32,000
anything but, well no sports as every
nerd...
14
00:01:32,000 --> 00:01:36,500
laughter
j: Our motivation was when we started
15
00:01:36,500 --> 00:01:43,859
taking fitness trackers, that most of them
are not encrypting locally. So you will
16
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
17
00:01:50,789 --> 00:01:55,630
most apps require that you upload your
data into the cloud. So that's again bad
18
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
19
00:02:02,710 --> 00:02:06,920
one thing why we hacked them. And the
other thing is that when we compared
20
00:02:06,920 --> 00:02:13,510
vendors, that they had quite reasonable
security, which is similar to many IoT
21
00:02:13,510 --> 00:02:19,470
systems. So, what we show today will apply
to other systems too. And their security
22
00:02:19,470 --> 00:02:26,450
model is nice, but requires sharing you
data to them. So, take the security, but
23
00:02:26,450 --> 00:02:32,091
get your data would be a nice thing. So
therefore we hacked them. I will first
24
00:02:32,091 --> 00:02:37,940
explain how the system works in general,
which messages are exchanged, and then go
25
00:02:37,940 --> 00:02:46,340
to more technical details.The trackers
have a key installed which is symmetric
26
00:02:46,340 --> 00:02:51,791
and it's enrolled during factory rollout.
So, it's already on the tracker when you
27
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
28
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
29
00:03:02,350 --> 00:03:08,600
longer, but that's the idea. And the
tracker only has Bluetooth LE, so you need
30
00:03:08,600 --> 00:03:12,480
the smartphone application which is
forwarding the traffic. The local
31
00:03:12,480 --> 00:03:18,090
connection is now very secure, but it
doesn't matter that much because of the
32
00:03:18,090 --> 00:03:21,780
end-to-end encryption. And now the thing
is, can we break the end-to-end
33
00:03:21,780 --> 00:03:28,250
encryption? Well, yes we can. The end-to-
end encryption is only used for the recent
34
00:03:28,250 --> 00:03:33,020
trackers, so models before 2015 were not
always using encryption and we could look
35
00:03:33,020 --> 00:03:39,300
a bit into the protocol. And there has
been a memory readout attack which was not
36
00:03:39,300 --> 00:03:43,990
patched for trackers until recently. So if
you buy a tracker now you have a good
37
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
38
00:03:49,060 --> 00:03:56,700
it so far and you can do memory readout.
And all these things are somewhat
39
00:03:56,700 --> 00:04:01,820
encryption flaws or connected to encryption.
And I'm now going to show you how you
40
00:04:01,820 --> 00:04:09,230
can now break the encryption on the
tracker and get your data. If you have the
41
00:04:09,230 --> 00:04:14,080
original smartphone app and a tracker, you
have two steps in the beginning. So you
42
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
43
00:04:19,230 --> 00:04:24,590
and you do some local pairing, which
anyone can do with a tracker.
44
00:04:24,590 --> 00:04:29,000
And then there's an interesting part,
which is remote association, and in this
45
00:04:29,000 --> 00:04:32,910
remote association you prove that you are
physically owning the tracker, for example
46
00:04:32,910 --> 00:04:39,680
by entering a PIN. And as soon as you have
this proof you can get authentication
47
00:04:39,680 --> 00:04:44,960
credentials from the server and use these
authentication credentials to run
48
00:04:44,960 --> 00:04:49,100
authenticated commands - and that's now
the part that is getting interesting
49
00:04:49,100 --> 00:04:54,460
because these authenticated commands you
can execute them as often as you want as
50
00:04:54,460 --> 00:04:58,880
soon as you have those authentication
credentials and they are valid forever
51
00:04:58,880 --> 00:05:06,240
because they are bound to the device key.
So, another question is first of all how
52
00:05:06,240 --> 00:05:12,160
you get these authentication credentials.
And therefore you can associate your
53
00:05:12,160 --> 00:05:16,530
tracker; there are some flaws in it, so
you need to prove that you are physically
54
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
55
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
56
00:05:30,010 --> 00:05:34,370
you have the smartphone app where you
enter the PIN. The PIN is transferred from
57
00:05:34,370 --> 00:05:37,580
the tracker end-to-end encrypted to the
server, you compare it on the server with
58
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
59
00:05:42,220 --> 00:05:46,090
those trackers that don't have a display -
you just tap them and the tapping
60
00:05:46,090 --> 00:05:52,300
confirmation is a wireless frame which you
can easily replay. And there is no
61
00:05:52,300 --> 00:05:57,960
confirmation of freshness of either of
those, so you can replay any sniffed
62
00:05:57,960 --> 00:06:04,800
remote association process. And there are
those old plain-text trackers and they
63
00:06:04,800 --> 00:06:10,180
have the serial number printed on the
packing, and you can just use the serial
64
00:06:10,180 --> 00:06:17,260
number and craft a valid packet from this
and do the association if you want. And
65
00:06:17,260 --> 00:06:21,360
since those association credentials are
valid forever - well, you just use them as
66
00:06:21,360 --> 00:06:25,470
soon as you have them - you could even
resell your tracker and use them again,
67
00:06:25,470 --> 00:06:31,490
and sniff someone else's data.
The first thing that we used to break
68
00:06:31,490 --> 00:06:35,790
encryption is an authenticated memory
readout. It was already found by Martin
69
00:06:35,790 --> 00:06:42,450
before on the Charge HR firmware. He
compared, actually, a firmware update and
70
00:06:42,450 --> 00:06:49,240
found that they removed the command, and
Fitbit didn't remove the command on the
71
00:06:49,240 --> 00:06:54,960
Fitbit One and Flex until October, so you
could still use this memory readout on the
72
00:06:54,960 --> 00:07:01,010
older trackers and you could just enter
any memory address and length and get all
73
00:07:01,010 --> 00:07:07,070
the data that is located at this address.
This includes the encryption keys, so with
74
00:07:07,070 --> 00:07:12,940
this encryption key you can then fake any
encrypted packet to the tracker or from
75
00:07:12,940 --> 00:07:19,610
the tracker including the dumps which
contain the activity data or even
76
00:07:19,610 --> 00:07:25,490
firmware.
And then you might ask yourself - well,
77
00:07:25,490 --> 00:07:29,440
why did they do this, the memory readout?
Obviously this was not patched, but they
78
00:07:29,440 --> 00:07:35,010
still have authentication and you need
authentication for so-called live mode,
79
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
80
00:07:40,370 --> 00:07:44,750
to send each time your current heartrate
to the server, let the server decrypt your
81
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
82
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
83
00:07:56,090 --> 00:07:59,729
airlink, enable some other Bluetooth
handles, so it's a bit hidden, so nobody
84
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.
85
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
86
00:08:12,080 --> 00:08:16,340
this - first of all, you can sniff it,
it's plain text, everyone could sniff it.
87
00:08:16,340 --> 00:08:22,870
And everyone having authentication
credentials can enable it. And, well,
88
00:08:22,870 --> 00:08:27,801
Fitbit fixed this on their last Firmware
update in the sense of that you can
89
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
90
00:08:32,948 --> 00:08:43,029
you didn't disable it manually and it's
present in the most recent Ionic smartwatch.
91
00:08:43,029 --> 00:08:46,520
Now Daniel is going to tell you more about
the firmware and hardware access.
92
00:08:46,520 --> 00:08:48,727
D: Alright. Thank you.
93
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
94
00:08:54,446 --> 00:08:59,850
want to have some access to the
actual hardware, so the tracker itself.
95
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
96
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
97
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
98
00:09:23,569 --> 00:09:28,660
with the smartphone app. And we also have
an accelerometer which detects your steps.
99
00:09:28,660 --> 00:09:34,899
And everything is connected via bus. And
most interestingly, we also know for some
100
00:09:34,899 --> 00:09:40,379
of the software which runs in the
firmware, basically which library they
101
00:09:40,379 --> 00:09:45,320
used. So for example for encryption, we
know that they use LibTomCrypt, and for
102
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
103
00:09:50,379 --> 00:09:57,589
firmware. So this really helped us in
reverse engineering. So this is what the
104
00:09:57,589 --> 00:10:04,880
PCB looks like if you tear it apart and
remove it from its casing basically. We
105
00:10:04,880 --> 00:10:12,129
already see that there are lots and lots
of testing points, and now this time we
106
00:10:12,129 --> 00:10:19,304
figure out what testing points we need to
connect the debugger. And so we figured
107
00:10:19,314 --> 00:10:25,569
out, or some other guys already figured
out that you need those four. So,
108
00:10:25,569 --> 00:10:32,350
depending on what protocol you want to use
for your debugger you need various amounts
109
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.
110
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
111
00:10:46,850 --> 00:10:52,569
we use just the ground pin from the
battery which we removed previously, and
112
00:10:52,569 --> 00:10:58,129
on the right hand side is just the
connector switch you can use to connect
113
00:10:58,129 --> 00:11:04,930
it, the Fitbit, to your power supply. And
so with this we can already dump the
114
00:11:04,930 --> 00:11:10,459
firmware, and we can also modify the
stored data. And now that we have the
115
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
116
00:11:15,079 --> 00:11:22,009
side is our test setup It may look kind of
crude, but it worked.
117
00:11:22,009 --> 00:11:29,329
And, so yeah, the memory layout is
basically split up in 3 parts. We have a
118
00:11:29,329 --> 00:11:34,160
flash which contains the firmware code,
and EPROM which contains the data which
119
00:11:34,160 --> 00:11:39,119
should survive an empty battery, so for
example your fitness data. And also an
120
00:11:39,119 --> 00:11:44,240
SRAM which is used for, or which provides
some space for firmware variables. So if
121
00:11:44,240 --> 00:11:51,239
we look into the flash for example in a
more detail, we see that there are
122
00:11:51,239 --> 00:12:01,009
actually 2 independent firmwares or stuff
which runs on that. So we have a part
123
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
124
00:12:05,851 --> 00:12:10,350
always want to have some fail safe mode
when you update the firmware. So jiska
125
00:12:10,350 --> 00:12:16,829
will talk about more this... about this in
more depth, in later slides, but for now
126
00:12:16,829 --> 00:12:21,449
just keep in mind that there are two
parts. And on the EPROM we have apart
127
00:12:21,449 --> 00:12:24,370
from this fitness data, we also have
everything we need for encryption, so we
128
00:12:24,370 --> 00:12:28,379
have our serial number. We have an
encryption key and we have even a switch
129
00:12:28,379 --> 00:12:34,629
which you can use to completely disable
encryption.
130
00:12:34,629 --> 00:12:40,889
So what we also wanted to do is enabling
GDB access, so to have dynamic debugging
131
00:12:40,889 --> 00:12:47,459
support. But we discovered this in case
you set everything up and you connect GDB
132
00:12:47,459 --> 00:12:53,440
to it and then you hit run, your GDB
connection will just reset after a certain
133
00:12:53,440 --> 00:12:58,679
point when the firmware boots up. And the
problem is that the firmware actually
134
00:12:58,679 --> 00:13:04,379
disables these GPIO ports during the
bootup. So it uses this for other stuff,
135
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,
136
00:13:09,489 --> 00:13:17,389
just we modify the firmware. And so in our
group we already developed this nexmon
137
00:13:17,389 --> 00:13:23,920
framework which we use previously to
binary patch some wifi firmwares, and now
138
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
139
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
140
00:13:38,149 --> 00:13:45,799
pins after the bootup to be capable of
debugging. So now we have basically GDB
141
00:13:45,799 --> 00:13:51,540
access, can set breakpoints and memory
watchpoints. Which really helped us in
142
00:13:51,540 --> 00:13:55,860
reverse engineering.
So now jiska will tell you more about
143
00:13:55,860 --> 00:14:00,850
wireless firmware flashing.
j: You might have seen our nice setup with
144
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
145
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
146
00:14:10,529 --> 00:14:14,579
flash your firmware, which needs some more
reverse engineering in the firmware of
147
00:14:14,579 --> 00:14:22,550
this process, and then we were able to do
it. The update process is a bit
148
00:14:22,550 --> 00:14:29,970
complicated, so in each activity data that
you transmit to the server, you include
149
00:14:29,970 --> 00:14:34,509
the firmware version of the tracker. And
the server then knows, well you have maybe
150
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
151
00:14:39,860 --> 00:14:44,009
firmware update available. But it's not
flashed onto the tracker until the user is
152
00:14:44,009 --> 00:14:52,259
actually tapping this update in the app.
But, this is not really a security feature, so
153
00:14:52,259 --> 00:14:57,420
anyone could trigger a firmware update.
It's not any user interaction required
154
00:14:57,420 --> 00:15:03,459
normally. As soon as the update is started
you get a microdump from the tracker,
155
00:15:03,459 --> 00:15:08,389
which contains tracker metadata including
the serial number and the firmware version
156
00:15:08,389 --> 00:15:12,279
once again, which is attached to a
firmware request. And the firmware request
157
00:15:12,279 --> 00:15:18,399
is then being replied from the server and
contains the BSL and APP firmware parts
158
00:15:18,399 --> 00:15:25,379
which Daniel just showed you. The firmware
starts then with the BSL flashing. The BSL
159
00:15:25,379 --> 00:15:31,989
is first validated, then it's written to
the flash and then you reboot into this
160
00:15:31,989 --> 00:15:37,779
BSL part. Same thing then for the APP
part, which is again validated, written to
161
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
162
00:15:41,910 --> 00:15:50,009
functionality back again.
This update format ensures that you are
163
00:15:50,009 --> 00:15:55,220
flashing the correct firmware in the
correct order to the tracker. So each
164
00:15:55,220 --> 00:16:00,209
chunk in the firmware is starting in the
actual tracker model. So each of them has
165
00:16:00,209 --> 00:16:04,199
this hex code depending on the tracker
model. Then you have a chunk which is
166
00:16:04,199 --> 00:16:09,260
marked either as BSL, APP, or the reboot
action. And depending on which of these
167
00:16:09,260 --> 00:16:15,881
actions you have either some zero bytes or
the actual content. And you have also a
168
00:16:15,881 --> 00:16:25,480
size limit of something like 64 kilobytes,
depending on the tracker. So you just need
169
00:16:25,480 --> 00:16:31,569
to attach these things together. So if you
have an APP firmware update it contains 3
170
00:16:31,569 --> 00:16:39,160
chunks, then 1 empty chunk, and 1 reboot
chunk. And all these chunks are attached
171
00:16:39,160 --> 00:16:45,329
to each other and then there's another
header. The header's having the encryption
172
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
173
00:16:52,160 --> 00:16:59,579
encrypted you have a CMAC tag. Now you
would say - well, you discovered how the
174
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
175
00:17:04,631 --> 00:17:07,230
some errors.
So, the address range is of course
176
00:17:07,230 --> 00:17:15,030
checked, you could pass this address range
check if you would flash one more round
177
00:17:15,030 --> 00:17:21,760
and then disable this address range check.
But okay, then you have a bitflip and CRC
178
00:17:21,760 --> 00:17:27,869
somewhere in the middle of the firmware,
where you need to flip a bit, calculate
179
00:17:27,869 --> 00:17:32,430
another CRC, include it into the firmware,
because otherwise the firmware that you
180
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
181
00:17:39,510 --> 00:17:43,530
not that nice, so you cannot simply
replace a string in the firmware for
182
00:17:43,530 --> 00:17:49,360
example without this being to happen.
And now Daniel is going to tell you how
183
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
184
00:17:57,899 --> 00:18:06,250
do firmware encryption in plaintext mode,
but most of the new trackers basically
185
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
186
00:18:11,500 --> 00:18:19,050
encrypted firmware update. What do we need
for that? Older models of the trackers use
187
00:18:19,050 --> 00:18:27,080
XTEA for encryption whereas newer models
use AES. For this you need basically three
188
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
189
00:18:34,409 --> 00:18:39,940
key which you can get with the
aforementioned memory readout attack and
190
00:18:39,940 --> 00:18:49,049
also an 8 byte MAC which you can just
calculate. For this they use LibTomCrypt
191
00:18:49,049 --> 00:18:55,230
which is a C-library, which we told you
before, but you can also use the
192
00:18:55,230 --> 00:19:01,130
spongycastle library which is in Java.
This also contains every function you
193
00:19:01,130 --> 00:19:08,211
need. Now we know everything we need. We
know how the communication works, we know
194
00:19:08,211 --> 00:19:14,041
how the firmware update is structured and
we know how to encrypt it properly. Let's
195
00:19:14,041 --> 00:19:18,680
put it all together.
Here are 6 steps which you need to do when
196
00:19:18,680 --> 00:19:28,480
you want to build your own modified Fitbit
flags firmware. First you get your
197
00:19:28,480 --> 00:19:35,340
symmetric key, then you get a plaintext
dump of your firmware binary. You transfer
198
00:19:35,340 --> 00:19:41,100
everything to a notebook or any PC
basically which you can then use to run
199
00:19:41,100 --> 00:19:48,909
our nexmon framework and then you modify
the firmware in any way we want. For the
200
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
201
00:19:57,850 --> 00:20:03,580
above. And for the nexmon framework, the
adapted version, we have also another repo.
202
00:20:03,580 --> 00:20:07,659
The last two steps are: transfer the
203
00:20:07,659 --> 00:20:11,620
firmware back to your smartphone,
reencrypt it and flash your tracker with
204
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
205
00:20:19,210 --> 00:20:25,690
can do with it. Of course you want to
modify your fitness tracker in an
206
00:20:25,690 --> 00:20:32,660
interesting fashion. So for example we
just modified it so that each and every
207
00:20:32,660 --> 00:20:45,330
step gets multiplied by 100. Here you can
see: I shake the Fitbit and each shake
208
00:20:45,330 --> 00:20:54,909
creates 100 steps.
applause
209
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.
210
00:21:00,360 --> 00:21:07,140
It says firmware update is necessary. But
this is because we told them that this is
211
00:21:07,140 --> 00:21:17,620
wrong. So this October update which Jiska
mentioned came out after our research.
212
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
213
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
214
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
215
00:21:45,360 --> 00:21:51,910
update yours because it was lying around.
For the live mode it is even nicer because
216
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
217
00:21:56,169 --> 00:22:00,669
live mode you can just disable the
internet connection of your tracker and
218
00:22:00,669 --> 00:22:10,790
extract all your data with this.
To sum up our task: Go out and flash your
219
00:22:10,790 --> 00:22:21,043
neighbor's device, keep control of your
own data, and run any code on your Fitbit.
220
00:22:21,043 --> 00:22:27,191
applause
221
00:22:27,191 --> 00:22:49,000
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!