Research on FitBit Flex - Technical Report

Axelle Apvrille, Fortinet

November 25, 2016

Abstract

This document is a working document with information found from ourown reverse engineering since 2014 and other information gathered on theweb and mailing lists.

It is important to understand that much information in here remains un-certain with quite possibly many errors. We obviously do not have access toFitbit’s design or sources ;) If you use information from this document, useit responsibly and at your own risk.

Why Fitbit trackers? Because they are widely distributed. And researchon IoT is important to Fortinet in terms of research on potential infectabilityand upcoming threats in the next few years.

This document has been sent to Fitbit in November 2016, and they havenot expressed any issue with its publication.

1 Hardware

1.1 Tracker

1.1.1 Inside the tracker

The new (Bluetooth) tracker contains [Bri13, Ele13, Apv15a]:

Figure 1: Fitbit Flex tracker we opened - broke a LED. Since then, students havefound a neater way to open it with heat gun [JM15]

1

• a motherboard with:

– ST Microelectronics 32L151C6 [ST 14] Ultra Low Power ARM Cor-tex M3 Microcontroller. The Cortex M3 processor is a 32-bit CPUintroduced in 2004 [ARM]. There’s an on-board 32Mhz oscillator forRTC. This processor can be read using STLinkv2 https://github.com/texane/stlink

– Nordic Semiconductor nRF8001 1346KV [Sema, Semb] Bluetooth LowEnergy v4.0 Connectivity IC . The chip supports several system com-mands such as enable/disable test mode, echo, sleep, GetBatteryLevel...

– ST Microelectronics LIS2DH [Mic]. This is a tri-axial MEMS (microelectro-mechanical system), with a I2C / SPI interface, and precisionof ± 2g/ ±4g/± 8g/± 16g. It measures movements on 3 axis [Fitd].

– a charger IC from TI: NXE TI BQ24040 [Tex14] battery lithium poly-mere (Li-Pol) - a 5-day battery life they say on fitbit.

• LEDs

• a Bluetooth antenna

• a battery - soldered to the motherboard.

• a NFC antenna (and a NFC controller).

• a Vibration Motor, Coin Type, w/ 2 Discrete Insulated Wires

The Fitbit Flex’s PCB has two faces: one with the main chips (e.g nRF andmicrocontroller) and another with test points. Each face has two layers [JM15].

Claims to be watertight down to 10m.

1.1.2 LEDs meaning

According to http://help.fitbit.com/articles/en_US/Help_article/What-do-the-light-patterns-mean-on-my-Flex, the meaning of theLEDs on the Flex are:

1.1.3 Which Tracker do I have?

On the back of the tracker we can see:

FCCID: XRAFB401 ICID: IC8542A-FB40 pat.fpat.co

[Bri13] seems to be tearing down the same model (FB401).

Model VID/PIDFitbit base - ANT Model 0x10c4 / 0x84c4Fitbit new model 0x2687 / 0xfb01Dynastream USB stick base 0x0fcf / 0x1008

2

P.... If you are currently charging your Flex, itscurrent battery level is low - currently charg-ing.

X..X. then .X..X Sleep mode is enabled.XXXXX then X.... .X... ..X.. ...X. ....X Leaving sleep mode

..X.. An alarm goes off. The Flex should be vibrat-ing too

Table 1: Meanings of the 5 LEDs on the Flex. X means the LED is on. P meansthe LED is ’pulsing’. The dot means it is off.

That’s what a Linux system sees for the Fitbit dongle in my case:$ lsusbBus 001 Device 005: ID 2687:fb01

Fitbit manufactures other devices such as:

• Aria

• Flex

• Force

• One

• Ultra

• Zip

• Alta

Tracker firmware are listed at https://help.fitbit.com/articles/en_US/Help_article/1372. This explains how to update it: https://help.fitbit.com/articles/en_US/Help_article/1871. And thisexplains how to reboot it: https://help.fitbit.com/articles/en_US/Help_article/1186.

1.2 Dongle

The dongle contains:

• Texas Instruments CC2540F128 55J P005 G4 [Tex] 2.4 GHz Bluetooth LowEnergy SoC on the dongle motherboard (see Figure 4). Has 128KB Flashmemory and an AES security co-processor. The AES securityprocessor can be used in particular to encrypt the BLE packets (SMP AES-128).

• Bluetooth Low Energy Antenna (see Figure 3)

3

Figure 2: Fitbit dongle teardown - Imagefrom http://www.designnews.com

Figure 3: Fitbit dongle Blue-tooth antenna - Image fromhttp://www.designnews.com

Figure 4: Fitbit dongle front - thanks toAurelien Francillon

Figure 5: Fitbit dongle back- thanks toAurelien Francillon

4

Address Direction0x81 Host receives a message from the tracker0x01 Host sends a message to the tracker0x82 Host receives a message to the dongle0x02 Host sends a message from the dongle

Table 2: The dongle actually exposes 2 pairs of USB endpoints, to transmit data tothe dongle, or to the tracker

• USB connection contacts

The dongle provides the following information with lsusb -vv

• idVendor. 0x2687

• idProduct. 0xfb01

• iManufacturer. 1 Fitbit Inc.

• iProduct. 2 Fitbit Base Station

It exposes 2 USB interfaces to the host: one for the dongle, and one for thetracker. ANd there are two USB end points for each [RAT13]. See Table 2

According to http://www.beyondlogic.org/usbnutshell/usb3.shtml#Endpoints:

“Endpoints can be described as sources or sinks of data. As the bus ishost centric, endpoints occur at the end of the communications chan-nel at the USB function. At the software layer, your device driver maysend a packet to your devices EP1 for example. As the data is flowingout from the host, it will end up in the EP1 OUT buffer. Your firmwarewill then at its leisure read this data. If it wants to return data, the func-tion cannot simply write to the bus as the bus is controlled by the host.Therefore it writes data to EP1 IN which sits in the buffer until suchtime when the host sends a IN packet to that endpoint requesting thedata. Endpoints can also be seen as the interface between the hard-ware of the function device and the firmware running on the functiondevice. “

From the host to the dongle, communication is done via USB, using interrupts.Interrupt USB transfers are used by peripherals that exchange small amounts ofdata and need immediate attention.

It is possible to synchronize the tracker without Fitbit’s dongle. The conditionsare displayed at Table 3

5

Description Works without dongle Works with standard BLE dongleWindows No ?Linux No ?OSX (on iMac) Yes ?iOS ? N/AAndroid Only with some phones N/A

Table 3: Use of Fitbit Dongle for synchronization

Date Version1.1

2014? 1.6November 2015? 2.5

Table 4: Dongle firmware

1.2.1 Firmware

There are several versions of dongle firmware. They get updated when plugged inwith the fitbit connect software on Windows.

1.3 Old tracker

The old tracker consists of four IC chips [RCB13]:

• FreeScale MMA7341L 3-axis MEMS accelerometer,

• MSP430F2618 low power TI MCU consisting of 92 KB of flash and 96 KBof RAM,

• nRF24API 2.4 GHz RF chip supporting the ANT protocol (1 Mbits/sec, 15ft transmission range)

• MEMS altimeter to count the number of floors climbed.

According to [RCB13], old trackers have two types of memory banks: readbanks (from which the dongle reads) and write banks (dongle can write here).

1.4 Other trackers

According to [Man12], the (old?) Fitbit Ultra uses:

• TI MSP430F5419A 16-bit “ultralow power” microcontroller. 128 kbytes offlash, 16 kbytes of RAM, and a 12-bit ADC.

• Freescale MMA7341LC three axis MEMS accelerometer. +/- 3g.

6

Read Bank 1 ? Fitness records. Each record is 16bytes long: TTTTCCSSSSDDDDFFwhere T is a 4-byte timestamp, C a 2-byte calories, S 4-byte steps, and F 2-byte floor

Write Bank 0 64 bytes Device settingsWrite Bank 1 16 bytes Daily user fitness record

Table 5: Tracker memory banks for old trackers [RCB13]

• MEAS MS5607-02BA barometric pressure sensor. “This sensor lets the Ul-tra track stair steps. It provides 20-cm altitude resolution and has SPI andI2C interfaces; an internal oscillator; and an ultralow-power, 24-bit delta-sigma ADC.”

• nRF24AP2 “2.4-GHz radio, released in July 2009, pairs a Nordic nRF24L01+transceiver with the ANT protocol”.

1.5 Tracker measurements

The tracker records:

• Tri-axial accelerations

• Time?

From tri-axial acceleration data, one can re-construct activities [KWM11, RDML05].The re-construction relies on the average acceleration, standard deviation, time be-tween peaks etc.

We assume that, from that information, the tracker computes [Fitb]:

• Walking steps

• Running steps

• Floors: computed from elevation during movement [Fitc]. Each stair is as-sumed to be of 10 feet. Only trackers with altimeter record altitude and thusfloors (e.g Fitbit Charge, Surge)

The information is recorded minutely [Fite]. According to Fitbit, there is generallyenough memory to store 7 days of data.

From information in your profile, it retrieves:

• Walking stride length. By default, this is computed from your height andgender: 0.415 ∗Height for a man, and 0.413 ∗Height for a woman, withaverage stride lengths of 66cm for a woman, and 78cm for a man http://www.livestrong.com/article/438170-the-average-walking-stride-length/. However, the exact measure can be adjusted manuallyfor the Fitbit tracker in user account settings.

7

Description Steps Distance (km) Walking stride (cm/step)Tracker on fan 186 steps 0.13 70Tracker on wheel [RCB13] 1166 1.44 120 (?)Genuine walking (not fake) 5777 4 70

Table 6: Fake vs real steps

• Running stride length. Same as walking stride, but for running. From heightand gender. This can be set manually.

• Basal Metabolic Rate (BMR). This is computed using height, weight, ageand gender.

It computes:

• Distance. Ex: distance = walkingstride ∗ walkingsteps. Note the FitbitSurge uses its GPS to track distance (when it has GPS signal).

• Calories. Based on BMR [Fita]

Summary data (calories, distance, steps, and floors) are stored for 30 days.In sleep mode, the tracker records movements. From the intensity of those

movements, the tracker assumes you are sleeping, restless or awake[Fitf].It computes sleep efficiency (quality) as 100 ∗ timeasleep/(timeasleep +

timerestless+ timeawokenduringsleep)

1.6 Vulnerabilities/Limits of the hardware

1.6.1 Fooling count of steps

Firmly shake the fitbit towards the ground and it will register a step. Tying thetracker to a fan also registers steps.

[RCB13] mentions 2 other attacks:

1. Attach the tracker to a rope. The longer the rope, the more steps willbe registered. To mitigate this attack, a GPS chip would be needed to seethat steps are registered but location does not change. This mitigation is notperfect though because people doing stepping would not see their activity.

2. Attach the tracker to a car wheel. In 20 minutes, the tracker believed theyhad walked 1166 steps. A GPS chip can mitigate this attack because thedistance will be too long for the steps.

8

1.7 Hardware crypto, or not?

The crypto - if any - is probably done on the STMicroelectronics STM32L 151ARM. However, this chip has no AES capabilities (they are first included in theversion 162 of the chip) : see STM32L151 documentation. and it is unlikely adifferent hardware design is (already) out (costs, maintenance...). So, either thereis no AES crypto at all, or it is not accelerated by hardware.

The reverse engineering of the Android application shows that AES-CMACand XTEA-CMAC is used when we need to authenticate to the tracker. AES-CMAC is used for Fitbit Surge, XTEA-CMAC is used for all other trackers.

2 Communication with the tracker

2.1 General format of messages

There are two types of messages:

• Dongle messages. Those messages are sent on endpoints 0x02 and 0x82.Their length is variable. Their general format has been presented at [Apv15b]:

UL CC PP ...

where

– UL is the useful length of the message (1 byte at most). This is thelength of UL, CC and PP, but not padding if any.

– CC is the command identifier (1 byte)

– PP is the payload (1 or several bytes). Sometimes the payload is paddedwith zeros up to 32 bytes, but not always.

• Tracker messages. Those messages are sent on endpoints 0x01 and 0x81.Their length is always 32 bytes. If smaller, the message is padded with zerosup to 32 bytes. The general format is:

C0 CC PP PP .... UL

– C0 indicates a control message.

– CC is the command identifier (1 byte)

– PP is the control payload (29 bytes). Padded with 00.

– UL is the useful length of the message, ie C0, CC and PP but not thepadding. In practice, the useful length seems to be limited to 0x14 (=20 bytes).

In com/fitbit/galileo/i, that’s where we see the terms “data” and “control”packets:

9

...else if(packet[0] != 0xFFFFFFC0) {

FitbitSystemLog.log("GalileoPacketDecoder", "it\’s data packet");byte[] v1 = this.a(packet);v0 = String.format("decoded packet: %s", com.fitbit.galileo.e.b.a(v1));FitbitSystemLog.log("GalileoPacketDecoder", v0);arg11.b(v1);goto label_34;

}else if(packet.length >= v7) {

FitbitSystemLog.log("GalileoPacketDecoder", "it\’s ctrl packet");

• Raw packets. For example messages truncated in several packets. Theycannot start by C0. If they should, then they should, then it is encoded usingSLIP into DB DC. And DB becomes DB DD.

2.2 Summary of messages

2.3 Dongle messages

2.3.1 Get Dongle Information - 01

Dongle Tracker(s)

Get Dongle Info Request02 01

Get Dongle Info Response15 08 ...

Get Dongle Information Request - 01 Endpoint Packet Length Instruction0x02 0x02 0x01

02 01

Get Dongle Information Response - 08 Endpoint Packet Length Useful Length Instruction0x82 32 0x15 0x08

Format is:

15 08 MAJ MIN dd dd dd dddd dd 74 04 00 02 00 00ff e7 01 00 02 ... 00

• MAJ is dongle major (1 byte)

• MIN is dongle minor (1 byte)

• dd is dongle bluetooth MAC address (6 bytes - e.g 83 18 10 39 cd 20)

10

Format (hex bytes) Padded to32 bytes?

Description Galileointeractiveshortcut

UL CC PP .. Messages sent to the dongle -endpoint 0x02

->..

02 01 Get Dongle Information Request02 02 Disconnect1a 04 PP .. Start Discovery d02 05 Cancel Discovery Request0b 06 PP .. Establish Link Request l02 07 Terminate AirLink Request03 08 PP Toggle Tx Pipe Request tx ..? 09 ? ? Unknown message02 0D PP Set Power Level? 10 ? ? Unknown message02 11 Get Dongle Status11 12 PP .. Establish Link Ex? 13 PP .. Establish Link Ex? 14 PP .. Unknown messages? 17 PP .. Unknown messages03 19 PP Performance test mode stop? f8 PP Read firmware data? f9 PP Write firmware data02 fa Erase firmware data? fb PP Enable firmware02 fc Reboot firmware02 fd Get Bootloader Inf?? ff Flood FirmwareUL CC PP .. Messages received on the don-

gle - endpoint 0x82<-..

20 01 PP ..√

Information message03 02 PP

√Finished Discovering Trackers

13 03 PP ..√

Tracker Discovered03 04 PP .. Establish Link Response03 05 PP .. Link Terminated Response08 06 PP ..

√Test Air Link Response

02 07 (Establish Link?) Confirmed15 08 PP ..

√Dongle Information Response

03 09 PP Unknown message02 0A Unknown response04 11 PP Unknown message02 fe

√Unknown command identifier

04 ff PP PP√

Dongle error

Table 7: Messages for the dongle11

Format Description Galileointeractiveshortcut

C0 CC PP ... UL Messages sent to the tracker - endpoint 0x01 <=..C0 01 -- ... 02 Reset LinkC0 04 PP ... 03 Handle secret (clear or display)C0 05 -- ... 02 Alert user requestC0 06 -- ... 02 Display code (on the tracker)C0 09 PP ... UL Echo RequestC0 0a PP ... 0c Initialize Air Link alC0 10 PP ... 03 Get Dump Request DC0 11 PP ... 0a Read memoryC0 24 PP ... 09 Start TransmissionC0 50 PP ... 0a Client ChallengeC0 52 PP ... 0a Authentication ResponseC0 A2 PP Unknown tracker packetC0 CC PP ... UL Messages received from the tracker - endpoint 0x81 =>..C0 01 -- ... 02 Reset Link ResponseC0 02 -- ... 02 Ack ResponseC0 03 PP ... 04 Nak / Error Code ResponseC0 05 -- ... 02 Alert user responseC0 08 -- ... 02 User Activity?C0 09 PP ... UL Echo ResponseC0 0b -- ... 02 Toggle Pipe ResponseC0 12 PP ... 05 First Ack Block ResponseC0 13 PP ... 05 Ack Block ResponseC0 14 PP ... 0c Air Link Initialized ResponseC0 40 PP ... UL Single block packet responseC0 41 PP ... 03 Start of DumpC0 42 PP ... 09 End of DumpC0 51 PP ... 0e Tracker Challenge

Table 8: Messages for the tracker

12

• 74:04:00:20:00:00:ff:e7:01:00:02 ?

Example of USB dump:

15:08:01:06:83:18:10:39:cd:20:74:04:00:20:00:00:ff:e7:01:00:02:00:00:00:00:00:00:00:00:00:00:00

This shows a USB dongle version 1.6 and with MAC address 83 18 10 39 cd20.

After firmware upgrade (see Table 4), I know have a dongle version 2.5 (MACaddress unchanged).

2.3.2 Information Messages from dongle - 01

Endpoint Length Instruction0x82 0x20 0x01

20 01 AS AS ... 00

where AS is an ASCII string.Known messages:

• adType 128BIT MORE

• adType FLAGS BR EDR

• adType FLAGS GENERAL

• adType SERVICE DATA

• ATT ERROR RSP

• bad StartDiscovery length. Usually the next packet provides the receivedpacket length.

• bad EstablishLink length

• before EstablishLink

• checking SVC UUID-128

• CancelDiscovery

• enumerate characteristics

• EP2 CTRL OUT - unknown packet: this is sent when endpoint 0x02 receivesan unexpected message

13

• EstablishLink called: on new trackers

• EstablishLinkEx called: on new trackers only

• EstablishLink: on old trackers only

• TerminateLink

• Already connected!

• GATT WriteXXX failed1

• GAP DEVICE INFO EVENT

• GAP DEVICE DISCOVERY EVENT

• GAP LINK TERMINATED EVENT(0)

• HID CTRL OUT ECHO REQUEST

• skipping AD item

• processGATTMsg no conn: trying to initialize an AirLink while there is noestablished link

• a integer string, like ’2’ or ’5’ or ’22’

Example of response to a cancel discovery request:

20:01:43:61:6e:63:65:6c:44:69:73:63:6f:76:65:72:79:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

which contains the string “CancelDiscovery”.This one is a response to a TerminateLink request

20:01:54:65:72:6d:69:6e:61:74:65:4c:69:6e:6b:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

This is the message “Already connected!”:

20:01:61:6c:72:65:61:64:79:20:63:6f:6e:6e:65:63:74:65:64:21:00:00:00:00:00:00:00:00:00:00:00:00

1GATT is for Generic Attribute Profile - https://developer.bluetooth.org/TechnologyOverview/Pages/GATT.aspx

14

This message contains “GATT WriteXXX failed” (and occurs if the pipe hasbeen enabled):

20:01:47:41:54:54:5f:57:72:69:74:65:58:58:58:20:66:61:69:6c:65:64:00:00:00:00:00:00:00:00:00:00

This one is “processGATTMsg no conn”

20:01:70:72:6f:63:65:73:73:47:41:54:54:4d:73:67:20:6e:6f:20:63:6f:6e:6e:00:00:00:00:00:00:00:00

2.3.3 Discovery

Dongle Tracker(s)

Request Start Discovery1A 04 BA 56 ...

20 01 StartDiscovery

Tracker Discovered13 03 51 67...

Finished Discovery03 02 01

Request Cancel Discovery02 05

20 01 CancelDiscovery

Start Discovery - 04 Endpoint Length Instruction0x02 26 (0x1a) 0x04

1a:04:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:UU:SS:SS:TT:TT:VV:VV:??:??

• UU is the UUID of Fitbit (adab0000-6e7d-4601-bda2-bffaa68956ba)

• SS is a first service (e.g 0xfb00). I guess those are GATT services and theservice id is actually the GATT attribute’s handle.

• TT is another service (e.g 0xfb01)

15

• VV is another service (e.g 0xfb02)

• Then I find a0 0f or c8 32. I don’t know what that is.

Example in Galileo logs:

04 ( BA 56 89 A6 FA BF A2 BD01 46 7D 6E 00 00 AB AD00 FB 01 FB 02 FB A0 0F ) - 26

Leftover capture data in USB shows:

1a:04:ba:56:89:a6:fa:bf:a2:bd:01:46:7d:6e:00:00:ab:ad:00:fb:01:fb:02:fb:a0:0f

or

1a:04:ba:56:89:a6:fa:bf:a2:bd:01:46:7d:6e:00:00:ab:ad:00:fb:01:fb:02:fb:c8:32:

Sending a discovery packet with only 0x19 bytes

19 04 48 61 63 6b 55 7246 6c 65 78 41 74 46 6f72 74 69 41 41 41 41 4141 41 41 41 41 41 41 41

is probably acceptable, as in return I receive several status messages.

16

Dongle Tracker(s)

Request Start Discovery19 04 48 61 ...

20 01 StartDiscovery

20 01 GAP DEVICE INFO EVENT

20 01 adType FLAGS GENERAL

20 01 adType FLAGS BR EDR

20 01 skipping AD item

20 01 2

20 01 adType 128BIT MORE

20 01 checking SVC UUID-128

20 01 adType SERVICE DATA

20 01 10

20 01 24

20 01 7

20 01 4

Handling errors:

• Bad length. If you send a Start Discovery packet with a bad length, the don-gle responds an information message “bad StartDiscovery length”, followedby another information message containing the received length. For instance,if you send a discovery packet with no payload (02 04), you’ll receive

– Information Message “bad StartDiscovery length”

– Information Message “2”

If you send a discovery packet 05 04 01 02 03, you’ll receive

– Information Message “bad StartDiscovery length”

– Information Message “5”

17

• Already connected. If a discovery has already begun? you may receive inreturn

– 02 0a

– followed by an information message containing “already connected!”

Discovered tracker response - 03 For each discovered tracker, the following issent:

Endpoint Packet Length Useful Length Instruction0x82 32 19 (0x13) 0x03

13:03:tt:tt:tt:tt:tt:tt:PP:RR:02:UU:UU:03:32:31:XX:ss:ss:00:00:00:00:00:00:00:00:00:00:00:00:00

Payload:

• tt tracker id (6 bytes)

• PP address type (1 byte). I always get 0x01.

• RR RSSI (1 byte). This is the signal power. Below -80 means the device istoo far away (or low batteries?).

• 02: fixed?

• UU attributes (2 bytes). I have seen 07 06 or 07 04 or 02 07.

• 03 32 31: fixed?

• XX is unknown. Sometimes 1e or 00.

• Service UUID (2 bytes). I see 00 fb or 4f 1e.

Example in Galileo logs

03 ( 51 67 06 E7 49 CF01 BF 02 07 04 0332 31 03 4F 1E ) - 19

Example in USB:

13:03:51:67:06:e7:49:cf:01:bf:02:07:04:03:32:31:03:4f:1e:00:00:00:00:00:00:00:00:00:00:00:00:00

18

Finished discovering all trackers - 02 Endpoint Packet Length Useful Length Instruction0x82 32 0x03 0x02

This message is sent when we have finished discovering all available trackers.The packet contains the total number of trackers seen.

03 02 nn 00 ... 00

Payload: number of trackers found. Padded with zeros.Example in USB left over.

03:02:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

2.3.4 Cancel discovery - 05

Endpoint Length Instruction0x02 2 0x05

02 05

Example in Galileo log:

--> 02 - 2

To send the command using Galileo interactive mode:

-> c-> 05<-

2.3.5 Establish Link to Tracker

Dongle Tracker(s)

Request Establish Link to Tracker0B 06 ...

Ack of Establish Link RequestEstablishLink called

Link Established Response03 04 00

GAP LINK ESTABLISHED EVENT

Link Confirmed02 07

or for errors:

Dongle Tracker(s)

Dongle Error04 ff 02 40

19

Establish link to tracker request - 06 Endpoint Length Instruction0x02 0x0b 0x06

0B 06 tt tt tt tt tt tt aa ss ss

Payload (9 bytes):

• tracker id (6 bytes)

• address type (1 byte)

• serviceUUID (2 bytes) - little endian. For example 4F 1E.

Examples:

--> 06 ( 51 67 06 E7 49 CF 01 00 FB ) - 11--> 06 ( 51 67 06 E7 49 CF 01 4F 1E ) - 11

USB capture:

0b:06:51:67:06:e7:49:cf:01:4f:1e

If you send an establish link with no payload (e.g 02 06), the dongle respondsan information message “bad EstablishLink length”, then “2”.

If you send an establish link with more payload, it does not seem to complain:

19 06 48 61 63 6b 55 7246 6c 65 78 41 74 46 6f72 74 69 41 41 41 41 4141 41 41 41 41 41 41 41

Establish Link Response - 04 Endpoint Length Instruction0x82 0x03 0x04

03 04 PP

It most cases payload is 00 (success? link not yet established?). In unsuccessfulcases, I get 21 (03 04 21) or 31 (03 04 31).

I get 31 for 19 06 ... (bogus establish link request) or 19 07 (bogus terminatelink request).

[02] 19 06 48 61 63 6b 55 7246 6c 65 78 41 74 46 6f72 74 69 41 41 41 41 4141 41 41 41 41 41 41 41

[02] 05 02 01 02 03[82] 03 04 31

20

Confirmed - 07 Endpoint Length Instruction0x82 0x02 0x07

02 07

I get this packet to confirm an established link, but I also get it just before aterminate link. So, this might be a generic confirmation response.

If an error occurs, the link is not confirmed, and instead we get a dongle errormessage 04 ff 02 40 (see section 2.3.19).

Establish Link Ex - 12 This command is used when pairing, I don’t exactly whatfor. It is similar to Establish Link.

Dongle Tracker(s)

EstablishLinkEx11 12 TrackerId AA ...

InformationEstablishLinkEx called

Link Established Response03 04 00

GAP LINK ESTABLISHED EVENT

Link Confirmed02 07

Sometimes, I also get an Information Message “before EstablishLink” just be-fore “EstablishLinkEx called”.

Endpoint Length Instruction0x02 0x11 (= 17) 0x12

11 12 tt tt tt tt tt tt aa 0600 06 00 00 00 c8 00

Payload (17 bytes):

• tracker id (6 bytes)

• address type (1 byte)

• there is a fixed 06 00 06 00 00 00 c8 00 afterwards, which is similar to theone in Initialize Air Link (section 2.5.2). I don’t know its meaning.

Example:

11:12:51:67:06:e7:49:cf:01:06:00:06:00:00:00:c8:00:00:00:73:00:00:00:04:00:00:00:0e:00:00:00:00

21

If you send a bad EstablishLinkEx request, e.g. 02 12, you’ll receive an infor-mation message “bad EstablishLink length” and “2”.

It seems that command id 0x13 is also related to establishing links. With badlength, it sends back information message “bad EstablishLink length” and “2”.

2.3.6 Terminate Air Link

Dongle Tracker(s)

Terminate Link Request02 07

InformationTerminateLink

Link Terminated Response03 05 16

InformationGAP LINK TERMINATED EVENT

Information”22”

TerminateLink Request - 07 Endpoint Length Instruction0x02 0x02 0x07

02 07

It appears possible to send more data in the terminate link request, this leads toan bogus establish link response (?!)

[02] 19 07 48 61 63 6b 55 7246 6c 65 78 41 74 46 6f72 74 69 41 41 41 41 4141 41 41 41 41 41 41 41

[82] 03 04 31 00 00 00 00 ..

Link Terminated Response - 05 Endpoint Length Instruction0x82 0x03 0x05

03 05 PP

Possible payloads encountered:

• 13

• 16 - occurs sometimes after a disconnect was issued and CancelDiscoveryand TerminateLink were sent back.

• 8

22

2.3.7 Disconnect - 02

Endpoint Length Instruction0x02 0x02 0x02The command will disconnect what is connected.

02 02

In Galileo interactive mode, send:

-> 02

Normally, you receive a CancelDiscovery response. If a link was established,then you also should receive a TerminateLink response.

Dongle Tracker(s)

Disconnect02 02

InformationCancelDiscovery 00...

InformationTerminateLink 00...

2.3.8 Set Power Level - 0x0d

Endpoint Length Instruction0x02 0x02? 0x0DThis command appears to be setting the power level for the dongle.Logs show:

INFO] BGSync: Dongle | Set Power Level | 5[INFO] *** CONTROL OUT bytes: 020D05[INFO] *** CONTROL IN bytes: 02FE000000000000000000000000000000000000000000000000000000000000

which seems to indicate that the 3rd byte is the power level. However, it isstrange because the useful length of the packet is set to 2.

In the case above, the dongle replies 02FE for any power level. I assumeit means it does not support the command (see Unknown command identifier re-sponse), but [All] assumes it means power level has been set.

23

2.3.9 Get Dongle Status - 0x11

Host Dongle

02 11

scanInProgress:

0

svcDiscoveryState:

0

dongleBLEState:

0Endpoint Length Instruction

0x02 0x02 0x11This request gets the current state of the dongle. The answer is sent back in the

form of 6 information messages:

1. scanInProgress: (this is the exact word sent back)

2. a boolean: 0 or 1. If a discovery has been started, the dongle sends back 1.If the discovery is canceled, it sends back 0. For example, if we do:

24

Host Dongle

Get Dongle Status

scanInProgress:

0

...

StartDiscovery

...

Get Dongle Status

scanInProgress:

1

...

CancelDiscovery

Get Dongle Status

scanInProgress:

0

3. svcDiscoveryState:

4. a boolean 0 or 1

5. dongleBLEState:

6. an integer (I have only seen 0 for now)

2.3.10 Performance test mode quit - 0x19

The dongle has a “performance testing mode” where it continuously spits packetssuch as below, and increments the payload by 1 each time, then at ff, loops to 00.

20 00 1e 1e 1e 1e 1e 1e

25

1e 1e 1e 1e 1e 1e 1e 1e1e 1e 1e 1e 1e 1e 1e 1e1e 1e 1e 1e 1e 1e 1e 1e

From a security point of view, this mode causes a Denial of Service of thedongle.

To get out of this mode, send this packet to the dongle’s HID:

03 19 08

The dongle may still spit a few messages before getting out of the test mode:

[02] : 03 06 07[82] : 20 00 24 24 24 24 24 2424 24 24 24 24 24 24 2424 24 24 24 24 24 24 2424 24 24 24 24 24 24 24[82] : 20 00 25 25 25 25 25 2525 25 25 25 25 25 25 2525 25 25 25 25 25 25 2525 25 25 25 25 25 25 25[82] Status Message : bad EstablishLink length[82] Status Message : 3

In the example above,

• We test that how the dongle responds to a dummy request 03 06 07

• The dongle replies with 2 packets from the performance test mode

• The dongle finally gets out of the performance test mode and we see twomore messages, not in performance test mode.

It seems the command 0x19 accepts other payloads than 0x08. For instance,this packet is valid, but I don’t know it is for:

[INFO] *** CONTROL OUT bytes: 04190100

2.3.11 Read firmware data

UL F8 WW ?? OO ?? ...

This command reads a chunk of firmware from flash memory on the dongle.

• WW is number of 32 bit words to read

• OO is start address to read from

This command only works if dongle is in bootloader mode it seems.

26

2.3.12 Write firmware data

UL F9 WW ?? OO ?? ...

• WW is number of 32 bit words to read

• OO is start address to read from

This command only works if dongle is in bootloader mode it seems.

2.3.13 Erase firmware data

02 fa

2.3.14 Enable firmware

UL FB ...

2.3.15 Reboot firmware

02 FC

2.3.16 Get bootloader info

02 FD

2.3.17 Flood firmware

UL FF BB

where BB is a boolean: 0 for disable, 1 for enable.

2.3.18 Unknown command identifier

The meaning of command identifier 0xfe is uncertain. Without any payload, itseems to mean the dongle received an unknown request. In other cases, it can bethe successful answer to a get dongle bootloader info request.

If the dongle receives an unknown/unsupported command identifier request, itanswers with 02 fe, where we assume the response simply means “I don’t knowthis command identifier”.

Endpoint Length Instruction0x82 0x02 0xfe

Host Dongle

02 0a

02 fe

27

Example: I sent (by error) on the dongle:

0c 0b 06 51 67 06 e7 49 cf 01 4f 1e

and received on the dongle (0x82):

02 fe

Any request with command identifier 0x0A to 0x0F, 0x16 will produce thesame response:

02 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The dongle responds with a 0xfe command identifier after a successful rebootin bootloader mode :

--> REBOOT_IN_BL_MODE (former DISTROY_IMAGE command 0x09)[ 0a 09 3a 17 6b f1 c5 e8 94 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]

<-- ACK_BL_MODE: 00 00[ 04 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]

Beware: dangerous to invoke

2.3.19 Dongle error - ff

Endpoint Length Instruction0x82 0x04 0xffIn some cases, the dongle may respond with an error message. The error pay-

load (error code?) is held on two bytes.

• 02 30: bad request ? I get this in response to 05 xx 01 02 03 (forexample) where xx is 0x1a-0x1f

[02] 05 1d 01 02 03[82] 04 ff 02 30 00 00 ...

• 02 40: EstablishLink not confirmed

• 04 30: response to buggy requests with command id 0x09

• 00 40: failure after GAP LINK ESTABLISHED EVENT

28

2.3.20 Unknown message

Command id 09

Host Dongle

02 09

04 ff 04 30

I have fuzzed the payload: all possible lengths with random bytes, but thedongle responds 04 ff 04 30 in all cases.

Response with command id 0x11 . I don’t know what this is for.Host Dongle

05 17 01 02 03

04 11 00 00...

Response with command id 0x0a . I get this answer when I send a short startdiscovery and others have been sent before too.

Host Dongle

Start Discovery: 19 04 48 61 63

02 0a

already connected!

Command id 0x10

Host Dongle

02 10

03 09 80

I have fuzzed the payload: all possible lengths with random bytes, but thedongle responds 03 09 80 in all the cases.

29

Command id 0x14

Host Dongle

02 14

Information Messagebad disc chars length

Information Message2

The second information message echoes the length of packet it received. So, ifno payload were sent (02 14), then it’ll reply “2”.

If the payload is ≥ 6, the dongle responds just an information message with“processGATTMsg no conn”. In some cases, I also get a status message “enumer-ate characteristics”:

[02] 19 14 41 78 65 6c 6c 6542 6c 61 68 56 6f 69 6c61 41 41 41 41 41 41 4141 41 41 41 41 41 41 41

[82] Status Message : enumerate characteristics[82] Status Message : processGATTMsg no conn

If I establish the air link before I issue 06 14 01 02 03 04, then I get

[02] : 06 14 01 02 03 04[82] Status Message : ATT_ERROR_RSP:[82] Status Message : 4[82] Status Message : 10

Command identifier 0x17 If I send a command 0x17 with no payload, I get aninformation message in return.

Host Dongle

02 17

Information MessageEP2 CTRL OUT - unknown packet

If I send a command 0x17 with some payload e.g 05 17 01 02 03, I get 04 11in return

Host Dongle

05 17 01 02 03

04 11 00 00

30

Command identifier 0x17 - 0xfb

Host Dongle

02 17

Information MessageEP2 CTRL OUT - unknown packet

2.4 Tracker messages

2.4.1 Reset Link - 01

Dongle Tracker(s)

Reset Link Requestc0 01...

ResetLink Responsec0 01 ...

Is this the airlink? or something else?

Request Endpoint Length Instruction0x01 ? 0x01

c0 01 PP ... UU

The payload does not have any particular meaning (?) and is echoed in theresponse. See Table 9.

Response Endpoint Length Instruction0x81 ? 0x01

c0 01 PP PP PP PP PP PPPP PP PP PP PP PP PP PPPP PP PP PP 00 00 00 0000 00 00 00 00 00 00 UU

The response works as an echo of the bytes in the request:

• At most 0x12 bytes of the payload are echoed (so that the useful length ofthe response is never greater than 0x14)

• Payload bytes 0x13-0x1f are zeroed.

• Payload bytes at 0x12 or before are not zeroed. Consequently, if the request’spayload is shorter than 0x12, there is often data leak

Example with data leak:

31

[01]c0 01 01 02 03 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05[81] :c0 01 01 02 03 00 51 67 06 e7 49 cf 00 00 18 56ca b7 d7 6f 00 00 00 00 00 00 00 00 00 00 00 05

Example where request’s payload is truncated:

[01]c0 01 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e0f 10 11 12 13 14 15 16 00 00 00 00 00 00 00 18[81]c0 01 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e0f 10 11 12 00 00 00 00 00 00 00 00 00 00 00 14

2.4.2 Ack Response - 02

Endpoint Packet Length Useful Length Instruction0x81 32 2 0xc0 0x02I don’t exactly know the meaning/use of this packet but it seems to be some

form of acknowledgement of a previous command.The command has no payload.

C0 02 ... 02

2.4.3 NAK response - 03

In com/fitbit/galileo/i, this packet is called “NAK”, which essentially indicates anerror occurred and thus an error response is sent.

Endpoint Packet Length Useful Length Instruction0x81 32 4 0xc0 0x03

The payload is

PP PP

So far, I have only seen:

• 04 10. If you send an ack (c0 02) with more than 2 useful bytes.

• 09 10. If you send a get dump packet with a bad dump type (e.g 1). Or ifyou send an Init Air Link Request with bad useful length.

• 15 20. If you send a c0 52 with a dummy packet or invalid useful byte length.Or if the computed CMAC for authentication is invalid.

• 16 20. If you send a dummy packet (c0 0x11).

32

2.4.4 Handle Secret - 04

Endpoint Packet Length Useful Length Instruction0x01 32 3 0xc0 0x04[Mar] says it is an AirLink disconnect opcode, but reversing the Android appli-

cation rather shows this is used for clearing secrets (com/fitbit/bluetooth/commands/b)or display secrets (Lcom/fitbit/bluetooth/commands/k).

In com/fitbit/galileo/ota/b, we see that this packet has a boolean for payload:private static byte[] makePacketC004F(boolean b) {

int v0 = 0;TrackerPacketFormat v1 = new TrackerPacketFormat();v1.firstbyte = 0xc0;v1.lowNibble = 4;v1.bits456 = 0;v1.bit7 = 0;byte[] v1_1 = v1.asBytes(); // v1 is c0 04

// v2 is one byte longer. copy v1 in v2byte[] v2 = new byte[v1_1.length + 1];System.arraycopy(v1_1, 0, v2, 0, v1_1.length);

// set last byte as booleanint v1_2 = v2.length - 1;if(b) {

v0 = 1;}

v2[v1_2] = ((byte)v0);

// c0 04 booleanreturn v2;

}

C0 04 BB ... 03

We see the function is called by

• Clear Secret command (boolean set to false)

• Display Secret command (boolean set to true)

The current implementation does not check BB is boolean, nor that the payloadis one byte long (see section 11).

33

2.4.5 Alert - 05

I do not know the exact meaning of this packet. Although it has no payload, itbehaves like an echo request (see Table 9).

Endpoint Packet Length Useful Length Instruction0x01 or 0x81 32 2 0xc0 0x05

The tracker responds to the request using the the rules specified at section 2.4.1The response has a useful length of 0x02 though, so the echo is a data leak.

2.4.6 Display code on the tracker - 06

The display code packets are also called ”set bond mode”.Dongle Tracker(s)

Display Code RequestC0 06 ... 02

Ack ResponseC0 02 ... 02

Request Endpoint Packet Length Useful Length Instruction0x01 32 ? 0xc0 0x06

It is assumed this packet sends to the tracker a code to display on its screen.On the fitbit flex, which has no screen, this packet has no payload:

C0 06 ... 02

It is assumed that the Tx Pipe has been enabled before issuing this command.

Response To a display code request, the flex responds a Ack Response with nopayload.

2.4.7 User Activity Response - 08

The reversing of com/fitbit/galileo/ota/c shows that this message is for ”user activ-ity”. This is perhaps for call or text notifications to be displayed on the tracker.upperzeroes:

switch(v1_1.lowNibble) {case 8: {

goto label_user_activity; // c0 08}

...label_user_activity:

msg = "RF_PKT_MISC_USER_ACTIVITY received";MySystemLog.log("GalileoPacketDecoder", msg);arg11.userActivity();goto label_34;

34

However, [Mar] says that User Activity is for 0x12.Endpoint Packet Length Useful Length Instruction

0x81 32 2 0xc0 0x08I got this packet sometime after an ack of a display code. I don’t know why.

C0 08 ... 02

2.4.8 Echo - 09

According to [All], the echo command has command identifier 0x09, but [Mar]says it is 0x13. However, my own experiment, and the reversing of com/fitbit/galileo/ota/cshows that it is 0x09.

Endpoint Packet Length Useful Length Instruction0x01 or 0x81 32 Depends 0xc0 0x09

In the request, the dongle specifies the useful length (i.e payload length +2).The response copies the payload following the rules specified at section 2.4.1.

Examples:

[01]c0 09 01 02 03 00 00 0000 00 00 00 00 00 00 0000 00 00 00 00 00 00 0000 00 00 00 00 00 00 05

[81]c0 09 01 02 03 00 51 6706 e7 49 cf 0a 0b 0c 0d0b c3 df a7 00 00 00 0000 00 00 00 00 00 00 05

[01]c0 09 0a 0b 0c 0d 00 0000 00 00 00 00 00 00 0000 00 00 00 00 00 00 0000 00 00 00 00 00 00 06

[81]c0 09 0a 0b 0c 0d 51 6706 e7 49 cf 0a 0b 0c 0d0b c3 df a7 00 00 00 0000 00 00 00 00 00 00 06

Some other command ids behave like an echo though they perhaps have slightlydifferent meanings. See Table 9.

35

Echo request Echo response Max echoed pay-load length

Payload byteswhich are zeroed

Payload bytes withData leak

c0 01 c0 01 0x12 0x13-0x1f ≤ 0x12c0 05 c0 05 0x12 0x13-0x1f ≤ 0x12c0 09 c0 09 0x12 0x13-0x1f ≤ 0x12

Table 9: Commands that behave like an echo

2.4.9 Read memory - 11

According to ??, there is another packet c0 11 which allows to read the memory ofthe tracker. This command only works after authentication:

• c0 50

• c0 51

• c0 52

• c0 11

Endpoint Packet Length Useful Length Instruction0x01 32 0x0a 0xc0 0x11

The format is the following

c0 11 MM MM MM MM LL LL LL LL 00 ... 00 0A

with:

• MM is a 4 byte address to access

• LL is the length to retrieve (4 bytes)

2.4.10 Data transmission to tracker - 24

Data transmissions are used to send information to the tracker. For example toforward a megadump response (see section 7.2) to the tracker.

36

Dongle Tracker(s)

Data TransmissionC0 24 ...

Ack First BlockC0 12 04 00 00 ...

Continu’d Transmission

Ack Further BlockC0 13 14 00 00 ...

Continu’d Transmission

Ack Further BlockC0 13 24 00 00 ...

Start transmission Endpoint Packet Length Useful Length Instruction0x01 32 5 0xc0 0x24

The format is:

c0:24:XX:LL:LL:LL:LL:RR:RR:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:09:

where

• MM. Mode. Only the lower nibble is taken in account. Possible values are0x01, 0x04 (FastAirLink Mode Request), 0x08. (Value 0x11 is understoodas 0x01, 0x14 as 0x04, 0x21 as 0x01 etc) Value 0x0a gets an error responsewith code 16 20.

• LL LL ... is a little endian length of the data to transmit.

• RR seems to be CRC16?

For example, if we have:

C0 24 04 C5 00 00 00 00 00

then, the length to be transmitted is 0xc5 = 197 bytes long.

First ack block - 12 Endpoint Packet Length Useful Length Instruction0x81 32 5 0xc0 0x12

The format is:

c0:12:MM:AA:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:05:

37

• MM is a copy of the MM byte in the data transmission request packet.

• AA is a sequence counter in little endian. As strange as it may seem, it isonly a 1 byte counter, and it will loop if the transmission takes more bytes.

Example:

<== [ C0 12 04 00 00 ] - 5==> [ 28 02 00 00 01 00 8E 1000 00 7D AE AB 0F 7F 915E 66 E8 29 ] - 20

Further ack blocks - 13 Endpoint Packet Length Useful Length Instruction0x81 32 5 0xc0 0x13

The format is:

c0:13:AA:AA:AA:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:05:

AA AA AA is a counter. It increments by 0x10 each time, ie if previous valuewas 94 00 00 then next value is a4 00 00.

Example:

c0:13:a4:00:00:db:01:00:00:4e:4d:a1:b1:01:00:b4:9e:82:41:5b:00:00:00:00:00:00:00:00:00:00:00:05

The last non empty transmission packet may be of less than 20 bytes. Forexample, the packet below has 17 bytes:

<== [ C0 13 94 00 00 ] - 5==> [ 21 71 D3 D1 82 70 E8 1F7F FE 39 37 08 8D AA 00 00 ] - 17

After the entire amount of data has been transmitted, a final packet is sent:

<== [ C0 13 A4 00 00 ] - 5==> [ C0 02 ] - 2

and the tracker answers by an ACK.

38

Type Description0x01 Microdump response0x03 Microdump [Mar]. In particular, a microdump is requested for a pairing.0x04 Megadump response0x0d Megadump

Table 10: Dump types

2.4.11 Dumps

Dongle Tracker(s)

Get Dump RequestC0 10 ...

Start Dump ResponseC0 41 ...

...

...

End Dump ResponseC0 42 ...

Asking the tracker for dumps - 10 Endpoint Packet Length Useful Length Instruction0x01 32 3 0xc0 0x10

c0 10 TT 00 ... 00 LL

Payload:

• TT is Type of dump. See Table 10

• LL is length of packet (03)

In interactive mode in galileo, you can send this as:

> => c0 10 0d

This is what we captured to end point 0x01, direction: out

c0:10:0d:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:03

If you have established a link with a tracker (in galileo interactive mode):

39

# connect> cOk# discover trackers> d# establish a link> lOk# enable tx pipe> tx 1Ok# initialise air link> alOk

then, you can request a microdump:

> => c0 10 03

Start of dump response - 41 Endpoint Packet Length Useful Length Instruction0x81 32 3 ? 0xc0 0x41

c0:41:DD ... 03

The payload consists of a single byte: the dump type - see Table 10.Example:

c0:41:0d:01:02:00:51:67:06:e7:49:cf:dd:ba:07:90:fe:db:bb:94:00:00:00:00:00:00:00:00:00:00:00:03

In galileo interactive mode, get the tracker’s response by wiresharking USBtraffic after

> <=

Example of response to a mini dump request:

c0:41:03:01:02:00:51:67:06:e7:49:cf:2f:29:a8:f6:7b:01:00:8f:00:00:00:00:00:00:00:00:00:00:00:03

Dump packets These packets are sent between a start of dump and an end ofdump

Endpoint Length Instruction0x81 32 -

See Section 7.1 for megadump format or 7.3 for minidump format.

40

End of dump - 42 This packet is sent by the tracker.Endpoint Packet Length Useful Length Instruction

0x81 32 9 0xc0 0x42

c0 42 TT CR CR SS SS 00 ... 00 LL

Payload:

• TT is the dump type: 0D for megadump

• CR is the transport CRC, in little endian

• SS is the dump size (2 bytes), in little endian

• LL is the length. Should be 0x09

Example:

[ C0 42 0D EE 90 13 01 00 00 ] - 9

• Dump type is 0x0d i.e. megadump

• Transport CRC is 0x90ee

• The megadump’s length is 0x0113 bytes

In USB leftover:

c0:42:0d:83:99:a3:01:00:00:55:03:a5:2f:29:a8:f6:7b:01:00:8f:00:00:00:00:00:00:00:00:00:00:00:09

Single block packet response In case the dump fits in a single block, the trackeris expected to answer c0 40. This is found from the reverse engineering of com/fitbit/galileo/ota/cbut I have not witnessed it.

Endpoint Packet Length Useful Length Instruction0x81 32 ? 0xc0 0x40

From com/fitbit/galileo/ota/GalileoOtaMessages$u, we work out that the pay-load begins with a dump type, and then followed by the dump.

c0 40 TT DD ... UL

public SingleBlockResp(byte[] packet) {super(packet);this.dumptype = TrackerBlock.getTrackerBlockForThisDumpType(

((byte)(packet[2] & 0xF)));this.c = ((byte)(packet[2] >>> 4 & 0xF));this.dump = SingleBlockResp.copyArray(packet, 3, packet.length);

}

41

2.4.12 Authenticating on the tracker

Fitbit trackers Ultra and Zip do not support authentication. Fitbit tracker Flex sim-ply assumes authentication is ok but does not do it.

Other trackers use a cipher based MAC for authentication. The cipher is AES(Fitbit Surge) or XTEA (other trackers). The MAC is computed on

1. a local random integer (on the mobile device for instance)

2. tracker’s random integer

Dongle Tracker(s)

Client ChallengeC0 50 LocalRandom

Authentication Challenge ResponseC0 51 Tracker Challenge SeqNum

Response to ChallengeC0 52 ComputedMAC ...

That’s the piece of code that shows it is not used for Flex:

if(!isencrypted || (TrackerAuthUtils.checkMac(this.authcredentials, packet.challenge_code, newint[]{this.localRandom, packet.tracker_random}))) {

if(isencrypted) {MySystemLog.log("TrackerAuthCommand", "MACs are equal");

}else {

MySystemLog.log("TrackerAuthCommand", "Tracker is not encrypted, we just assume it\’s authed");}

Client Challenge - 50 Endpoint Packet Length Useful Length Instruction0x01 32 0x0a 0xc0 0x50

The payload is:

CC CC CC CC CC CC CC CC

where C is the client’s challenge (8 bytes). The tracker won’t respond is less than8 challenge bytes are provided. If more challenge bytes are provided, it looks as ifit does not care and truncates at 8 bytes.

Tracker Challenge - 51 Endpoint Packet Length Useful Length Instruction0x81 32 0x0e(= 14) 0xc0 0x51

The payload is:

CC CC CC CC CC CC CC CCSS SS SS SS

42

• 8-byte challenge. This is the tracker challenge.

• 4-byte sequence counter. Incremented by 1 each time. Little endian.

Example:

c0 51 a2 31 12 e7 bc 73bf 97 1b 06 00 00 f4 a898 14 56 56 00 00 00 0000 00 00 00 00 00 00 0e

Sequence of challenges:

2a d2 e3 6f 1d 1c 22 726c a2 55 c7 75 04 28 db31 54 83 21 5a 53 37 b8a2 31 12 e7 bc 73 bf 97...

Authentication Response - 52 This is not confirmed, but it looks like the payloadis expected to be the XTEA-CMAC (or AES-CMAC for Fitbit Surge) of

1. the local random integer (provided in the client challenge packet)

2. tracker’s random integer (provided in the tracker challenge packet)

The key for the CMAC is unknown yet :(Endpoint Packet Length Useful Length Instruction

0x01 32 0x0a (for XTEA-CMAC) or 0x12 (for AES-CMAC) 0xc0 0x52The tracker checks the CMAC, and if not correct answers with an error re-

sponse with code 15 20.

Unknown packet - a2 Sniffing bluetooth packet shows the existence of dongleto tracker packet:

c0:a2:b0:c2:33:37:6b:55:72:46:6c:65:78:41:74:46:6f:72:74:69

I don’t know what this is for.

2.5 Messages which involve dongle and tracker

2.5.1 Toggle Tx Pipe

Dongle Tracker(s)

Toggle Pipe Request03 08 ...

Toggle Pipe ResponseC0 0B

43

Toggle Tx Pipe Request Endpoint Length Instruction0x02 0x03 0x08

Payload:

• 00 disable

• 01 enable

Toggle Tx Pipe Response Endpoint Packet Length Useful Length Instruction0x81 32 2 0xc0 0x0b

c0 0b ?? ?? ?? ?? ?? ???? ?? ?? ?? ?? ?? ?? ???? ?? ?? ?? ?? ?? ?? ???? ?? ?? ?? ?? ?? ?? 02

Payload - it is possible this payload is just meaningless data because the usefullength at the end is 2.

• MAJ

• MIN

• tracker id

Example:

<== [ C0 0B ] - 2c0:0b:0c:01:02:00:51:67:06:e7:49:cf:dd:ba:07:90:fe:db:bb:94:00:00:00:00:00:00:00:00:00:00:00:02

2.5.2 Initialize Air Link

Dongle Tracker(s)

Request Init Air LinkC0 0A 0A 00 ...

Tracker Air Link Test Response08 06 06 00...

Air Link InitializedC0 14 0C...

44

Initialize Air Link Request Endpoint Packet Length Useful Length Instruction0x01 32 12 (0x0c) 0xc0 0x0a

Format:

c0:0a:0a:00:06:MM:MM:00:00:00:c8:zz:......

zz:LL

Payload:

• 0a 00 06: fixed

• MM MM: Max connection interval (2 bytes, little endian integer): typically600 seconds.

• 00 00 00 c8: fixed

• zeros

• LL is the useful length i.e header + payload length (but not the zeros)

Example:

galileo:[ C0 0A 0A 00 06 00 06 00 00 00 C8 00 ] - 12

left over USB data:c0:0a:0a:00:06:00:06:00:00:00:c8:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:0c

AirLink test response Endpoint Length Useful Length Instruction0x82 32 8 0x6

The payload is: 06:00:00:00:c8:00:00:00. It is padded with zeros.

08:06:06:00:00:00:c8:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

AirLink initialized response Endpoint Length Useful Length Instruction0x81 32 12 (0x0c) 0xc0 0x14

If ok, the tracker responds this to air link initialization. It contains device infoand initiates an authentication handshake:

c0 14 LL MAJ MIN 00 tt tt tt tt tt tt 00 ... 00 LL

45

Payload:

• LL is the payload length

• MAJ is tracker version major

• MIN is tracker version minor

• tt is the tracker’s MAC address

Example in Galileo:

[ C0 14 0C 01 02 00 51 67 06 E7 49 CF ] - 12

Example caught in leftover data:

c0:14:0c:01:02:00:51:67:06:e7:49:cf:dd:ba:07:90:fe:db:bb:94:00:00:00:00:00:00:00:00:00:00:00:0c

Example with memory leak:

c0:14:0c:01:02:00:09:73:78:63:f7:f3:2f:31:68:3b:6b:02:00:36:00:00:00:00:00:00:00:00:00:00:00:0c

where :

• MAJ is 01

• MIN is 02

• tracker is 09 73 78 63 f7 f3

• leak is 2f 31 68 3b 6b 02 00 36

46

2.6 Example of Flow

2.6.1 Establish link flow

Dongle Tracker(s)

Disconnect02 02

InformationCancelDiscovery 00...

InformationTerminateLink 00...

Get Dongle Info02 01

Get Dongle Info15 08 01 06 83 18...

Start Discovery1a 04 ba 56...

InformationStartDiscovery 00...

Discovered Tracker13 03 TrackerId...

No more trackers03 02 Amount..

Cancel Discovery02 05

InformationCancelDiscovery 00..

Establish Link0B 06 TrackerId Addr SUUID SUUID...

Information20 01 EstablishLink called 00..

Ack03 04

Information20 01 GAP LINK ESTABLISHED EVENT 00..

Confirm02 07

2.6.2 Flow to get megadump

2.6.3 Flow for initial pairing

Do 5 times:

47

Description Endpoint Command PayloadEnable Tx Pipe 0x02 03 08 01Tx Pipe Open 0x81 c0 0b 0c 01 02Init Air Link 0x01 c0 0a 0a 00 06 00 00 00 c8 00 ...Test AirLink response 0x82 08 06 06 00 00 00 c8 00 ...AirLink Initialized response 0x81 c0 14 0c MAJ MIN 00 TrackerId ...Ask for megadump 0x01 c0 10 0d 00 ... 03Ack - Start megadump 0x81 c0 41 0d 01 02 00 TrackerId ... 03

0x81 28 02 00 00 01 ...0x81 01 00 0f 00 ... 13

End of Megadump 0x81 c0 42 0d 83 99 ... 09Reset Air Link ? 0x01 c0 01 00 ... 02

0x81 c0 01 0d 83 99 ... 02Disable Tx Pipe 0x02 03 02 00Tx Pipe Closed 0x81 c0 0b 0d 83 99 ...02Terminate Link 0x02 02 07

0x82 20 01 TerminateLink ... 000x82 03 05 16 00 ...0x82 20 01 GAP LINK TERMINATED EVENT 00 ...0x82 20 01 32 32 00 ...

Table 11: USB communication flow to the tracker

48

• Out: Start Discovery

• In: Information message “StartDiscovery”

• In: Tracker discovered

• In: Finished discovering trackers (1)

Then do twice:

• Out: Start Discovery

• In: Information message “StartDiscovery”

• In: Tracker discovered

• Out: Cancel Discovery (02 05)

• In: Finished discovering trackers (1)

• In: Information message “CancelDiscovery”

Then

• Out: Establish Link Ex

• In: Information message “EstablishLinkEx called”

• In: Establish link response (00) - not yet established

• In: Information message “GAP LINK ESTABLISHED EVENT”

• In: Establish link confirmed

• Out: Toggle Pipe enable (01)

• In: Toggle Pipe Response

• Out: Initialize AirLink

• In: AirLink init response

• Out: Display Code ... with no code! (c0 06 ... 02)

• In: Ack

• In: User Activity

• Out: Get Minidump (c0 10 03 ... 03)

• In: Start of dump

• In: messages containing the minidump (30 02 ...)

49

• In: End of dump

• Out: Get megadump

• In: Start of dump

• In: messages containing the megadump

• In: End of dump

• Out: Start transmission

• In: Firsk block ack response

• Out: message containing megadump response

• In: Ack block response

• Out: c0 02 00 .... 02

• In: Ack response

• Out: reset link

• In: reset link response

• Out: Toggle Pipe Disable (00)

• In: Toggle Pipe Response

• Out: Terminate air link request

• In: Information message “TerminateLink”

• In: link terminated response with payload 0x16

• In: Information message GAP LINK TERMINATED EVENT

• In: Information message “22”

• Out: Start Discovery

• In: Information message “StartDiscovery”

• In: Tracker discovered

• In: Finished discovering trackers (1)

50

3 Bluetooth

The communication between the dongle and the tracker uses Bluetooth Low En-ergy (this is referenced as Bluetooth LE, BLE, BTLE, or Bluetooth Smart - seehttp://en.wikipedia.org/wiki/Bluetooth_low_energy). This isdone via AirLink.

Prior versions of the tracker used a proprietary ANT protocol (http://en.wikipedia.org/wiki/ANT_%28network%29). This is a 2.4 Ghz bidirec-tional Personal Area Network (PAN) protocol.

Both BLE and ANT are protocols meant for short-range, low-power, low-maintenance networks.

BLE emerged in 1998, defined as part of the Bluetooth 4.0 specifications. Itis incompatible with standard Bluetooth (unless dual-mode is implemented whereboth Bluetooth and BLE are supported).

BLE packets have 2 different types of PDU: advertising PDUs and data PDUs.Advertising occurs either when the device broadcasts its presence (ADV IND) or ifsomeone starts a scan (SCAN REQ) to which devices respond with a SCAN RSP.This occurs on channels 37, 38 or 39.

A typical transaction consists of:

• Device advertises itself (e.g ADV IND or ADV DIRECT IND)

• Master sends a CONNECT REQ, followed by an Empty Packet.

• Device (slave) sends a ATT packet containing for example a Handle ValueIndication

• Master acknowledges with an Empty Packet

• Device terminates connection with a LL TERMINATE IND

• Master acknowledges with an Empty Packet

To sniff Bluetooth LE, we can use:

• Ubertooth https://github.com/greatscottgadgets/ubertooth

• Bluefruit LE Sniffer https://www.adafruit.com/product/2269

3.1 BLE stack

The USB payload is encapsulated in attribute values of Attribute packets:

Application

Host Controller Interface

L2CAP - Logical Link and Adaptation Layer

ATT - Attribute Protocol

LL - Link Layer

51

Bluetooth BLEDate 1994 1998Frequency band 2.4- to 2.483-GHz sameFrequency Hop-ping SpreadSpectrum (FHSS) -at PHY level

1600 hops per secondover 79 1-MHz-widechannels

40 2-MHz-wide channels.37 data channels and 3 ad-vertising channels

Symbol rates 1, 2, or 3 Mbits/s 1 Mbit/sApplicationthroughput

0.7-2.1 Mbits/s 305 Kbits/s

Connection type When a device is con-nected, a link is main-tained even if no data issent

Maximum range 150 meters (open field)Latency (to con-nect)

100+ms less than 6ms

Max current 25mA? 15mAPower consump-tion

10mW - Between 2 and100 times less than Blue-tooth

Security 56 to 128 bit AES-128 CCM at LinkLayer (LL) level

Table 12: Comparison between Bluetooth and BLE

52

L2CAP serves as a protocol multiplexer. It also handles packet fragmentation.L2CAP packets contains:

• a length

• a channel identifier (CID) where 0x0004 is for the ATTribute protocol.

3.1.1 BLE security

BLE uses AES-128 CCM for link-layer (LL) encryption. AES-CCM is (currently)secure, but BLE’s key exchange protocol is flawed [Rya13]. The protocol followsthese steps:

1. A temporary 128-bit AES key (TK) is selected based on pairing mode:

• Just Works(TM): key is zeros

• 6-digit pin: key is a value between 0 and 999,999 padded to 128 bits

• Out of Band (OOB): key is defined by other means. In that case,[Rya13]’s bruteforce normally fails, however OOB is seldom used.

2. A short term key is established (STK), based on TK

3. A long term ker is established (LTK), based on STK, and can be used acrosssessions. However, at the beginning of each session, a nonce is exchanged.[Rya13] forces by rejected the LTK (LL REJECT IND)

[Rya13] attacks it as follows:

1. If a LTK is established, reject it by sending a LL REJECT IND packet. Goto 2.

2. If a LTK is not established, brute force TK, deduce STK and LTK.

3. Once LTK is known, sniff the packets for the nonce, if necessary jam the con-nection to force a new session, and thus force master and slave to exchangea new nonce.

3.2 ATT

ATT is the Attribute Protocol [Gup13, TCAD14]. Attributes can be fetched bya 16-bit unique identifier handle (which does not change across sessions). Thishandle makes the attribute addressable. 0x0000 is an invalid handle.

Conceptually, attributes are always located on the server and accessed (andpotentially modified) by the client.

The next transaction is not sent until the previous one has finished.Possible commands are:

53

• Read Request and Read Response: to read a given attribute. The responsecontains the value of the attribute.

• Write Request and Response: write a given attribute with a given value andacknowledge the command. The response does not include any particularinformation.

• Write Command: it is the same as a write request, but with no expectedacknowledgement.

Opcode: Write Command (0x52)Handle: 0x000eValue: c0:06:04:00:00:00:00

Sending a write command with gatttool can be done using char-write-cmd:

[F3:F7:63:78:73:09][LE]> char-write-cmd 0x000c 0100

• Signed Write: this command is sent from the client to the server, to set aparticular attribute value. There is no response. Additionally, a “signed”write includes a signature.Example:

Opcode: Signed Write Command (0xd2)Handle: 0x897bValue: c0:a2:b0:c2:33:37:6b:55Sign Counter: 1701594738Signature: 78:41:74:46:6f:72:74:69

Note that, in that case, the packet layout is wrong as value, sign counter andsignature contain the USB packet (so, for instance, the signature is not a realsignature!).

• Handle Value Notification: in the Bluetooth terminology, this command issent from the server to the client, to provide information about an attribute atany time. There is no response to this command.

Opcode: Handle Value Notification (0x1b)Handle: 0x000bValue: c00900... (USB packet)

• Handle Value Indication: this is the same as a Handle Value Notification,except this command gets a response (client to server) called Handle ValueConfirmation.

54

Figure 6: BLE capture showing a Get Megadump command

• Find Information Request and Response: to obtain a list of all attributesin a particular handle range. The response is a list of handle/UUID pairs.Example:

Opcode: Find Information Request (0x04)Starting Handle: 0x0009Ending Handle: 0x000e

and response:

Opcode: Find Information Response (0x05)UUID Format: 16-bit UUIDs (0x01)Handle: 0x0009UUID: GATT Primary Service Declaration (0x2800)Handle: 0x000aUUID: GATT Characteristic Declaration (0x2803)

• Find By Type Value Request and Response: to find the handle ranges thatmatch a given UUID.

Opcode: Find By Type Value Request (0x06)Starting Handle: 0x0001Ending Handle: 0xffffUUID: GATT Primary Service Declaration (0x2800)Value: ba:56:89:a6:fa:bf:a2:bd:01:46:7d:6e:60:48:ab:ad

and the response:

55

Command Method codeError Response 0x01Find Information Request 0x04Find Information Response 0x05Find By Type Value Request 0x06Find By Type Value Response 0x07Read request 0x0aRead response 0x0bWrite request 0x12Write response 0x13Handle value notification 0x1b

Table 13: Method of command to be set in opcode field

Battery service UUID 0x180FBattery Level characteristic 0x2A19

Table 14: Assigned UUID

Opcode: Find By Type Value Response (0x07)Handles info:Handle: 0x0009Group End Handle: 0x000e

• Error Response: this is sent in lieu of the normal response when an erroroccurs. For example, this trace shows an error response to a Find By TypeValue Request for a handle 0x000a because the attribute is not found:

Opcode: Error Response (0x01)Request Opcode in Error: Find By Type Value Request (0x06)Handle in Error : 0x000aError Code: Attribute Not Found (0x0a)

Each command is referred to by its opcode. Opcodes are encoded on 1 byte inATT packets with:

• byte 1 is for authentication signature true(1) or false(0)

• byte 2 is for command (1) or not (0)

• bytes 3-8 are for the method. For example, 0x12 is for write requests

56

3.3 GAP

GAP stands for Generic Access Protocol. It is a mandatory service of BLE. https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gap:

It controls connections and advertising in Bluetooth. GAP is whatmakes your device visible to the outside world, and determines howtwo devices can (or can’t) interact with each other.

3.4 GATT

See https://epxx.co/artigos/bluetooth_gatt.phpGATT stands for Generic Attribute Profile, and sits above ATT (Attribute Pro-

tocol). It deals with actual data transfer procedures (contrary to GAP which defineslow level interactions with the device). It is a mandatory service for BLE (and wasmade for Bluetooth Low Energy).

GATT handles attributes, where attributes are conceptual entities that carrydata (or meta data). In GATT terminology, those attributes are located on theserver: that’s the flex (yes, the peripheral) and accessed by a client.

An attribute consists of:

1. A handle. 16-bit. That’s how attributes are accessed.

2. A type. This is a UUID.

3. Permissions. Ex: access permissions, encryption...

4. A value. 512 bytes at most.

GATT organizes attributes in services (section 3.4.1) and characteristics (sec-tion 3.4.2).

3.4.1 GATT services

GATT services are collections of characteristics and relationships to other services.A GATT service is defined by a service declaration attribute:

• A 16-bit handle (to address the service)

• A type. Primary (0x2800) or secondary services (0x2801)

• A permission: read only

• A value: the service’s UUID

Several standard services (e.g Device Information) are defined by BluetoothSIG. In that case, their UUID is in the form:

57

YYYYXXXX-0000-1000-8000-00805f9b34fb

where 00000000-0000-1000-8000-00805F9B34FB is the base UUID, defined athttps://www.bluetooth.com/specifications/assigned-numbers/service-discovery. Such UUIDs are sometimes shortened 0xXXXX orOxYYYYXXXX.

The list of standard services can be found at https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx.

3.4.2 GATT characteristics

Characteristics are the entities/containers which contain user data. They are definedby:

1. A characteristic declaration attribute: metadata for the user data

• Handle

• Type: 0x2803

• Permission: read only

• Value: characteristic UUID

2. A characteristic value attribute: contains the user data

• Handle

• Type: characteristic UUID

• Permission

• Value

3. Optional: characteristic descriptors: expands the declaration with more info.

A list of standard characteristics can be found at https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicsHome.aspx.

Characteristics properties are on 1 byte:

• 0x01 broadcast

• 0x02 read

• 0x04 write without response

• 0x08 write

• 0x10 notify

• 0x20 indicate

58

• 0x40 authenticated signed writes

• 0x80 extended properties

See Bluetooth Core Specifications v4.0 Vol.3, Part G, section 3.3.1.1. Uncertain,but it seems that characteristics can be shared by several services.

3.5 Using a BLE interface

If your computer supports Bluetooth Low Energy, or with a basic BLE USB dongle,it is possible to issue a few commands.

3.5.1 Installation of bluez

On Linux, install the latest version of bluez (and uninstall any older bluez* pack-age):

$ wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.41.tar.xz$ tar -xvf bluez-5.41.tar.xz$ cd bluez-5.41/$ sudo apt-get install libudev-dev libical-dev libreadline-dev$ ./configure enable-library disable-systemd$ make$ make check$ sudo make install$ sudo cp attrib/gatttool /usr/bin$ sudo cp tools/btmgmt /usr/bin/

3.5.2 Configuring the BLE interface

My BLE dongle is seen as:

$ lsusb (on the laptop)Bus 003 Device 011: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode

Then configure the interface:

$ sudo hciconfig hci0 up

3.5.3 Scanning for BLE devices

Once the BLE interface is up (see section 3.5.2), it is possible to scan for nearbyBLE devices:

$ sudo hcitool lescanF3:F7:63:78:73:09 Flex

59

3.5.4 Connecting to a BLE device

The BLE interface needs to be up (see section 3.5.2).To connect to a Fitbit Flex tracker, you must use random addresses (see https:

//blog.lacklustre.net/posts/Bluetooth_Recon_With_BlueZ/).The specs defines two types of addresses: public and random addresses. Randommeans you do not care about your own address.

$ sudo gatttool -I -t random -b F3:F7:63:78:73:09[ ][F3:F7:63:78:73:09][LE]> connect[CON][F3:F7:63:78:73:09][LE]

On the charge, authentication is required, and connecting with high security isan option: https://hackimalement.wordpress.com/2015/06/13/bluetooth-low-energy-theorie-et-pratique/.

If you get “Error: connect: Connection refused (111)” make sure to set thedongle in BLE mode:

$ sudo bluez-path/tools/btmgmt le onhci0 Set Low Energy complete, settings: powered br/edr le

Alternatively, if you don’t need GATT, you can connect using hcitool only:

$ sudo hcitool -i hci0 lecc --random F3:F7:63:78:73:09

If you want more information, launch hcidump before (optionally with -x or-R):

$ hcidump &

Then, further commands will display the HCI events and commands.Note it is not possible to use hcitool, hcidump or gatttool with Fitbit’s USB

dongle.

3.5.5 Issuing ATT commands

You can use a tool named gatttool. This tool is compiled in bluez-5.41 inattrib.

• Connect to the device (see section 3.5.4).

[F3:F7:63:78:73:09][LE]> connectAttempting to connect to F3:F7:63:78:73:09Connection successful

• Listing primary services

60

[F3:F7:63:78:73:09][LE]> primaryattr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fbattr handle: 0x0008, end grp handle: 0x0008 uuid: 00001801-0000-1000-8000-00805f9b34fbattr handle: 0x0009, end grp handle: 0x000e uuid: adab06e3-6e7d-4601-bda2-bffaa68956baattr handle: 0x000f, end grp handle: 0x0012 uuid: 558dfa00-4fa8-4105-9f02-4eaa93e62980attr handle: 0x0013, end grp handle: 0x0018 uuid: 0000180a-0000-1000-8000-00805f9b34fbattr handle: 0x0019, end grp handle: 0xffff uuid: 0000180f-0000-1000-8000-00805f9b34fb

See also [Mar16].

• Listing characteristics

[F3:F7:63:78:73:09][LE]> characteristicshandle: 0x0002, char properties: 0x02, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fbhandle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fbhandle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fbhandle: 0x000a, char properties: 0x12, char value handle: 0x000b, uuid: adabfb01-6e7d-4601-bda2-bffaa68956bahandle: 0x000d, char properties: 0x06, char value handle: 0x000e, uuid: adabfb02-6e7d-4601-bda2-bffaa68956bahandle: 0x0010, char properties: 0x12, char value handle: 0x0011, uuid: 558dfa01-4fa8-4105-9f02-4eaa93e62980handle: 0x0014, char properties: 0x02, char value handle: 0x0015, uuid: 00002a29-0000-1000-8000-00805f9b34fbhandle: 0x0017, char properties: 0x02, char value handle: 0x0018, uuid: 000006e3-0000-1000-8000-00805f9b34fbhandle: 0x001a, char properties: 0x12, char value handle: 0x001b, uuid: 00002a19-0000-1000-8000-00805f9b34fb

• Read Request

[F3:F7:63:78:73:09][LE]> char-read-hnd 0x000cCharacteristic value/descriptor: 01 00

• Write Request

char-write-req 0x000c 0000Characteristic value was written successfully

• Write Command

[F3:F7:63:78:73:09][LE]> char-write-cmd 0x000c 0100

• Handle Value Notification. To receive those notifications, you must spec-ify –listen and set the Client Characteristic Configuration attributes to 0100(get notifications). The Client Characteristic Configuration attributes can belisted using:

61

[F3:F7:63:78:73:09][LE]> char-read-uuid 2902handle: 0x000c value: 01 00handle: 0x0012 value: 00 00handle: 0x001c value: 00 00

• Handle Value Indication. Same as handle value notification but set valueto 0200. Note thant 0300 will set both indication and notification and 0000will disable.

3.6 Bluefruit LE Sniffer

Bluefruit LE Sniffer contains a Bluetooth LE SoC from Nordic, nRF51822 https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822.

To capture traffic on Linux, get sniffer from https://github.com/adafruit/Adafruit_BLESniffer_Python, make sure python-serial is installed, thenrun:

sudo python sniffer.py /dev/ttyUSB0Logging data to logs/capture.pcapConnecting to sniffer on /dev/ttyUSB0Scanning for BLE devices (5s) ...Found 3 BLE devices:

[1] "" (F3:F7:63:78:73:09, RSSI = -67)[2] "" (F4:5C:89:8A:F4:1C, RSSI = -87)[3] "" (65:ED:C3:EB:35:DB, RSSI = -85)

Note that the tracker cannot be scanned if somebody is already connected to it.To exit sniffing, simply press Ctrl-C and view logs in logs directory:

-rw-r--r-- 1 root root 118255 Nov 21 14:12 capture.pcap-rw-r--r-- 1 root root 5034 Nov 21 14:11 log.txt

To read pcaps captured by the sniffer with wireshark, you need to compilethe Nordic BLE dissector plugin. The dissector sources are available at https://github.com/adafruit/Adafruit_BLESniffer_Python. The in-stallation procedure is explained at [Sti15].

A few required packages: libpcap-dev libgtk2.0-dev libtool-binI personally compiled wireshark 1.12 with:

$ ./configure --with-qt=no --with-gtk2=yes

62

3.7 Ubertooth

Ubertooth is:

• a USB dongle

• a RF frontend radio chip: CC2400

• a LPC microcontroller

It is possible to sniff BLE traffic using the Ubertooth hardware. See https://blog.lacklustre.net/posts/BLE_Fun_With_Ubertooth:_Sniffing_Bluetooth_Smart_and_Cracking_Its_Crypto/ and https://github.com/greatscottgadgets/ubertooth.

I used Ubertooth One r161-p8 [Spi15]BLE sniffing has bugs (see https://github.com/greatscottgadgets/

ubertooth/issues/113): the capture does not work all the time, apparentlybecause BLE advertising may use three channels (37, 38 or 39) and the Ubertoothhardware can only listen at one channel at the time. Thus, if it’s not listening at theright channel, it does not capture the packets2.

Nevertheless, I manage to capture BLE packets “most of the time” using Uber-tooth firmware 2015-10-R1 and corresponding tools.

The procedure to update the firmware is described at here:

$ ubertooth-dfu -d bluetooth_rxtx.dfu -rSwitching to DFU mode...Checking firmware signature..................................Detached

To capture packets, using -f (mandatory), and it seems to work better if you askthe tool to tracker the MAC address of the dongle or the tracker, and if you start bytrying the advertising channel 38:

$ ubertooth-btle -tf3:f7:63:78:73:09 -f -A 38 -c followdongle.pcapor$ ubertooth-btle -t25:d4:d5:14:33:88 -f -A 38 -c followtracker.pcap

3.8 Fitbit’s BLE

3.8.1 Fitbit Flex GATT services

All services listed in Table 15 have a value of type GATT Primary ServiceDeclaration (00002800-0000-1000-8000-00805f9b34fb - shortened 0x2800).

63

Handle Value Description0x0001 00001800-0000-1000-8000-00805f9b34fb 0x1800 Generic Access (standard)0x0008 00001801-0000-1000-8000-00805f9b34fb 0x1801 Generic Attribute (standard)0x0009 ADAB30D4-6E7D-4601-BDA2-BFFAA68956BA0x000f 558DFA00-4FA8-4105-9F02-4EAA93E62980 Fitness Data Service0x0013 0000180a-0000-1000-8000-00805f9b34fb 0x180a Device Information (standard)0x0019 0000180f-0000-1000-8000-00805f9b34fb 0x180F Battery Service (standard)

Table 15: Fitbit Flex GATT services

3.8.2 Fitbit Flex descriptors

Descriptors are attributes with a specific meaning

3.8.3 Fitbit Flex characteristics

• 00002a00-0000-1000-8000-00805f9b34fb (shortened UUID: 0x2a00):Device Name (standard). Handle 0x0002. Value handle: 0x0003. Value ex-ample: 46 6c 65 78 (ASCII: Flex)

• 00002a01-0000-1000-8000-00805f9b34fb (0x2a01) Appearance(standard). Handle 0x0004. Value handle 0x0005. Value example: 00 00

• 00002a04-0000-1000-8000-00805f9b34fb (0x2a04). PeripheralPreferred Connection Parameters (standard). Handle 0x0006. Value han-dle 0x0007. Example: 06 00 06 00 00 00 c8 00 (that’s the value sent by theInit Air Link command) - this corresponds to Connection interval: 7.50ms,slave latency: 0, supervision timeout multiplier:200

• adabfb01-6e7d-4601-bda2-bffaa68956ba. Handle 0x000a. Valuehandle 0x000b. Example of content: displays the previous command? e.gc0 42 ... (end of dump)

• adabfb02-6e7d-4601-bda2-bffaa68956ba. Handle 0x000d. Valuehandle 0x000e. Example of content: displays another of the previous com-mands? e.g. c0 06 01 02 03 04 (display code)

• 558dfa01-4fa8-4105-9f02-4eaa93e62980. Enable Notificationsto retrieve fitness data. Handle 0x0010. Value handle 0x0011. Example ofcontent: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

• 00002a29-0000-1000-8000-00805f9b34fb (0x2a29) ManufacturerString Name (standard). Handle 0x0014. Value handle 0x0015. Typical

2That’s the current apparent reason, but it’s under investigation.

64

UUID of type Short Type meaning Handleswith thattype

00002800-0000-1000-8000-00805f9b34fb 0x2800 GATT PrimaryService Declara-tion

0x0001,0x8, 0x9,0xf, 0x13,0x19

00002803-0000-1000-8000-00805f9b34fb 0x2803 GATT Characteris-tic Declaration

0x2, 0x4,0x6, 0xa,0xd, 0x10,0x14,0x17...

00002a00-0000-1000-8000-00805f9b34fb 0x2A00 Device Name 0x000300002a01-0000-1000-8000-00805f9b34fb 0x2a01 Appearance 0x000500002a04-0000-1000-8000-00805f9b34fb 0x2a04 Peripheral Pre-

ferred ConnectionParameters

0x0007

00002a19-0000-1000-8000-00805f9b34fb 0x2a19 Battery Level 0x001b00002a29-0000-1000-8000-00805f9b34fb 0x2a29 Manufacturer

Name String0x0015

00002902-0000-1000-8000-00805f9b34fb 0x2902 Client Characteris-tic Configuration

0x000c,0x0012

00002904-0000-1000-8000-00805f9b34fb 0x2904 Characteristic Pre-sentation Format

0x0016,

000006e3-0000-1000-8000-00805f9b34fb ? 0x0018adabfb01-6e7d-4601-bda2-bffaa68956ba ? 0x000badabfb02-6e7d-4601-bda2-bffaa68956ba ? 0x000e558dfa01-4fa8-4105-9f02-4eaa93e62980 ? 0x0011

Table 16: Fitbit descriptors

65

value: 46 69 74 62 69 74 00 00 00 00 00 00 00 00 00 00 00 00 00 (ASCII:Fitbit ...)

• 0000fb00-0000-1000-8000-00805f9b34fbHandle 0x0017 Valuehandle 0x0018. Example of content: 07 04 (note this belongs to the deviceinformation service, so it could be something like the tracker version)

• 00002a19-0000-1000-8000-00805f9b34fb (0x2a19) Battery Level(standard). Handle 0x001a. Value handle 0x001b. Example of content: hexvalue between 0-100? I read 0x20. You get notifications when it changes.

3.8.4 BLE capture flow

1 selectTracker()2 doLink()3 doInject(id=0x09)4 doInfect(id=0x06, reinit=False,5 data = [0x04, 0x00, 0x00, 0x00, 0x00])6 doInfect(id=0x04, reinit=False, data = [0x00])7 doInfect(id=0x24, reinit=False,8 data = [0x04, 0x00, 0x00, 0x00, 0x00])9 doInfect(id=0x02, reinit=False, data = [0x00])

10 doInfect(id=0x10, reinit=False,11 data = [0x04, 0x00, 0x00, 0x00, 0x00])12 doInfect(id=0x05, reinit=True)

This corresponds to what Galileo says in its debug messages:

Discovering for UUID adab0000-6e7d-4601-bda2-bffaa68956ba: 0xfb00, 0xfb01, 0xfb02

Basically, once a Bluetooth session is set up between the dongle and the tracker,the information flows as such (e.g see Table 18)

• The dongle sends its requests with an ATT Write Command (0x52 = noauthentication signature, cmmand, method write request) to handle 0x000e(always that one). The value contains the USB payload with only usefulbytes (no 00 padding nor training useful length byte).

Precisely, the expected format of a USB packet for the tracker is:

C0 CC PP ... PP 00 .. 00 UL

in that case, at BLE ATT level, we see:

C0 CC PP ... PP

• The tracker responds with a Handle Value Notification (0x1b) on handle0x000b (always that one). The value contains the payload

66

Codelinenumber

Frame no. Direction BLE packet

29591 D→ T Find By Type Value Request: search for a GATT Pri-mary service declaration between 0x0001 and 0xffff

29594 T→ D Find By Type Value Response: we found it from0x0009 to 0x000e

29595 D→ T Find By Type Value Request: search for a GATT Pri-mary service declaration between 0x000a and 0xffff.Why is it searching again?

29598 T→ D Error Response: no attribute at 0x0a29599 D→ T Find Information Request for handles 0x0009 to

0x000e29602 T→ D Find Information Response: we have GATT Primary

service declaration in 0x0009, GATT characteristicdeclaration in 0x000a

29603 D→ T Find Information Request for handles 0x000b to0x000e

29606 T→ D Find Information Response: handle 0x000b isfor service UUID adabfb01-6e7d-4601-bda2-bffaa68956ba

29607 D→ T Find Information Request for handles 0x000c to0x000e

29610 T→ D Find Information Response: handle 0x000c is forclient characteristic configuration (0x2902), and0x000d is for GATT characteristic declaration(0x2803)

1 29611 D→ T Find Information Request for handle 0x000e1 29614 T→ D Find Information Response: this is service UUID

adabfb01-6e7d-4601-bda2-bffaa68956ba1 29618 T→ D Read Response: 12:0b:00:ba:56:89:a6:fa:-

bf:a2:bd:01:46:7d:6e:01:fb:ab:ad service discoveryresponse for UUID adabfb01-6e7d-4601-bda2-bffaa68956ba

1 29622 T→ D Read Response: 06:0e:00:ba:56:89:a6:fa:-bf:a2:bd:01:46:7d:6e:02:fb:ab:ad service discoveryresponse for UUID adabfb02-6e7d-4601-bda2-bffaa68956ba

Table 17: Flow of BLE packets corresponding to service discovery

67

2 c0:0a:0a:00:-06:00:06:00:-00:00:c8:00

29625 D→ T Write Command: Initialize Air Link

2 c0:14:0c:01:-02:00:91:cf:-77:62:ae:cd

29703 T→ D Handle Value Notification: air linkinitialized response - contains thetracker’s major/minor version (1.2) andMAC address (91:cf:77:62:ae:cd)

3? c0:a2:b0:c2:-33:37:6b:55:-72:46:6c:65:-78:41:74:46:-6f:72:74:69

29706 D→ T Signed Write Command: ? - containspart of the injected string

3 c0:09:00:48:-61:63:6b:55:-72:46:6c:65:-78:41:74:46:-6f:72:74:69

29711 T→ D Handle Value Notification: Echo Re-sponse - contains the injected string

4-5 c0:06:04:00:-00:00:00

30222 D→ T Write Command

c0:02 30231 T→ D Handle Value Notification: ack re-sponse

6 c0:04:00 30374 D→ T Write Commandc0:02 30385 T→ D Handle Value Notification: ack re-

sponse7-8 c0:24:04:00:-

00:00:0030526 D→ T Write Command

c0:12:04:00:00 30529 T→ D Handle Value Notification: First AckBlock Response

9 c0:02:00 30661 D→ T Write Commandc0:03:04:10 30664 T→ D Handle Value Notification: typical er-

ror response to ack (c0 02) with morethan 2 useful bytes 2.4.2

10-11 c0:10:04:00:-00:00:00

30790 D→ T Write Command

c0:03:09:10 30793 T→ D Handle Value Notification: typical er-ror indicating a bad dump type 2.4.2

12 30953 T→ D Like frame no. 2961812 30957 T→ D Like frame no. 2962212 30962 D→ T Like 29625. Initialize Air Link12 31030 T→ D Like 29703. air link initialized re-

sponse12 c0:05:01:02:03 31033 D→ T Write Command

c0:05:01:02:03 31038 T→ D Handle Value Notification: typical an-swer to an alert user request

68

Frameno

Direction Command

148 D→ T Write Command (0x52) for handle 0x000e withvalue c0 10 0d (get dump)

154 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 41 0d (start of dump)

156-656

T→ D Handle Value Notification (0x1b) for handle 0x000bwith value being the dump

659 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 42 0d d4 41 a3 0c 00 00

660 T→ D Same as 659?664 D→ T Write Request for handle 0x000c - to be overwritten

with 0x0000667 T→ D Write Response, acknowledging previous write in

664

Table 18: Flow corresponding to getting megadump from tracker

Frameno

Direction Command

107 D→ T Write Command (0x52 = no authentication signa-ture, cmmand, method write request) for handle0x000e with value c0 05

109 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 05

Table 19: Flow corresponding to sending an alert to the tracker

Frameno

Direction Command

244 D→ T Write Command (0x52 = no authentication signa-ture, cmmand, method write request) for handle0x000e with value c0 50 00 01 03 04 05 06 07

249 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 51 20 43 8a 54 71...

1114 D→ T Write Command (0x52 = no authentication signa-ture, cmmand, method write request) for handle0x000e with value c0 50 00 01 03 04 05 06 07

.. .. ..

Table 20: Flow corresponding to getting random data via uncomplete authentica-tion

69

Note that tables 18 and 21 carry encrypted payload. This means that decryptionoccurs on the tracker itself, and not on the dongle.

The first minidump is:

30:02:00:00:01:00:f4:01:00:00:dc:e7:12:31:10:07:09:d0:cc:be07:0f:72:ed:76:81:1e:ec:1c:56:c0:77:67:81:9d:90:24:2b:dc:3fef:ca:07:10:86:a9:d9:78:5e:02:1b:9c:7b:fc:6e:cc:d0:e2:b0:d9a4:bc:74:35:55:d5:77:e0:81:ac:ac:39:57:f3:c8:a2:7f:03:22:bc6c:ba:03:d0:c4:de:b6:2c:52:6a:30:01:23:7b:eb:b7:eb:cb:e0:5386:af:bd:d5:fc:12:2a:dd:8b:86:11:c9:e4:17:e9:65:b5:e2:d1:566e:00:00

The second minidump, we get is:

30:02:00:00:01:00:fa:01:00:00:dc:e7:12:31:10:07:7a:c7:75:a3c2:c8:20:97:0e:d2:85:a1:52:a2:6f:45:c9:b0:bb:bc:5a:be:ab:70a2:f5:4f:3c:c9:4b:6d:df:68:8a:6f:31:9d:00:c1:ab:a4:bf:88:7128:88:30:1e:57:47:fe:f8:0e:e4:b5:8d:ea:4d:be:33:ca:c9:e9:3519:86:e9:a0:aa:8d:00:0f:84:b9:11:c1:90:09:b6:ba:09:89:de:0405:25:e5:58:a6:be:f1:a2:f4:fe:2a:95:67:3e:d1:4d:b0:6f:2a:e86e:00:00

Note that if the tracker does not receive a packet, the dongle resends it. Seepackets 108920-108923.

3.8.5 Fitbit Service Examples

Battery Service According to Bluetooth Specs (https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.battery_service.xml), the Battery Service has a single charac-teristic which is:

The Battery Level characteristic is read using the GATT Read Char-acteristic Value sub-procedure and returns the current battery level asa percentage from 0% to 100%; 0% represents a battery that is fullydischarged, 100% represents a battery that is fully charged.

The Battery Level characteristic has UUID 0x2a19 and belongs to Battery Ser-vice (0x180f). Its value can read and notifications can sent when the value changes.Its type is Client Characteristic Configuration (i.e 0x2902) which “defines how thecharacteristic may be configured by a specific client” (see Bluetooth Specs).

According to the specs “A client may read and write this descriptor to deter-mine and set the configuration for that client. Authentication and authorizationmay be required by the server to write this descriptor.”.

• Default value is 0x0000

70

Frameno

Direction Command

3358 D→ T Write Command (0x52) on handle 0x000e withvalue c0 10 03 (requesting microdump)

3389 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 41 03 (start of dump)

3391 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value 30:02:00:00: 01:00:f4:01: 00:00:dc:e7:12:31:10:07 :09:d0:cc:be. This corresponds to a de-vice identifier of dc:e7:12:31:10:07

3405 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0:42:03:d2: b3:7b:00:00:00. This is thepacket of end of dump. In this case, the size of thedump is 0x7b (123 bytes).

3592 D→ T Write Command (0x52) on handle 0x000e withvalue c0:24:01:69:60:02:00:46:07:00. This notifiesthe tracker that the dongle has data it wants to send.The size of the data is 0x026069 (155753 bytes).

3595 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 12 01 00 00 - which means the trackeracknowledges the block.

3598 D→ T Write Command (0x52) on handle 0x000e withvalue 30 02 ... The dongle is pushing the minidumpresponse to the tracker.

3603 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 13 11 00 00 - which means the trackeracknowledges the previous block.

140229 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 13 e1 00 00 acknowledges the lastblock.

140236 D→ T Write Command (0x52) on handle 0x000e withvalue 60 02 ?

141340 D→ T Write Command (0x52) on handle 0x000e withvalue c0 10 03 : requesting another minidump

141347 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0 41 03 (start of dump)

141367 T→ D Handle Value Notification (0x1b) for handle 0x000bwith value c0:42:03:bf:14:7b:00:00:00 (end ofdump) - again 7b bytes.

Table 21: Flow corresponding to a firmware update

71

• bit 1: notifications enabled (1) or not (0).

• bit 2: indications enabled (1) or not (0)

• other bits are reserved

Map for the Battery Level characteristic:

• Characteristic UUID: 00002a19-0000-1000-8000-00805f9b34fb (0x2a19)

• Characteristic included in Battery Service (0x180f).

• Characteristic Handle: 0x001a

• Value handle: 0x001b

• Value type: 0x2902 Client Characteristic Configuration

[CON][F3:F7:63:78:73:09][LE]>char-read-uuid 00002a19-0000-1000-8000-00805f9b34fb[CON][F3:F7:63:78:73:09][LE]>handle: 0x001b value: 00

The shortened uuid also works: char-read-uuid 2a19.This looks like the tracker is not charged.When it is charged:

[F3:F7:63:78:73:09][LE]> char-read-uuid 00002a19-0000-1000-8000-00805f9b34fbhandle: 0x001b value: 20Notification handle = 0x001b value: 1c[F3:F7:63:78:73:09][LE]> char-read-uuid 00002a19-0000-1000-8000-00805f9b34fbhandle: 0x001b value: 1c

To be notified when the battery value changes, you must set the appropriateClient Characteristic Configuration to 0x0001. The values which support configu-ration are the following:

[F3:F7:63:78:73:09][LE]> char-read-uuid 2902handle: 0x000c value: 00 00handle: 0x0012 value: 00 00handle: 0x001c value: 00 00

Only one of these values belongs to the battery service:

• 0x000c: belongs to service adabfb00-6e7d-4601-bda2-bffaa68956ba.

• 0x0012: belongs to 558dfa00-4fa8-4105-9f02-4eaa93e62980.

72

• 0x001c: belongs to 0000180f-0000-1000-8000-00805f9b34fb, which is thebattery service!

So, if we want to be notified for battery value changes, it’s 0x001c we mustconfigure:

[F3:F7:63:78:73:09][LE]> char-write-req 0x001c 0100Characteristic value was written successfully

And then, from now on the Battery Level will notify us of changes. For in-stance, below, we see the tracker is charging.

Notification handle = 0x001b value: 00Notification handle = 0x001b value: 04Notification handle = 0x001b value: 08Notification handle = 0x001b value: 10

Note the tracker does not allow to set 0200 or 0300 (indications impossible):

[F3:F7:63:78:73:09][LE]> char-write-req 0x001c 0200Error: Characteristic Write Request failed: Internal application error: I/O[F3:F7:63:78:73:09][LE]> char-write-req 0x001c 0300Error: Characteristic Write Request failed: Internal application error: I/O

This is because 0x001b has characteristics properties NOTIFY and READ only,but not INDICATION:

[F3:F7:63:78:73:09][LE]> characteristicshandle: 0x001a, char properties: 0x12, char value handle: 0x001b, uuid: 00002a19-0000-1000-8000-00805f9b34fb

Device Information Service The Device Information service has several char-acteristics. All are optional.

• Manufacturer Name String. This one is set to Fitbit followed by zeros.

• Model Number String. Not set.

• Serial Number String. Not set.

• Hardware Revision String. Not set.

• Firmware Revision String. Not set.

• Software Revision String. Not set.

• System ID. Not set.

• IEEE 11073-20601 Regulatory Certification Data List. Not set.

• PnP ID. Not set.

73

Misc notification data What are the other notifications for? Indeed, we are au-thorized to set notifications in two other cases: 0x000c and 0x0012. Using gatttool,we work out that:

• 0x000c: belongs to service adabfb00-6e7d-4601-bda2-bffaa68956ba.

> primaryattr handle: 0x0009, end grp handle: 0x000euuid: adabfb00-6e7d-4601-bda2-bffaa68956ba

and that it is used to configure handle 0x0018

> characteristicshandle: 0x0017, char properties: 0x02, char value handle:0x0018, uuid: 0000fb00-0000-1000-8000-00805f9b34fb

This handle contains:

[F3:F7:63:78:73:09][LE]> char-read-hnd 0x0018Characteristic value/descriptor: 07 04

• 0x0012: belongs to 558dfa00-4fa8-4105-9f02-4eaa93e62980.

> primaryattr handle: 0x000f, end grp handle: 0x0012uuid: 558dfa00-4fa8-4105-9f02-4eaa93e62980

and that it is used to configure handle 0x0011

handle: 0x0010, char properties: 0x12, char value handle: 0x0011,uuid: 558dfa01-4fa8-4105-9f02-4eaa93e62980

This handle contains:

char-read-hnd 0x0011Characteristic value/descriptor: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

4 Fitbit webserver

• Host: client.fitbit.com.

• This is IP address 108.168.255.213.

• whois 108.168.255.213 reveals the company is based in California(1201 12th Ave Apt 5, CA 94122), the hosts are administered by SoftLayerTechnologies (based in Dallas).

74

• The abuse e-mail is abuse@fitbit.com

• The web server is Apache Tomcat/7.0.56

import requestspayload = ’<?xml version="1.0"?><galileo-client version="2.0"></galileo-client>’

r = requests.post(’http://client.fitbit.com/tracker/client/message’,data=payload)

print r.content...Apache Tomcat/7.0.56 - Error report...

4.1 Silent alarms

It is possible to set silent alarms on the website or the mobile app. The alarms willhave the flex vibrate at a given time. The command for the alarm is sent in themegadump response after a sync with the flex.

• There is no communication with the web server or the dongle at the time thealarm goes off.

• There is no specific message in such a sync: the information has to be in-cluded in the megadump response.

5 Communication protocol with client.fitbit.com

HTTP POST to /tracker/client/message. Content-Type is text/xmlClient Server - /tracker/client/message

Client infoclient-id and version, mode ’status’

Server version2.0

Megadumpmode ’sync’

Megadump responsetracker id

5.1 Tracker to Server: galileo-client

Messages from tracker to server are encapsulated within the galileo-clientenvelope :<?xml version="1.0" encoding="UTF-8"?><galileo-client version="x.y">...</galileo-client>

75

So far, the version of galileo-client has only been 2.0.The galileo-client may contain various information:

• Client info

• Tracker data

• Server state

• Command responses

• UI responses

5.1.1 Client info

<client-info><client-id>...</client-id><client-version>...</client-version><client-mode>...</client-mode><dongle-version major="x" minor="y" hw="z">

</client-info>

• client-id, client-version: see Table 22

• client-mode:

– firmware: request newest firmware

– status: say hello

– sync: synchronize device

– force-sync: force synchronization (see http://hacksbypete.blogspot.fr/2013/01/fitbit-sync-decode-part-1.html)

– pair: pair the device

• dongle version: I used to have a major 1, minor 6 and hw 0. It is now major2, minor 5.

5.1.2 Tracker

<tracker tracker-id="..."><data>...</data>

</tracker>

• tracker-id: this identifies your device. Mine is 516706E749CF. This is notpresent for status.

76

Client Version User-Agent Client-idWindows Fitbit Connect 1.0.3.5511 Fitbit Agent

1.0 Win-dows

91a05321-5baf-45ff-8c40-bf425d578d45

Galileo [All] 0.5dev 6de4df71-17f9-43ea-9854-67f842021e05

Android Client Id 9925b84b-e50e-4c9a-8c4d-a3a1fbf17e7e

Android 5.1 client ? ea972f11-0d20-4fad-9ba0-9097368a5c7

Table 22: FitBit clients parameters

• type: this is an optional parameter. Possible types are assumed to be megad-ump, minidump, megadumpresponse, minidumpresponse.

• data: it is base64 encoded. Sample data below.

Base64 encoded of megadump (notifying of 22 new steps):

KAIAAAEA4AMAANLAVi4VB4wLO8nCexKYKrVFvDydBuFeu1Vxr0rAxXwnTfqqq3pIBd74R8AMyQ5pnPSTIDcgbANJtmvWUsoo0ekL9aCD08gMr2Kup9VxmIYvMsXWlRvHIZyaIfdp8Bp4lt+iCkVPv3+aDIB9H9b/y5Qn96cGd7vJ/Rv07Y3l3MK7xLz35NKYtAhG7qwa66zB2A6w0sZiKolmOVOGt8Mw34ug9qC4IwLEtAnyY331daUK3ChiiDzWrshNNn30hLunH4QO7tHz0gzWRWWZ5b4j1Q4Z+KVMljohw+3+0lk8ZC5JVVMDGDIV7ruiot1w+2sFGsxC4HuiBcYIppe8n4y3JLUA9lZm9MCeAme9tUS7vza4H2PjfA0q5NQjYHoSOXjk6LwBDqBlqcn3o4X+ccYg7Q4la/3YZ011TBA+Z4BheZr91ZyvFZUM9Mv/X0nOhZ0Q28DF5kc4hyxz2nRm0FVDDHNAtuG6w/8LP5nw/PLW3gs6N5hI0xfOItT38qGcHBv+BQL+4L2YHfQPzAq38iQihMQNhcWwA7BqaMSSmH+fkgoY6TpvUlrC2bYM61LfsloTVC++UJgXFnjLjXk+3sSKQDVpp3X+B/LFf2469fPr16qoLs2rL9fmvAEA

Example of base64 encoded megadump response

KAIAAAEAMwQAAEOR1liIFvhPjda1LlVT+JAIDe3AU+Vtm/1CfnPY2lpvXtUKidtoFKXoTxPm8Iqzxk4l5R9Z0aJvYHywfjXWPM3xQ6mqBYNhkED9/yZVI3EXsYJ4sHp31Kcd7BA8rGIdnEqhd4tykP8lpDLC2eKWKNJoPNadHoBD9gD2cGQvCS+Y8ztsKX0akB5OGU7EyK8AlcYX9OAH3Zxwfe/Qn2wA+h95rjEGJEpiHPXSLdt5LR20apPp6TucNROqAAA=

Example of base64 microdump

MAIAAAEAegMAANLAVi4VB8Etiw9GkWSqzyAAiOpzRUwefScuzCn9AcMsbGPcOgMkWZseF8i5owajlEJ8gNGlq5reyEIXorFP1XPmLjGUOPNKzwRehNF4HaGbV3ZhpkPB7C78pivEXsN06jDeMsGdG7wXz7qSX4PsbgAA

77

5.1.3 Server State

<server-state>...</server-state>

• server-state: corresponds to the last value sent by the server. Example:8p7p8luvopkjmwojdvtx

5.1.4 Command Responses

<command-response>see possible command responses

</command-response>There are several possible command responses to server commands:

• list-trackers: lists available trackers

<list-trackers><available-tracker><tracker-id> ...</tracker-id><tracker-attributes>0706</tracker-attributes><rsi>-57</rsi></available-tracker>

</list-trackers>

– tracker attributes: always 07 06 in my cases

– rsi: relative signal indication (strange, I always get -57)

• ack-tracker-data: this is to acknowledge data sent by the server

<ack-tracker-data tracker-id="516706E749CF" />

• paired-tracker-data<paired-tracker-data><bluetooth-id>MACADDRESS</bluetooth-id></paired-tracker-data>

5.1.5 UI responses

<ui-response action=".." />where the action is the name of the UI which was displayed (see 5.2.1).If an answer must be sent, then it is provided as a parameter. For example:

<ui-response action=".."><param name="chosenDevice">QUARK</param></ui-response>

78

5.2 Server to tracker

Answers from the server are found within galileo-server.<?xml version="1.0" encoding="UTF-8" standalone=’’yes’’?><galileo-server version="x.y">...</galileo-server>

So far version has only been 2.0.Within that enveloppe, one can find various other tags:

• server-version: this tag used to be empty. It now seems to contain a stringdescribing the environment and version of the server:

Environment: production; Version: 423d75dd50534bdddf356f20ba290c1b0aa5b2ec

• server-state: a random state string, e.g 8p7p8luvopkjmwojdvtx

• ui-request: to display a window popup

• tracker: contains megadump or minidump responses. E.g

<tracker tracker-id="09737863F7F3" type="megadumpresponse">...</tracker>

• commands

• back-off: tells us when we are expected to sync.

5.2.1 Server initiated popup

If a window pop-up is to be displayed, then the server also includes:<ui-request action=’’connecting’’>

<client-display containsForm=’’false’’ minDisplayTimeMs=’’20000’’

width=’’650’’ height=’’450’’>... document ... (lots of JavaScript)

</client-display></ui-request>

There are several UIs:

• init: initialize pairing

• connecting

• chooseDeviceType (e.g. flex, one, charge...)

• deviceList: to request a discovery of nearby trackers

79

• requestTap: to complete the pairing

• pairProgress (explicit!)

• done: e.g. pairing complete

5.2.2 Server commands

The server can send commands:<commands>several possible commands - see below

</commands>

• ack-tracker-data: to acknowledge tracker data sent by the client<ack-tracker-data tracker-id=’’...’’ />

• send data to the tracker, for example a megadump response<tracker tracker-id="516706E749CF" type="megadumpresponse"><data>KAIAAAEA4QMAAKHNsE7fVdO22n4l6dNU2XMRu9koser...</data></tracker>

• connect-to-tracker: for example, requests a microdump (or a megadump),and in the next command, disconnects from the tracker. and sends the mi-crodump or megadump response.<connect-to-tracker tracker-id=’’...’’ response-data=’’microdump’’/>

<connect-to-tracker tracker-id=’’...’’ response-data=’’megadump’’/>

<connect-to-tracker tracker-id=’’...’’ response-data=’’disconnect’’/>

• list-trackers: search given trackers with minimum signal strength. Searchto be done for min/max time. Searches only trackers with given attributes.<list-trackers immediateRsi=’’...’’ minDuration=’’...’’ maxDuration=’’...’’><searchAttribute>...</searchAttribute>

</list-trackers>

• pair-to-tracker: the tracker will return a microdump?

• tap-to-pair: at the end of the pairing, the user is requested to tap its tracker.

<tap-to-pair tracker-id="..." />

5.2.3 Back off

<back-off><min>900000</min><max>1800000</max>

80

• min. minimum delay for next sync. In milliseconds

• max. maximum delay for next sync.

5.3 Flow for pairing

Client Server

Request to pair a Flexclient-mode ’pair’, ui-response chooseDeviceType to QUARK

Initialize pairingui-request ’init’, client-display form with localized text etc

Ack pairing initclient-mode ’pair’, ui-response init

List nearby trackersui-request ’deviceList’, client-display form, list-trackers immediate-Rsi

My Trackersclient-mode ’pair’, available trackers

Tap your trackerui-request ’requestTap’, client-display form, tap-to-pair

Pairedclient-mode ’pair’, tracker with minidump, paired-tracker with MAC address

Request megadumpui-request ’pairProgress’, client-display form, connect-to-tracker megadump

Megadumpclient-mode ’pair’, tracker with megadump

Megadump responseui-request ’done’, client-display form, connect-to-tracker disconnect, tracker megadump response

Statusclient-mode ’status’

Statusgalileo-server

5.4 Playing with the protocol

Sending a dummy sync message with data = 1234: server answers nothing:<?xml version="1.0" encoding="UTF-8" standalone=’’yes’’?><galileo-server version="2.0"/>

Replay. Send a real sync message:

81

<?xml version="1.0" encoding="UTF-8"?><galileo-client version="2.0"><client-info><client-id>91a05321-5baf-45ff-8c40-bf425d578d45</client-id><client-version>1.0.3.5511</client-version><client-mode>sync</client-mode><dongle-version major="1" minor="6" hw="0" /></client-info><tracker tracker-id="516706E749CF"><data>KAIAAAEAiAQAANLAVi4VB61NpJw6oheXV2zglBDc9tqCkPIus1p7yLfErfEwfxYsnSO/rwXUGD8xNABLacuf9TCM3/e1WRN6V9vG/QBcOjjaUczeEIsVlve7U+un2gPvpO6KnVmEFQIejBLsYePo/14rb7MRloBCrOBKlb3JJzFv9OeXM+qVSVS0JRsIclmHdOglmnP72F3ByZu2KDHu0SgNe1sOqhbFF9gBXa3wolCvC2q+SU3FR/Sx0BjuIYTU3SRsrkfKdtnLK4UR2ACbvZd6C6bOhjQ9xvwxb4Yp8LEw5wrrw5ZNO82F4dc5DjHAoxgT8eWraWsxc3xeAhRHDHRQMNQhXHYM10domH6+81oFjpjZRudVhjJB4R/nxAmzMYL/kgawNcFNMm0gElN5MkjWRHlFUwTCHgRD+EHR0Ljqre4iAZVnLFhsHVxuXNdc45kOv/2tDmZkBWVTXAmlOxNy3s93le85KFDz7rsVzMHRFCNAywUWap2OxTIFeqj2lUkv7fD4FaPWrR5bybNligdusDMlwdI63d4tfcl3Myywe4cNLsWTwWl760w7pubjDPOQgOqMrrElnJOBHW67Bh2zPhqEg9Rz4NoRXa5WUmjVhgi/qgnsjM0NVsVfCq7QnViDm+KNpXyyKM+uFemIYMdsunjmMPiY79OFS8Y9PjbWNqySJm0cNUzdhu3oPA9aXauR9e0yCLc08V1qtikyKzt/Cw098O5SJekG0yAwECJ+x8safVIw/QOp83aw8vmciStxvqdycSCm1SkyclKlGtvnh5lgsYUxN4eA/KZVt6CAvcoUk97A+w/n+o9FJO4HmoDOZSblEsopdMvTBYCrvQYgJ0qcOiCm8to/KMa2cZB9+RBOEP+P7n0g0k1mYXPuUQM9eTOTxF2JzjsnMlClxlZ9LJrhGueBlZz5VAq+JiGVNNjv6aSiybFYNcRBm3NO5wPSwCZVLqSh4vmaCmReWSngB5nQIEGAp/q8FZQ7SCDoQmGfJvPEDpBhcx6MNpd2gzLdG+VCd/JrntlyLVjqsCJbixUC5ENEl5NviEGsKrepDrkn0LO7O27t8Jug2VjhUr2Nb6uKLX2CN132xmr1aIK15Or/dt6zw2nydBaW84hZeWnMntnbeybFjEPg99zF4pxPnIMqsNSuNdSLjxjdRLf5s29Vowe8eLx5ew0o3eR7PfI/dYXqxNUfn2dCutRGn3kb+9hUaugxaHl3oBEPNo8WgPQ253EQbsdyy53yDKiOy04Z8YsrHB0f0Xy9AiR7Ep27Z0S33qT2zOGkvVjZHu+31QFNVOeacdIWr2/EeQcBz7GKSEKmQS9kBlXdhrJrKRkXX5//5XOpJtOUeiRJfU4cGAl707y3CQxdiEtMp7hubwIcGSbsQDIgkPoplGPQ59A9xxPOtuST9zCGknQAiACncDUekKzelpWGVv17vLFLIFA04bhIFQWqAOhZ74ikr7ikaS0kPd3k/DSdsTMquQZhhqpHDBVf+YK3L1FgU0SiIzJHxC8SzQygHtlF1cBrp0XVdiOjxmKMVl1vbLIazQyAFsLGVm57hNz6hS9NSFz0YbBGa6p6z6MaOpT7TfIwhwQA</data></tracker></galileo-client>

The server responds:

82

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><galileo-server version="2.0"><server-version></server-version><tracker tracker-id="516706E749CF" type="megadumpresponse"><data>KAIAAAEAiQQAAD4AZromJAlNkAHNaSpYQhUnzSJuo8AW+AE467Jb/5ou1nhffA3koNiMRQgBTgpU5bfZNF5y56fvEokfClBQdPwonRT7hSIzLYXO+/I2BBthntJe5xdkPJQixfanpLCDd+xkHZcE5o18oyVkjmV+oaf0S/od/n1fiB4q1SZ+WHhmzUb17syeYmkeFSaQNUklJojbO4/aJgd+8Ubj53NZXmCi3MbTQLYGqlV3AsZrlTPEKU/8HpnQ5QyqAAA=</data></tracker></galileo-server>

If I replay the first megadump, the server now responds HTTP 429 (Too ManyRequests). With a valid megadump whose sequence counter is invalid, I managedto get this response: The server responds:<?xml version="1.0" encoding="UTF-8" standalone="yes"?><galileo-server version="2.0"><error>INVALID\_TRACKER\_DATA:com.fitbit.protocol.serializer.DataProcessingException: Parsing field timestamp of the objectof type com.fitbit.protocol.model.FieldType. IO error processing data.</error></galileo-server>

6 Mobile applications

Log data is sent by email (com.fitbit.util.c.b). The logs contain:

• zipped database

• battery level

• app name and version

• device manufacturer, model, product, brand, release

7 Dump file format

In the HTTP POST, we send the dump in base64 format.

7.1 Megadump

The megadump is sent in dump packets (section 2.4.11) , between a start of dumppacket (section 2.4.11), and an end of dump packet (section 2.4.11).

MM TT 00 00 VV VV SS SS SS SS NN NN NN NN NN NNEE EE EE ...

83

Model ValueFlex 0x28Zip 0xf4One 0x26

Charge 0x2dCharge HR 0x2e

Table 23: Device model byte - 1st byte of megadump

Model ValueGalileo 0x01

One 0x05Flex 0x07

Charge 0x08Charge HR 0x12

Alta 0x15

Table 24: Last byte of article number depends on tracker model

• Device model. 1 byte.

• Device type. 1 byte. It seems that 0x02 is for Tracker. Another possible typeis for scale or unknown.

• 2 bytes unused (or unknown)

• Security scheme. 2 bytes. Little endian.

– 0x0000 means unencrypted megadump (for old Fitbit Flex)

– 0x0001 means CRC-16

• Sequential Counter. 4 bytes? Eg. E8 03 00 00 Little endian format. Foreach different dump request, the counter is incremented by 2. Example: lasttime, sequence counter was 0x448. No requests has been issued since. Nextrequest will have sequence counter 0x44a.

• Article number. 6 bytes. As indicated on the shipping box (finding of“Dany” dsx@bluewin.ch). The last byte indicates the tracker’s model:

I have already encountered:

– 15 22 24 2F 15 07 - assumed to be for a FitBit Flex

– D2 C0 56 2E 15 07 - my FitBit Flex

– C9 9B F8 2D 15 07 - a colleague’s FitBit Flex

– 7B 2E 9F 2B 2D 05 - reported as a Fitbit One

84

– 7B 16 E4 2A 2A 05 - report as an old FitBit One.

– 97 4F 03 52 8D 12 - reported as a Fitbit Charge HR.

– EC 2B 18 32 4E 12 - reported as a Fitbit Charge HR

– 09 57 4c 30 11 07 - ?

– 6C 47 B3 44 A6 0B - reported as a Fitbit One

• Encrypted blob. Starts at offset 17 (0x11). Ends with some padding?

Example of megadump sent by the tracker:

28 02 00 00 01 00 00 05 00 00 d2 c0 56 2e 15 070b 38 a7 84 f9 f0 e8 0b 19 7f 1a cf be 9d a2 9172 94 93 5c 20 7d b7 90 80 13 94 86 2a d3 c4 66e4 a3 ce 3f 7f d9 8c eb ff 76 57 d0 3a bd 01 0151 71 8f 45 09 46 74 71 ab 55 01 a7 5b e2 bb 0b73 b0 d5 01 15 4c 0a 2e d3 13 a6 ac e4 4f cb 92..a1 f8 cc 5d bc fd 5c 7e 55 4a 13 45 8c 40 d1 576a 7c ed b3 7a cd 47 56 e1 04 00

For unencrypted megadumps, it seems we don’t have that model identifier.“Dany” reports he has instead “07 40 07 40”. Other people report this format:

MM TT 00 00 VV VV SS SS SS SS 00 00 00 00WW WW RR RR BB BB

where

• WW is the walking stride length in little endian, in mm.

• RR is the running stride length, little endian, in mm

• BB is the Basal Metabolic rate, little endian. Fitbit is said to use the standardMD Mifflin-St Jeor equation:

BMR = 9.99∗weight(kg)+6.25∗height(cm)−4.92∗age(years)+s (1)

where s is +5 for male and -161 for female.

For example

28 02 00 00 00 00 01 00 00 00 00 00 00 00 D2 02 89 03 D5 23

• Fitbit Flex (0x28)

• Tracker (0x02)

• Version (0.0)

85

• Sequence counter 0x0001

• Walking stride: 0x02d2 = 722mm

• Running stride: 0x0389 = 905mm

• BMR: 0x23d5 = 9173

Other example of megadump sent by the tracker:

28 02 00 00 01 00 57 15 01 00 C9 9B F8 2D 15 07 53 46 74 0ACE C3 1E 75 2F 5F 3A 26 AE 13 87 8F C4 05 A6 76 5D 9C 6E 58E1 23 45 B0 8D 65 F3 E6 86 42 CB DB CF 17 6E B5 85 59 58 FCE0 29 96 D0 3E 47 2D 1C 92 71 B4 B8 89 E8 2A 8E 2B 9E 7E BC...B8 F6 8C 7B 8D 46 15 49 0D DB 8D 2F CD 2C 16 B7 9E 12 86 7095 92 F1 60 2F C1 48 27 7A E6 F1 BC BB 0F 00

This is an example of megadump from a Charge HR (915 bytes long):

2D 02 00 00 01 00 5F 01 00 00 EC 2B 18 32 4E 12 6C 1F 55 0895 F7 57 6A 93 B6 E1 2D A3 46 F8 CB 88 E6 44 BE C7 03 9F 6102 B4 D5 25 47 48 50 3C 1D EC 6D 5D 93 58 58 75 6E 0E 73 3CDE D9 99 74 48 B9 1B CB 00 40 10 54 12 A0 26 D8 AE 46 8D 895F 0C 10 A9 96 01 B5 6C 80 DD 6D B3 FD E5 56 1B 1E 32 18 CE1C C0 E2 55 E2 24 6B 7C 18 3E 1D 37 6B 40 91 79 A0 F3 11 56D2 65 42 A1 F5 BA A1 46 29 FB 10 22 34 94 60 EE A5 9D F2 B1...CA C7 16 F0 5E FA D4 58 83 88 97 ED 93 E6 9A C4 11 04 4B 6766 AD A4 5A 33 73 C9 35 57 47 28 49 64 03 00

7.2 Megadump response

Format is:

DD 02 00 00 01 00 SS SS SS SS

where:

• DD is device type. 0x28 for Flex

• SS SS SS SS is a sequence counter.

• The rest looks like an encrypted blob.

This is a megadump response sent to the tracker.

86

28 02 00 00 01 00 33 04 00 00 43 91 D6 58 88 16 F8 4F 8D D6B5 2E 55 53 F8 90 08 0D ED C0 53 E5 6D 9B FD 42 7E 73 D8 DA5A 6F 5E D5 0A 89 DB 68 14 A5 E8 4F 13 E6 F0 8A B3 C6 4E 25E5 1F 59 D1 A2 6F 60 7C B0 7E 35 D6 3C CD F1 43 A9 AA 05 8361 90 40 FD FF 26 55 23 71 17 B1 82 78 B0 7A 77 D4 A7 1D EC10 3C AC 62 1D 9C 4A A1 77 8B 72 90 FF 25 A4 32 C2 D9 E2 9628 D2 68 3C D6 9D 1E 80 43 F6 00 F6 70 64 2F 09 2F 98 F3 3B6C 29 7D 1A 90 1E 4E 19 4E C4 C8 AF 00 95 C6 17 F4 E0 07 DD9C 70 7D EF D0 9F 6C 00 FA 1F 79 AE 31 06 24 4A 62 1C F5 D22D DB 79 2D 1D B4 6A 93 E9 E9 3B 9C 35 13 AA 00 00

Another example:

28 02 00 00 01 00 58 15 01 00 04 D3 49 02 AC DF FD E9 50 65E7 4E 3E 67 4C 50 23 DD 03 A8 B9 E2 23 A8 C9 E0 22 8F AF 9A03 CB EA A1 AB B6 BE 2F 43 55 00 B0 1E A1 1D B9 7A 37 B6 8EA2 AD 81 A7 1A 59 6D 2A 52 2E 34 18 34 A5 54 E5 38 17 7B 796A B7 37 2E 91 92 DE 10 6D 91 4F 15 C1 41 A9 97 E8 E1 3C 4C6C 17 2F E5 B9 A7 5D D9 50 FB 5D 6B 8E 1A A9 AE FB 5C 65 C40D 64 0C B4 8D 9B 51 E4 CC 23 23 BE 71 02 21 EF 16 9C EE C088 C3 B4 F5 32 EA 35 FB 75 57 A5 AA 5D F5 9A 92 48 95 48 F8DF 99 DC 04 25 C1 DA 2C 87 41 06 B2 8C 52 17 C4 1E 6F 7A A251 27 B1 52 66 94 A9 27 A9 AD 76 07 9A 2A AA 00 00

7.3 Minidump

Minidumps can be read from captured USB packets. All packets have a usefullength of 0x14 (remaining bytes being padded by zeros), except the last one, whichin our case has a length of 0x03. In that last packet, we see that the remaining bytesare the same as the previous packet (memory not cleaned up), but those bytes are(probably) useless.

The total length of the minidump is 123 bytes (0x7b).Format:

30:02:II:II:II:II:CC:CC:CC:CC:MM:MM:MM:MM:MM:MM:...6e 00 00

• II is a 4 byte integer? (wild guess!)

• CC is a sequence counter (4 bytes)

• MM is the article number (see 24)

• There are 104 (0x68) opaque bytes in the middle. 104 does not divide by 16,so it can’t be AES encryption. It can be XTEA.

87

• 6e:00:00 is fixed. At the end.

Example of captured USB packets:

30:02:00:00:01:00:14:04:00:00:d2:c0:56:2e:15:07:da:4a:bd:49:00:00:00:00:00:00:00:00:00:00:00:14

d1:bd:34:f5:15:55:4b:34:f4:aa:17:2a:fb:c4:40:4e:c1:eb:24:ab:00:00:00:00:00:00:00:00:00:00:00:14

78:82:36:97:9d:c1:ee:1b:92:56:53:4f:20:01:c6:d6:57:1c:34:06:00:00:00:00:00:00:00:00:00:00:00:14

32:cc:ed:85:87:95:22:a8:a5:65:ea:e9:80:fa:da:c9:2b:f8:0d:bf:00:00:00:00:00:00:00:00:00:00:00:14

95:63:9f:f1:51:a9:d0:b9:a6:cb:20:a3:fa:ff:1c:73:c0:df:11:41:00:00:00:00:00:00:00:00:00:00:00:14

7f:db:75:77:cf:81:8d:b8:e8:3c:55:07:50:62:f0:d3:a1:e1:49:17:00:00:00:00:00:00:00:00:00:00:00:14

6e:00:00:77:cf:81:8d:b8:e8:3c:55:07:50:62:f0:d3:a1:e1:49:17:00:00:00:00:00:00:00:00:00:00:00:03

which corresponds to this minidump:

3002 0000 0100 1404 0000 d2c0 562e 1507da4a bd49 d1bd 34f5 1555 4b34 f4aa 172afbc4 404e c1eb 24ab 7882 3697 9dc1 ee1b9256 534f 2001 c6d6 571c 3406 32cc ed85

88

8795 22a8 a565 eae9 80fa dac9 2bf8 0dbf9563 9ff1 51a9 d0b9 a6cb 20a3 faff 1c73c0df 1141 7fdb 7577 cf81 8db8 e83c 55075062 f0d3 a1e1 4917 6e00 00

Example of minidump on the Fitbit Flex:

3002 0000 0100 7a03 0000 d2c0 562e 1507c12d 8b0f 4691 64aa cf20 0088 ea73 454c1e7d 272e cc29 fd01 c32c 6c63 dc3a 0324599b 1e17 c8b9 a306 a394 427c 80d1 a5ab9ade c842 17a2 b14f d573 e62e 3194 38f34acf 045e 84d1 781d a19b 5776 61a6 43c1ec2e fca6 2bc4 5ec3 74ea 30de 32c1 9d1bbc17 cfba 925f 83ec 6e00 00

Other example of minidump with Fitbit Flex (Francois’s tracker):

3002 0000 0100 7600 0000 c99b f82d 1507d70b 741e 0e27 e45f 0da9 0082 8a5c 66f006f4 a414 a48e a35e 95cf 9584 4663 fccc25e5 ab4e 3f06 ecb5 8991 4940 a716 dda9cdfe cc20 9df2 8d68 a660 ab6b 76db 44c802d8 02f3 162d 125e 8f4c 694d a412 91961f78 7906 07a0 2b16 f8bd 1b67 f714 b05b456e 04a4 9d16 6c1a 6e00 00

Example of minidump on FitBit One:

30 02 00 00 01 00 E2 19 00 00 72 7A 2C 2B 28 05F2 E0 18 02 0F 3B E3 6B 02 8E 3F F5 8B 8D B9 7AF1 CB 58 0F 17 2E BE EC 4D B5 E9 59 62 78 56 6437 FB FA 79 2B 22 90 2B F6 F0 E0 DE DD E6 2F 2F5A 6B 41 F7 1B 97 F9 5F 5F A3 CB 22 14 2C 2C 230D A8 11 39 9F 45 F3 89 23 79 B2 63 48 04 63 8C0D C5 0C 01 56 F2 8B 1C D1 B1 87 F0 6E BB 91 1BF2 9B FA 75 0B D1 2A 7B 6E 00 00

• 30 02 00 00 01 00. 30 identifies a minidump (whether flex or one)

• 7a 03 00 00. Sequential counter

• D2 C0 56 2E 15 07. Device identifier?

• the rest is the encrypted minidump

• 6E 00 00 end

89

8 Tools

This section refers to [All]. Other tools:

• Busdog [bus]

8.1 Galileo commands

./run --no-upload --dump --force --no-https-only -d --exclude 09737863F7F3

8.2 Galileo interactive commands

./run interactive

To request a minidump:

> c ; d ; l ; tx 1 ; al; => c0 10 03;<= ; <= ; <=; <=; <=; <=; <=; <=

To send commands to the dongle, the interactive mode adds the packet lengthat the beginning so you must not specify it.

Example (trying to establish link with tracker):

-> 06 51 67 06 e7 49 cf 01 4f 1e

Actually sends:

0B 06 51 67 06 e7 49 cf 01 4f 1e

8.3 Understanding Galileo debug messages

--> 06 ( 51 67 06 E7 49 CF 01 00 FB ) - 11<== [ C0 0B ] - 2

• the arrow shows the direction of data. → is incoming data, ← is outgoingdata. A simple arrow is communication on the control channel. A doublearrow is communication on the data channel.

• the payload is between the ( ... )

• the command instruction is outside the (...)

• the length of the packet is at the end - length

8.4 Android application

In most cases, the Android application only accesses the online fitbit account, andnot the tracker. However, with some smartphones, wirelessly syncing the trackerwith the smartphone is possible. It requires the smartphone to have a Bluetooth LEchip and the chip to be accessible to Android applications. See http://www.fitbit.com/fr/devices.

90

9 Prior research

In 2011, Andy Baio reported that Fitbit leaked sexual activity of customers throughsearch engines [Rao11]. The problem originated from the default privacy settingsof user profiles which was being set to public. Fitbit did a quick fix the next day[Bry11] where it prevented access to user profile pages by search engines. Fit-bit also had the pages removed from Google, Bing and Yahoo (http://www.forbes.com/sites/kashmirhill/2011/07/05/fitbit-moves-quickly-after-users-sex-stats-exposed/).

The tracker does not track sexual activity, only movements. It’s on the websitethat the user logs given activities, each activity coming with a given amount of calo-ries. For example, http://boingboing.net/2010/05/17/urinating-uses-up-14.html lists amusing Fitbit categories such as “cooking Indian breadon an outside stove” which counts for 211 calories per hour.

[RCB13] have built FitBite, a suite of tools, that exploit vulnerabilities on Fitbitdevices (see Table 25). The attacks were demonstrated on old fitbit devices, andseveral issues have been fixed since, however, some issues are still there.

Id Vulnerability Current status1 During login, user password is sent in cleart-

ext in a HTTP POSTUses HTTPS. TODO: Checkhow device is associated withFitbit account

2 Synchronization data is not checked for con-sistencyInject abnormal data (very high, very low...)into online accountInject abnormal data on tracker to cause baddisplay on trackerGet undeserved achievement awards

3 Synchronization data is not authenticatedInject data on any tracker within your rangeInject data on the account of another user

4 Synchronization data is not protectedEavesdrop fitness data of any tracker withinyour range

5 Denial of ServiceDrain battery by syncing the tracker continu-ously

6 Abusing the step/distance (etc) sensorsAttaching tracker to a rope to increase numberof steps

Tried with a 10cm rope: it works

Attaching tracker to a car wheel I assume this still works

Table 25: Attacks demonstrated by [RCB13] on the old Fitbit device

91

10 TestsSend tracker packets C0 xx with differ-ent command ids and payload lengths

Tracker does not check payloadis 0x00 or 0x01 when receiv-ing c0 04 and responds normallyTracker does not check payloadlength is 0 when receiving c0 01Tracker does not check payloadlength is 0 when receiving c0 05Tracker does not check payloadlength is 0 when receiving c0 06

Send a get dump packet requesting anunknown dump type (C0 10 01...)

Responds with an error packetC0 03 09 10

Send a Data transmission c0 24 withvarious XX values

Responds to X =1, 4 and 8.Responds an error response for0x0a (code 16 20). Does not re-sponds to other packets

Send tracker an invalid toggle pipe 0308 05

Does not care and seems to pro-cess the request (C0 0B...)

Replay a megadump containing an in-crement of 22 steps

Does not work

10.1 Fuzzing command ids for tracker packets

10.1.1 Command id < 0x80

We send tracker packets with command identifier from 0 to 0xff with various pay-load lengths.

Test results are listed at Table 26

10.1.2 Command id ≥ 0x80

We notice that the tracker does not seem to consider the highest bit of commandids, i.e 0x84 is like 0x04, 0x91 is like 0x11 etc.

11 Vulnerabilities

11.1 Physical attacks

• Battery draining attack - by constantly communicating with the device, orforcing it to sync.

• Abusing physical sensors. Shaking the device firmly towards the floor regis-ters a foot step. Fitbit also mentions other cases: http://help.fitbit.

92

Command Payload lengths for which we get a response Responsec0 01 0 - 5, 7-29 (probably 0-29) 0: AirLink Init Resp.c0 04 1-29 c0 02 with no payloadc0 05 0-9, 11-17, 19-29 (probably 0-29) c0 05 echoc0 06 0-29 c0 02 with no payloadc0 09 0-12, 14-28 (probably 0-29) c0 09 echoc0 0a 11-29 11. AirLink Init Response. Oth-

erwise: c0 03 09 10 error packetc0 10 1-29 c0 03 09 10 and data leakc0 11 8-29 c0 03 16 20 and data leakc0 23 0-6, 8-20, 22-29 (probably 0-29) c0 02 with no payloadc0 24 1-29 Ack of 1st block: c0 12 01 00 00c0 50 ? Tracker challenge: c0 51c0 51 0 AirLink Init Response c0 140x52 ? If authentication is incorrect, er-

ror response c0 03 15 20

Table 26: Tracker packet command id fuzzing

com/articles/en_US/Help_article/How-accurate-is-my-Flex

There are many instances where your hands may be moving, butyour body may not be, such as playing the drums, cooking, oreven burping a baby.

11.2 Software vulnerabilities

• Data leak from memory - FG-VD-15-013

• Denial of Service on dongle - FG-VD-15-117

• Fitbit Connect Service - Unquoted Service Path Privilege Escalation - https://www.exploit-db.com/exploits/40482/ - Ross Marks.

12 Hacks

12.1 Using the tracker as a hardware random number generator

The tracker’s authentication messages contain an 8-byte tracker challenge. As-suming the challenge is random, we issue numerous authentication requests to thetracker so as to generate random sequences and turn the tracker in a RNG.

python ./talk2flex.py -v -o hwrandom

93

0x81 Data leak Data leak after payload Echo packet with len0x14

0x84 c0 02 with data leak c0 02 with data leak c0 020x85 c0 85 with data leak c0 85 with data leak after

payload0x86 c0 02 with data leak c0 02 with data leak c0 020x89 c0 89 with data leak c0 89 with data leak after

payloadecho packet with len 0x14

0x8a Error response: c0 03 0910 with data leak

0x90 Error response: c0 03 0910with data leak

Error response: c0 03 1620

0x91 Error response: c0 03 1620 with data leak

Error response: c0 03 1620

0xa3 c0 02 with data leak c0 02 with data leak c0 020xd2 Error response: c0 03 15

20 with data leak

Table 27: Packets with command identifiers ≥ 0x80 behave like if bit 8 wasn’t set

We evaluate the randomness of such a RNG using ent and Dieharder. Bothare batteries of statistical tests for random number generators, ent is referenced byNIST, and Dieharder can be seen as an improvement to the Diehard tests.

Ent tests the following:

• Entropy. This is information density. The higher, the better.

• Chi-square test. This is a sensitive test for randomness. Good results areexpected to have a percentage ranging from 10 to 90%. However, note thatUnix rnd does not meet this criteria.

• Arithmetic mean. Good results should have their mean close to 127.5

• Monte Carlo Pi. Should be close to the value of Pi :)

• Serial Correlation Coefficient. Measures to which extent each byte dependsupon the previous byte. Good results should be close to 0.

Dieharder runs several tests as seen below:

test_name |ntup| tsamples |psamples| p-value |Assessment#===================================================================

diehard_birthdays| 0| 100| 100|0.01952634| PASSEDdiehard_operm5| 0| 1000000| 100|0.95656441| PASSED

diehard_rank_32x32| 0| 40000| 100|0.92242771| PASSEDdiehard_rank_6x8| 0| 100000| 100|0.84998217| PASSED

94

Description Entropy Bytes collectedFrench litterature3 4.592678 435,674LATEXsource file of this document 5.265866 125,012Litterature encrypted with RC4 7.999537 435,674Litterature encrypted with DES-EDE3-CFB 7.999573 435,674Litterature encrypted with AES-256-CBC 7.999595 435,674Linux PRNG /dev/urandom 7.999659 500,000Radioactive decay events 500,000Fitbit tracker 7.999660 500,000

Table 28: Entropy of various texts

diehard_bitstream| 0| 2097152| 100|0.56058176| PASSEDdiehard_opso| 0| 2097152| 100|0.67199884| PASSEDdiehard_dna| 0| 2097152| 100|0.43376816| PASSED

diehard_count_1s_str| 0| 256000| 100|0.91039342| PASSEDdiehard_count_1s_byt| 0| 256000| 100|0.99361139| PASSEDdiehard_parking_lot| 0| 12000| 100|0.54735549| PASSED

...

We compare random bytes produced by the tracker to other sources:

• A non-random text (taken from French litterature)

• A non-random LATEXsource file

• Linux /dev/random and /dev/urandom

dd if=/dev/random of=entropy-dev-random bs=1 count=500000

• Encrypted output of our first non-random text using Triple DES-EDE3-CFB,AES-256-CBC and RC4

openssl enc -des-ede3-cfb -in julesverne -out encrypteddes

• Radioactive decay events

12.2 Using the tracker to lock one’s session

As demonstrated at [Apv15c], we can detect the owner of the fitbit is moving awayand perform an action when this happens.

13 Old trackers

The old trackers use a different protocol to talk to the tracker.

95

Description Chi-squarepercent-age

Mean Monte-Carlo Pierror per-centage

Serial corre-lation coeffi-cient

Dieharderfailed tests

French litterature 0.01% 98.5940 26.80% 0.143300 2 weakLATEXsource file 0.01% 81.9099 27.32% 0.393652 2 weakLinux PRNG/dev/urandom

75% 127.4903 0.57% -0.000619 0

Lit. encrypted withRC4

25% 127.2838 0.06% -0.001044

Lit. encrypted withDES3

50% 127.5316 0.12% -0.000862

Lit. encrypted withAES

50% 127.6598 0.50% -0.000536

Fitbit tracker 75% 127.46413 0.36% 0.000482 3 weakRadioactive decayevents

40.98% 0.06%

Table 29: Stats tests on various texts

Opcode Description0x22 Read a given memory bank0x23 Write a given memory bank0x24 Retrieve tracker information0x25 Erase a given memory bank

Table 30: Old tracker protocol opcodes

96

14 Monetization

You can earn money (directly or indirectly) with your tracker: http://www.bradsdeals.com/blog/earn-money-with-fitbit-jawbone-fitness-tracker

• Achievemint. https://www.achievemint.com/ You can earn a 50dollar check.

• Higi. https://higi.com/. You earn mostly discounts.

• Pact. http://www.gym-pact.com/. You place bets on your achieve-ments.

References

[All] Benoit Allard. Galileo. https://bitbucket.org/benallard/galileo.

[Apv15a] Axelle Apvrille. Fitness Tracker: Hack in Progress. Hacktivity, Bu-dapest, Hungary, October 2015.

[Apv15b] Axelle Apvrille. Fitness Tracker: Hack in Progress. Hackin Paris, https://hackinparis.com/data/slides/2015/axelle_aprville_hackinparis.pdf, June 2015.

[Apv15c] Axelle Apvrille. Geek Usages for your Fitbit Flex Tracker. Hack.lu,http://archive.hack.lu/2015/fitbit-hacklu-slides.pdf, October 2015.

[ARM] ARM. Cortex m3-processor. http://www.arm.com/products/processors/cortex-m/cortex-m3.php.

[Bri13] Brittany. Fitbit Flex Teardown. http://ifixit.org/blog/5042/fitbit-flex-teardown/, July 2013.

[Bry11] Martin Bryant. Details of Fitbit users’ sex lives removed from searchengine results. http://thenextweb.com/insider/2011/07/04/details-of-fitbit-users-sex-lives-removed-from-search-engine-results/, July 2011.

[bus] Busdog. https://code.google.com/p/busdog/.

[Ele13] Teardown: Fitbit Flex. http://electronics360.globalspec.com/article/3128/teardown-fitbit-flex, October 2013.

97

[Fita] Fitbit. How does fitbit know how many calories i’ve burned?http://help.fitbit.com/articles/en_US/Help_article/How-does-Fitbit-know-how-many-calories-I-ve-burned.

[Fitb] Fitbit. How does my tracker calculate distance. http://help.fitbit.com/articles/en_US/Help_article/How-does-my-tracker-calculate-distance.

[Fitc] Fitbit. How does my tracker count floors? http://help.fitbit.com/articles/en_US/Help_article/How-does-my-tracker-count-floors.

[Fitd] Fitbit. How does my tracker count steps. http://help.fitbit.com/articles/en_US/Help_article/How-does-my-tracker-count-steps.

[Fite] Fitbit. I’m going on a trip what should i know about traveling with myfitbit? http://help.fitbit.com/articles/en_US/Help_article/I-m-going-on-a-trip-What-should-I-know-about-traveling-with-my-Fitbit/.

[Fitf] Fitbit. Sleep tracking faqs. http://help.fitbit.com/articles/en_US/Help_article/Sleep-tracking-FAQs.

[Gup13] Naresh Gupta. Inside Bluetooth Low Energy. Artech House, 3 2013.

[JM15] Alexandre Jacquemot and Quentin Margueritte. Attacks on the FitbitFlex. Semester project, Fall 2015, Eurecom. Supervisor: Aurelien Fran-cillon., 2015.

[KWM11] Jennifer R. Kwapisz, Gary M. Weiss, and Samuel A. Moore. Activityrecognition using cell phone accelerometers. SIGKDD Explor. Newsl.,12(2):74–82, March 2011.

[Man12] Patrick Mannion. High-res pressure sensor brings stair-track capabilityto Fitbit Ultra. http://www.edn.com/design/medical/4395806/High-res-pressure-sensor-brings-stair-track-capability-to-Fitbit-Ultra, September 2012.

[Mar] Sam Marshall. Reverse Engineering Fitbit BLE Protocol. http://samdmarshall.com/blog/fitbit_re.html.

[Mar16] Quentin Margueritte. Bluetooth Low Energy Packet Forging. SemesterProject, Spring 2016, Eurecom. Supervisor: Ludovic et Axelle Apvrille.,July 2016.

98

[Mic] ST Microelectronics. Lis2dh - mems digital output motion sen-sor: ultra low-power high performance 3-axes femto accelerom-eter. http://www.st.com/web/catalog/sense_power/FM89/SC444/PF252928.

[Rao11] Leena Rao. Sexual Activity Tracked by Fitbit Shows Up in GoogleSearch Results. http://techcrunch.com/2011/07/03/sexual-activity-tracked-by-fitbit-shows-up-in-google-search-results/, July 2011.

[RAT13] RAThomas. Fitbit Flex under Linux. https://docs.google.com/file/d/0BwJmJQV9_KRccWlRZ0tibHc1cFk/edit, Au-gust 2013.

[RCB13] Mahmudur Rahman, Bogdan Carbunar, and Madhusudan Banik. Fit andvulnerable: Attacks and defenses for a health monitoring device. CoRR,pages –1–1, 2013.

[RDML05] Nishkam Ravi, Nikhil Dandekar, Preetham Mysore, and Michael L.Littman. Activity recognition from accelerometer data. In Proceedingsof the 17th Conference on Innovative Applications of Artificial Intelli-gence - Volume 3, IAAI’05, pages 1541–1546. AAAI Press, 2005.

[Rya13] Mike Ryan. Bluetooth: With low energy comes low security. In Pro-ceedings of the 7th USENIX Conference on Offensive Technologies,WOOT’13, pages 4–4, Berkeley, CA, USA, 2013. USENIX Association.

[Sema] Nordic Semiconductor. nrf8001. https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF8001.

[Semb] Nordic Semiconductor. nrf8001 single chip connectivity. https://developer.bluetooth.org/DevelopmentResources/Documents/nRF8001%20Development%20.pdf.

[Spi15] Dominic Spill. Ubertooth one. https://github.com/greatscottgadgets/ubertooth/wiki/Ubertooth-One,February 2015.

[ST 14] ST Microelectronics. STM32L15xx6/8/B. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00277537.pdf, July 2014.

[Sti15] Stian. Ble sniffer in linux using wireshark. https://devzone.nordicsemi.com/blogs/750/ble-sniffer-in-linux-using-wireshark/, September 2015.

99

[TCAD14] Kevin Townsend, Carles Cufi, Akiba, and Robert Davidson. GettingStarted with Bluetooth Low Energy. O’Reilly Media, 5 2014.

[Tex] Texas Instruments. CC2540: SimpleLink Bluetooth Smart WirelessMCU with USB. http://www.ti.com/product/cc2540.

[Tex14] Texas Instruments. bq2404x 1A, Single-Input, Single Cell Li-Ion and Li-Pol Battery Charger With Auto Start. http://www.ti.com/lit/ds/symlink/bq24041.pdf, February 2014.

100