Firmware update

[floe]

Hi everyone, one of the features still missing from libfreenect2 is the firmware update. I had the opportunity to get an USB3 capture of an outdated Kinect v2 getting connected to an official SDK running on Windows 10 in a VM; I didn't have time so far to analyze it. If anybody is interested in digging into the raw PCAP files (which, in theory, should of course also include the firmware itself), I'm making them available here: http://floe.butterbrot.org/external/firmware_pcap/

/cc @xlz @marcan @qdot @christiankerl @larshg @sh0

[xlz]

Are there some textual descrptions for kinect1.pcap kinect2.pcap kinect3.pcap? Which one should I look at?

[floe]

Sorry - the first kinect1.pcap is probably not very useful (lots of connect & disconnect events), kinect2 and kinect3 should in theory contain one full update process + some image streaming afterwards.

[xlz]

I'm able to extract 5 firmware blobs. They seem to be signed. I think they are copyrighted code.

-rw-r--r-- 1 xlz xlz 61440 Nov  9 12:23 1.bin
-rw-r--r-- 1 xlz xlz 61440 Nov  9 12:23 2.bin
-rw-r--r-- 1 xlz xlz 61440 Nov  9 12:23 3.bin
-rw-r--r-- 1 xlz xlz  4300 Nov  9 12:22 5.bin
-rw-r--r-- 1 xlz xlz  4300 Nov  9 12:23 6.bin

I transcribed the pcaps to readable commands https://gist.github.com/xlz/1d737766bb5a97f77475. (Values of firmware blobs, camera parameters, p0 tables are removed.)

Basically it uses 0x04 command to upload a blob to certain firmware "segment", and once for each of 1,2,3,5,6 segments. Then uses 0x05 command to check status until certain success condition. It seems there will be port reset after each upload. I'm not sure who initiated this. Also Microsoft SDK checks firmware versions again and again, not sure of the meaning.

There are two major issues about the firmware update feature:

• There has to be a way to retrieve the firmware blobs from Microsoft sources. Firmware is copyrighted so it can't be included in libfreenect2. Where do they come from in this case, are the firmware blobs generated by KinectService.exe or downloaded from Microsoft website?
• Concern of bricking the hardware by firmware flashing bugs.

[floe]

Impressive work, as always. Is there a way to tell what architecture the firmware is for, e.g. for disassembly?

I would assume that the firmware is part of KinectService; however, I didn't check for network traffic simultaneously. I'd also refrain from actually adding any firmware update capability to libfreenect2; at most, I would suggest to add a tool to manually poke at the Kinect using command 0x04. Did you see anything that might be a firmware download command?

[sh0]

The firmware blobs are baked into KinectService.exe (version v2.0_1409) using custom executable resource (type = RCDATA, id = 101). This resource file could be extracted using standard tools or be copied straight from file (offset = 0x00389b80 = 3709824, size = 0x000ff9d0 = 1046992).

This resource blob starts with 'INAM' and hence I call it INAM file. The following structure describes the header:

struct s_inam {
    0x00: char[4] magic; // = "INAM"
    0x04: uint32_t version; // = 1
    0x08: uint32_t entries_offset; // = 0x20 = 32 // from file start
    0x0c: uint32_t entries_count; // = 7
    0x10: uint32_t unk10; // = 0x0666fa92 = 107412114
    0x14: uint32_t unk14[3]; = { 0, 0, 0 }
};

Firmware blob entry table follows the header:

struct s_entry {
    0x00: uint32_t id;
    0x04: uint32_t offset; // from file start
    0x08: uint32_t size;
    0x0c: uint32_t unk0c; // = 0 or 1
    0x10: uint16_t version[8]; // = { 0000 0400 470f 0000 0000 0000 0000 0000 }
    0x20: uint8_t unk20[0x10]; // all zeroes
}; // size = 0x30 = 48

Each firmware blob has following layout:

struct s_firmware {
    // signature [0x0117]
    0x0000: char[4] signature_magic; // = "Sign"
    0x0004: uint32_t signature_size; // = 0x010c = 268
    0x0008: uint32_t signature_version; // = 0
    0x000c: uint8_t signature_data[0x010c];

    // header [0x0034]
    0x0118: uint16_t header_version[8]; // = { 0000 0400 470f 0000 0000 0000 0000 0000 }
    0x0128: uint32_t header_address_a;
    0x012c: uint32_t header_address_b;
    0x0130: uint32_t header_size;
    0x0134: uint32_t header_crc32;
    0x0138: uint32_t header_0138; // = 1
    0x013c: uint32_t header_013c; // = 2
    0x0140: uint32_t header_0140; // = 0
    0x0144: uint32_t header_0144; // = 0
    0x0148: uint32_t header_0148; // = 0

    // content
    0x014c: uint8_t content[header_size];
}

There are 7 firmware blobs with following details:

fw00: address_a = 0x00000000, address_b = 0xffff0040, size = 0x00003b30 = 15152
fw01: address_a = 0x20400040, address_b = 0x204006a8, size = 0x0001bdb8 = 114104
fw02: address_a = 0x20400040, address_b = 0x20400680, size = 0x0001bdb8 = 114104
fw03: address_a = 0x20010040, address_b = 0x2001239c, size = 0x000c13fc = 791548
fw04: address_a = 0x00000000, address_b = 0x00000000, size = 0x00000100 = 256
fw05: address_a = 0x00000000, address_b = 0x00000000, size = 0x00000f80 = 3968
fw06: address_a = 0x00000000, address_b = 0x00000000, size = 0x00000f80 = 3968

Files fw00 to fw03 are ARM code. For some reason fw01 and fw02 have exactly same content so there are only 3 distinct files with executable code. The address_a and address_b fields are related to ROM loading/start addresses. fw03 contains some tables at the end of the file. Files fw04 to fw06 contain some unknown data tables.

[xlz]

md5sums of the 5 blobs.

5e9b38f2a22920f88f8ce05c47359c4b  1.bin
ff4b2bf423814b4c17e4b503261c482a  2.bin
4b9a03ad0b5f70effa1a784a8925814f  3.bin
0cdad3462a01c7bccd4898a743565453  5.bin
fa465151f5ddca455ca2306a6650117b  6.bin

@sh0 See if you can map the uploaded segment number with fw0?. https://gist.github.com/xlz/ba98525d8f7b8472f2b9

[sh0]

I uploaded all relevant files here. *.bin files are the signed blobs (start with Sign tag) and *.arm files contain only the firmware content (with headers stripped).

Also here are the md5 sums for convenience:

444d68c9292cc91fe3ea12220e350e48  firmware-00.arm
07f2d865e48463c4aea3396580969112  firmware-01.arm
07f2d865e48463c4aea3396580969112  firmware-02.arm
6b29cb23136eea94556821e47bbbb14c  firmware-03.arm
ceb844f25840855a8694e4715b38b0ea  firmware-04.arm
04bcec8d28dcd04c32631d4ecadea356  firmware-05.arm
fb1bdcf74a2c3a5972fb7cf74bc40830  firmware-06.arm

ef94ebec25cd0b367085fb0d2c826222  firmware-00.bin
4b8f53411b3980d171780adaee28de12  firmware-01.bin
1050a58366240469224ab71c303a97b8  firmware-02.bin
33f741bc072d7fc28c0a433a4f956b32  firmware-03.bin
bdc789ba57a7ceefab833124197f40dd  firmware-04.bin
0cdad3462a01c7bccd4898a743565453  firmware-05.bin
fa465151f5ddca455ca2306a6650117b  firmware-06.bin

[xlz]

are baked into KinectService.exe

Then the update mechanism should be Windows driver update. From my experience Windows will automatically install Kinect Runtime without asking for any EULA or licenses. The runtime is also here http://www.microsoft.com/en-us/download/details.aspx?id=44559. It looks like it has no EULA or licenses, so the user can just download and update that and extract firmware blobs without installing it.

Did you see anything that might be a firmware download command?

I didn't see any. The transcribed commands are all the bulk transfers. There were no other bulk transfers.

[xlz]

So firmware-0{1,2,3}.bin and {1,2,3}.bin have the same content for the first 0xf000 bytes. And firmware-0{5,6}.bin {5,6}.bin are the same.

[sh0]

I just figured out why fw01 and fw02 look similar - both actually contain two signed blobs. First blob starts at 0x0000 and the second one at 0xf0ec.

Also fw03 has blobs at 0x000000 and 0x021fb4.

[xlz]

There are a few more questions:

• What is the correct length for uploading? The uploaded length is shorter than the available length.
• Why are firmware 0 and 4 not uploaded? (Looks like unk0c means bool no_upload, being 1 for id 0,4 and 0 for 1,2,3,5,6). These two are "critical" sections.
• What is the possible purpose of each blob?

[floe]

Just speculation, but is it possible that blobs 0 and 4 are basically just backups? I.e. firmware is usually present in two copies, and one copy is preserved in case the update or signature check fails?

[xlz]

@sh0 I think that is not two blobs. The second "Sign" is the code that checks the signature.

[sh0]

@xlz All makes sense now, the second 'Sign' tag threw me off on a wild goose chase.