LimHD200i: Difference between revisions

From Lundman Wiki
No edit summary
No edit summary
Line 50: Line 50:




I compiled '''dropbear''' [[http://www.lundman.net/ftp/dropbear-0.50.arm-elf.tgz]] SSH server for arm-elf, but unfortunately it does not start. Most likely due to the very poorly populated '''/dev/''' directory. (There are no tty*/pty* etc).
I compiled '''dropbear''' [[http://www.lundman.net/ftp/dropbear-0.50.arm-elf.tgz]] SSH server for arm-elf, but unfortunately it does not start. Most likely due to the very poorly populated '''/dev/''' directory. (There are no tty*/pty* etc). Read about '''telnetd''' instead.


So I wrote my own very raw program that listens for connections, and spawns requested program, like '''/bin/sh'''. [[http://www.lundman.net/ftp/shell.arm-elf.tgz]]  Without terminal support. At least then I can find out why dropbear does not start.
So I wrote my own very raw program that listens for connections, and spawns requested program, like '''/bin/sh'''. [[http://www.lundman.net/ftp/shell.arm-elf.tgz]]  Without terminal support. At least then I can find out why dropbear does not start. [Which I did, read about '''telnetd''' instead.]




Line 81: Line 81:


And pack up your firmware and flash it. '''root''' has no password, so log right in.
And pack up your firmware and flash it. '''root''' has no password, so log right in.
# telnet 192.168.11.16
Trying 192.168.11.16...
Connected to limhd200i.
Escape character is '^]'.
uclibc login: root
uclibc[/root]# uname -a
Linux uclibc 2.4.22-em86xx-uc0-sigma #2 �� 8�� 7 14:59:04 HKT 2007 armv4l unknown
uclibc[/root]#





Revision as of 02:56, 12 September 2007

DISCLAIMER! This is not supported by Tomacro, and CAN brick/destroy your expensive equipment and I can not be held responsible for any damage. This guide should not be read by anyone.


If you get the latest firmware file from Tomacro, for example [[1]] and unrar it. You should see something like:

-rw-rw-r-- 1 lundman lundman   861184 Jul  4 20:28 bak.bin
-rw-rw-r-- 1 lundman lundman    58128 Jul  3 10:18 boot.bin
-rw-rw-r-- 1 lundman lundman 13542400 Sep  6 10:49 update.bin
-rw-rw-r-- 1 lundman lundman    65536 Jun 28 10:28 userpref.bin


The most interesting file is update.bin. If you do a quick hexdump -C on it you will soon notice that it is in romfs format.

# hexdump -C update.bin |head -3
00000000  2d 72 6f 6d 31 66 73 2d  00 ce a3 c0 a2 f9 ad e0  |-rom1fs-........|
00000010  6d 61 6d 62 6f 00 00 00  00 00 00 00 00 00 00 00  |mambo...........|
00000020  00 00 00 49 00 00 00 20  00 00 00 00 d1 ff ff 97  |...I... ........|


If you have access to a Linux box you can mount it. (I do not, but colleague created a virtual-node for me).

# mount -o loop -t romfs update/bin /mnt
# ls -l /mnt/
drwxr-xr-x 1 root root      32 Jan  1  1970 bin
-rw-r--r-- 1 root root 1385048 Jan  1  1970 bitmap.bin
drwxr-xr-x 1 root root      32 Jan  1  1970 curacao
drwxr-xr-x 1 root root      32 Jan  1  1970 dev
-rw-r--r-- 1 root root 2018068 Jan  1  1970 em8xxx.o
drwxr-xr-x 1 root root      32 Jan  1  1970 etc
-rw-r--r-- 1 root root    5288 Jan  1  1970 gpio_int.o
drwxr-xr-x 1 root root      32 Jan  1  1970 home
-rw-r--r-- 1 root root  177728 Jan  1  1970 irqhandler.bin
drwxr-xr-x 1 root root      32 Jan  1  1970 lib
-rwxr-xr-x 1 root root 1112711 Jan  1  1970 linux.bin.gz
-rw-r--r-- 1 root root   33986 Jan  1  1970 llad.o
drwxr-xr-x 1 root root      32 Jan  1  1970 mnt
drwxr-xr-x 1 root root      32 Jan  1  1970 opt
drwxr-xr-x 1 root root      32 Jan  1  1970 proc
drwxr-xr-x 1 root root      32 Jan  1  1970 root
drwxr-xr-x 1 root root      32 Jan  1  1970 sbin
drwxr-xr-x 1 root root      32 Jan  1  1970 tmp
drwxr-xr-x 1 root root      32 Jan  1  1970 usr
drwxr-xr-x 1 root root      32 Jan  1  1970 var
-rw-r--r-- 1 root root   31156 Jan  1  1970 vsyncparam.bin


romfs is always mounted read-only, so you can not edit /mnt. Simply rsync it somewhere else and start your chances.

# rsync -arv /mnt ~/limtest/


I compiled dropbear [[2]] SSH server for arm-elf, but unfortunately it does not start. Most likely due to the very poorly populated /dev/ directory. (There are no tty*/pty* etc). Read about telnetd instead.

So I wrote my own very raw program that listens for connections, and spawns requested program, like /bin/sh. [[3]] Without terminal support. At least then I can find out why dropbear does not start. [Which I did, read about telnetd instead.]


Re-creating the firmware. You need to get genromfs and issue a command like:

# ~/genromfs-0.5.2/genromfs -f ~/test.bin -d ~/limtest/mnt/ -V mambo
# ls -l test.bin
-rw-rw-r-- 1 lundman lundman 13542400 Sep  6 10:49 test.bin

Rename it to update.bin, copy it to your LimHD200i's HD1, or USB, in a subdirectory called update and try it out. Setup menu, Update App item.

Will it work, I'll find out tonight...


Ok my shell does work fine, but also found out that telnetd work well, that comes with it. I would suggest then:

# cd mnt/sbin
# ln -s ../bin/busybox telnetd
# cd ../etc/init.d/
# vi S30network
insmod gpio_int.o

/sbin/telnetd &

cd /curacao
./curacao /mnt /dev/ir

And pack up your firmware and flash it. root has no password, so log right in.

# telnet 192.168.11.16
Trying 192.168.11.16...
Connected to limhd200i.
Escape character is '^]'.

uclibc login: root
uclibc[/root]# uname -a
Linux uclibc 2.4.22-em86xx-uc0-sigma #2 �� 8�� 7 14:59:04 HKT 2007 armv4l unknown
uclibc[/root]# 



Inside the LimHD200i

The HD1 is mounted read-only, so from a default setup there is not much point in compiling smbd, nfsd or ftpd, since you will not be able to modify the HDD.

/dev/ide/host0/bus0/target0/lun0/part1   298.1G    260.4G     37.7G  87% /mnt/HD1

/dev/ide/host0/bus0/target0/lun0/part1 on /mnt/HD1 type ntfs (ro,noatime,nodiratime,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1)

USB DVD drive looks like;

/dev/scsi/host0/bus0/target0/lun0/cd  3266902   3266902         0 100% /mnt/USB1

Unfortunately, libdvdcss's csstest program claim all the disks I've tried are not scrambled:


uclibc[/tmp]# ./csstest /dev/scsi/host0/bus0/target0/lun0/cd
cool, I found libdvdcss version 1.2.9
examples:
  ./csstest /dev/hdc 1024
  ./csstest D: 1024
  ./csstest scrambledfile.vob 1024
uclibc[/tmp]# ./csstest /dev/scsi/host0/bus0/target0/lun0/cd 1024 
cool, I found libdvdcss version 1.2.9
requested sector:      00     00     01     2u...     2{     1i     0�     2e     2�     17     1n     1}     2�     0d     05     1}     2�     09     1�     1�     2s     3g     2�     0l     03     2�...
sector is not scrambled

uclibc[/tmp]# ./csstest  /mnt/USB1/video_ts/vts_01_2.vob 1024
cool, I found libdvdcss version 1.2.9
zS@j>-�301�}�<O2NR���BV1�cn����-�pC>݃�"��?���?��E?��v?��?���?�̂?��E?���?��?���?@j>zS@j>-�30�...<O2NR���BV1�cn����-��?���?��E?��v?��?���?�̂?��E?���?��?���?��"Q
sector is not scrambled


Ah just a misunderstanding of how csstest works. That's the block I want to unscramble, and only video streams are scrambled.

uclibc[/tmp]# ./csstest /dev/scsi/host0/bus0/target0/lun0/cd 1000001
cool, I found libdvdcss version 1.2.9
requested sector:  00 00 01 2c... 0� 0� 2� 18 1� 2~ 2� 2� 0� 0} 1w 0� 2� 1p 0g 2                                                                     2� 0� 2e 2g 0� 0d 0�...
unscrambled sector:  00 00 01 2c... 2� 1� 1s 1z 1� 2 2� 1� 0� 1f 1u 0| 2p 0� 0�                                                                           1� 0� 0� 27 0� 13 1l...


FUSE

As it turns out, there are at least two FUSE filesystems that sits on libdvdread / libdvdcss. I could use one of those, or a more raw one that only uses libdvdcss. However, first we will need FUSE compiled, and that is not easy. It seems only Fuse-1.4 will compile against such an old kernel. Most Fuse filesystems will not work against the old FUSE.

I have tried a few versions of FUSE.

Fuse-2.0b from [[4]]

uclibc[/tmp]# insmod fuse.ko
Using fuse.ko
insmod: unresolved symbol match_octal
insmod: unresolved symbol page_cache_release
insmod: unresolved symbol sema_init
insmod: unresolved symbol match_token
insmod: unresolved symbol BUG_ON
insmod: unresolved symbol down
insmod: unresolved symbol down_interruptible
insmod: unresolved symbol down_trylock
insmod: unresolved symbol match_int
insmod: unresolved symbol grab_cache_page
insmod: unresolved symbol up
insmod: unresolved symbol test_bit


Fuse-2.5.3:

uclibc[/tmp]# insmod fuse.o 
Using fuse.o
insmod: unresolved symbol page_cache_release
insmod: unresolved symbol get_user_pages
insmod: unresolved symbol grab_cache_page


Fuse-1.4:

uclibc[/tmp]# insmod fuse.o
Using fuse.o
insmod: unresolved symbol page_cache_release
insmod: unresolved symbol BUG_ON
insmod: unresolved symbol grab_cache_page


As it happens, grab_cache_page call can be replaced by a find_get_page. I have not found a replacement for page_cache_release but as a proof of concept I can go without it (and leak memory).

get_user_pages would be trickiest in 2.5.3, otherwise 1.4 should run if the BUG_ON thing isn't hard.


Trying Fuse

Ok tried 2.5.3 and patched my way around things with some serious hacks:

uclibc[/tmp]# insmod fuse-25.o
Using fuse-25.o
uclibc[/tmp]# lsmod
Module                  Size  Used by    Tainted: P
fuse-25                25664   0 (unused)

uclibc[/tmp]# ./hello-25 /mnt/USB2 -d -s &
25157

But unfortunately df shows no mounts, and there is nothing to see in there. Oh well. It is possible the userland patches never gets to the kernel, as we can't daemonize, nor fork.