I’ve analyzed the structure of the “.bin” files used for firmware updates on the iSpot, and will document/update my findings below.
Here is a hex-dump of the beginning of a firmware update “.bin” file (this is from “iSpot_Software_080510.bin”):
00000000 49 4d 57 2d 43 36 31 35 57 00 00 00 00 00 00 00 |IMW-C615W.......| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 04 03 02 01 01 09 09 04 fa 06 00 00 07 00 00 00 |................| 00000030 00 04 00 00 ec 96 11 00 c6 3d 6c 04 ad 30 9f 57 |.........=l..0.W| 00000040 eb 68 2f c1 f3 9f da 48 ec 9a 11 00 00 00 52 00 |.h/....H......R.| 00000050 33 dd ab bd 0f da 5d 02 f2 db c1 5e 35 bb 61 7e |3.....]....^5.a~| 00000060 ec 9a 63 00 72 73 16 00 d9 ed ae eb 3d 90 b8 87 |..c.rs......=...| 00000070 9d 7e 10 93 a8 2d 52 4f 00 00 00 00 00 00 00 00 |.~...-RO........| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 31 2e 31 2e 31 00 00 00 00 00 00 00 00 00 00 00 |1.1.1...........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
Here is a description of the data at specific offsets:
0000-001e : Text description of image file (“name”)
001f-001f : I believe this is just a NULL terminator for the above string
0020-0023 : Used by the flash_program application to determine byte order (big- vs little- endian) of the file. Should always be “04 03 02 01”.
0024-0027 : Version number (“vpos”): (“01 09 09 04” in this build: corresponds to “v1994”)
0028-002b : SVN version number (“svn”): same as value stored in this image’s “/etc/version.svn”, stored as a little-endian 32-bit value
002c-002c : Bitmask describing which ‘sub-files’ are contained in the .bin (“bintype”).
If bit 0 is set (bitmask 0x01), then the image contains a KERNEL.
If bit 1 is set (bitmask 0x02), then the image contains a jffs2 root filesystem (ROOTFS).
If bit 2 is set (bitmask 0x04), then the image contains a WiFi firmware image (WIFI).
If bit 3 is set (bitmask 0x08), then the image contains an unknown 4th sub-file image (UNDEF).
002d-002f : Unknown/undefined
KERNEL info:
0030-0033 : Offset into .bin file to start of kernel image (if “bintype” KERNEL bit is set) (little-endian 32-bit)
0034-0037 : Size of kernel image (if “bintype” KERNEL bit is set) (little-endian 32-bit)
0038-0047 : MD5 hash of kernel image (if “bintype” KERNEL bit is set)
ROOTFS info:
0048-004b : Offset into .bin file to start of jffs2 root filesystem image (if “bintype” ROOTFS bit is set) (little-endian 32-bit)
004c-004f : Size of jffs2 root filesystem image (if “bintype” ROOTFS bit is set) (little-endian 32-bit)
0050-005f : MD5 hash of jffs2 root filesystem image (if “bintype” ROOTFS bit is set)
WIFI info:
0060-0063 : Offset into .bin file to start of WiFi firmware image (if “bintype” WIFI bit is set) (little-endian 32-bit)
0064-0067 : Size of WiFi firmware image (if “bintype” WIFI bit is set) (little-endian 32-bit)
0068-0077 : MD5 hash of WiFi firmware image (if “bintype” WIFI bit is set)
UNDEF info:
0078-008f : Appears to be room for fourth ‘sub-file’ info
0090-???? : If “bintype” WIFI bit is set, then the ASCII (NULL terminated) version string for the WiFi image is stored here (max length unknown).
????-00c3 : Unknown (currently NULL bytes)
Looking at the specific file header show in the hex-dump above, you can see that the “svn” version number is 0x000006fa (“1786” decimal).
The “.bin” file contains a kernel image, a jffs2 root filesystem image, and a WiFi firmware image (because “bintype” is “07”, so all three file type bits are set).
The KERNEL image starts at offset 0x00000400 into the “.bin” file, and is 0x1196ec bytes long.
The ROOTFS image starts at offset 0x119aec into the “.bin” file, and is 0x00520000 bytes long.
The WIFI image starts at offset 0x00639aec into the “.bin” file, and is 0x00167372 bytes long.
Sub-file image format
The KERNEL image is a standard compressed kernel image (with a ‘header applet’ which decompresses the kernel payload and jumps to it). It is for an ARM architecture CPU.
The ROOTFS image is a JFFS2 filesystem image. This was likely created either directly using “mkfs.jffs2”, or by dumping the contents of the flash chip partition after the JFFS2 image was created there.
The WIFI image is a standard compressed kernel image with an embedded init ramdisk (“initrd”). This kernel is for a MIPS architecture CPU.
Manipulating firmware update image
I plan on releasing some utilities for unpacking/repacking the contents of a firmware update image. Once finished, a link will be provided here.
EDIT: The firmware manipulation utility has been released. See this article : “Release of ‘fwtool’ – firmware image manipulation tool“.
Disclaimer: information on this site is for educational purposes only, and intended to help iSpot owners experiment with their own devices. I do not condone any hacking for illegal purposes, such as stealing service, etc.
Pingback: Why don’t firmware ‘downgrades’ work on the iSpot? | Hacking the iSpot