Nike+ FuelBand SE BLE Protocol Reversed • Hacker News Board

Re: Nike+ FuelBand SE BLE Protocol Reversed

#21

Post by BorisMelnik » Fri, Jan 30, 2015, 8:05 AM UTC

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

Re: Nike+ FuelBand SE BLE Protocol Reversed

#22

Post by albertzeyer » Fri, Jan 30, 2015, 8:36 AM UTC

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.

Re: Nike+ FuelBand SE BLE Protocol Reversed

#23

Post by mkesper » Fri, Jan 30, 2015, 8:59 AM UTC

albertzeyer wrote: post #22

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.

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.

Re: Nike+ FuelBand SE BLE Protocol Reversed

#24

Post by zaroth » Fri, Jan 30, 2015, 10:35 AM UTC

Dylan16807 wrote: post #13

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.

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?

Re: Nike+ FuelBand SE BLE Protocol Reversed

#25

Post by zumtar » Fri, Jan 30, 2015, 10:46 AM UTC

userbinator wrote: post #17

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

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.

Re: Nike+ FuelBand SE BLE Protocol Reversed

#26

Post by rasz_pl » Fri, Jan 30, 2015, 2:28 PM UTC

FF FF FF FF FF FF

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

Re: Nike+ FuelBand SE BLE Protocol Reversed

#27

Post by evilsocket » Fri, Jan 30, 2015, 2:39 PM UTC

shred45 wrote: post #11

evilsocket wrote: post #7

Earlier quoted context omitted.

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

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

yep, android phone ( nexus 5 ) and some hci bluetooth sniffing on a nexus 4 ( you can enabled it on 4.4.4 under dev settings panel )

Re: Nike+ FuelBand SE BLE Protocol Reversed

#28

Post by evilsocket » Fri, Jan 30, 2015, 2:41 PM UTC

spydum wrote: post #12

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…

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

Re: Nike+ FuelBand SE BLE Protocol Reversed

#29

Post by cordite » Fri, Jan 30, 2015, 4:14 PM UTC

evilsocket wrote: post #28

spydum wrote: post #12

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…

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

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

Re: Nike+ FuelBand SE BLE Protocol Reversed

#30

Post by evilsocket » Fri, Jan 30, 2015, 4:16 PM UTC

cordite wrote: post #29

evilsocket wrote: post #28

Earlier quoted context omitted.

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

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

EXACTLY :D