Did I read somewhere that there was some authentication or encryption
that might be a barrier to accessing it?
Be careful. We probably don't have the rights to redistribute the
firmware blob itself, but you can grab and extract it from the MS
firmware update [1]. Let's avoid legal trouble. :)
Sebastian: can you say whether the firmware found in that update
matches what you upload in the bulk transfers?
-Drew
[1] - http://groups.google.com/group/openkinect/browse_thread/thread/17d96d9c36e3effc/df0a76abb4fd8414
On Thu, Feb 24, 2011 at 12:22 PM, Sebastian Ortiz <sebo...@gmail.com> wrote:
> Here's some notes on what I've been able to figure out so far and how:
> http://www.keyboardmods.com/2011/02/kinect-audio-reverse-engineering.html
> I returned my xbox a while ago and I've been rather busy lately, so I
> haven't been able to make any progress beyond what I've described in the
> link above.
Wow. That's awesome. It looks very do-able then.
Interesting.
audios.bin contains the same string starting at offset 0x0005e148.
2bl.bin contains the same string at 0x00009838. I'd guess this is the
bootloader.
>
> The size of the bin file is 911580. I don't know if this matches the size of
> one of those update files, maybe Mike Harrison can comment?
The audios.bin in the firmware update is 512544 bytes.
2bl.bin in the firmware update is 196608 bytes.
So, I don't know exactly what's being sent and what isn't.
I haven't seen anyone post details on how the firmware upload sequence
actually works, so I looked at the adafruit dumps until it made sense.
I was able to successfully extract a byte-for-byte identical copy of
audios.bin from the USB logs. Here's what I think happens:
The transfers that begin "09 20 02 06" appear to be commands. The
first one probably means "start a firmware download". The next 32
such commands seem to be "upload firmware block" - they specify how
many more bytes to expect to receive (0x4000, except the last one,
which is 0x1220), and where in memory to put them (first one is
0x00080000, next is 0x00084000, and it grows by the byte count each
time). After each of these commands, a series of transfers containing
the next set of bytes from the firmware are sent. The 34th command
appears to be "jump to this address" which jumps to the beginning of
the just-uploaded code.
Then the device disconnects, reenumerates, and I haven't looked past there.
I'll write this up on the wiki later, but the initial firmware payload
is precisely the 512544 bytes found in audios.bin in the firmware
update, so it may be possible to have users extract the firmware from
this update.
-Drew