Cirugía a un PVR

Mi colega el que me puso el mote que da nombre a esta página, el otro día me obsequió con un trabajito de investigación. Su mayor exponente de estar a la vanguardia de la tecnología, un PVR Thomson DTH 8550E se había estropeado y no le permitía acceder al menú del equipo debido a que la placa base del mismo estaba frita (palabras del servicio técnico).

En estos casos el aparato se lleva a la casa a hacer efectiva la garantía, pero mi amigo temía (con razón) por el destino que sufrirían las pelis que tenía guardadas en el disco duro, con vídeos de sus monstruitos haciendo el monstruo en diversos eventos sociales. Bueno el caso es que como en la tienda le iban a dar un aparato nuevo, me lo trajo al sanatorio de dispositivos electrónicos de Makinolo para tratar de extraer la información del disco antes de despedirse de el.

No me pareció en principio una tarea muy complicada. Al abrir el cacharro se observaba perfectamente una unidad grabadora de DVD Philips y un disco duro IDE Seagate ST3160022ACE de 160Gb.

Conecté el disco a uno de mis PCs y la BIOS lo reconoció a la primera. Sin embargo Windows XP, aunque lo detectó como dispositivo nuevo, no fue capaz de añadirlo a la lista de unidades.
Supuse que el problema era que el sistema de ficheros que usaba el disco duro no era el NTFS que usa XP así que metí un Knoppix en el CD y volví a arrancar. Se supone que esta distribución de Linux, autocontenida en un CD, es capaz de detectar y montar unidades de disco de los mas diversos sistemas de ficheros, incluyendo FAT, FAT32, EXT2, EXT3, EFS, NTFS y algunos mas que no se usan muy habitualmente.
El knoppix detectó el disco, pero a la hora de montarlo… no era capaz de determinar el sistema de ficheros. Lancé un fdisk -l para sacar la tabla de particiones del disco, pero me decía que no había tabla de particiones. Buscando alguna solución por Google di con una utilidad para Linux, llamada gpart que se supone capaz de adivinar el particionamiento de un disco duro que por cualquier causa haya perdido la tabla de particiones.
gpart, después de casi una hora de escaneo, no fue capaz de decirme nada en absoluto acerca del disco, así que solo me quedaba acudir a mis amigos de Soygeek, a ver si a alguno se le ocurría de que forma podía leer, de manera no invasiva (es decir, sin escribir nada en el disco, para no dejarlo inservible de cara al PVR), el dichoso disco.

Me indicaron una dirección de internet en la que se hablaba del disco duro de un aparato de la misma marca pero de un modelo anterior, el DTH 7000, donde confirmé que estos aparatos utilizan un formato propietario. Allí encontré el DTH Explorer que lee los discos del DTH 7000, creado por Didier Cadiou (Francés, al igual que la marca Thomson). No podía ser tan fácil. No funcionó. No identificaba el disco como un disco Thomson.
Esta página me llevo a un Grupo de Yahoo en el que se hablaba sobre el DTH 7000 y en el que habia otra utilidad mas espartana que se llamaba DRS 7000 Data Extraction Tool. Tampoco hubo suerte, no era capaz de detectar el disco.

Parecía como si entre las dos versiones del aparato hubiesen cambiado el formato del sistema de ficheros, así que me tocó explorar directamente el disco a nivel físico con la utilidad WinHex para ver si encontraba algo aprovechable.
Después de mirar un montón de bytes que parecían no tener ningún sentido encontré lo siguiente:

uJ e20A-og2 00 7

Parecía claro que era una fecha, el Jueves 20 de Agosto de 2007, pero codificada de alguna manera extraña. Observandolo atentamente se ve que se cogen los caracteres de 2 en 2 y se dan la vuelta, como si estuviese usando Big Endian de 16 bits pero con todos los valores, no solo los numéricos. En efecto, al darle la vuelta a los caracteres me salía:

Jue 02-Ago 2007

Esto podía ser perfectamente una entrada en una tabla de archivos que indicase la fecha de creación de uno de los vídeos del disco. Como había visto otros códigos raros en otras zonas del disco, repetidos muchas veces, pase a descifrarlos:

tSrogaLeba siTynDU F

Parece rumano, pero no, deshaciendo la encriptación rústica que usan:

StorageLabs TinyUDF

¡MAGIA!

Ahora si que Google iba a ser de mucha ayuda, el disco estaba usando el TinyUDF (Universal Disk Format) que es una variante del sistema de ficheros usado para almacenar archivos en medios ópticos como DVDs o CD. En concreto el aparato este usa la librería TinyUDF de StorageLabs.
Al parecer es bastante común que los PVR (aparatos de DVD y TDT) con disco duro usen este sistema de archivos por las ventajas que ofrece. UDF también lo usan las unidades REV removibles de Iomega.

Buscando mas por foros y mas foros, encontré que casi todos los que se habían visto en esta tesitura estaban usando con gran éxito un programa, el SiGMATek_DVBH_1000_HDD_Reader, que permite montar las unidades TinyUDF usadas en los PVR en un Windows XP.
Como cabía esperar, a mi no me funcionó, ni cuando desactivé el soporte para unidades virtuales de CD/DVD (Nero, Alcohol120%, etc…) que parece que entra en colisión con este software.
Busqué mas y llegué al pvr101disk, una especie de driver para windows que se interpone entre el driver de UDF que lleva el propio windows (udfs.sys) y el disco físico y hace el swapping de bytes on-the-fly. Hay que usarlo en modo línea de comandos después de instalarlo de manera rudimentaria.
Pero tampoco funciona y esto ya si que me terminó de cabrear.

Si cualquiera de vosotros ha llegado hasta aqui buscando como montar una unidad de disco de un PVR (DVD o TDT) en un PC, seguro que ya ha encontrado la solución en el anterior párrafo, porque la inmensa mayoría usan TinyUDF con encriptación de byte swapping. Solo los tíos con mala suerte como yo hacen que las historias estas continúen…

La solución desesperada y ya por salvaguardar el honor de geek, como dice Futur3: comprar un disco duro de 160Gb, hacer una copia por sectores con el dd de Linux (tarda 3,3 horas poniendo los discos en buses IDE diferentes), usar un script a nivel físico con el 010Editor para swapear los bytes de todo el contenido y montar el disco como unidad UDF. El script de swap lo he tenido corriendo unas 20 horas y me he hartado, solo había llegado a 17Gb.
Aun así, con el swap a medio hacer, intenté montarlo como unidad UDF pero no había forma de que Windows o Linux la reconocieran.

La conclusión a la que llego es que los de Thomson han creado algún tipo de variación mínima sobre la encriptación básica del swapeo de bytes que usan todos los PVR clónicos (DAK, Airis, Sigmatek, Technosonic, etc…) y que por eso el programa de Sigmatek no vale para este PVR.
Lo único que me queda por hacer es descubrir cual es esa «variación» y reprogramar el pvr101disk.sys para que funcione, pero esa tarea me parece que demanda mucho mas tiempo del que puedo dedicarle a esto.

Lo que ha pasado en realidad, me he dado cuenta después de que mi amigo cambiase en la tienda el Thomson DTH8550E por un Thomson DTH8650E y me lo volviese a traer, es que al jodersele el aparato se corrompió parte de la estructura de archivos del disco UDF, por eso el software de sigmatek no era capaz de reconocerlo. Los datos de vídeo estan en su sitio (encriptados, eso si) pero las tablas de archivos no, por lo que el disco está desestructurado y sacar los vídeos va a ser un trabajo de chinos.

Ahora, sabiendo que los archivos de vídeo son VOB, como los del DVD (MPEG2) y que su firma son sectores que empiezan con la cadena hex 000001BA (en muchos de ellos aparece también la cadena ZORAN01, pero no encuentro referencias en google) , me resta sacar trozos de unos 5Gb del tirón (no me queda mas espacio en el otro disco del PC) y visionarlos con el videolan (es la caña, visualiza lo que sea sin hacer preguntas de formato de fichero ni nada) para ver si encuentro los dichosos vídeos. Luego me tocará recortar con el StreamClip o el VideoReDo (aunque este ultimo se cuelga en cuanto hay un cambio de timecode en el stream, y en mi caso hay muchiiiisimos) y exportarlos con no se aún que herramienta para convertirlos en DVD y haberme ganado con ello la salvación eterna, porque vamos, menudo trabajito.

Así que, como en los programas de al filo de lo imposible en los que no consiguen subir a la cima del monte himalayo de turno, y aun así retransmiten la gesta, pues yo publico este post de fracaso, con un par :).