Nike+ FuelBand SE BLE Protocol Reversed

http://www.evilsocket.net/2015/01/29/nike-fuelband-se-ble-protocol-reversed/

by daw___ • 11 years ago

185 28 11 years ago

revelation• 11 years ago

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.

yonran• 11 years ago

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.

evilsocket6• 11 years ago

yeah I thought about physical sniffing and wanted to buy/build a bt sniffer myself ... but you know, some Android versions have a builtin bt sniffing feature ;)

eyeareque2• 11 years ago

Imagine how much fun you could have with sending messages to runner's bands at Nike branded half and full marathons! :) Not that I would do that.

nkg• 11 years ago

Or you could use Cmd_UploadGraphic and upload some filthy splash screen to their bands... Not that I would do that.

eyeareque2• 11 years ago

This might be helpful for anyone wanting to play with low level BT traffic: http://ubertooth.sourceforge.net/

evilsocket6• 11 years ago

I'm seriously thinking about buying/building one of those

shred45• 11 years ago

FYI, I've recently worked on a similar project, and I tried both the ubertooth and this TI development kit device [1]. The TI device and software was much more reliable and is pretty much plug in and go. Did you do all of this through an Android phone? Very cool.

[1] http://www.ti.com/tool/cc2540emk-usb

ta33• 11 years ago

on a related note, is the act of decompiling jars legal if the software was obtained legally, ie bought?

evilsocket6• 11 years ago

http://reverseengineering.stackexchange.com/questions/60/is-...

mrsteveman12• 11 years ago

Even if you are allowed to reverse engineer software in certain cases, directly taking what you learned from the effort and using it to write other code by yourself is another matter. It's the sort of situation we have "clean room" reverse engineering[1] procedures for.

[1] http://en.wikipedia.org/wiki/Clean_room_design

fredkelly• 11 years ago

This is awesome!

For what it's worth, I spent a little time playing with their Fuel API when the first band was released: http://fredkelly.net/articles/2012/12/21/nike_fuel.html

spydum• 11 years ago

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?

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

evilsocket6• 11 years ago

author here ... it's not THAT easy, that specific piece of code was highly obfuscated by proguard ( you know the a.class, b.class, c.class thing? XD ) and everything made me think about the "correct" algorithm, still I can't find where that 0xFF... is being set :P

cordite• 11 years ago

In other words, obsfuscation was used instead of just applying good practice, and good practice is seemingly harder to debug for development than obsfuscation.

Dylan16807• 11 years ago

I'm baffled by the intended authentication path not using the entire 4 bytes of the CRC after bothering with such a big random number.

zaroth• 11 years ago

I'm baffled by everything about the intended authentication path?! TFA has like 6 paragraphs which reduce to;

  CRC32(MD5(Pin)||Nonce)[0:1]

My eyes! Is something wrong with HMAC?

userbinator• 11 years ago

Here is a related, quite detailed teardown of the FuelBand: http://www.youtube.com/watch?v=7xdajSS_cOU

zumtar• 11 years ago

This is great video and thanks for the link, but just to be clear to others it is not a teardown of the current BLE capable model that the OP has reverse engineered.

mrsteveman12• 11 years ago

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.

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

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 :)

[1] http://infincia.github.io/pyairview/

coding4all• 11 years ago

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.

BorisMelnik• 11 years ago

Extremely impressive, have been watching this technology and have seen a number of folks attempt this.

albertzeyer• 11 years ago

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.

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.

mkesper• 11 years ago

I got one as a present and oh, how I hate Nike for not even caring about android users, much less of using this kind of sensitive data without uploading to their cloud. The device itself is usable as a quite ok step counter requiring Windows only software to even do _anything_ with it. As it measures mainly walking, I cannot even recommend it for the intended purpose.

frogpelt• 11 years ago

I wonder if there is a market boost that comes from having your stuff hacked.

Using the Keurig 2.0 as an example: Adding DRM to the coffee maker turned off a lot of people. But once a hack was discovered it generated more publicity for the company. It makes me want to buy one just because I know I can get around the DRM. If it never had DRM, I don't think I would want one as bad.

rasz_pl• 11 years ago

FF FF FF FF FF FF

maybe Nike hired Sony random number guy(return 4)?

Nike+ FuelBand SE BLE Protocol Reversed

Related Stories