NMT:firmware: Difference between revisions

From Lundman Wiki
No edit summary
No edit summary
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Network Media Tank Firmware ==
== List of compatible streamers ==
Note that this list is not a complete reference, and all listed products are not confirmed, but in theory llink should work with most Syabas middleware hardware. There is a product list maintained on the [http://www.networkedmediatank.com/wiki/index.php/Products NMT wiki].<br>


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
''Please add to this list if you have found a player confirmed to work with [[llink]].''




32Megs compressed. Inside that we have:
Syabas NMT powered media players:
* Confirmed: Popcorn Hour A-100, A-110, B-110, A-200, C-200 [http://www.popcornhour.com popcornhour.com]
* Confirmed: Digitek HDX900, HDX1000 [http://hdx1080.com/ hdx1080.com]
* DuneHD Ultra, [http://www.dune-hd.com/ dune-hd.com]
* ISTAR Mini, [http://istarhd.com/ istarhd.com]
* eGreat EG-M31A, EG-M31B [http://www.egreathd.com egreathd.com]
* Shenzhen Elektron EHP-600, 606 Mini [http://www.elektron-china.com/en/viewproduct.asp?id=180 elektron-china.com]
* CMI SYVIO-200 [http://www.cmicable.com/en/products_details.asp?id=307 cmicable.com]
* Dueple 700D [http://www.dueple.se/ dueple.se]
* Kaiboer K-100 [http://www.kaiboerhd.com/views.asp?hw_id=395 kaiboerhd.com]
* Dragontech ioBox-100HD [http://www.dragontechcorp.com/products/iobox-100hd.htm dragontechcorp.com]
* Balocco Box [http://www.telcominstrument.com/p_359_18_43_balocco-lettore-box-multimediale-nmt-media-player-hdtv-full-hd-matrioska-bittorrent-hdmi-mkv-h264-internet-lan-ethernet-browser-web-nas-upnp-p2p-youtube-harddisc.html telcominstrument.com] (eGreat clone)
* Icy Box IB-MP309HW-B [http://www.networkedmediatank.com/showthread.php?tid=16868 www.networkedmediatank.com] does NOT have colour buttons on remote!
* Popbox V8 [http://www.popbox.com/onlinestore/ http://www.popbox.com/onlinestore/]


-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.
UPnP players
* PlugPlayer app for iPhone and iPad. [http://www.plugplayer.com/ plugplayer.com]
* XBMC, OS X, Live and AppleTV2 tested. [http://xbmc.org/ XBMC]
* EyeController for iDevices and Android
* Softmedia Player


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.
Other or older players:
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
* Confirmed: Quartek WHD500-V9 (works fine but problem with skins? Need more test info.)
Block 1 type: ker, length 5368832
* Confirmed: AVeL LinkPlayer2, [http://www.iodata.com/en/news/060623.htm iodata.com]
Block 2 type: xos, length 33012
* Confirmed: Buffalo LinkTheater, [http://www.buffalo-technology.com/products/multimedia/linktheater-ag/linktheater-wireless-ag-network-media-player/ buffalo-technology.com]
Block 3 type: app, length 13161224
* Flexcomm Haidee1000, [http://www.flexcomm.com.cn/products/Haidee1000.html flexcomm.com.cn]
Version 1: xPe0t2, Version 2: c402dPOPk14
* NETGEN NETBOX 7600HD
* Viewsonic hdmr-2000
* Sony Playstation 3
* Sony Bravia TV


The first block is a romfs called '''SPLASH_BOOT'''.
Work done for XBox 360, but unknown if it works yet.
 
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 <code>dd if=01-15-071218-14-POP-402-000.bin bs=5401952 skip=1|tar xzfv -</code>
 
At '''00526D50''' is the CRC of the filesystem. It can be calculated using the following code:
 
<pre>
      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;
  }
      }
</pre>
 
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).
 
 
== RusHD firmware ==
 
Very similar. The difference here is that the rootfs that is inside the vmlinux image contains a whole lot more than usual, and is in '''cpio''' format. This has the base minimum for rootfs, with busybox etc.
 
Pull out anything starting with '''gzip''' header:
 
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 this case:
 
# cpio -ivd --no-absolute-filenames < ../2test.2560000
# ls -l
total 120
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 bin
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 CVS
drwx------ 7 lundman lundman 4096 2008-05-13 09:45 dev
drwxr-xr-x 5 lundman lundman 4096 2008-05-13 09:45 etc
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 home
lrwxrwxrwx 1 lundman lundman  12 2008-05-13 09:45 init -> /bin/busybox
drwxr-xr-x 3 lundman lundman 4096 2008-05-13 09:45 lib
lrwxrwxrwx 1 lundman lundman  11 2008-05-13 09:45 linuxrc -> bin/busybox
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 mnt
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 opt
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 proc
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 root
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 sbin
drwxr-xr-x 2 lundman lundman 4096 2008-05-13 09:45 tmp
drwxr-xr-x 6 lundman lundman 4096 2008-05-13 09:45 usr
drwxr-xr-x 3 lundman lundman 4096 2008-05-13 09:45 var
# ls -l bin/
total 1760
-rwxr-xr-x 1 lundman lundman 777460 2008-05-13 09:45 bash
-r-xr-xr-x 1 lundman lundman  7158 2008-05-13 09:45 bashbug
-rwxr-xr-x 1 lundman lundman 699300 2008-05-13 09:45 busybox
-rwxr-xr-x 1 lundman lundman  9696 2008-05-13 09:45 fw_extract
-rwxr-xr-x 1 lundman lundman  15804 2008-05-13 09:45 genxenv
 
 
And so on. Now, I am not entirely sure how the real '''rootfs''' is stored, but if you read '''etc/init.d/S77misc''' you can quickly see how it is extracted:
 
FW_FILE_OFF=6291968
echo "Found /D/system/$FW_FILE_NAME, trying it"
/bin/fw_extract /D/system/"$FW_FILE_NAME" $FW_FILE_OFF |
  tar -C /firmware -xzf -
 
So I simply did that as well, I ran '''fw_extract''' on my PCH.
 
./fw_extract dune_firmware_rushd_080422_2238.dff 6291968 > bin-rootfs.tgz
# tar -ztvf bin-rootfs.tgz
-rwxr-xr-x alex/users      729 2008-04-23 03:38 ./scripts/boot.sh
drwxr-xr-x alex/users        0 2008-04-23 03:38 ./dvdplayer2/
drwxr-xr-x alex/users        0 2008-04-23 03:38 ./dvdplayer2/bin/
-rwxr-xr-x alex/users  1110748 2008-04-23 03:38 ./dvdplayer2/bin/play_dvd
-rwxr-xr-x alex/users      790 2008-04-23 03:38 ./dvdplayer2/run
drwxr-xr-x alex/users        0 2008-04-23 03:38 ./ftpserver/
 
Success.
 
== iStar firmware ==
 
Quite similar to PCH. I ran the giant perl line from RusHD to pull out all gzips, and found the rootfs pretty quickly.
 
-rw-r--r-- 1 lundman lundman 43683840 2008-05-13 09:19 test.6480772

Latest revision as of 05:56, 27 October 2011

List of compatible streamers

Note that this list is not a complete reference, and all listed products are not confirmed, but in theory llink should work with most Syabas middleware hardware. There is a product list maintained on the NMT wiki.


Please add to this list if you have found a player confirmed to work with llink.


Syabas NMT powered media players:


UPnP players

  • PlugPlayer app for iPhone and iPad. plugplayer.com
  • XBMC, OS X, Live and AppleTV2 tested. XBMC
  • EyeController for iDevices and Android
  • Softmedia Player

Other or older players:

  • Confirmed: Quartek WHD500-V9 (works fine but problem with skins? Need more test info.)
  • Confirmed: AVeL LinkPlayer2, iodata.com
  • Confirmed: Buffalo LinkTheater, buffalo-technology.com
  • Flexcomm Haidee1000, flexcomm.com.cn
  • NETGEN NETBOX 7600HD
  • Viewsonic hdmr-2000
  • Sony Playstation 3
  • Sony Bravia TV

Work done for XBox 360, but unknown if it works yet.

Retrieved from "http://lundman.net/wiki/index.php?title=NMT:firmware&oldid=4055"