Siemens Gigaset HD795 T

Iniciado por odracir

...Creo yo que esto lo conoces, más que nada lo pongo para que me corrijan Denis111 o Mapelo si me equivoco en lo que "creo"...

odracir, todo lo has explicado muy bien. Lo que pasa es que los que usamos Linux a veces damos por supuesto cosas que los usuarios de Windows desconocen.

Pero tú lo has enfocado bien: a los usuarios del HD795T no les hace falta para nada todo lo que se ha contado en los últimos mensajes, pues vosotros ya tenéis acceso total al todos los ficheros del sistema, y además como root (administrador supremo) con telnet.

Los usuarios del HD795TW, con el firmware sin tocar, no tenemos acceso por ftp a nada, y el samba está enjaulado (chroot) al contenido de HDD1 (los fichero de música, imagen y vídeo que hemos almacenado) y a USB1 (el pendrive que podemos pinchar). Formatear un pendrive con ext3 y ponerles un enlace simbólico apuntando a la raiz (/) del sistema Linux del aparato es el truco para poder ver por primera vez todo el árbol de directorios y ficheros. A los usuarios del HD795T no les hace falta nada de esto, pues ya lo ven cuando hacen telnet.

La gracia de todo esto es que nos hemos encontrado con que algunos ficheros se pueden modificar, y hemos corregido alguna de las configuraciones del ftp para hacerlo funcionar. El paso para los usuarios del HD795TW ha sido muy grande, pues antes no podíamos usar este rápido protocolo para transferir ficheros en red. Otra novedad para nosotros los del TW es que podemos ordenar los canales sin el trauma de que se pueda reiniciar el aparato constantemente, porque hemos podido acceder en modo lectura y escritura al fichero que guarda los canales.

La pregunta que nos hemos hecho ha sido que como ya podemos ver todo el sistema, y sabemos cómo modificarlo para mejorar sus prestaciones, si podríamos activar servicios (como el de telnet, y así disponer también de todo lo avanzado en este foro con el HD795T). El problema es que solo podemos modificar al acceder por samba o por ftp a un limitado número de ficheros, pues accedemos como un usuario no privilegiado (diferente de root). El truco al que estamos dando vueltas es que si existe un error de los programadores y algún fichero que el sistema ejecute de forma automática (y lo hará como root) podemos editarlo y meterle alguna instrucción provisional que nos interese. Por ejemplo, si ese rcS nos hubiera servido, hubiera sido útil meterle en la última línea el comando chmod 0777 /etc/inetd.conf (que modifica los permisos sobre dicho fichero), para luego (ya con permisos de lectura/escritura) quitar el comentario (#) de la línea que arranca el telnet. Fijaos que como no tenemos permisos para modificar el inetd.conf lo que intentamos es buscar una falla en el sistema que haga el trabajo por nosotros, pero con privilegio del root que es como casi siempre funciona la máquina linux en sus procesos automáticos de arranque.

Y por ahí vamos. Y como otro forero ha puesto de manifiesto, ni siquiera sabemos si el busybox incluye el programa telnetd o también está capado, lo que complicaría muy mucho el asunto.

Iniciado por odracir

Bien, entonces está lo que hacen en los IAMM, que diría están como vosotros. En este link lo explican:

KGDTeam • Ver Tema - Activar o instalar Telnet en Reproductores Realtek RT1283

En el caso que linko usan FTP, pero ahora mismo tenéis acceso SAMBA (y además decís que con eso el FTP) así que tenéis el mismo caso.

Eso no sirve porque ellos tienen el fichero inetd.conf en /usr/local/etc (donde se permite escribir) y los Gigaset lo tienen en /etc (sistema de archivos de solo lectura).

Según lo veo yo hay 3 posibles salidas:

1) Continuar buscando un ejecutable (binario o script) en un directorio donde se pueda escribir. Y puesto que el rcS de /usr/local/etc no sirve, los siguientes candidatos deberían ser los ficheros que puedan ejecutarse en /tmp o sus subdirectorios. En los firmwares SDK3 de otros reproductores el home del servidor http estaba ahí y creo recordar que también los scripts de Samba y BT.

2) Si no se encuentra un ejecutable válido, la segunda posibilidad pasaría por buscar la forma de des/cifrar el firmware y crear uno nuevo con el telnet (o lo que se quiera) activado. Teniendo acceso al sistema de ficheros completo, quizá se pueda encontrar la clave y/o el certificado necesario.

y 3) Si nada de lo anterior funciona, lo siguiente sería aprovechar alguna vulnerabilidad del software que se ejecuta actualmente en el reproductor.

Lo más útil sería la número 2, pero lo más fácil es la 1, y encima no necesitas ningún software adicional.

Saludos.

¿Alguien ha probado a la "violación" física del aparato? Me explico: sacar el HD y conectarlo al ordenador. ¿Qué parte del sistema de ficheros funciona en memoria y qué parte están en el disco duro? Si todos los ficheros están en el HD, ¿podríamos hacer un chroot y entrar al modo Gentoo?

Iniciado por mapelo

¿Alguien ha probado a la "violación" física del aparato? Me explico: sacar el HD y conectarlo al ordenador. ¿Qué parte del sistema de ficheros funciona en memoria y qué parte están el disco duro?

Creo que basta conectarlo por usb y ver que ahi hay una particion swap, una ntfs, y 190MB del espacio libre (¿para que?)

Iniciado por calimocho

2) Si no se encuentra un ejecutable válido, la segunda posibilidad pasaría por buscar la forma de des/cifrar el firmware y crear uno nuevo con el telnet (o lo que se quiera) activado. Teniendo acceso al sistema de ficheros completo, quizá se pueda encontrar la clave y/o el certificado necesario.

Correcto. De momento me gustan los scripts en /usr/local/etc/ppp . El fichero pppoe.conf tiene un parametro PPPOE_EXTRA="" que seran parametros extra para el ejecutable de ppp donde podriamos meter " & /usr/bin/telnetd &" o algo así. El problema es que este fichero se sobreescribe al configurar pppoe etonces luego voy a ver si existe un servidor pppoe para instalar en un ordenador y si se conecta bien cambair este parametro en pppoe.conf y reiniciar el aparato (para que se ejecute al arranque).

Lo de descifrar el firmware puede ser que sirva este http://rc.vc/files/playon/un-aes_rss.TXT porque con el programito alli Index of /files/playon/ (un-aes_rss.exe) se descifran bien los srcripts (*.rss) de los menus.

Muchas gracias odracir, está todo muy claro, creo que voy a probar lo de los symlinks y ya os comentaré.
Creo que te asombra el uso del rcS en el 795T, pues si, te lo aseguro, yo lo tengo "petao" de cosillas utiles para mi, desde la ejecución de comandos propios en el Dvdplayer (bastante peligroso) hasta la ejecución del demonio del cron, creación de directorios, etc.

Por cierto, y perdonad que se me halla pasado por alto, pero en el directorio /usr/local/etc del 795T, además del rcS, también se ejecuta en el arranque el fichero profile, en el cual tengo también muchas cosas, como 8 alias (pseudocomandos muy largos que uso a menudo) y 6 variables de entorno que también me simplifican las cosas desde telnet. La cuestión es ¿ tenéis los del TW el fichero profile?.

@mapelo

Muchas gracias mapelo a ti también, sobre el busybox, te puedo decir que casi seguro que tiene el telnetd, ya que ese sistema es independiente (no es de Siemens ni de Realtek) y creo que el fichero estará "completo", mira desde telnet la salida de este comando:

Código:

/usr/local/etc # busyboxBusyBox v1.1.3 (2010.04.29-10:11+0000) multi-call binary


Usage: busybox [function] [arguments]...
   or: [function] [arguments]...


        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as!


Currently defined functions:
        [, [[, addgroup, adduser, ash, basename, busybox, cat, chmod, chown, chroot, clear, cp, cut, date, dd, delgroup, deluser, devfsd, df,
        dirname, dmesg, du, e2fsck, echo, egrep, eject, expr, false, fdisk, fgrep, find, free, fsck, fsck.ext2, fsck.ext3, ftpget, ftpput, getopt,
        grep, halt, head, hexdump, hostname, httpd, hwclock, id, ifconfig, inetd, init, insmod, ipcrm, ipcs, kill, killall, klogd, linuxrc,
        ln, logger, login, losetup, ls, lsmod, lzmacat, mkdir, mke2fs, mkfs.ext2, mkfs.ext3, mkfs.extk, mknod, mkswap, mktemp, modprobe, more,
        mount, mv, netstat, nice, passwd, pidof, ping, pivot_root, poweroff, printf, ps, pwd, readlink, reboot, rm, rmdir, rmmod, route, sed,
        sh, sleep, sort, stty, swapoff, swapon, sync, syslogd, tail, tar, tee, telnetd, test, tftp, time, touch, tr, true, tune2fs, udhcpc,
        udhcpd, umount, uname, unlzma, unzip, uptime, usleep, vi, wc, wget, which, yes

Lo que he hecho es ejecutar el propio comando busybox y te enseña todo sus comandos internos entre los que está el demonio de telnet telnetd.
En el T el link a telnetd está en el directorio /usr/sbin, te muestro la salida de ls -l:

Código:

/usr/sbin # lltotal 1008
drwxr-xr-x    2 root     root           561 Mar  7  2011 .
drwxr-xr-x    7 root     root            75 Mar  7  2011 ..
lrwxrwxrwx    1 root     root            17 Mar  7  2011 chroot -> ../../bin/busybox
-rwxr-xr-x    1 root     root         67856 Apr 29  2010 dosfsck
-rwxr-xr-x    1 root     root         14968 Apr 29  2010 flash_eraseall
lrwxrwxrwx    1 root     root            28 Mar  7  2011 httpd -> /usr/local/etc/busybox1.11.2
lrwxrwxrwx    1 root     root            17 Mar  7  2011 inetd -> ../../bin/busybox
-rwxr-xr-x    1 root     root         92604 Apr 29  2010 loader_a
-rwxr-xr-x    1 root     root         34948 Apr 29  2010 mkdosfs
-rwxr-xr-x    1 root     root         61512 Apr 29  2010 mkudffs
-rwxr-xr-x    1 root     root         14952 Apr 29  2010 nandwrite
-rwxr-xr-x    1 root     root        496240 Apr 29  2010 pppd
-rwxr-xr-x    1 root     root         38836 Apr 29  2010 pppoe
-rwxr-xr-x    1 root     root          9046 Apr 29  2010 pppoe-connect
-rwxr-xr-x    1 root     root          8900 Apr 29  2010 pppoe-connect.in
-rwxr-xr-x    1 root     root          1197 Apr 29  2010 pppoe-init
-rwxr-xr-x    1 root     root          1524 Apr 29  2010 pppoe-init-suse
-rwxr-xr-x    1 root     root          1502 Apr 29  2010 pppoe-init-suse.in
-rwxr-xr-x    1 root     root          1151 Apr 29  2010 pppoe-init-turbolinux
-rwxr-xr-x    1 root     root          1129 Apr 29  2010 pppoe-init-turbolinux.in
-rwxr-xr-x    1 root     root          1175 Apr 29  2010 pppoe-init.in
-rwxr-xr-x    1 root     root         34756 Apr 29  2010 pppoe-relay
-rwxr-xr-x    1 root     root         55796 Apr 29  2010 pppoe-server
-rwxr-xr-x    1 root     root          9639 Apr 29  2010 pppoe-setup
-rwxr-xr-x    1 root     root          9619 Apr 29  2010 pppoe-setup.in
-rwxr-xr-x    1 root     root         22296 Apr 29  2010 pppoe-sniff
-rwxr-xr-x    1 root     root          5591 Apr 29  2010 pppoe-start
-rwxr-xr-x    1 root     root          5518 Apr 29  2010 pppoe-start.in
-rwxr-xr-x    1 root     root          2178 Apr 29  2010 pppoe-status
-rwxr-xr-x    1 root     root          2327 Apr 29  2010 pppoe-stop
-rwxr-xr-x    1 root     root          2277 Apr 29  2010 pppoe-stop.in
-rwxr-xr-x    1 root     root          9680 Apr 29  2010 realbox
lrwxrwxrwx    1 root     root             7 Mar  7  2011 realfsck.dos -> realbox
lrwxrwxrwx    1 root     root             7 Mar  7  2011 realmkfs.dos -> realbox
lrwxrwxrwx    1 root     root            17 Mar  7  2011 telnetd -> ../../bin/busybox
lrwxrwxrwx    1 root     root            17 Mar  7  2011 udhcpd -> ../../bin/busybox

Como puedes ver la penúltima línea es el link de telnetd al fichero busybox

Espero que sirva para algo

Saludos

Parece que esta es la clave AES usada para descifrar ficheros del firmware en HD795TW: AD1406BEF0D27AFFE80013AB5E9C99AD Esta en /sys/realtek_boards/AES_IMG_KEY y se puede descargarla por ftp (pos samba no va).

EDIT: En teoría según esto http://forums.seagate.com/t5/FreeAge...ight/true#M833 podemos quitar secureboot y todos marssha1_rsa_hashValue de configuration.xml para meter imagenes modificadas (squashfs1) pero tengo miedo En windows se puede usar esto http://www.mediafire.com/?5ywo7wceeazaonl para desencriptar los ficheros *.aes (cambiando la clave AES en los bats).

Hola, me respondo a mi mismo con el tema de los symlinks.

Este tema viene de hace bastante tiempo (Satai en Oct 2010, como ha buscado odracir), pero a mi todas las pruebas me han resultado en errores de distinto tipo, pero los intentos que he hecho ahora tampoco me han funcionado y buscando en Google he encontrado que los links simbólicos (ln -s) no se pueden realizar en sistemas de ficheros tipo FAT, sólo en sistemas ext2 y ext3 (o sea tipo linux), yo necesito un link a /usr por ejemplo que es NTFS pero no lo consigo.

Los links que si le funcionaban a Satai eran sobre /tmp/hdd/root que es de tipo ext

¿Alguna idea?

Saludos

Iniciado por Carva

yo necesito un link a /usr por ejemplo que es NTFS pero no lo consigo.

Los links que si le funcionaban a Satai eran sobre /tmp/hdd/root que es de tipo ext

¿Alguna idea?

Me temo que /usr no "es NTFS" sino que está en la flash en squashfs. ¿Qué es lo que intentas hacer exactamente? En /usr no podrás crear un enlace simbólico porque squashfs es un sistema de ficheros que no permite la escritura. En la partición NTFS del disco duro tampoco podrás crear un enlace simbólico. Donde sí que podrás crear enlaces simbólicos es en /usr/local/etc y en la partición root, por ejemplo.

Saludos.

Iniciado por calimocho

Me temo que /usr no "es NTFS" sino que está en la flash en squashfs. ¿Qué es lo que intentas hacer exactamente? En /usr no podrás crear un enlace simbólico porque squashfs es un sistema de ficheros que no permite la escritura. En la partición NTFS del disco duro tampoco podrás crear un enlace simbólico. Donde sí que podrás crear enlaces simbólicos es en /usr/local/etc y en la partición root, por ejemplo.

Saludos.

Hola calimocho, gracias por responder.

Lo que quiero hacer es poder "ver" desde Windows la estructura de /usr/local/etc para poder acceder directamente a dos ficheros muy importantes:
* /usr/local/etc/dvdplayer/dtv_channel.txt
* /usr/local/etc/dvdplayer/schedule_record.db
Que son el fichero de canales para poder ordenarlo, hacer copia de seguridad, etc. y el fichero de la base de datos de la programación, que es el que usa mi programa RecTimerMgr para realizar las programaciones desde un ordenador con Windows.

Hasta ahora lo que hago, a mano o automáticamente desde el programa, es abrir una sesión de telnet, copiar los ficheros a un sitio "visible" desde Windows (yo uso: /tmp/hdd/volumes/HDD1/BT), manipular ahí los ficheros y mediante otra (o la misma) sesión de telnet devolver los ficheros a su "sitio" correcto.

Si pudiese tener esos ficheros "a mano" desde Windows me ahorraría todo el trasiego y las entradas de telnet; así la gente del TW podría usar mi programa RecTimerMgr sin necesidad de tener telnet.

Saludos

Iniciado por Carva

Hola calimocho, gracias por responder.

Lo que quiero hacer es poder "ver" desde Windows la estructura de /usr/local/etc para poder acceder directamente a dos ficheros muy importantes:
* /usr/local/etc/dvdplayer/dtv_channel.txt
* /usr/local/etc/dvdplayer/schedule_record.db
Que son el fichero de canales para poder ordenarlo, hacer copia de seguridad, etc. y el fichero de la base de datos de la programación, que es el que usa mi programa RecTimerMgr para realizar las programaciones desde un ordenador con Windows.

Hasta ahora lo que hago, a mano o automáticamente desde el programa, es abrir una sesión de telnet, copiar los ficheros a un sitio "visible" desde Windows (yo uso: /tmp/hdd/volumes/HDD1/BT), manipular ahí los ficheros y mediante otra (o la misma) sesión de telnet devolver los ficheros a su "sitio" correcto.

Si pudiese tener esos ficheros "a mano" desde Windows me ahorraría todo el trasiego y las entradas de telnet; así la gente del TW podría usar mi programa RecTimerMgr sin necesidad de tener telnet.

Saludos

En tu caso la cosa es bastante sencilla. En el caso de los que tengan TW (entiendo que es la versión que tiene el firmware cifrado) seguramente no lo será tanto (no lo puedo afirmar ya que no he visto el contenido del mismo).

Prueba a editar el fichero /usr/local/etc/package/samba/lib/smb_anonymous_head.conf y añade las siguientes líneas:

[DVDPLAYER]
path=/usr/local/etc/dvdplayer
hide dot files=yes
hide files=/.*/lost+found/
guest ok=yes
writable=yes
force create mode=0775
force directory mode=0775

Primero cambia permisos y demás opciones si así lo crees necesario. Esto se copió de las opciones que usa el firmware de un Woxter 3200 para compartir los discos/pendrives por Samba. Y lo metemos en smb_anonymous_head.conf porque ese fichero se copia sin modificar, así que una vez modificado, cuando se reinicie Samba tendrás acceso a la carpeta /usr/local/etc/dvdplayer y a todos sus ficheros.

Si en los firmwares TW tienen ese fichero en la misma partición (/usr/local/etc) también se podrán aprovechar de este "truco". En caso de que dicho fichero esté en un sistema de ficheros squashfs, deberían modificar el firmware e incluir el fichero modificado en el nuevo firmware. Incluso en el caso de que el fichero esté en le mismo sitio que en los otros firmwares, deberán comprobar que se está haciendo uso de él; no vaya a ser que ocurra como con el rcS que seguía ahí pero se estaba usando la copia de /etc.

Saludos.

Iniciado por calimocho

En tu caso la cosa es bastante sencilla. En el caso de los que tengan TW (entiendo que es la versión que tiene el firmware cifrado) seguramente no lo será tanto (no lo puedo afirmar ya que no he visto el contenido del mismo).

Prueba a editar el fichero /usr/local/etc/package/samba/lib/smb_anonymous_head.conf y añade las siguientes líneas:

[DVDPLAYER]
path=/usr/local/etc/dvdplayer
hide dot files=yes
hide files=/.*/lost+found/
guest ok=yes
writable=yes
force create mode=0775
force directory mode=0775

Primero cambia permisos y demás opciones si así lo crees necesario. Esto se copió de las opciones que usa el firmware de un Woxter 3200 para compartir los discos/pendrives por Samba. Y lo metemos en smb_anonymous_head.conf porque ese fichero se copia sin modificar, así que una vez modificado, cuando se reinicie Samba tendrás acceso a la carpeta /usr/local/etc/dvdplayer y a todos sus ficheros.

Si en los firmwares TW tienen ese fichero en la misma partición (/usr/local/etc) también se podrán aprovechar de este "truco". En caso de que dicho fichero esté en un sistema de ficheros squashfs, deberían modificar el firmware e incluir el fichero modificado en el nuevo firmware. Incluso en el caso de que el fichero esté en le mismo sitio que en los otros firmwares, deberán comprobar que se está haciendo uso de él; no vaya a ser que ocurra como con el rcS que seguía ahí pero se estaba usando la copia de /etc.

Saludos.

Muchas gracias calimocho.

Funciona!!

Ya le tenía echado el ojo a esa carpeta que me comentas, pero no sabía sobre que fichero actuar, porque están todos estos:

Código:

/usr/local/etc/package/samba/lib # ll
total 9
drwxr-xr-x    1 105      65534         2048 Apr 18 15:24 .
drwxr-xr-x    1 105      65534         2048 Mar  7  2011 ..
-rw-r--r--    1 root     root           885 Apr 18 15:24 smb.conf
-rw-r--r--    1 root     root           885 Apr 18 15:24 smb_anonymous.conf
-rw-r--r--    1 105      65534          571 Mar  7  2011 smb_anonymous_head.conf
-rw-r--r--    1 root     root           717 Apr 18 15:24 smb_user.conf
-rw-r--r--    1 105      65534          405 Mar  7  2011 smb_user_head.conf

Y precisamente los ficheros que había descartado eran los que terminan en head, porque me parecían los menos indicados y mira por donde era uno de estos. He visto que los que no terminan en head tienen configurados los accesos a hdd1 y a usb1, pero la verdad es que no se para que se usa cada uno ni en que momento.

El caso es que con tus indicaciones ha funcionado a la primera.

Muchas gracias

Saludos

Iniciado por calimocho

Prueba a editar el fichero /usr/local/etc/package/samba/lib/smb_anonymous_head.conf y añade las siguientes líneas:

[DVDPLAYER]
path=/usr/local/etc/dvdplayer
hide dot files=yes
hide files=/.*/lost+found/
guest ok=yes
writable=yes
force create mode=0775
force directory mode=0775

En el HD795TW también funciona. Comprobado.

Iniciado por denis111

Parece que esta es la clave AES usada para descifrar ficheros del firmware en HD795TW: AD1406BEF0D27AFFE80013AB5E9C99AD Esta en /sys/realtek_boards/AES_IMG_KEY y se puede descargarla por ftp (pos samba no va).

EDIT: En teoría según esto HOWTO: Roll Your Own Firmware - Seagate Community Forums podemos quitar secureboot y todos marssha1_rsa_hashValue de configuration.xml para meter imagenes modificadas (squashfs1) pero tengo miedo En windows se puede usar esto Free Cloud Storage - MediaFire para desencriptar los ficheros *.aes (cambiando la clave AES en los bats).

A mí no me deja ni por samba ni por ftp en el TW leer el lichero con la clave AES que comentas AD1406BEF0D27AFFE80013AB5E9C99AD, por si depende de la versión del firmware que tengas y sea diferente a la mía.

De todas formas, lo he probado descomprimiendo el firmware y dentro de la carpeta package2, intentandolo con una imagen encriptada de squashfs1, desde Linux, con la sentencia de desencriptado:

Código:

openssl aes-128-ecb -d -in ./squashfs1.img.aes -out squashfs1.img -k AD1406BEF0D27AFFE80013AB5E9C99AD

me ha devuelto el error de "bad magic number" que supongo será que la clave no le ha gustado nada de nada.

Iniciado por mapelo

En el HD795TW también funciona. Comprobado.

Bueno mapelo, pues me vas a obligar a hacer una nueva versión de mi programa RecTimerMgr usando esta nueva característica.

También esto significa que tanto en el 795T como en el 795TW se podrán ordenar los canales "con la gorra" , ya que el programa DTVChannelManager podrá acceder DIRECTAMENTE al fichero con esta ruta (para el 795T):
\\Gigaset_hd795t\dvdplayer\dtv_channel.txt

Esto también funciona. Comprobado

Saludos