Actualización v1.4
Muchas mejoras y agregados.
Ahora escrito en C#, lo cual hace que las funciones sean más rápidas.
Quiero hacer notar qué, aunque esta nueva versión ha sido probada, puede contener errores.
La mayoría han sido depurados, pero esto no representa que el archivo obtenido sea válido.
Esto es porqué, tanto las cabeceras y los offsets de la zona de caché pueden ser distintas en cada SoC.
Esto hace que la aplicación pueda confundir un offset de cierta zona como válido, cuando en verdad no lo es.
Como ejemplo: expongo lo que llamo (MagicBytes), esto hace referencia a ciertos bytes que se deben encontrar para determinar la zona de caché.
Supongamos que la zona de cache tiene los bytes 0x00, 0xBE, 0xEF, 0x00, que son los clásicos para MStar, estos bytes no deben ser buscados desde el principio del archivo, sino desde el final.
¿Por qué? Porque si buscamos estos bytes desde el principio podemos encontrar varias coincidencias.
En cambio, si estos bytes se buscan desde el final del archivo, el resultado es más certero.
Pero esto no garantiza haber encontrado un offset correcto, ya que aunque el proceso se haga a la inversa, también origina encontrar un offset que no sea el correcto.
Esto ha sido solventado buscando firmas gráficas dentro del sector y avisar al usuario que posiblemente no sea el offset correcto y poder abortar la operación para seleccionar otra opción.
Puedo considerar que este proyecto apenas anda en pañales y lo pienso seguir mejorando.
Gracias al haber portado el programa de VB a C#, pienso que muchas cosas se van a mejorar.
Dentro de este mismo tema iré subiendo sus actualizaciones.
También espero poder agregar la reparación de otro tipo de volcados.
Sobre esto ya realicé algunas pruebas y han sido satisfactorias.
De igual forma agradeceré si tienen un volcado de un TV con problemas y que lo adjunten, especificando modelo de tarjeta, tipo de memoria SPI Flash, etc.
Lo analizaré, y si es reparable, lo agregaré a la lista.
Esto es con el fin de agregar nuevos tipos de reparación de volcados al programa.
Aprovecho para comentar que de ahora en adelante mis programas estarán en inglés.
Y es que he recibido bastantes correos pidiendo esto.
Para mí no es ningún problema, siempre y cuando se trate de un programa reciente.
Pero si ya cuenta con varias versiones, pues sí que me resultará complicado cambiar cientos de cadenas en español al inglés.
Espero que comprendan que este Foro supera nuestras fronteras latinas y que hay muchas personas a las que les es más fácil comprender el idioma inglés.
A fin de cuentas, para los ingenieros en electrónica es un lenguaje requerido.
Funciones extra agregadas:
getCRC32:
Obtiene el checksum de un archivo basado en la comprobación de redundancia cíclica de 32 bits de una serie de bytes.
Sirve para comprobar la diferencia entre archivos y así mismo agregar una comprobación de integridad.
En esta versión ya no se inyecta el CRC32 en el nuevo archivo porque resultó ser incomprobable.
Solo se deja para comprobar la diferencia entre archivos.
Align File to 0xFF:
Alinea un archivo que esté fuera del rango numérico basado en bytes justos.
Es decir, un archivo convencional de 1 KB deberá ser de 1024 bytes.
Un archivo de 1 MB deberá ser de 1048576 bytes, etc.
Comprobado el offset final, el archivo será rellenado con 0xFF hasta completar lo seleccionado.
Esto es útil en los volcados MStar y tal vez en otros para establecer si el archivo es firmware o copia.
Si les interesa el tema podré seguir avanzando con el proyecto.
Espero que sí y que puedan aportar con nuevos bytes de la zona de caché en volcados.
¿Cómo encontrar la zona de caché?
Es fácil, este sector siempre se encuentra después de la zona de datos.
O sea, casi al final del volcado.
Ya sea en memorias de 2MB, 4MB, 8MB, etc, la zona de caché podrá ser encontrada porque deberá contener más de 512 KB con 0xFF
Así que, podemos considerar que desde donde empecemos a encontrar 0xFF en un rango de 512 KB, será la zona de caché.
Y esos bytes anteriores a 0xFF son los que mencioné anteriormente como MagicBytes.
Y para validar estos MagicBytes, debemos tener otros archivos para poder comparar y validarlos, ya que deben existir y después de ellos encontrar 0xFF
Ante esto, pongo un ejemplo:
En la imagen de arriba se pueden ver los MagicBytes de un clásico volcado MStar (00BEEF00) y lo que sigue es la zona de caché.
Es donde el procesador escribe y lee datos.
Las fallas principales se deben a una mala escritura debido a cortes eléctricos y es cuando se pueden alterar sectores en esta zona que posteriormente harán que el TV no inicie.
Esta es la zona que se repara, ya sea eliminándola o reescribiéndola con 0xFF.
Cuando se elimina supondrá para el TV que se trata de un firmware nuevo y mostrará la pantalla de configuración.
De igual forma si se reescribe con 0xFF, pero el archivo obtenido tendrá el mismo tamaño.
Y aquí es donde entra el alineamiento, que básicamente lo que hace es dejar el archivo reparado pero alineado hasta completar los bytes faltantes.
Ejemplo de un archivo no alineado:
Ejemplo del mismo archivo pero alineado:
Aquí la alineación fue de 4 bytes, y esto lo hace la aplicación de forma automática.
Aunque pienso poner esta opción como opcional.
Este tema tiene por finalidad evitar la compra de archivos que ustedes mismos pueden reparar.
Actualización v1.6
.- Se mejoró la comprobación de gráficos dentro de la zona de caché para realizar una mejor selección del tipo de reparación.
Esto es porque algunos volcados pueden contener más de un archivo gráfico y puede ser eliminado si no se elije la opción correcta.
El programa avisará cuando esto suceda y dará la opción de continuar con la reparación sin importar este caso, o elegir otra opción.
Debido a esta circunstancia se añadió otro tipo de reparación. (Número 5)
.- Se corrigieron otros bugs menores que finalmente hacen que el programa sea más estable.
