OpenYou.org

libfitbit Hangups

2011-08-07T20:34:29-07:00

First off, hello to everyone who found us through the MIT Tech Review article or Ubuntu Community talk! Been a bit slow around here lately, but hoping to get things booted back up.

It seems the most requested thing at the moment is a finalized version of libfitbit. Currently, we’re at v0.0.1, which was released in February and hardly worked. There’s been a lot of progress since then, and we are now able to replicate full communications with the tracker. There’s really just one problem left with the library, and that’s the subject of today’s post.

So, unless you’re into specifics of the implementation of the ANT protocol, you can probably skip the rest of the post. However, if you’re interested in helping me kill the last bug before I can start making distributable, read on.

I recommend having the ANT Protocol Specification open while following along, as I’ll be talking about packet types quite a bit. Also, if you have any comments, please leave them on the github issue about this problem.

UPDATE: And, 2 hours after I post this, I fix it myself. I wasn’t resetting the USB device correctly, which meant we were getting weird configuration conflicts from the last session run. Fixing the device reset clears this, and libfitbit will now retreive information multiple times without having to completely un/replug the key. I’ll write up a “rest of the things I need to do” post tomorrow to let everyone know what’s next.

Whenever libfitbit connects to the tracker, the first transfer after plugging in the USB goes fine. We start communications with an ANT reset message, and we always get back a 0x6F package (Startup Message) with a payload of 0x00 (POWER_ON_RESET), which is what we expect since we just powered on the ANT stick. We then continue on through establishing a communications channel, running a beacon signal to find the tracker, and other steps as laid out in the fitbit protocol document.

The problem comes in on the second run of a libfitbit based utility. We try and reset the device, but instead of getting back a 0x6F packet, we usually receive something that looks like a bulk data receive packet, like we would expect back from a bank transfer. Further executions the utility will result in the same, until the point where the receive command from the reset completely times out, and continues to do so. The only way to fix things at this point is to unplug/replug the ANT stick, at which point things work fine again, for one round of communication.

The actual fitbit client doesn’t have to deal with this due to the fact that it grabs the device right when it starts up, and doesn’t let go until shutdown. I suppose I could try stopping and restarting the service with the base plugged in while watching an analyzer, and that may be my next step.

This bug is the major thing holding up library development right now. Until this is fixed, I can’t reliably run multiple sessions with the fitbit, and having to replug the USB stick isn’t a viable solution. I’m pretty sure I’m missing something about how connections should end or restart, but progress on this one is slow so far.

Withing Scale Network Hijacking

2011-06-06T23:01:19-07:00

The Withings Scale is a pretty simple piece of hardware. Set it up on your wifi network, weigh yourself, and it instantly sends your weight to the Withings website.

Now, as Withings isn’t really taking and analyzing a ton of data, it’s (apparently) fairly trivial to pull all the needed data from their website. However, there are those who aren’t completely happy with that solution, and who also don’t want to deal with the slow flash interface.

The people at Proxilium decided to reverse engineer the network protocol, doing a full trace on the communications between the scale and the home website, and extracted all of the data the scale sends to the website. Not only that, he shows how to set up alternate DNS rules to route off calls to the website to a local webserver, so you can have your own data store. Neat!

libfitbit Development Update

2011-05-26T23:20:12-07:00

There’s been a lot of interest in libfitbit lately, so here’s a quick update on where I am with development.

Web client is now completely working. Was stuck on ANT burst sends not working, which are used to update the device time and stats like height and weight. Putting in a sleep between burst sends seems to have fixed it. Because, much like putting a bird on it, putting a sleep in it fixes everything.
Tested the fitbit with the Garmin ANT Stick, works fine. Hoping to test with Suunto stick within the next week, the goal being to have multiple ant antennas on multiple machines, all which can communicate with any ANT hardware.
Can get per-minute Step Count and Active Point Score from the fitbit

This is close to getting us to a v0.1 release, which I’m hoping will happen next week after the Quantified Self Conference. I’m also working on documentation and making a couple of useful utilities, such as a linux daemon for web service uploads (yes, I realize I’m doing fitbit’s work for them, and no, I’m not real thrilled about it either), and dumping data to json/xml.

In terms of what I’d like to see for versions after that:

Finish the data format protocol. There’s still a couple of packets I’m not sure about, and I haven’t figured out how events (sleep, etc…) work yet.
Dividing out the ANT protocol class and ANT antenna classes into their own library, so they can be shared between multiple device libraries. I’m moving toward this with the current design, but don’t want it holding up the v0.1 release
May a C version? I’m not exactly motivated about this since python works fine for me right now, but if the need arises, it could be nice to have around. The ANT people have actually said they have little linux experience on staff, so I wouldn’t be expecting their support on the library side soon anyways. Definitely an ownable area for anyone looking to start up an open source project, and there’s a ton of code already out there…
Whatever else people are looking for. Let me know in the github issues if you have requests.

libomron Verified Working with BP791IT

2011-05-25T17:31:12-07:00

I’ve received from email from an OpenYou reader who purchased the BP791IT, which is the updated version of the HEM790IT Blood Pressure Monitor from Omron.

They’ve verified that this blood pressure monitor does work with OpenYou’s libomron library. So, go forth and purchase, knowing you can still pull your data off of the device on any platform libomron supports (which is anything libusb supports).

Please note that I’ve been getting a few issue reports with getting libomron working on OS X, having to do with the kexts not causing the device to detach from the HID Manager correctly on 10.6.7+. These reports have been rather intermittent, but if you experience any issues, please get in touch with me via email or file a bug report on the github site.

Upcoming Speaking Engagements

2011-05-13T21:12:12-07:00

This summer is shaping up to be a busy one…

I’m speaking at Maker Faire. Twice, even!

2011-05-21 3:30pm - OpenYou.org Presentation, Health 2.0 Stage
2011-05-21 6:00pm - OpenKinect Presentation, Main Stage

Then there’s the Quantified Self Conference on May 28-29th, 2011, at the Computer History Museum in Mountain View, CA. There’s no central presentation, but honestly, I probably won’t stop talking at any point during the 2 days, as I have a table at the expo, plus will be helping out with the health hardware session and the hackathon.

On June 23rd, I’ll be doing a presentation on the OpenKinect project at NetExplorateur Zoom 2011 in Paris.

The Quantified Coder and OpenYou Subprojects

2011-05-13T19:47:12-07:00

Earlier this week, I spoke at Google I/O on OpenYou and The Quantified Coder Project, one of the first “things I can do with all of the hardware I’m working on for OpenYou” projects. The talk is now available on YouTube.

(if it doesn’t happen automatically, wind above to 12:47 for the start of my talk, though the whole thing is a great watch if you’ve got the time, as there are lots of QSy topics in it)

For those interested in the talk content, the slides and notes are available as a zip file.

As I’ve been working on sensors for OpenYou, I’ve been coming up with different ideas about what to do with all of this data once I’ve got it. Having an end goal for these projects keeps me motivated while I’m in the bit mines. What’s I’ve come up with so far:

Golden Gate Wall - Rock climbing is a big new hobby for me (only been at it about a year), and seems like a neat place to think about engineering. There’s already some neat research papers, for instance. I figured I’d 3D scan a rock climbing wall in Berkeley, CA, and start mapping information about it. Looking to do things like automated route planning based on past traversal by climbers who are wearing sensors, maybe doing some infoviz on the biometrics, etc…
Quantified Coder - In looking at accessing all of this hardware, I have to think about where I’m gonna be most of the time, and what I can do with the data from that time. Mostly, it’s gonna be spent in front of the computer. So, why not try and make it add value to what I’m doing, like programming? That’s what quantified coder is about. For now, check out the talk above for a more in-depth explanation of where I see it going.

Right now, my main goal with OpenYou is to get the community moving, adding a wiki for protocol information, and getting a few of the driver projects to version 1. I’ve done information gathering/centralization projects like this before (for instance, with the Compaq IA-1 Internet Appliance, many years ago), but they tend to lose focus if there’s not a goal outside of that. The projects above give this procedure some shape, which will hopefully means I can keep on-going interest and attention as everything progresses.

So, in conclusion, yes, OpenYou is a my very own meta-quantified-self project. Nice that things work out like that sometimes.

Fitbit and Security, or Lack Thereof

2011-04-18T22:11:09-07:00

One of the libraries that I work on as part of OpenYou is libfitbit, an access library for the FitBit pedometer device.

It’s basically a tiny accelerometer that clips to clothing to work as a pedometer. It can also communicate wirelessly with its base station, so that whenever a user walks by their computer and assuming they have the Fitbit server software running, it’ll automatically sync. The data is stored on fitbit’s website (shown above, lower right), where they give you a nicely designed interface to see it, compare to friends, and for a fee, have it analyzed by on staff trainers.

The hardware itself is very well designed. In 3 months of having the device, I have yet to lose it (which is a small miracle), and it stays clipped to clothing. The battery seems to last pretty much forever, and the display is nice and crisp. The wireless has quite a range too, picking up the device while I’m in other rooms.

The problems began when it didn’t have drivers for syncing via linux. Doing what it is I do, I figured I’d whip some up real quick. This is where things when horribly, horribly wrong.

(For those that want to skip the story telling version of this and just read the hard technical details, the reverse engineering document is available on the repo, which has all of the gritty technical details.)

The first thing I normally do when looking at new hardware is to check out what I can about the software that ships with the device. There’s usually some logs around to help out. In fitbit’s case… Well, the logs are beyond helpful. They’re scary. Here’s a chunk from the beginning of one of them.

01/28 23:31:55 Sending 4357 bytes of HTML to UI…
01/28 23:31:55 Processing request…
01/28 23:31:55 Waiting for minimum display time to elapse [1000ms]…
01/28 23:31:56 Waiting for form input…
01/28 23:31:57 [POWER EVENT] POWER STATUS CHANGE
01/28 23:32:04 [POWER EVENT] POWER STATUS CHANGE 01/28 23:32:14 UI [\.\pipe\Fitbit|kyle]: F
01/28 23:32:14 Processing action ‘form’…
01/28 23:32:14 Received form input: email=[USER UNENCRYPTED EMAIL HERE]&password=[USER UNENCRYPTED PASSWORD HERE]&[other stuff]
01/28 23:32:14 Connecting [2]: POST to http://client.fitbit.com:80/device/tracker/pairing/signupHandler with data: email=[USER UNENCRYPTED EMAIL HERE]&password=[USER UNENCRYPTED PASSWORD HERE]&[other stuff]
01/28 23:32:14 Processing action ‘http’…
01/28 23:32:14 Received HTTP response:

Yes, that’s a user’s email and password, unchanged and in clear text, being flung over to their website via a pure http connection. This step is also logged to the user’s hard drive in a clear text file, that is world readable.

This is bad.

The log goes on to verbosely record everything the fitbit says to the website and vice versa. Fitbit sends all commands from their website to the device, meaning they never have to upgrade their client software, though firmware does have to be updated on the device every so often. This policy is actually an interesting move. It made it way easier for me to replicate how their client works for libfitbit, but also keeps them from having to update their client when they make new firmware.

To continue the fun, we move onto the promiscuous base stations. As a convenience measure, any Fitbit tracker device (the thing you wear, lower left in the picture above) will sync with any base station (the part that connects to the computer, upper portion of picture above). This means that if you’re at a friend’s place who has a fitbit, the device will sync, without you having to do anything.

However, in order for the information to go from the user’s fitbit that’s attached to them, to their account on the website, there has to be some identifier on the device to let the website know who’s who. The tracker serial number does this. The first thing the website asks for is the tracker number, and it then returns the user ID associated with the tracker number. The user ID is what’s used to access a profile page, i.e.

http://www.fitbit.com/user/[user_id]

After knowing the combination of user id and tracker serial, anyone can be basically authenticated and can send data to the site under the account the tracker is bonded to.

This is an incredibly easy system to spoof. I could walk around with a netbook and a fitbit base station in my backpack, gather serial numbers at a public meetup, then have all the account information I wanted.

Which brings us to the crux of the problem, and the reason I believe the software is the way it is currently: Why would I do that?

It’s just steps, after all. Who cares?

This is one of the things I’m seeing more and more when reverse engineering medical hardware. It’s not financial information, it’s not important health information, so why should it be locked down?

While this may seem like a rather light issue (other than the password in the clear thing, which is 100% inexcusable), with common thought being ‘woo, someone stole my steps!’, the implications can get pretty staggering depending on how far out we want to cast the timeline, especially in relation to device popularity.

First off, one of the major marketing points of QS hardware right now seems to be synergy between information stores. Fitbit can now instantly upload a user’s data to DailyBurn, Google Health, and other sites that the user links to it. This is considered a value-add for health hardware, since users may have been keeping information elsewhere before whatever device they’re using existed. This also means that if I have write access to one account via the methods described above, I have write access to many accounts via account bonding across sites, assume the user has created those bonds.

To crank the paranoia level another notch, the amount of device companies I’ve talked to that are also looking at linking to health insurance companies really makes this a horror story. If someone maliciously gets into a user’s health device account that then links into health insurance/health care, who knows what havoc could be wreaked.

Finally, there’s lots of metadata that can be lifted from these devices as more and more of them go wireless. If you’re wearing something that uniquely identifies you, that means all someone needs is a base station to tell who the user was, where they were, and when. In the days of geolocative apps and constant check-ins, there comes the question of whether people might want that implicitly, but this seems like it should be opt-in versus opt-out (or in this case, no opting at all).

So, yeah. Fitbit is a great design, and completely insecure, though not unfixably so. Everything I’ve talked about above could be easily fixed. Flip on https for transfers (but please don’t encrypt everything, as I’d like my drivers to keep working), don’t log everything ever to disk, allow users to set whether they want base sync promiscuity or not. It’s not that bad. However, the fact that this was even seemed like a good idea in the first place is a bad precedent for health hardware to come.

And all I wanted was ~~a pepsi~~ some linux drivers.

OpenYou at the Quantified Self Conference

2011-04-04T10:21:09-07:00

After making it to the San Francisco Quantified Self meetup last week, it became obvious how silly it would be to not show up to the Quantified Self conference in May. So, we’ll be there with whatever hardware we can drag along. Looking forward to meeting people and talking about what can be done with new hardware!

Project Updates - Liblightstone and libomron

2011-03-27T22:25:09-07:00

Time for what I do best, more project updates!

First off, after 3 years of brokenness, liblightstone may see full stability for multiple devices in upcoming v1.5.

The lightstone is a USB device that comes with the “Journey to Wild Divine” video game. The point of the game is to teach users to relax and breath deeply. However, with the game itself working sporatically thanks to being based on a very old version of Director, actually finding peace with WD rarely happens.

liblightstone was established in 2006 to help owners of the lightstone access data from the device in an open source, cross platform way. However, it has been plagued with bugs when trying to use multiple devices on the same machine, and the release of an updated lightstone with different USB VID/PID pairs caused problems. After finally obtaining one of the newer lightstones last week, I’ve fixed the aforementioned problems and hope to release v1.5 soon. I hope these will make the driver stable enough to call the hardware access project done for the foreseeable future.

v1.5 will hopefully be released in the next couple of days, after I do some testing across windows machines. I’ve been getting odd differences in device enumeration between machines with the WDK installed versus without.

The USB access code from liblightstone is also used in projects like libomron and emokit, so these bugfixes will be finding their way to other projects soon.

libomron is also going to be seeing some work soon as we try to continue it toward v1.0.

libomron is a driver for Omron based USB devices, such as the

HJ-720ITC Pedometer
HEM-790-IT Blood Pressure Monitor

It currently only covers those two pieces of hardware, as well as their foreign counterparts (like the M10-IT blood pressure monitor). However, it looks like most of Omron’s equipment uses the same protocol, so the base of the library is extensible to new equipment as it comes out.

While the omron equipment isn’t as flashy as, say, the fitbit, it’s far cheaper ($20 for omron’s USB pedometer if you find it on sale, versus $99 for a fitbit).

libomron is currently approaching v1.0, with a few things left to be done in order to get multiple devices working (same issue as liblightstone had), as well as getting device clearing working. Finally, we’re hoping to have a simple XML/JSON/CSV data exporter available so it can be easily run by other programs with no need for interfacing at the source level, unless you want neat progress bars or something. Everyone loves neat progress bars.

np_epoc v0.2 released

2011-03-14T00:12:09-07:00

v0.2 of the np_epoc external for Max/MSP and Pd has been released.

VID/PID and key are now selectable by users. Users can also get a device count to make sure the VID/PID pair is set up correctly.

Hopefully key and ID detection will be done by emokit soon, but that’s going to take a little more work since we’re not yet sure how the key is deduced on connection.

Binaries are available on the sourceforge NP Labs release site.