Reverse Engineering the Nike+iPod Protocol • Aaron Parecki

Reverse Engineering the Nike+iPod Protocol

February 11, 2008
I just got a Nike+iPod gadget thingy. It's pretty cool, and stores all the running stats in xml files on the iPod, making for easy hacking of the running data. However, that's not what I really want to do with it.

I got one of Sparkfun's USB serial adapters for it, and can now get the raw data off of it. What I need to be able to detect is whether the sensor received an impact.

Before I bought this, I had heard that the sensor in the shoe transmits its ID every time the runner takes a step. However, after a little experimentation, I found this is not the case. Stepping on the sensor activates it, and once active, broadcasts some data chunks every 1 second. The dump below is from me dropping the sensor on the table, then letting it sit there until it stopped sending. You can see it took 13 seconds of just sitting there before it stopped sending data.

FF 55 1E 09 0D 0D 01 70 C5 07 30 A5 FD AE FA C4 BF 32 0C 52 86 08 AF C9 EA 1C 56 31 CA B8 02 33 32 79 FF 55 1E 09 0D 0D 01 70 C5 07 30 A6 45 59 1F 91 DC 8E C4 FB 66 37 DB 010 9E 75 69 6F 99 08 C4 0A 95 BE FF 55 1E 09 0D 0D 01 70 C5 07 30 A7 1C 94 06 1A 84 A8 010 9A 22 E8 F8 8B F9 67 44 0E 6B AB BB E0 C2 53 FF 55 1E 09 0D 0D 01 70 C5 07 30 A8 57 53 73 39 0F 14 DE 0E 3B 5C 38 73 22 72 23 AD 3A 49 C9 1A 4A EF FF 55 1E 09 0D 0D 01 70 C5 07 30 AA 06 85 D1 B6 9F AB B7 20 3C B9 CD EF DA 6B E5 5D E8 86 A7 42 36 B0 FF 55 1E 09 0D 0D 01 70 C5 07 30 AB EF DC BC ED 7F FB 7E 9B 89 31 07 57 4B B5 B3 79 DA FC E2 4B 8F CA FF 55 1E 09 0D 0D 01 70 C5 07 30 AC 78 B4 0B 79 76 3D 08 B8 F2 B8 C6 D5 B2 AB 13 C7 68 0E 6B E2 78 CC FF 55 1E 09 0D 0D 01 70 C5 07 30 AD 2B 17 0E DA E4 E3 B2 AF 65 5B 90 1F D5 72 F7 85 89 A8 9F A6 FD AE FF 55 1E 09 0D 0D 01 70 C5 07 30 AE A1 3E 49 7C 5E C4 4A 5B 29 0A 9A 9D A3 E5 D0 EE 66 D4 53 F9 010 F3 FF 55 1E 09 0D 0D 01 70 C5 07 30 AF AC CD 2A 92 46 79 E4 53 34 32 D1 6A F7 22 E8 6D C6 D1 9D CB 67 03 FF 55 1E 09 0D 0D 01 70 C5 07 30 A0 B3 69 55 76 07 76 11 CC 9D A8 AD 29 3B B9 87 A4 17 F1 F9 CB 06 65 FF 55 1E 09 0D 0D 01 70 C5 07 30 A1 23 53 40 C5 F5 22 50 BD 83 F1 5D 69 EC D0 4D 1C D0 DA 49 EA A9 2D FF 55 1E 09 0D 0D 01 70 C5 07 30 A2 6F 27 1A 08 2A 93 81 B6 33 2F A0 6B BF B6 D1 4C 9B 0F 33 D1 16 41

(If you look closely, you'll see some 010's in there. That is obviously not a real hex byte, and has something to do with the VB program that Sparkfun put together. I can't actually get the checksums to work out, otherwise I'd be able to tell what it should be.)

Here is what we know so far, compiled from here and here

FF 55 : Apple Accessory Protocol header 1E : length of packet data (from mode through data before checksum) 09 : mode for Nike+ 0D 0D : command 01 : unknown (start of parameter) 70 C5 07 30 : my transmitter's ID A5 : appears to be a counter, always starts with A, counts from 0-F next 21 bytes : unknown

79 : 8 bit additive checksum ((sum of all length/mode/command/parameter bytes) & 0xFF) Note: I can't actually get this to calculate out correct on any of the rows. I must be doing something wrong.

Currently I don't have enough information in order to be able to tell whether a packet contains a footstep or not, since it continues to transmit even after it stops getting footsteps.

Links:
Mon, Feb 11, 2008 9:14am -08:00 #Nike+iPod
Have you written a response to this? Let me know the URL:

Posted in /articles