Reparador de Dumps (TV Chinos no Smart)

[D@rkbytes]

He podido comprobar que aunque el checksum de 4 bytes posterior a la firma o patrón hexadecimal es un buen indicador para evaluar la integridad del dump, y así determinar si es posible su reparación por la limpieza de el bloque de caché, no será un método infalible cuando de comprobar un dump del que se desconoce su funcionamiento se trata, pues se nota que si le cambiamos el Logo de inicio al volcado ya la comprobación no tiene coincidencia con el checksum de 4 bytes.

Así es, cuando el volcado es modificado con otro gráfico, se debería recalcular el checksum y volverlo a escribir.
Esto es fácil de hacer por aplicación en volcados donde se tiene una firma o patrón consistente, como el firmware para el SoC MSD3393LU/LUM.

En los volcados para el SoC TSUMV59/69 también se puede identificar fácilmente el fin del firmware, pero existen variantes que extienden la firma.
El problema con estas variantes es que ya no es fácil determinar el final del firmware, ya que varía entre 2 y 9 bytes de longitud después de 0x00BEEF00.
Es por eso que TV Logo Changer no lo reescribe, ya que lo hace de forma genérica, y porque el checksum global no es comprobado por el sistema.

En resumen: si tienes un volcado que funciona pero tiene un checksum erróneo, reescribe el correcto para futuras comprobaciones.

 

[D@rkbytes]

Actualización v5.27.08.25 (Engineer x86)

.- Se agrega la comprobación de integridad global (merge.bin).
Esta comprobación solo es válida para los firmware del tipo MSD3393LU/LUM y TSUMV59/69
Como la firma de final de firmware para el TSUMV59 es variable, tuve que implementar un algoritmo de reconocimiento.
No obstante, existen algunas variantes que podrían no ser evaluadas adecuadamente y presentar un checksum incorrecto.
Ante esto, se mostrará la posición del posible checksum para poderlo comprobar y realizar el proceso de comprobación manualmente.

.- Se agrega la opción de reescribir el checksum del merge.bin, pero bajo ciertas circunstancias.
1.- Que el bloque de ROM se encuentre en buen estado.
2.- Que se tenga la certeza de que el archivo aunque fue modificado sea funcional.
Esto vendría siendo en el caso de haber cambiado el logotipo o modificado otra cosa que no afecte el funcionamiento.
Nota: El bloque de ROM que corresponde al AP_C.bin es de solo lectura y en este bloque no se encuentran los logotipos.

Comentario extra...
El método que tenía pensado para cambiar el tipo de control remoto, no funcionó.
Por suerte ingresó al taller un TV con placa TP.MS3393.PB855 y pude realizar varias pruebas, pero todas fallaron.

 

[osmelfb5]

Actualización v5.27.08.25 (Engineer x86)

.- Se agrega la comprobación de integridad global (merge.bin).
Esta comprobación solo es válida para los firmware del tipo MSD3393LU/LUM y TSUMV59/69
Como la firma de final de firmware para el TSUMV59 es variable, tuve que implementar un algoritmo de reconocimiento.
No obstante, existen algunas variantes que podrían no ser evaluadas adecuadamente y presentar un checksum incorrecto.
Ante esto, se mostrará la posición del posible checksum para poderlo comprobar y realizar el proceso de comprobación manualmente.

.- Se agrega la opción de reescribir el checksum del merge.bin, pero bajo ciertas circunstancias.
1.- Que el bloque de ROM se encuentre en buen estado.
2.- Que se tenga la certeza de que el archivo aunque fue modificado sea funcional.
Esto vendría siendo en el caso de haber cambiado el logotipo o modificado otra cosa que no afecte el funcionamiento.
Nota: El bloque de ROM que corresponde al AP_C.bin es de solo lectura y en este bloque no se encuentran los logotipos.

Comentario extra...
El método que tenía pensado para cambiar el tipo de control remoto, no funcionó.
Por suerte ingresó al taller un TV con placa TP.MS3393.PB855 y pude realizar varias pruebas, pero todas fallaron.

Qué lastima que no se pudo tener resultados con la modificación de los datos relacionado al cambio del control remoto.
Por lo que veo, es mucho más difícil de lo que pensaba.
Me gustaría saber qué procedimiento usaste, quizás pueda tener alguna idea para el tema de la modificación de los datos relacionados al cambio del control remoto.

 

[D@rkbytes]

En primer instancia, reemplazar AP_C.bin y recalcular los nuevos datos para reescribir el bloque IMG_INFO.
También hice lo mismo con PM.bin, y después hacer uso de algunas rutinas de los repositorios para obtener información sobre las librerías y sus posiciones de inserción, como por ejemplo: getFlashTable2, parseBinIDInfo y doPack, entre otras.
Con esto se obtiene toda la información del merge.bin, incluyendo los identificadores y el tipo de compresión de cada bloque.
Como son scripts de Phyton, se pueden usar en Linux o en Windows, pero yo opté por convertirlos a C Sharp.
Y aunque puedes escribir aplicaciones en Phyton para usar en Windows, esto genera ejecutables de gran tamaño o una gran cantidad de dependencias, algo que nunca me ha gustado, incluso, odio los NuGet, inclinándome por el repositorio y clases propias.
Ya teniendo la información, el resto fue determinar por análisis el bloque a reemplazar.
Para esto, obviamente también se requería un extractor y embeber sus datos como footer para usarlos en la inyección.
Como este proceso hace que cambie el tamaño del binario, se debe hacer un sumario global y reescribir los nuevos valores.

Suena fácil, pero no lo es, son varias comprobaciones y métodos los que se requieren para que el binario resultante tenga una estructura correcta.
Aunque este objetivo se logró, no funcionó, y existe un motivo fundamental...
Durante la compilación, la rutina doPack va escribiendo un footer conforme va insertando y/o comprimiendo los archivos.
Este footer requiere una firma (magic) con la que obtiene un identificador (idx_magic), incrementa un contador y un tail (cola o posición actual), más flags y tipo de compresión.
Así que con cualquier módulo que se llegue a alterar, el resto dejará de funcionar porque las posiciones cambiarán físicamente.
O sea que se tendrían que reescribir los footers de todos los módulos, lo cual es sumamente complicado.

Finalmente puedo decir que, aunque lo que traté de hacer no funcionó, aprendí bastante sobre este tipo de firmware para SPI Flash.