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.
<i>applause</i>

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...

<i>laughter</i>
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.
<i>applause</i>

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.

<i>applause</i>

subtitles created by c3subtitles.de
in the year 2017. Join, and help us!