0:00:13.735,0:00:19.410
Herald Angel: This talk is going to be[br]doping your Fitbit. It's gonna be held by

0:00:19.410,0:00:27.260
jiska and daniel. In case you have been to[br]any of the smaller CCC events in the past,

0:00:27.260,0:00:33.399
I think 3 maybe 4 years, you might know[br]jiska from the, that you're usually where

0:00:33.399,0:00:39.120
there is sewing machines. And actually[br]double plus for both of them, because for

0:00:39.120,0:00:42.870
daniel it's actually the second shift[br]today as a speaker, which by itself

0:00:42.870,0:00:53.600
probably is stressful. Getting back to the[br]smaller events. On the MRMCD this year

0:00:53.600,0:00:56.690
they had sort of the first session on the[br]same topic, so if you missed that you

0:00:56.690,0:01:01.159
might want to check out the recording of[br]this. There they spoke about decoding the

0:01:01.159,0:01:06.310
messages. This time they're gonna talk[br]about the actual firmware of the fitbits.

0:01:06.310,0:01:13.969
And with that I give the stage to you.[br]<i>applause</i>

0:01:13.969,0:01:23.450
DanielAW: Thank you.[br]jiska: Welcome to our talk on doping your

0:01:23.450,0:01:27.770
fitbit. We will show you how to modify the[br]firmware so that you don't have to

0:01:27.770,0:01:32.000
anything but, well no sports as every[br]nerd...

0:01:32.000,0:01:36.500
<i>laughter</i>[br]j: Our motivation was when we started

0:01:36.500,0:01:43.859
taking fitness trackers, that most of them[br]are not encrypting locally. So you will

0:01:43.859,0:01:50.789
always have a chance to get the data from[br]users, which is not nice for privacy. And

0:01:50.789,0:01:55.630
most apps require that you upload your[br]data into the cloud. So that's again bad

0:01:55.630,0:02:02.710
for privacy. If you look at fitbit they[br]are one of the market leaders, so that's

0:02:02.710,0:02:06.920
one thing why we hacked them. And the[br]other thing is that when we compared

0:02:06.920,0:02:13.510
vendors, that they had quite reasonable[br]security, which is similar to many IoT

0:02:13.510,0:02:19.470
systems. So, what we show today will apply[br]to other systems too. And their security

0:02:19.470,0:02:26.450
model is nice, but requires sharing you[br]data to them. So, take the security, but

0:02:26.450,0:02:32.091
get your data would be a nice thing. So[br]therefore we hacked them. I will first

0:02:32.091,0:02:37.940
explain how the system works in general,[br]which messages are exchanged, and then go

0:02:37.940,0:02:46.340
to more technical details.The trackers[br]have a key installed which is symmetric

0:02:46.340,0:02:51.791
and it's enrolled during factory rollout.[br]So, it's already on the tracker when you

0:02:51.791,0:02:57.800
buy it. And it's used for end-to-end[br]encryption with the server. So, the system

0:02:57.800,0:03:02.350
is as secure as end-to-end encryption. As[br]soon as you have a flaw of course no

0:03:02.350,0:03:08.600
longer, but that's the idea. And the[br]tracker only has Bluetooth LE, so you need

0:03:08.600,0:03:12.480
the smartphone application which is[br]forwarding the traffic. The local

0:03:12.480,0:03:18.090
connection is now very secure, but it[br]doesn't matter that much because of the

0:03:18.090,0:03:21.780
end-to-end encryption. And now the thing[br]is, can we break the end-to-end

0:03:21.780,0:03:28.250
encryption? Well, yes we can. The end-to-[br]end encryption is only used for the recent

0:03:28.250,0:03:33.020
trackers, so models before 2015 were not[br]always using encryption and we could look

0:03:33.020,0:03:39.300
a bit into the protocol. And there has[br]been a memory readout attack which was not

0:03:39.300,0:03:43.990
patched for trackers until recently. So if[br]you buy a tracker now you have a good

0:03:43.990,0:03:49.060
chance that you didn't patch the software[br]so far yourself or someone else didn't do

0:03:49.060,0:03:56.700
it so far and you can do memory readout.[br]And all these things are somewhat

0:03:56.700,0:04:01.820
encryption flaws or connected to encryption.[br]And I'm now going to show you how you

0:04:01.820,0:04:09.230
can now break the encryption on the[br]tracker and get your data. If you have the

0:04:09.230,0:04:14.080
original smartphone app and a tracker, you[br]have two steps in the beginning. So you

0:04:14.080,0:04:19.230
log in into the app, which is, if you make[br]you own app, is not necessarily required

0:04:19.230,0:04:24.590
and you do some local pairing, which[br]anyone can do with a tracker.

0:04:24.590,0:04:29.000
And then there's an interesting part,[br]which is remote association, and in this

0:04:29.000,0:04:32.910
remote association you prove that you are[br]physically owning the tracker, for example

0:04:32.910,0:04:39.680
by entering a PIN. And as soon as you have[br]this proof you can get authentication

0:04:39.680,0:04:44.960
credentials from the server and use these[br]authentication credentials to run

0:04:44.960,0:04:49.100
authenticated commands - and that's now[br]the part that is getting interesting

0:04:49.100,0:04:54.460
because these authenticated commands you[br]can execute them as often as you want as

0:04:54.460,0:04:58.880
soon as you have those authentication[br]credentials and they are valid forever

0:04:58.880,0:05:06.240
because they are bound to the device key.[br]So, another question is first of all how

0:05:06.240,0:05:12.160
you get these authentication credentials.[br]And therefore you can associate your

0:05:12.160,0:05:16.530
tracker; there are some flaws in it, so[br]you need to prove that you are physically

0:05:16.530,0:05:23.040
present, but well, how do you do this? I[br]mean, the first part is of course if you

0:05:23.040,0:05:30.010
have a display then you have a PIN. The[br]PIN is displayed on the tracker, and then

0:05:30.010,0:05:34.370
you have the smartphone app where you[br]enter the PIN. The PIN is transferred from

0:05:34.370,0:05:37.580
the tracker end-to-end encrypted to the[br]server, you compare it on the server with

0:05:37.580,0:05:42.220
the thing that you entered in the app.[br]That's okay-ish, but then there are also

0:05:42.220,0:05:46.090
those trackers that don't have a display -[br]you just tap them and the tapping

0:05:46.090,0:05:52.300
confirmation is a wireless frame which you[br]can easily replay. And there is no

0:05:52.300,0:05:57.960
confirmation of freshness of either of[br]those, so you can replay any sniffed

0:05:57.960,0:06:04.800
remote association process. And there are[br]those old plain-text trackers and they

0:06:04.800,0:06:10.180
have the serial number printed on the[br]packing, and you can just use the serial

0:06:10.180,0:06:17.260
number and craft a valid packet from this[br]and do the association if you want. And

0:06:17.260,0:06:21.360
since those association credentials are[br]valid forever - well, you just use them as

0:06:21.360,0:06:25.470
soon as you have them - you could even[br]resell your tracker and use them again,

0:06:25.470,0:06:31.490
and sniff someone else's data.[br]The first thing that we used to break

0:06:31.490,0:06:35.790
encryption is an authenticated memory[br]readout. It was already found by Martin

0:06:35.790,0:06:42.450
before on the Charge HR firmware. He[br]compared, actually, a firmware update and

0:06:42.450,0:06:49.240
found that they removed the command, and[br]Fitbit didn't remove the command on the

0:06:49.240,0:06:54.960
Fitbit One and Flex until October, so you[br]could still use this memory readout on the

0:06:54.960,0:07:01.010
older trackers and you could just enter[br]any memory address and length and get all

0:07:01.010,0:07:07.070
the data that is located at this address.[br]This includes the encryption keys, so with

0:07:07.070,0:07:12.940
this encryption key you can then fake any[br]encrypted packet to the tracker or from

0:07:12.940,0:07:19.610
the tracker including the dumps which[br]contain the activity data or even

0:07:19.610,0:07:25.490
firmware.[br]And then you might ask yourself - well,

0:07:25.490,0:07:29.440
why did they do this, the memory readout?[br]Obviously this was not patched, but they

0:07:29.440,0:07:35.010
still have authentication and you need[br]authentication for so-called live mode,

0:07:35.010,0:07:40.370
for example if you have a heart rate[br]sensor on the Fitbit, then you don't want

0:07:40.370,0:07:44.750
to send each time your current heartrate[br]to the server, let the server decrypt your

0:07:44.750,0:07:48.690
heartrate, and so on because then it would[br]lag a lot and you would have a high load

0:07:48.690,0:07:56.090
on the server. So what they did was more[br]where you can do some strange closing of

0:07:56.090,0:07:59.729
airlink, enable some other Bluetooth[br]handles, so it's a bit hidden, so nobody

0:07:59.729,0:08:05.070
didn't find it so far, and then you get a[br]very nice thing, which is this live data.

0:08:05.070,0:08:12.080
And it is not encrypted and it's a summary[br]of your current data. So, two things about

0:08:12.080,0:08:16.340
this - first of all, you can sniff it,[br]it's plain text, everyone could sniff it.

0:08:16.340,0:08:22.870
And everyone having authentication[br]credentials can enable it. And, well,

0:08:22.870,0:08:27.801
Fitbit fixed this on their last Firmware[br]update in the sense of that you can

0:08:27.801,0:08:32.948
disable the live mode if you wish to, but[br]you can still use it on any tracker where

0:08:32.948,0:08:43.029
you didn't disable it manually and it's[br]present in the most recent Ionic smartwatch.

0:08:43.029,0:08:46.520
Now Daniel is going to tell you more about[br]the firmware and hardware access.

0:08:46.520,0:08:48.727
D: Alright. Thank you.

0:08:48.727,0:08:54.446
For or some of the stuff which we already[br]told you, and also the dynamic debugging, we

0:08:54.446,0:08:59.850
want to have some access to the[br]actual hardware, so the tracker itself.

0:08:59.850,0:09:07.850
But first of all let's look at some[br]schematic on how the PCB is structured. So

0:09:07.850,0:09:13.360
we have the main system on a chip, which[br]is from STM in our case. Here it's based

0:09:13.360,0:09:23.569
on an Cortex M3, and we also have of course[br]BLE chip, which is used for communication

0:09:23.569,0:09:28.660
with the smartphone app. And we also have[br]an accelerometer which detects your steps.

0:09:28.660,0:09:34.899
And everything is connected via bus. And[br]most interestingly, we also know for some

0:09:34.899,0:09:40.379
of the software which runs in the[br]firmware, basically which library they

0:09:40.379,0:09:45.320
used. So for example for encryption, we[br]know that they use LibTomCrypt, and for

0:09:45.320,0:09:50.379
BLE we at least know that the LibBLEShield[br]is very similar to what they use in the

0:09:50.379,0:09:57.589
firmware. So this really helped us in[br]reverse engineering. So this is what the

0:09:57.589,0:10:04.880
PCB looks like if you tear it apart and[br]remove it from its casing basically. We

0:10:04.880,0:10:12.129
already see that there are lots and lots[br]of testing points, and now this time we

0:10:12.129,0:10:19.304
figure out what testing points we need to[br]connect the debugger. And so we figured

0:10:19.314,0:10:25.569
out, or some other guys already figured[br]out that you need those four. So,

0:10:25.569,0:10:32.350
depending on what protocol you want to use[br]for your debugger you need various amounts

0:10:32.350,0:10:40.980
of testing pins, and herefore in our case[br]we use SWD, so we just need four pins.

0:10:40.980,0:10:46.850
Namely testing point 8, 9, 10, and then[br]ground pin. And, so you can also see that

0:10:46.850,0:10:52.569
we use just the ground pin from the[br]battery which we removed previously, and

0:10:52.569,0:10:58.129
on the right hand side is just the[br]connector switch you can use to connect

0:10:58.129,0:11:04.930
it, the Fitbit, to your power supply. And[br]so with this we can already dump the

0:11:04.930,0:11:10.459
firmware, and we can also modify the[br]stored data. And now that we have the

0:11:10.459,0:11:15.079
firmware, let's have a closer look into[br]it. By the way, this on the right hand

0:11:15.079,0:11:22.009
side is our test setup It may look kind of[br]crude, but it worked.

0:11:22.009,0:11:29.329
And, so yeah, the memory layout is[br]basically split up in 3 parts. We have a

0:11:29.329,0:11:34.160
flash which contains the firmware code,[br]and EPROM which contains the data which

0:11:34.160,0:11:39.119
should survive an empty battery, so for[br]example your fitness data. And also an

0:11:39.119,0:11:44.240
SRAM which is used for, or which provides[br]some space for firmware variables. So if

0:11:44.240,0:11:51.239
we look into the flash for example in a[br]more detail, we see that there are

0:11:51.239,0:12:01.009
actually 2 independent firmwares or stuff[br]which runs on that. So we have a part

0:12:01.009,0:12:05.851
which is called BSL, and a part which is[br]called APP. And the reason for that is you

0:12:05.851,0:12:10.350
always want to have some fail safe mode[br]when you update the firmware. So jiska

0:12:10.350,0:12:16.829
will talk about more this... about this in[br]more depth, in later slides, but for now

0:12:16.829,0:12:21.449
just keep in mind that there are two[br]parts. And on the EPROM we have apart

0:12:21.449,0:12:24.370
from this fitness data, we also have[br]everything we need for encryption, so we

0:12:24.370,0:12:28.379
have our serial number. We have an[br]encryption key and we have even a switch

0:12:28.379,0:12:34.629
which you can use to completely disable[br]encryption.

0:12:34.629,0:12:40.889
So what we also wanted to do is enabling[br]GDB access, so to have dynamic debugging

0:12:40.889,0:12:47.459
support. But we discovered this in case[br]you set everything up and you connect GDB

0:12:47.459,0:12:53.440
to it and then you hit run, your GDB[br]connection will just reset after a certain

0:12:53.440,0:12:58.679
point when the firmware boots up. And the[br]problem is that the firmware actually

0:12:58.679,0:13:04.379
disables these GPIO ports during the[br]bootup. So it uses this for other stuff,

0:13:04.379,0:13:09.489
which is bad for us. And so we decided, so[br]what can we do to reenable them. Yeah,

0:13:09.489,0:13:17.389
just we modify the firmware. And so in our[br]group we already developed this nexmon

0:13:17.389,0:13:23.920
framework which we use previously to[br]binary patch some wifi firmwares, and now

0:13:23.920,0:13:30.850
we just adapted it - [ironically:] just adapted it - for[br]the Fitbit firmware. And now we are able

0:13:30.850,0:13:38.149
to modify the firmware in any way we want,[br]and of course we can just reset the GPIO

0:13:38.149,0:13:45.799
pins after the bootup to be capable of[br]debugging. So now we have basically GDB

0:13:45.799,0:13:51.540
access, can set breakpoints and memory[br]watchpoints. Which really helped us in

0:13:51.540,0:13:55.860
reverse engineering.[br]So now jiska will tell you more about

0:13:55.860,0:14:00.850
wireless firmware flashing.[br]j: You might have seen our nice setup with

0:14:00.850,0:14:06.050
the open Fitbit, but it's quite hard to[br]open a Fitbit. So it's not super hard, but

0:14:06.050,0:14:10.529
it's hard to use it again after it's[br]opened. So the idea is now to wirelessly

0:14:10.529,0:14:14.579
flash your firmware, which needs some more[br]reverse engineering in the firmware of

0:14:14.579,0:14:22.550
this process, and then we were able to do[br]it. The update process is a bit

0:14:22.550,0:14:29.970
complicated, so in each activity data that[br]you transmit to the server, you include

0:14:29.970,0:14:34.509
the firmware version of the tracker. And[br]the server then knows, well you have maybe

0:14:34.509,0:14:39.860
an outdated firmware and in this case in[br]the app there is shown that there is a new

0:14:39.860,0:14:44.009
firmware update available. But it's not[br]flashed onto the tracker until the user is

0:14:44.009,0:14:52.259
actually tapping this update in the app.[br]But, this is not really a security feature, so

0:14:52.259,0:14:57.420
anyone could trigger a firmware update.[br]It's not any user interaction required

0:14:57.420,0:15:03.459
normally. As soon as the update is started[br]you get a microdump from the tracker,

0:15:03.459,0:15:08.389
which contains tracker metadata including[br]the serial number and the firmware version

0:15:08.389,0:15:12.279
once again, which is attached to a[br]firmware request. And the firmware request

0:15:12.279,0:15:18.399
is then being replied from the server and[br]contains the BSL and APP firmware parts

0:15:18.399,0:15:25.379
which Daniel just showed you. The firmware[br]starts then with the BSL flashing. The BSL

0:15:25.379,0:15:31.989
is first validated, then it's written to[br]the flash and then you reboot into this

0:15:31.989,0:15:37.779
BSL part. Same thing then for the APP[br]part, which is again validated, written to

0:15:37.779,0:15:41.910
flash, and then there's a reboot into the[br]APP. And in the APP you have the normal

0:15:41.910,0:15:50.009
functionality back again.[br]This update format ensures that you are

0:15:50.009,0:15:55.220
flashing the correct firmware in the[br]correct order to the tracker. So each

0:15:55.220,0:16:00.209
chunk in the firmware is starting in the[br]actual tracker model. So each of them has

0:16:00.209,0:16:04.199
this hex code depending on the tracker[br]model. Then you have a chunk which is

0:16:04.199,0:16:09.260
marked either as BSL, APP, or the reboot[br]action. And depending on which of these

0:16:09.260,0:16:15.881
actions you have either some zero bytes or[br]the actual content. And you have also a

0:16:15.881,0:16:25.480
size limit of something like 64 kilobytes,[br]depending on the tracker. So you just need

0:16:25.480,0:16:31.569
to attach these things together. So if you[br]have an APP firmware update it contains 3

0:16:31.569,0:16:39.160
chunks, then 1 empty chunk, and 1 reboot[br]chunk. And all these chunks are attached

0:16:39.160,0:16:45.329
to each other and then there's another[br]header. The header's having the encryption

0:16:45.329,0:16:52.160
options and if it's encrypted a nonce and[br]the end has another CRC or if it's

0:16:52.160,0:16:59.579
encrypted you have a CMAC tag. Now you[br]would say - well, you discovered how the

0:16:59.579,0:17:04.631
firmware update works and that's nice, but[br]if you do it like this you will still get

0:17:04.631,0:17:07.230
some errors.[br]So, the address range is of course

0:17:07.230,0:17:15.030
checked, you could pass this address range[br]check if you would flash one more round

0:17:15.030,0:17:21.760
and then disable this address range check.[br]But okay, then you have a bitflip and CRC

0:17:21.760,0:17:27.869
somewhere in the middle of the firmware,[br]where you need to flip a bit, calculate

0:17:27.869,0:17:32.430
another CRC, include it into the firmware,[br]because otherwise the firmware that you

0:17:32.430,0:17:39.510
flash will not boot and show you firmware[br]version 0.0 in all activity dumps which is

0:17:39.510,0:17:43.530
not that nice, so you cannot simply[br]replace a string in the firmware for

0:17:43.530,0:17:49.360
example without this being to happen.[br]And now Daniel is going to tell you how

0:17:49.360,0:17:57.899
the encryption on top of all this works.[br]D: The problem is, so we now know how we

0:17:57.899,0:18:06.250
do firmware encryption in plaintext mode,[br]but most of the new trackers basically

0:18:06.250,0:18:11.500
have encryption enabeled by default. So[br]what we now need to do is to just build an

0:18:11.500,0:18:19.050
encrypted firmware update. What do we need[br]for that? Older models of the trackers use

0:18:19.050,0:18:27.080
XTEA for encryption whereas newer models[br]use AES. For this you need basically three

0:18:27.080,0:18:34.409
things: 2 byte nonce which is contained in[br]each and every dump you get, a 128 bit encryption

0:18:34.409,0:18:39.940
key which you can get with the[br]aforementioned memory readout attack and

0:18:39.940,0:18:49.049
also an 8 byte MAC which you can just[br]calculate. For this they use LibTomCrypt

0:18:49.049,0:18:55.230
which is a C-library, which we told you[br]before, but you can also use the

0:18:55.230,0:19:01.130
spongycastle library which is in Java.[br]This also contains every function you

0:19:01.130,0:19:08.211
need. Now we know everything we need. We[br]know how the communication works, we know

0:19:08.211,0:19:14.041
how the firmware update is structured and[br]we know how to encrypt it properly. Let's

0:19:14.041,0:19:18.680
put it all together.[br]Here are 6 steps which you need to do when

0:19:18.680,0:19:28.480
you want to build your own modified Fitbit[br]flags firmware. First you get your

0:19:28.480,0:19:35.340
symmetric key, then you get a plaintext[br]dump of your firmware binary. You transfer

0:19:35.340,0:19:41.100
everything to a notebook or any PC[br]basically which you can then use to run

0:19:41.100,0:19:48.909
our nexmon framework and then you modify[br]the firmware in any way we want. For the

0:19:48.909,0:19:57.850
first and last two steps we have an Android app.[br]You can see the URL and the source code

0:19:57.850,0:20:03.580
above. And for the nexmon framework, the[br]adapted version, we have also another repo.

0:20:03.580,0:20:07.659
The last two steps are: transfer the

0:20:07.659,0:20:11.620
firmware back to your smartphone,[br]reencrypt it and flash your tracker with

0:20:11.620,0:20:19.210
it. Of course we did this before and now[br]we can show you a nice demo of what you

0:20:19.210,0:20:25.690
can do with it. Of course you want to[br]modify your fitness tracker in an

0:20:25.690,0:20:32.660
interesting fashion. So for example we[br]just modified it so that each and every

0:20:32.660,0:20:45.330
step gets multiplied by 100. Here you can[br]see: I shake the Fitbit and each shake

0:20:45.330,0:20:54.909
creates 100 steps.[br]<i>applause</i>

0:20:54.909,0:21:00.360
And maybe it is good to say that this does[br]not work with the latest firmware update.

0:21:00.360,0:21:07.140
It says firmware update is necessary. But[br]this is because we told them that this is

0:21:07.140,0:21:17.620
wrong. So this October update which Jiska[br]mentioned came out after our research.

0:21:26.870,0:21:33.899
J: These modifications, you can apply them[br]on a Fitbit 1, Flex or Charge HR. For the

0:21:33.899,0:21:41.380
1 and Flex the firmware update is not that[br]far ago so you have high chances to modify

0:21:41.380,0:21:45.360
your tracker if you now buy one that is in[br]original packing or if you just didn't

0:21:45.360,0:21:51.910
update yours because it was lying around.[br]For the live mode it is even nicer because

0:21:51.910,0:21:56.169
live mode is there on all trackers so if[br]you are happy with the data you get in

0:21:56.169,0:22:00.669
live mode you can just disable the[br]internet connection of your tracker and

0:22:00.669,0:22:10.790
extract all your data with this.[br]To sum up our task: Go out and flash your

0:22:10.790,0:22:21.043
neighbor's device, keep control of your[br]own data, and run any code on your Fitbit.

0:22:21.043,0:22:27.191
<i>applause</i>

0:22:27.191,0:22:49.000
subtitles created by c3subtitles.de[br]in the year 2017. Join, and help us!