Banner publicitario de PCBWay
desktop

Creador de Imagen Ext4 para modificar Firmware Mstar

Quiero saber cómo se generan los últimos 8 dígitos (c9f9568b, ed90437f, 7cfbb3b2)?
Cada versión es diferente.
 

Adjuntos

  • IMG_20250213_203700.jpg
    IMG_20250213_203700.jpg
    128.5 KB · Visitas: 5
¿Qué son esos archivos?
En los archivos de actualización de software o firmware, los últimos números son la revisión del programa.
El programador los puede ingresar personalmente, o establecer en el compilador que realice el incremento de forma automática al compilar.
 
El tamaño del firmware empaquetado debe ser el mismo que el tamaño del firmware original; de lo contrario, el dispositivo no será reconocido.
¿Qué te hace suponer que es así? ¿Cuál es el mensaje de error ante eso?

Sin embargo, ya te mostré una posible solución...
Suponiendo, pero lo dudo, que se realice comprobación por tamaño del archivo del firmware, la solución es relativamente fácil.
Tienes 3836 bytes de alineamiento a partir del offset 0x702FB124, incluyendo el footer, que puedes ir eliminando para ajustar el tamaño.
Solo que esto representa que la modificación realizada no puede ser superior a este límite, pero sí inferior, ya que se pueden agregar bytes.
 
Utilicé (Mstar Firmware Unpacker & Repacker) para empaquetar el firmware, luego actualicé la máquina y vinculé la información obtenida mediante la ejecución del código UART.
Esta es la información que se obtiene al actualizar el firmware original.
 

Adjuntos

  • 1.txt
    5.2 KB · Visitas: 6
  • 2.txt
    12.1 KB · Visitas: 5
Última edición por un moderador:
Según el log, toma la longitud del nombre y la muestra...
Current file = upgrade_zlm104gi_v1.00113_dc579922.bin lenght =38
Longitud del nombre del archivo = 38 caracteres.
Luego toma el tamaño del archivo...
file_fat_filesize return = 0x6E96A020
O sea, 1855365152 bytes = 1.72 GiB o 1.85 GB.
Posteriormente muestra...
check file failed: upgrade_zlm104gi_v1.00113_dc579922.bin
Pero haciendo referencia a "file" no a "size", y como archivo se pueden verificar los CRC-32 y también los datos de cabecera.

La validez del segundo archivo es normal, puesto que fue creado correctamente y no sé de qué manera creaste el que no funciona.
Como he mencionado anteriormente, dudo mucho que la comprobación sea por tamaño, pero se puede comprobar fácilmente.
Si mencionas que no se realiza comprobación por CRC-32, entonces modifica un solo byte en cualquier zona de alineamiento del firmware válido.
Si el alineamiento es con 0x00, cambia un byte por 0xFF o viceversa, esto mantendrá el tamaño pero se alterará el checksum.
Entonces, si la verificación es por tamaño, el archivo será validado como correcto, pero si es por CRC-32 obtendrás el error.
Esto mismo lo puedes aplicar en la cabecera, por ejemplo: cambiando el año 2023 por 2025 en "Build TIME :".
 
strImgName is NULL or strImgSize is NULL!
�upgrade_ZLM104Gi_V�U-pkg filename is short!
�ZLM104Gi�upgrade_%s_v�Start Checking USB CH UpgradeFile.

Vi este mensaje (strImgName is NULL or strImgSize is NULL!) en Mboot. Esta información no está disponible en otros firmwares.
 
Última edición:
strImgName y strImgSize son variables del tipo string o cadenas de caracteres que hacen referencia al nombre y al tamaño del archivo de imagen o firmware, pero como cadenas, y aunque strImgSize primeramente pueda ser adquirido de esa forma, se puede convertir a entero si se requiere.
Pero NULL hace referencia a una cadena vacía o con valor nulo, no a una diferencia de valores.
Esta información no está disponible en otros firmwares.
Eso no importa, ya que ese mensaje no muestra diferencia de tamaños, sino la inexistencia de datos en las variables.

La falta de conocimiento sobre el idioma inglés y programación, te está confundiendo bastante.
 
Atrás
Arriba