Reparador de Dumps (TV Chinos no Smart)

[D@rkbytes]

He intentado instalar los complementos que piden en el archivo leeme, estos archivos se instalan teniéndolos previamente copiados, cosa que no está en al archivo fuente, la persona que compartió dicho archivo no incluyo el compilador.

Obviamente, no tiene caso incluir archivos de terceras personas que se pueden conseguir aparte.

Busqué en el gestor de aplicaciones de ubuntu, sin ningún resultado.

Pues no, es como creer que Windows viene con Visual Studio por defecto.

tampoco encontré resultados en la búsqueda en san Google

¿Qué cosa estás buscando?

Esto es lo que se requiere:
Samba
Cygwin
GCC

Lo que yo no entiendo es el motivo de querer realizar la compilación.
Lo único que necesitas es estudiar los códigos fuente y la secuencia de compilación que está en los makefile.
¿De qué te serviría compilar un archivo? Ya vienen varios compilados en la carpeta boot.

 

[osmelfb5]

Obviamente, no tiene caso incluir archivos de terceras personas que se pueden conseguir aparte.

Pues no, es como creer que Windows viene con Visual Studio por defecto.

¿Qué cosa estás buscando?

Esto es lo que se requiere:
Samba
Cygwin
GCC

Lo que yo no entiendo es el motivo de querer realizar la compilación.
Lo único que necesitas es estudiar los códigos fuente y la secuencia de compilación que está en los makefile.
¿De qué te serviría compilar un archivo? Ya vienen varios compilados en la carpeta boot.

samba lo conozco que es para compartir recursos de red con windows, Cygwin en una ocasión lo instale como intermediario entre linux y windows, junto a tras utilidades para descomprimir firmware hace un tiempo pero yo no tuve resultados esperados, con la descompresión, lo de el nombre de los archivos makefile no lo sabia, por eso necesito, info por que son varios archivos, que cuyo funcionamiento no conozco, partiendo de lo que me dices del archivo makefile, samba cywin, en caso de samba por mi interpretación y conociendo el uso de samba, en el entorno de visualización colinux si reria necesario, por que tendria que montar una unidad de red para que entre windows y linux se pueda interactuar o compartir recursos de red, esa seria la interpretación que tengo, mi pregunta esta como se puede abrir el archivo makefile, o este archivo hay que descomprimir con Cygwin.
La otra cosa,esta en que vi varios archivos con el nombre IR entre en algunos y ni la configuración como nombres de funciones direcciones, hexadecimal, con sus protocolos usados por ejemplo NEC, que es el protocolo más usado.
Para mi criterio, puede ser que me equivoque, Samba Cygwin desde una sección real de linux no sea necesario, en caso de windows si por la diferencia que tienen en sus tipos unos entre otro , cosa quedaría de la forma siguiente samba se usaría para montar una unidad de red, con la ruta seleccionada que seria unidad z:\shareware\aeon\current-stable-20081007
según la traducción:
Instalar la cadena de herramientas en Cygwin]

1. Busca tu unidad z (o \\mstarfs01\share)
2. z:\shareware\aeon\current-stable-20081007
Obtén el archivo aeon-20081007-cygwin.tar.bz2
3. Abre la consola de Cygwin
4. Haz clic en el directorio "aeon-20081007-cygwin.tar.bz2"
5. mkdir /opt este comando crea la carpeta opt
6. tar jxvf aeon-20081007-cygwin.tar.bz2 -C /opt
7. Edita /etc/profile.d/chakra.sh
export PATH=$PATH:/opt/aeon/bin
export PATH_CHAKRA=<la ruta a tu directorio chakra>
8. Cierra la consola y ejecútala de nuevo
Encontré este enlace: GitHub - mattyait/cygwin_windows: Setting up Linux environment by using cygwin on windows

 

[D@rkbytes]

Como no respondiste mis preguntas y porque veo que insistes en querer realizar una compilación compleja, lo mejor es que consultes con un programador en entorno Linux.
Yo he obtenido mucha información sin compilar ningún archivo, solo estudiando los códigos fuente, y lo que me interesa lo paso a C#.

 

[osmelfb5]

Como no respondiste mis preguntas y porque veo que insistes en querer realizar una compilación compleja, lo mejor es que consultes con un programador en entorno Linux.
Yo he obtenido mucha información sin compilar ningún archivo, solo estudiando los códigos fuente, y lo que me interesa lo paso a C#.

ok, revise como tres archivos makefile en especial revise \TSUMV69_M12\boot\sboot , revisado algunos archivos que tienen que ver con los datos del control remoto, realmente tengo muy poca experiencia, programando en c++, de todas formas voy seguir indagando, ahora no se que tipos de datos se escogen, o serian direcciones hex para luego implementar en el software para que las busque, no se si a partir de alguna información encontrada, se le pueda implementar al software reparador de firmware o hacer otro para ese fin, en dependencia de lo posible.

 

[D@rkbytes]

Es que no es tan fácil comprender el proceso y tampoco es así como piensas.
El proceso de compilación es complejo porque se usan varios archivos, algunos van encriptados con AES y comprimidos con diferentes formatos,
Cada bloque lleva un magic_id, una firma o indicador de compresión y un checksum.
En los makefile se elabora un proyecto de unión de los archivos y cómo procesarlos (merge).
También se indican los offsets, los tamaños y los chunks o paddings.
No todos los códigos están en C++, también existen varios scripts en Phyton, bash y archivos .elf para la ejecución en Linux.
Te puedes encontrar con problemas de compatibilidad entre sistemas de 16 bits con algunos .exe si corres Cygwin x64.

Para agregar funciones al reparador se necesitan bases concretas y que funcionen.
No tiene caso que agregue cosas solo para ir probando y mucho menos ahora que no dispongo de ese tipo de TVs porque acá ya casi no hay.

Puedes estudiar C++ o C# (C Sharp), o ambos y crear tus propias aplicaciones de prueba.
Algo así como esto, que es con lo que hice algunas pruebas...

En Visual Studio puedes usar C++/CLI y C# si unes los proyectos, que es lo que comúnmente hago.

Programar no es fácil y lleva tiempo aprender, pero después podrás comprender los códigos fuente.
Yo no domino mucho el C++, aunque lo entiendo, al igual que Phyton, pero C# es más amigable.
Tanto el C++ como el C# parten del C, que son extensiones pero orientadas a objetos, así que es más conveniente que empieces por ahí.

Finalmente, si crees que algo es importante para ti, pues debes aprenderlo.

 

[osmelfb5]

Por lo que veo, hay mucho camino por andar, quizás algún día se pueda hacer unas cosas, por lo menos aquí los tvs no Smart siguen entrando al país y otros pocos Smart si están llegando, solo me queda seguir buscado y estudiando, gracias por la información compartida.
Me gustaría saber si es recomendado programar con QT

 

[D@rkbytes]

Estudia el repositorio MStar Chakra3, tal vez te sea más fácil de entender.
Ese proyecto contiene información relevante sobre el firmware para SPI Flash.

Me gustaría saber si es recomendado programar con QT

No, la verdad no lo recomiendo.

 

[D@rkbytes]

Actualización v3.30.7.25 (Engineer)

Se agrega un reparador del bloque ROM (AP_C "Compressed Application Processor"), que es el que corresponde al firmware, kernel y otras partes críticas.
Este bloque está protegido por checksum, un daño en este bloque puede causar estancamiento en el inicio o TV inoperante.
El proceso de reparación se basa en encontrar el bit corrupto por fuerza bruta, tomando como referencia el checksum sembrado.
Dependiendo del offset en donde se encuentre la corrupción, será lo que tarde el proceso, y pueden ser varias horas.
Por experiencia con este tipo de volcados, regularmente solo es un bit el que se altera, si son más, el archivo no podrá ser reparado.
Es inviable crear una rutina que procese al menos dos bits, ya que serían billones de comparaciones, y tardaría días, aún con multi thread.

Esta es la información que se muestra cuando el bloque de ROM (AP_C) se encuentra dañado...


Aquí cuando el bloque ha sido reparado...


El proceso es mostrado mediante una barra de progreso y una etiqueta para el tiempo restante.
Durante la primer etapa de escaneo, el tiempo restante puede ser algo inestable, pero se irá corrigiendo posteriormente.
Como esto puede tardar varias horas, pueden dejar la PC/Laptop en proceso durante la noche y verificar por la mañana.
Si quieren realizar una prueba rápida, modifiquen un solo bit de un volcado MStar después del offset 0x20080, por ejemplo, en el offset 0x2018F.
El análisis se realiza en segundo plano, así que no debe afectar el desempeño del PC, y se puede cancelar en cualquier momento.
No se preocupen si notan que no hay avance en la barra de progreso, ya que dependiendo la posición del bit corrupto, podrá mostrar avance tras varios minutos.
En cuanto la verificación del checksum sea correcta, se realizará la reparación del archivo, creando una copia consecutiva si encuentra una previa.
Si la reparación tuvo éxito, será notificado en el log y también auditivamente.

Recuerden copiar su archivo patterns.xml para que sigan conservando sus patrones o firmas de reparación con cada actualización.

 

[bubulub]

Actualización v1.9

.- Se agrega soporte para tres tipos de volcados en la placa "EL.V53-FA48".
.- Se aplica un algoritmo para encontrar el nombre original del firmware.
Esta nueva característica es muy importante para el caso de extraer únicamente el firmware, ya que ahora se puede estar seguro de usar un nombre correcto para la instalación por USB.
No en todos los volcados pude obtener el nombre del firmware, pero sigo estudiando más algoritmos para tratar de encontrarlos.

TE comparto un dato para encontrar el nombre del firmware ya que he probado varios volcados basados en el Soc 3393 y no ha fucionado, pero si busco con el editor HXD la palabra: "eden" (sin comillas) me da el nombre del firmware, quizas lo puedas implementar en tu programa

 

[D@rkbytes]

El algoritmo que uso se basa en buscar los bloques LZMA, descomprimirlos y buscar el nombre por medio de un patrón definido.
Los firmware MStar contienen varias palabras clave para identificar bloques, si se busca "eden" se pueden encontrar varias referencias, ya que es una de las plataformas MStar, así como "marlon", "maya", "melody", "milan", "nasa", whisky", etc.

Como mencioné, no en todos los volcados se puede encontrar un nombre, pero cuando se encuentra se muestra de esta forma:

Ese nombre no se puede encontrar con un editor hexadecimal, y puede ser cualquier otro, porque vienen con diferentes nombres.

 

[D@rkbytes]

Actualización v4.11.08.25 (Engineer x86)

1.- Se agrega la descompresión del bloque AP_C para su análisis con el visor de cadenas.

El tipo de compresor se detecta automáticamente, pero está basado en el tipo de sistema operativo.
El más común es AEON, y se puede seleccionar la arquitectura ARM o MIPS como OS Type, dependiendo de la compilación del firmware.
El tamaño del bloque también es calculado automáticamente.

2.- Se agrega compresión y descompresión MSCOMPRESS, MSCOMPRESS7 y LZSS (Algoritmo MStar).

Con esta opción pueden comprimir o descomprimir bloques o archivos para su análisis.
Por ahora la única compresión/descompresión que se puede cancelar es LZSS.

3.- Se agrega comprobación de checksums CRC-16 y CRC-32 con los polinomios usados por MStar.

Esta opción sirve para comprobar los checksums de archivos o bloques.
Si seleccionan "Calculate by Block" deben establecer la posición de inicio y la de final del bloque en el archivo a analizar.
Si no se selecciona se calculará todo el contenido del archivo.
Los CRCs de MStar no son estándar, se usa un polinomio diferente y otras características extra.

Espero que estos nuevos métodos les sean de utilidad para seguir analizando los volcados MStar en SPI Flash.

 

[D@rkbytes]

Método sencillo de comprobación de un volcado tipo MSD3393

Primero les explicaré las características sobre este tipo de firmware ya compilado.
Básicamente se compone por dos bloques principales.
El primer bloque es el AP_C (Compressed Application Processor).
El segundo bloque es el MERGE, o sea, todo el contenido del volcado, (Bootloader, PM, AP_C, Módulos e Información de Fuente).
El bloque de caché no está contemplado durante la compilación, pero sí es usado como almacenamiento externo.
Viene siendo el espacio restante de la memoria SPI Flash tras la instalación del firmware.

La firma o magic_merge de final de firmware es '0D0A000000001BDE' y posterior a la firma se encuentra el checksum global (4 bytes).
Este checksum es el que debemos comprobar para verificar la integridad del volcado.


Procedimiento de comprobación:

Usaremos el editor hexadecimal H x D (Nota: separo el nombre porque se genera un emoji).
Abrir el archivo a analizar y buscar el magic_merge como valor hexadecimal (Control + F).



Si el volcado es válido, se debe encontrar la firma justamente después del archivo de información de la fuente tipográfica del firmware...


Este es el final del firmware o MERGE, lo enmarcado en rojo es la firma (magic_merge) y lo enmarcado en amarillo es el checksum.

Ahora debemos colocar el cursor en el primer byte del checksum (en este caso sobre 7D) para obtener el desplazamiento.
Ya que tengamos el cursor en el primer byte del checksum, presionamos las teclas Alt + Insert o presionar el botón derecho del ratón y seleccionar 'Copiar desplazamiento'.


Ahora ejecutamos la aplicación Dump Repair (Engineer) y nos dirigimos a la pestaña 'MStar CRCs'.
Abrimos el archivo, seleccionamos 'MStar CRC-32', 'Calculate by Block' y establecemos el offset de inicio y el de final del bloque, que viene siendo el desplazamiento copiado.
En este caso sería así:


Al presionar 'Calculate' debemos obtener el mismo checksum que el que se insertó cuando el firmware fue compilado.
Si no obtenemos el mismo checksum, obviamente será porque el volcado está dañado y no servirá de nada limpiar el bloque de caché.
El checksum para el firmware compilado, ahora MERGE.BIN, se inserta como Big-Endian, por eso lo veremos tal cual como el calculado y no invertido, que sería en Little-Endian, como en el caso del bloque AP_C.BIN, pero el checksum del AP_C es insertado en otra parte y no al final de este.

Por si se preguntan: ¿Cómo es que sabe todo esto? La respuesta es: Estudiando los repositorios que les he compartido.
Esta comprobación es más determinante que la del bloque AP_C, puesto que se comprueba completamente la integridad del firmware.
Con esta sencilla verificación podrán determinar si el problema se debe a firmware corrupto o daño en placa.

Este método lo pienso integrar próximamente para automatizar el proceso, pero les quise compartir esta información antes para que tengan un poco más de conocimiento sobre este tipo de archivos.