Showing posts with label usb. Show all posts
Showing posts with label usb. Show all posts

Sunday, January 27, 2013

Fitbit Dongle Enumeration

I just checked in my notes on how the USB dongle responds to enumeration.  You can see them here:

https://github.com/hiptopjones/fitbit/blob/master/UsbDongle/usb_enumeration.txt

I learned a lot about the workings of USB devices, but can now see that it publishes two HID interfaces, each of which produces reports of a generic 32 bytes at a time.  While this is not a HID device in the traditional (mouse, keyboard, joystick) sense, and using a HID interface means quite low data rates, I expect this is done (at least partly) to avoid needing special drivers on most common operating systems.

I haven't yet figured out the format of these packets, but I can see normal sync data (matching the blocks in the sync log), as well as a number of strings like "StartDiscovery", etc.

I had been wondering if the strings represented some sort of command-based protocol with the dongle, instructing it to perform bluetooth operations, but I see that most of these strings are on IN endpoints, which means they're probably just there for logging, and not instructions.  This is supported by the fact that we see lines like this in the log:

    <Notice>: IN<CTRL> trace: StartDiscovery

I can't yet rule out that one of the HID interfaces could be being used for the transport layer of the Bluetooth stack, but I don't see bluetooth stack-like strings in the binaries on Mac or Windows.

Continuing to investigate.

Tuesday, January 22, 2013

Fitbit USB Dongle Sniffing

Sync packets are all well and good, and decoding them continues to be a priority, but I decided to give it another go with the USB filter driver today.

Using busdog, I'm now seeing chatter text in a USB trace!  (Does that mean the link is not encrypted?)

11 In  (USB URB Function: 9) 0.007991 32 48 45 59 20 48 45 59 21 20 20 48 49 47 48 46 49 56 45 20 20 00 00 00 00 00 00 00 00 00 00 00 14 HEY HEY!  HIGHFIVE  ............

I expected that the filter driver would just pick up bluetooth transport (HCI?) bytes, but I also see strings in the log that make me wonder if the dongle uses something like a serial protocol to communicate with the host PC.  That would be weird, though, or at least not like most other bluetooth dongles.

13  In  (USB URB Function: 9)   0.000002    32  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  .CancelDiscovery...............
. . .
13  In  (USB URB Function: 9)   0.000003    32  20 01 47 41 50 5f 4c 49 4e 4b 5f 45 53 54 41 42 4c 49 53 48 45 44 5f 45 56 45 4e 54 00 00 00 00  .GAP_LINK_ESTABLISHED_EVENT....

Anyway... we'll see.  I don't have protocol docs for Bluetooth LE, but perhaps by subtracting the bytes in the sync log from this output and doing some more reading, I'll be able to deduce something more about the actual device communication.