Creador de Imagen Ext4 para modificar Firmware Mstar

[Fogonazo]

هل هناك أداة لفك هذا الضغط؟
أود أن أشكرك
@​

دارك بايتس​

quiero desempacar y empacar

الرجاء استخدام ترجمة جوجل

 

[D@rkbytes]

¿Existe alguna herramienta para descomprimir esto?

Mira el post #615 de TV Debugging Tool

quiero desempacar y empacar

La aplicación mencionada en ese post únicamente desempaca.

 

[gang1991]

Quiero crear un archivo system_sparse con un tamaño en bytes.

 

[D@rkbytes]

Quiero crear un archivo system_sparse con un tamaño en bytes.

Pues adelante, la última versión de la aplicación lo puede hacer.

 

[gang1991]

El paquete de firmware 104gi que les dije antes no se puede cambiar de tamaño. La máquina comprueba el tamaño del paquete de firmware. Si cambia el tamaño del paquete de firmware, la máquina no lo reconocerá.

 

[D@rkbytes]

El paquete de firmware 104gi que les dije antes no se puede cambiar de tamaño.

¿Y dónde está ese firmware para conocer su estructura?

 

[gang1991]

¿Y dónde está ese firmware para conocer su estructura?

No lo sé, solo sé que la máquina verifica el tamaño del paquete de firmware.

 

[D@rkbytes]

¿Cómo que no sabes dónde está el firmware?
¿Entonces qué cosa instalas?
¿De dónde se puede descargar?

 

[gang1991]

¿Cómo que no sabes dónde está el firmware?
¿Entonces qué cosa instalas?
¿De dónde se puede descargar?

Lo he compartido contigo antes.Los paquetes de firmware se pueden editar usando HDX.

Mstar Firmware Unpacker & Repacker

Si descarga el volcado de ems sin restablecer la configuración de fábrica, será de 2,5 GB, si primero inicia el chip en el menú de servicio, la partición se reduce 10 veces. Por tanto su razonamiento no es correcto. Debe haber formato.

www.forosdeelectronica.com

 

[D@rkbytes]

Lo he compartido contigo antes.

Bueno, la verdad es que no me voy a poner a buscar en cuál de los 78 mensajes que tienes por ahora publicaste el firmware.
Sin embargo, dudo mucho que se compruebe el tamaño, tal vez se compruebe un checksum, y si así fuera, en algún lugar del firmware debe estar definido, ya que el procesador necesita instrucciones externas para que las ejecute, y las instrucciones de comprobación deben estar en el bootloader.

 

[gang1991]

Hasta ahora he visto tres máquinas de este tipo, de Changhong TV, dos con chips MediaTek y una con chips HiSilicon.

 

[D@rkbytes]

¿Cuáles son los modelos de esas placas?

 

[gang1991]

¿Cuáles son los modelos de esas placas?

No prestamos atención al modelo de la placa, sólo al chip.

1.01 GB file on MEGA

mega.nz

 

[D@rkbytes]

Yo lo veo como un firmware normal basado en un script, con su cabecera, creación de particiones, carga de archivos con su correspondiente descompresión y finalmente sus variables de entorno y footer, que es donde están los checksums usando CRC-32.

La comprobación por tamaño de archivo es ilógica, y es por estas razones...
1.- No se podrían realizar actualizaciones OTA ni por memoria USB, ya que cada actualización, por lógicas razones tendría un tamaño diferente.
2.- En el supuesto caso de añadir el tamaño del firmware en algún sector, esto comprometería el valor de alguno de los checksums y se obtendría una comprobación incorrecta.
3.- En cada actualización se tendría que realizar la actualización del bootloader que contenga el tamaño que se debe comprobar del firmware.
Lo cual, aparte de ilógico, es sumamente inconveniente y comprometedor.

Para mí el problema es que, tal vez tengas una falta de interpretación sobre los mensajes de error, que desconozco.
Es muy probable que aún no sepas la forma correcta de editar un firmware y compilarlo para que funcione y sea validado adecuadamente.
Pero definitivamente, validar la instalación de un firmware por tamaño, se me hace algo completamente irracional, por eso se validan sus secciones con CRC-32.

 

[gang1991]

Tienes razón, lo entiendo igual, pero después de editar el firmware, no es necesario modificar el crc32, déjalo como está y el flash pasará. Entonces este firmware no tiene nada que ver con crc32.
Es posible que Changhong TV no necesite verificar CRC-32 (la selección del tipo de pie de página NORMAL_FOOTER y XGIMI_STANDARDT son aceptables)

 

[D@rkbytes]

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.

 

[gang1991]

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.

Después de agregar 00 o FF y parpadear, permanezca en la marca micro.
Estoy editando el firmware de HiSilicon. ¿Hay alguna manera de crear uno con el mismo tamaño que el firmware sparse_system original?

 

[D@rkbytes]

¿Hay alguna manera de crear uno con el mismo tamaño que el firmware sparse_system original?

Ese o esos archivos "sparse_system" que en realidad es la partición EXT4 system.img, son finalmente divididos a archivos sparse porque dentro del firmware las imágenes no deben superar los 160 MB.

Cuando el firmware es desempacado, esos archivos sparse se descomprimen y posteriormente se unen para crear la imagen EXT4 original.
Si esa imagen EXT4 se monta y se edita, siempre debe conservar su tamaño original, a menos de que sea redimensionada, cosa que en la mayoría de los casos de edición no es necesario.

Una vez que la imagen se termina de modificar, es cuando se procede a la compilación del firmware, y si en el script está definido que la imagen sea tratada como sparse, se podrá definir el tamaño de cada parte en las opciones de compilación.
Debido al sistema de compresión sparse, cada parte puede resultar en tamaños diferentes o iguales al tamaño establecido, pero nunca mayor.
En el script del firmware se establece el tipo de compresión usado, las direcciones y el tamaño de cada parte, para que la imagen sea escrita en la e-MMC.

Así qué, finalmente, las partes sparse de una imagen EXT4 dividida, tras su descompresión siempre se obtendrá la imagen EXT4 con su tamaño original.

Por lo tanto, esto reitera que, tras la compilación de una actualización, el firmware siempre tendrá un tamaño diferente, motivo por el cual no resulta conveniente una comprobación por tamaño de archivo, pero sí por CRC-32

 

[gang1991]

Entiendo todo lo que dijiste. Este dispositivo fue producido en los últimos años.
Al actualizar su dispositivo, primero verifique el tamaño del paquete de firmware. Si los tamaños coinciden, se vuelve a comprobar el CRC. Si las dimensiones no coinciden, no será reconocido.
¿Hay alguna manera de crear un sparse_system con las mismas dimensiones que el original?

 

[D@rkbytes]

¿Hay alguna manera de crear un sparse_system con las mismas dimensiones que el original?

Eso ya lo expliqué, y con más detalle en el post #38