La cosa è relativamente semplice (... :) ) se l'apparato in questione garantisce un accesso interattivo al sistema operativo, ovvero permette di accedere con telnet, rsh o ssh o attraverso una console seriale. Spesso questa modalità di connessione non è garantita, infatti i produttori si "proteggono" da modifiche più o meno volontarie bloccando la possibilità di accedere direttamente al sistema operativo dell'apparato stesso.
Questa cosa non è nuova, più o meno una decina di anni fa venivano installati i bot per irc direttamente sui router D-link, sfruttando quella che ormai spero sia una vulnerabilità chiusa del software .
Ho acquistato, qualche tempo fa, un media player. Precisamente il media titan CMT2DW.
Dopo averlo usato per un po' mi sono accorto che andava un po' stretto rispetto alle mie esigenze. Ad esempio il trasferimento al disco interno del mediaplayer è una operazione un po' rognosa, dipende dal sistema operativo del pc che si usa e, in genere, ha delle performance scadenti. Ovviamente l'apparecchio, per quanto dicevo prima, non ha la possibilità di ricevere connessioni via telnet o ssh direttamente.
L'approccio iniziale è stato di togliere l'hard disk interno dal mediaplayer e di connetterlo ad un pc per capire cosa ci fosse dentro. Dato che per me è stato impossibile riuscire decomprimere il fs che porta il sistema operativo del media player ho googolato un po' fino a trovare il wydev-mod4.1. Dopo un po' di smadonnamenti sono riuscito ad applicare il firmware modificato, riuscendo così ad aprire il telnet, l'ftp e altri servizi di base.
A questo punto ci si può divertire, sempre tenendo conto delle limitazioni sopra esposte.
La mia idea, per questo articolo, è di far diventare il mediaplayer un mediacenter. Ovvero voglio che tutti i media risiedano direttamente sull'apparato e che questo non si occupi solo di fare da player per i flussi esterni. In parte il firmware installato è servito a questo scopo, infatti tra le cose che vengono rese disponibili c'è anche la possibilità di riprodurre flussi internet (tramite servizi di sottoscrizione tipo webservices wyplay). Inoltre il fw modificato permette di gestire tutti i servizi installati sul player attraverso una comoda interfaccia web.
Il progetto prevede:
*) iscsi client. Per poter condividere attraverso la lan fs con contenuti multimediali e farli vedere come locali sul player
*) amule server. (che si può controllare con una gui da un pc collegato alla stessa lan)
*) web radio player
... e altre cosucce che eventualmente mi verranno in mente.
Intanto per iniziare è bene conoscere il sistema sul quale dovremo lavorare.
Collegandosi in telnet facciamo alcuni test per determinare correttamente l'hw:
karmam@backup:~$ telnet 10.0.0.15
Trying 10.0.0.15...
Connected to 10.0.0.15.
Escape character is '^]'.
wydev-mod-v4.1 (Future is ours!)
/ $ id
uid=0(root) gid=0(root)
/ $ uname -a
Linux (none) 2.6.23.17_stm23_0118-MDBOXA_V0100_sti7109-26 #1 PREEMPT Wed Sep 2 20:20:45 CEST 2009 sh4 unknown
/ $ df -h
Filesystem Size Used Available Use% Mounted on
/dev/sda6 249.8M 169.6M 80.2M 68% /
tmpfs 512.0k 12.0k 500.0k 2% /dev
none 34.1M 0 34.1M 0% /dev/shm
tmpfs 1.0M 4.0k 1020.0k 0% /tmp
tmpfs 1.0M 200.0k 824.0k 20% /var
tmpfs 512.0k 0 512.0k 0% /media
/dev/sda3 464.0G 227.6M 463.8G 0% /wymedia
/dev/sda6 249.8M 169.6M 80.2M 68% /proc/wybox/WC
/ $ free
total used free shared buffers
Mem: 69784 64460 5324 0 0
Swap: 257032 96 256936
Total: 326816 64556 262260
/ $ cat /proc/cpuinfo
machine : Wyplay MediaBox Prototype Board
processor : 0
cpu family : sh4
cpu type : STb7109
cut : 3.2
cpu flags : fpu
cache type : split (harvard)
icache size : 16KiB (2-way)
dcache size : 32KiB (2-way)
bogomips : 263.16
Trying 10.0.0.15...
Connected to 10.0.0.15.
Escape character is '^]'.
wydev-mod-v4.1 (Future is ours!)
/ $ id
uid=0(root) gid=0(root)
/ $ uname -a
Linux (none) 2.6.23.17_stm23_0118-MDBOXA_V0100_sti7109-26 #1 PREEMPT Wed Sep 2 20:20:45 CEST 2009 sh4 unknown
/ $ df -h
Filesystem Size Used Available Use% Mounted on
/dev/sda6 249.8M 169.6M 80.2M 68% /
tmpfs 512.0k 12.0k 500.0k 2% /dev
none 34.1M 0 34.1M 0% /dev/shm
tmpfs 1.0M 4.0k 1020.0k 0% /tmp
tmpfs 1.0M 200.0k 824.0k 20% /var
tmpfs 512.0k 0 512.0k 0% /media
/dev/sda3 464.0G 227.6M 463.8G 0% /wymedia
/dev/sda6 249.8M 169.6M 80.2M 68% /proc/wybox/WC
/ $ free
total used free shared buffers
Mem: 69784 64460 5324 0 0
Swap: 257032 96 256936
Total: 326816 64556 262260
/ $ cat /proc/cpuinfo
machine : Wyplay MediaBox Prototype Board
processor : 0
cpu family : sh4
cpu type : STb7109
cut : 3.2
cpu flags : fpu
cache type : split (harvard)
icache size : 16KiB (2-way)
dcache size : 32KiB (2-way)
bogomips : 263.16
Vediamo subito che ci sono poco più di 80MB liberi sulla partizione destinata al SO e circa 5MB liberi di memoria... pochino.
Proseguendo l'analisi:
/ $ fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 122 979964+ 83 Linux
/dev/sda2 123 154 257040 82 Linux swap
/dev/sda3 155 60735 486616882+ 83 Linux
/dev/sda4 60736 60801 530145 5 Extended
/dev/sda5 60736 60736 8032 83 Linux
/dev/sda6 60737 60768 257039+ 83 Linux
/dev/sda7 60769 60769 8032 83 Linux
/dev/sda8 60770 60801 257039+ 83 Linux
Disk /dev/sdb: 256 MB, 256901120 bytes
16 heads, 32 sectors/track, 980 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 77 19711+ 83 Linux
/dev/sdb2 78 980 231168 83 Linux
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 122 979964+ 83 Linux
/dev/sda2 123 154 257040 82 Linux swap
/dev/sda3 155 60735 486616882+ 83 Linux
/dev/sda4 60736 60801 530145 5 Extended
/dev/sda5 60736 60736 8032 83 Linux
/dev/sda6 60737 60768 257039+ 83 Linux
/dev/sda7 60769 60769 8032 83 Linux
/dev/sda8 60770 60801 257039+ 83 Linux
Disk /dev/sdb: 256 MB, 256901120 bytes
16 heads, 32 sectors/track, 980 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 77 19711+ 83 Linux
/dev/sdb2 78 980 231168 83 Linux
Nella partizione /dev/sdb2 ci sono i due file core e kernel che rappresentano la versione originale del "firmware" e del SO, quella per intenderci che viene ripristinata in caso di hard reset del player.
Il kernel, come ci si poteva attendere, è una immagine uboot:
karmam@sphynx:~/temp/test$ file kernel
kernel: u-boot legacy uImage, MDBOXB_V0100_7109, Linux/SuperH, OS Kernel Image (gzip), 1612455 bytes, Thu Sep 3 11:07:48 2009, Load Address: 0x84001000, Entry Point: 0x84002000, Header CRC: 0x1C6A1A4A, Data CRC: 0x9AE4C8C9
karmam@sphynx:~/temp/test$ mkimage -l kernel
mkimage: ERROR: "kernel" has bad header checksum!
kernel: u-boot legacy uImage, MDBOXB_V0100_7109, Linux/SuperH, OS Kernel Image (gzip), 1612455 bytes, Thu Sep 3 11:07:48 2009, Load Address: 0x84001000, Entry Point: 0x84002000, Header CRC: 0x1C6A1A4A, Data CRC: 0x9AE4C8C9
karmam@sphynx:~/temp/test$ mkimage -l kernel
mkimage: ERROR: "kernel" has bad header checksum!
Ho l'impressione che qualcosa sia cambiato (...o sia stato customizzato) nella struttura dell'immagine per uboot.
Praticamente il file "kernel" dovrebbe contenere (a occhio) il kernel e il l'immagine iniziale per poter caricare il file "core", che poi è l'intero rootfs (anche questa è una mia idea... di documenti precisi in merito ce ne sono pochi, per cui bisogna fare delle prove...)
Non c'è niente di specifico in internet... o almeno non l'ho trovato... però ci sono spiegazioni per altre architetture o formati... un po' di fantasia :)
alcuni link:
qui [link https://oss.renesas.com/modules/document/?Getting%20Started%20with%20SH4%20and%20QEMU ] c'è l'esempio di come creare una macchina virtuale con qemu che emuli il processore sh4
questo è per la medesima piattaforma che uso io... ma non ha funzionato :| [link http://en.wikibooks.org/wiki/Media_Centers_Based_on_Wyplayer/Firmware#Extraction_Script] però mi ha dato delle idee...
in questo [link http://balau82.wordpress.com/2010/04/12/booting-linux-with-u-boot-on-qemu-arm/] invece trattano più o meno la stessa cosa per piattaforma ARM e qemu.
L'idea generale è di creare una macchina virtuale con qemu nella quale compilare i vari sw che andrò ad installare, poi, nel player. L'idea folle che mi è venuta in mente è di ricostruire tutto il sistema... ovvero ricompilare tutto in una nuova versione e soprattutto ricompilare tutto col supporto delle uclib invece delle gclib. Questo dovrebbe garantire una maggiore disponibilità di spazio ma, soprattutto, di memoria. poi vedrò come installare il tutto nel player ;)
fine prima parte :) alla seconda ci sto lavorando


0 commenti:
Posta un commento