Llink:changelog

Network Media Tank Firmware

I downloaded a random version of the firmware, which looks like:

-rw-rw-r--  1 lundman lundman  32380583 Nov  8 00:58 01-13-071101-13-POP-402.zip

32Megs compressed. Inside that we have:

-rw-rw-r-- 1 lundman lundman 17970150 Nov  2 11:11 01-13-071101-13-POP-402-000.bin
-rw-rw-r-- 1 lundman lundman      723 Nov  7 23:32 README.txt
-rw-rw-r-- 1 lundman lundman 14536029 Nov  7 15:44 syb8634.nmt
-rw-rw-r-- 1 lundman lundman      108 Nov  2 22:27 usbupdate.html

Looking at the large 01-13-071101-13-POP-402-000.bin file first, we notice that it has a 76 bytes header.

It is a 3des encrypted header which contains information about the image. The first 4 bytes contains the length of the header and should match 76. Next we have the size of the flash counted in DWORDS and next we have the number of blocks. It also includes a CRC and for each block we have an ASCII description of the block type followed by the length. The header ends with a couple of version strings. A small program parsing and decrypting the header gives the following:

Flash size is 33554432? and number of blocks is 3
Block 1 type: ker, length 5368832
Block 2 type: xos, length 33012
Block 3 type: app, length 13161224
Version 1: xPe0t2, Version 2: c402dPOPk14

The first block is a romfs called SPLASH_BOOT.

00000000  4c 00 00 00 22 5b 91 94  6c 2f 9f 6e 37 20 a1 2e  |L..."[..l/.n7 ..|
00000010  8f 31 3c cd 61 59 d4 c4  53 aa 66 5b e6 00 ae 58  |.1<.aY..S.f[...X|
00000020  ee 3a 1a 92 0c e6 02 b3  22 8b 29 7c 50 9f 8e d0  |.:......".)|P...|
00000030  87 8a 91 09 32 a9 df df  68 0a 86 43 3d 7c 59 93  |....2...h..C=|Y.|
00000040  ce 85 27 59 56 bd 36 bf  76 8d 6d db 2d 72 6f 6d  |..'YV.6.v.m.-rom|
00000050  31 66 73 2d 00 53 18 f0  40 a7 b4 ad 53 50 4c 41  |1fs-.S..@...SPLA|
00000060  53 48 5f 42 4f 4f 54 00  00 00 00 00 00 00 00 49  |SH_BOOT........I|

If we cut out the first 76 bytes and mount it, we get:

-rw-r--r-- 1 root root  881252 Jan  1  1970 10xrpc_xload_audio_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rw-r--r-- 1 root root  326500 Jan  1  1970 11xrpc_xload_video_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rw-r--r-- 1 root root   30724 Jan  1  1970 12xrpc_xload_demux_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rwxr-xr-x 1 root root     773 Jan  1  1970 30vsyncparam_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.zbf
-rwxr-xr-x 1 root root   34262 Jan  1  1970 31bitmap_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.zbf
-rw-r--r-- 1 root root    6404 Jan  1  1970 32xrpc_xload_dviinit_prod.bin
-rw-r--r-- 1 root root  189524 Jan  1  1970 33xrpc_xload_irq_handler_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rw-r--r-- 1 root root 3975492 Jan  1  1970 50xrpc_xload_vmlinux_ES4_prod.bin
-rwxr-xr-x 1 root root      64 Jan  1  1970 dvi.bin

Definitely hardware boot. Loads the various microcodes for the Sigma 8635 chip, which personally I am not interested in. Lastly we appear to have the kernel itself at about 4Megs. However, all up, the whole thing is only 5MB in size. So there is more in the first file after the romfs. One of the values in the header is probably an offset. The size of the romfs is roughly 5.2MB, or 00531c00 in hex. Romfs header has 005318f0, plus 76 bytes at a guess.

But romfs are padded up to nearest 1024. So the size will be 00531c00, plus 76 bytes. This becomes 00531c4c.

005318e0  00 00 00 00 00 00 00 40  39 20 28 88 64 76 69 2e  |.......@9 (.dvi.|
005318f0  62 69 6e 00 00 00 00 00  00 00 00 00 00 00 00 00  |bin.............|
00531900  01 00 00 00 00 00 64 00  72 00 00 00 02 00 00 00  |......d.r.......|
00531910  08 00 00 00 37 00 00 00  0c 00 00 00 89 00 00 00  |....7...........|
00531920  0f 00 00 00 04 00 00 00  33 00 00 00 30 00 00 00  |........3...0...|
00531930  3e 00 00 00 00 00 00 00  03 fe 9b ff 00 00 00 00  |>...............|
00531940  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00531c50  05 00 00 00 c0 7c 00 00  00 00 00 00 00 00 00 00  |.....|..........|
00531c60  00 00 00 00 00 00 00 00  f4 80 00 00 04 00 ff 07  |................|
00531c70  d5 94 c5 33 40 8d 18 9e  17 41 5c e2 ad 49 9e 19  |...3@....A\..I..|
00531c80  11 6b a1 d5 21 76 76 4e  10 60 40 9e 7a 1d 01 52  |.k..!vvN.`@.z..R|
00531c90  89 5f c7 3a 98 bc 7f ef  b5 fe fd fa 7b 36 0b 32  |._.:........{6.2|
00531ca0  7f 29 ba 91 91 85 2c 77  fe 4a 14 c8 cf 91 0c 34  |.)....,w.J.....4|
00531cb0  5b 55 44 45 32 85 c7 9f  ed d0 26 d7 93 3d c7 b1  |[UDE2.....&..=..|
00531cc0  1a 7c 59 6b de db 10 c5  48 da 73 c7 6c a2 f1 0e  |.|Yk....H.s.l...|

It is not clear what this block contains but at offset 00531c68 we find the length, leading us to the next block at 0053194c+000080f4.

Let us take a look at 01-15-071218-14-POP-402-000.bin:

0051EC50   05 00 00 00  C0 7C 00 00  00 00 00 00  00 00 00 00  .....|..........
0051EC60   00 00 00 00  00 00 00 00  F4 80 00 00  04 00 FF 07  ................
0051EC70   D5 94 C5 33  40 8D 18 9E  17 41 5C E2  AD 49 9E 19  ...3@....A\..I..

Next block is thus at 0051ec50+0000f480:

00526D40   E8 D2 C8 00  31 34 00 00  50 4F 50 00  34 30 32 00  ....14..POP.402.
00526D50   EE DB 2F 12  00 00 00 00  00 00 00 00  00 00 00 00  ../.............
00526D60   1F 8B 08 00  BD D3 67 47  00 03 EC 9A  7B 9C 96 53  ......gG....{..S

What we have at 00526D60 is a gzipped tar-image.

00526D40   E8 D2 C8 00  31 34 00 00  50 4F 50 00  34 30 32 00  ....14..POP.402.
00526D50   EE DB 2F 12  00 00 00 00  00 00 00 00  00 00 00 00  ../.............
00526D60   1F 8B 08 00  BD D3 67 47  00 03 EC 9A  7B 9C 96 53  ......gG....{..S

Unpack with dd if=01-15-071218-14-POP-402-000.bin bs=5401952 skip=1|tar xzfv -

At 00526D50 is the CRC of the filesystem. It can be calculated using the following code:

      for(j = 0; j < length; j++) {
	  unsigned int b = buffer[j]<<8;
	  for(k=0; k<8; k++) {
	    if((b ^ crc) & 0x8000) {
	      crc = (crc << 1) ^ 0x1021;
	    } else {
	      crc <<= 1;
	    }
	    b <<= 1;
	  }
      }

If you read the kernel image itself (to find out what filesystems it supports), you will find it has the same header:

00000000  00 00 00 00 05 00 00 00  20 a6 3c 00 00 00 00 13  |........ .<.....|
00000010  02 00 00 00 03 00 00 00  04 00 00 00 44 a9 3c 00  |............D.<.|
00000020  0c 00 01 ff 97 80 fc f4  6b 69 38 93 ef 8a 6e cf  |........ki8...n.|

00000320  3c 0f e2 a6 46 4e 49 42  11 00 00 10 00 00 02 90  |<...FNIB........|
00000330  00 00 02 90 ac f6 e5 ba  00 00 03 02 f1 a5 3c 00  |..............<.|
00000340  00 00 00 00 1f 8b 08 08  26 a6 2a 47 02 03 76 6d  |........&.*G..vm|
00000350  6c 69 6e 75 78 2e 62 69  6e 00 ec 5b 0f 6c 1c 55  |linux.bin..[.l.U|
00000360  7a ff 76 76 76 bd 0e 1b  3c 76 36 61 43 02 d9 b1  |z.vvv...<v6aC...|

Indeed all files inside the romfs has this header. Could just mean they are signed. It is interesting that the filename is there is plain-text.

The syb8634.nmt contains a gzipped tarball, which can be extracted with

dd if=syb8634.nmt skip=1 bs=60 | tar -xzvf -

50xrpc_xload_vmlinux_ES4_prod.bin

The kernel resides in this file and to unpack we can do:

dd if=50xrpc_xload_vmlinux_ES4_prod.bin skip=1 bs=836 |zcat >vmlinux.bin

This image also contains the initial ramdisk which can be extracted to cwd with:

dd if=vmlinux.bin skip=1 bs=4399104|zcat|cpio -id --no-absolute-filenames

fw_image

The tool fw_image that is on the platform, has extern references to des3_decrypt_block, so that makes me think it uses des3 on the image, it also has the CRC functions for each part, before flashing them to /dev/mtd*

The function des3_decrypt_block is found in /lib/libdes.so.1.0.0 and confirmed to be a standard 3des (at least it is compatible with the one in OpenSSL).

The function prototype looks like this:

extern void des3_decrypt_block(void *data, int size, uint8_t *key);

The key has a length of 16 bytes and includes parity bits. The data buffer serves as both input and output.

This makes me confident that I can find the decryption keys should I need to. I have no interest in doing so at this time, I only wanted to know I had the option should Syabas decide to attempt to plug the hole that lets me have root. So even if they did so now, I believe I have all the information needed to decrypt any future firmware (yes, even if they change it in future).

Other firmwares

Pull out anything starting with gzip header from a binary file:

perl -e '$file="test" ; $A=`cat $file` ; while ($A =~ /\x1f\x8b\x08/g) { $pos = length $`; $pos += 0; printf "%X\n", $pos; system("dd if=$file  of=2test.$pos.gz bs=$pos skip=1 > /dev/null 2>&1 "); system("gunzip -c 2test.$pos.gz > 2test.$pos")};'

You can then run file test.* to see interesting things, in particular tarball rootfs, and kernels.