It's interesting that somehow, because this is reverse engineered now and I can do funny things with it and hack around with it, I actually consider to buy this thing.<p>I would wish that more companies would allow for modifications / hacks right from the start and actually support that. That would attract the hacker community and might result in many more interesting use cases.
This might be helpful for anyone wanting to play with low level BT traffic: <a href="http://ubertooth.sourceforge.net/" rel="nofollow">http://ubertooth.sourceforge.net/</a>
So I'm confused.. was author just not able to follow thru code path to find that the auth token was just spamming 1's? or was it a bit more cryptic than that?<p>the real code in the APK for computing the auth_token was probably some developers some pride and joy, worked weeks on it.. but when it came time to ship, damn thing wouldnt work with the shipped hardware.. so they buried a small assignment which overwrote the original computed auth token just to make the thing work? where is THAT code, i'd like to see it! If so, that is one of those great snippets where you can visually see the developer gave up. We should have a name for that sort of thing (I'm guilty of the same.. in my.. older works).
Here is a related, quite detailed teardown of the FuelBand: <a href="http://www.youtube.com/watch?v=7xdajSS_cOU" rel="nofollow">http://www.youtube.com/watch?v=7xdajSS_cOU</a>
Fun stuff. I would also recommend using some kind of packet sniffer to collect sample data which can make your static analysis easier. To do this, buy the CC2541 development kit with packet sniffer for about $25. Alternatively, you can write a BLE proxy (using two Bluetooth adapters). To Apple’s credit, the CoreBluetooth API on iOS does not let the app know the MAC address of the peripheral, so the app will never know that it is talking to your proxy vs the actual device.
Hardware reverse engineering has gotten so much easier since everyone is obligated to deliver some useless Android (preferred) or iPhone app with their consumer junk. No one seems to bother with obfuscation.
Very interesting, I've not yet ventured in to the BLE protocol world yet. I'd love to see what the Fitbit protocol looks like, they require a special USB dongle just to connect to Macs that already have BLE built-in, yet iOS hardware works on its own. Strange.<p>My first opportunity to reverse engineer undocumented hardware was Ubiquiti Networks Airview2 900MHz/2.4GHz spectrum analyzer USB sticks, the cheap $39 ones that hit the market back when Wi-Spy sticks were really the only comparable hardware and were quite a bit more expensive. They have an undocumented serial protocol for controlling the device and getting RF power level readings (and the proper info to parse it).<p>Once I got the basic command set figured out I wrote up documentation and a Python library[1]. Without reverse engineering the device firmware or the original software it was basically blind guessing (and later automated guessing). Finding a new command and being able to put more and more of the puzzle pieces together to see the big picture is really fun :)<p>[1] <a href="http://infincia.github.io/pyairview/" rel="nofollow">http://infincia.github.io/pyairview/</a>
This is awesome!<p>For what it's worth, I spent a little time playing with their Fuel API when the first band was released: <a href="http://fredkelly.net/articles/2012/12/21/nike_fuel.html" rel="nofollow">http://fredkelly.net/articles/2012/12/21/nike_fuel.html</a>
Thanks for writing this. I think I'll try reversing Fitbit beyond Galileo. Also, for those who don't know, Wireshark can sniff the Fitbit dongle using usbmon module incase you don't have a BTLE enabled device. MITMProxy is also great for making dumps to be studied.