|
|
| (11 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 seems to have 76 byte header of some sort, followed by a romfs called '''SPLASH_BOOT'''.
| | 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 |
|
| |
|
| 00000000 4c 00 00 00 22 5b 91 94 6c 2f 9f 6e 37 20 a1 2e |L..."[..l/.n7 ..|
| | Other or older players: |
| 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:
| | * Confirmed: Quartek WHD500-V9 (works fine but problem with skins? Need more test info.) |
| | * Confirmed: AVeL LinkPlayer2, [http://www.iodata.com/en/news/060623.htm iodata.com] |
| | * Confirmed: Buffalo LinkTheater, [http://www.buffalo-technology.com/products/multimedia/linktheater-ag/linktheater-wireless-ag-network-media-player/ buffalo-technology.com] |
| | * Flexcomm Haidee1000, [http://www.flexcomm.com.cn/products/Haidee1000.html flexcomm.com.cn] |
| | * NETGEN NETBOX 7600HD |
| | * Viewsonic hdmr-2000 |
| | * Sony Playstation 3 |
| | * Sony Bravia TV |
|
| |
|
| -rw-r--r-- 1 root root 881252 Jan 1 1970 10xrpc_xload_audio_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
| | Work done for XBox 360, but unknown if it works yet. |
| -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 -
| |
| | |
| === 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).
| |