Seria posible modificar voces en los mapas?

[JesusD]

Bueno, pensando un poco, creo que solamente es posible calcular los SIZE_* metiendo los archivos en un pen o en una MV con una partición a parte de la del sistema, e ir cambiando el formato de la partición.

Tiene muchos archivos que ocupan menos de 1Kb que es el tamaño del cluster en en SIZE_1 y por lo tanto, van a ocupar 1 Kb aunque su tamaño sea menor y así sucesivamente con el resto de unidades de asignación. Por lo que creo que el calculo es imposible, o muy engorroso.

Tambien pensé en modificar solamente el SIZE_* con el que tenemos formateado el pen en el que vamos a meter el Firm, pero en el pen tenemos el archivo comprimido, creo que los valores SIZE_* son para cuando lo descomprime, que imagino que es en la memoria interna del SMEG, y esta no sabemos en que formato está. Por lo que creo conveniente calculalos todos.

[yesansa]

Hola @JesusD

He estado probando lo que decias de probar con varios valores de unidad de asignacion. Al principio siempre me salia el mismo valor que correspondia con el size_1 = 10.923.008

He tenido que darle formato lento para que me cambiara los valores de acuerdo al nuevo valor de unidad de asignacion. Y al copiar la carpeta sd_dir descomprimida los valoes size_X coinciden. Asi que yo creo que ya estoy listo para intentar instalarlo en el coche.

 

He estado mirando tambien el archivo sd_dir.bin en firmwares anteriores y en los firmwares 5.4br8 y 5.41br4 ocupa 5471KB

Y en los Firmwares 5.42br4, 5.42cr2 y 5.43ar2 ocupa 3916KB

Luego ya descomprimdo el tamano de la carpeta sd_dir es practicamente siempre el mismo, (unos 10.1MB).siempre con diferencias de bytes que estan reflejados en el valor size. Hasta aqui todo mas o menos normal, lo que me ha llamado la atencion han sido los valores size_x en los archivos sd_dir.bin.inf por que son siempre los mismos a pesar de la diferencia en el valor size (que es el valor del tamano de la carpeta sd_dir descomprimido)

ejemplo del archivo sd_dir.bin.inf del firmware 5.41br4

CRC32: -48456501
SIZE: 10638022
SIZE_1: 10923008
SIZE_2: 11333632
SIZE_4: 12124160
SIZE_8: 13762560
SIZE_16: 17121280
SIZE_32: 23986176

 

Firmware 5.42cr2

CRC32: 1380278674
SIZE: 10638004
SIZE_1: 10923008
SIZE_2: 11333632
SIZE_4: 12124160
SIZE_8: 13762560
SIZE_16: 17121280
SIZE_32: 23986176

 

PD. No se donde esta el sonido de aviso de radares, he encontrado uno que creo que es pero no estoy seguro, si alguien me dijera donde se  encuentra este archivo se podria intentar tambien cambiarlo 

 

PD2. @JesusD Ya puestos se podria tambien intentar actualizar el archivo con el logo de las emisoras de radio para que aparezcan en la pantalla pero tampoco estoy seguro de cual es el archivo en concreto que hay que cambiar

[JesusD]

 

 

Hola @yesansa respecto a esto:
 

Cita

 

He estado mirando tambien el archivo sd_dir.bin en firmwares anteriores y en los firmwares 5.4br8 y 5.41br4 ocupa 5471KB

Y en los Firmwares 5.42br4, 5.42cr2 y 5.43ar2 ocupa 3916KB

Luego ya descomprimdo el tamano de la carpeta sd_dir es practicamente siempre el mismo, (unos 10.1MB).siempre con diferencias de bytes que estan reflejados en el valor size. Hasta aqui todo mas o menos normal, lo que me ha llamado la atencion han sido los valores size_x en los archivos sd_dir.bin.inf por que son siempre los mismos a pesar de la diferencia en el valor size (que es el valor del tamano de la carpeta sd_dir descomprimido)

ejemplo del archivo sd_dir.bin.inf del firmware 5.41br4

 

 

seguro que es por que los archivos que cambian son pequeños y dada la unidad de asignación en el formato de la unidad ocupan la misma unidad de asignación, a si que los valores SIZE_X son los mismos o muy parecidos.

 

 

Respecto a:

Cita

 Ya puestos se podria tambien intentar actualizar el archivo con el logo de las emisoras de radio para que aparezcan en la pantalla pero tampoco estoy seguro de cual es el archivo en concreto que hay que cambiar

 

El archivo se llama RadioLogo.sqlite y se encuentra en:

SMEG_PLUS_UPG\AUDIO_BT\system.bin\system\Data_base\sqlite\

SMEG_PLUS_UPG\AUDIO_BT_256\system.bin\system\Data_base\sqlite\

SMEG_PLUS_UPG\NAV\system.bin\system\Data_base\sqlite\

no se porque aparece en 3 ubicaciones distintas pero lo suyo sería cambiar las 3.

el archivo es este:

RadioLogo.sqlite

 

Respecto al archivo de aviso de radares, no he conseguido encontrarlo, pero sería la leche poder cambiarlo.

 

[yesansa]

Hola @JesusD

He estado hechando un vistazo a lo de radiologo.sqlite

Un conocido tiene un peugeot 2008 de los de la ultima revision (el coche es JZV, asi que creo que es del verano 2017) asi que supongo que su navegador es un smeg+ iv2 y a el se le ven los logos de las emisoras, no se si todas pero cuando me estuvo esnsenando el coche si que me fije y se veia el logo en la pantalla. 

Asi que me he descargado el ultimo firmware del navegardor smeg+ iv2 y he comparado el archivo radiologo.sqlite con ultracompare de los dos firmwares (smeg+ y smeg+ iv2) y ambos archivos son exactamente iguales.

Entonces, por que a el se le ven los logos y a mi no? (yo tambien tengo un 2008, pero la version smeg+) A mi me hace pensar que debe de ser algo mas lo del tema de los logos. tiene que haber algo mas en el firmware para cargar esos logos y no el archivo radiologo.sqlite

[admin]

No os olvidéis de votar, que este mes es más corto y las votaciones están igualadas.

[JesusD]

El 22/2/2018 a las 21:36, yesansa dijo:

Hola @JesusD

He estado hechando un vistazo a lo de radiologo.sqlite

Un conocido tiene un peugeot 2008 de los de la ultima revision (el coche es JZV, asi que creo que es del verano 2017) asi que supongo que su navegador es un smeg+ iv2 y a el se le ven los logos de las emisoras, no se si todas pero cuando me estuvo esnsenando el coche si que me fije y se veia el logo en la pantalla. 

Asi que me he descargado el ultimo firmware del navegardor smeg+ iv2 y he comparado el archivo radiologo.sqlite con ultracompare de los dos firmwares (smeg+ y smeg+ iv2) y ambos archivos son exactamente iguales.

Entonces, por que a el se le ven los logos y a mi no? (yo tambien tengo un 2008, pero la version smeg+) A mi me hace pensar que debe de ser algo mas lo del tema de los logos. tiene que haber algo mas en el firmware para cargar esos logos y no el archivo radiologo.sqlite

Hola @yesansa creo que el archivo radiologo.sqlite es una base de datos que relaciona el identificador de la emisora con el logo que tiene que mostrar, si el 2008 tiene el radiologo.sqlite igual que el nuestro, no sé como lo hace. En el archivo que colgé he añadido los identificadores que faltaban para relacionarlos con el logo, imagino que falte alguno, pero se añadieron unos cuantos. Si te fijas el archivo original y el que modifiqué ocupan lo mismo y puede que tenga como 20 registros o más, más que el original, creo que con una modificación no suben los bytes. Con el del 2008 puede ocurrir lo mismo, pero eso se puede  ver abriendolo y viendo si están incluidas las emisoras que le faltan al nuestro.

Un saludo

[yesansa]

Muy buenas @JesusD

Si ya vi lo del radiologo.sqlite y lo abri y edite con el DB Browser sqllte, Y cmo bien dices si que anadste un monton de lineas nuevas con nuevos PI de emisoras y el archivo seguia ocupando lo mismo, lo cual es muy bueno por que no hay que modificar los valores size_x en el archivo system.bin.inf

De todas formas he agragado otro par de PIs que no tenias, quiza por que algunos son referentes a madrid, y he eliminado una lnea Null que se te habia quedado, pero la verdad es que me ahorraaste mazo de trabajo (por no decir todo) con tu archivo sqlite.

Asi que bueno, ya he agregado el archivo sqlite y reempaquetado de nuevo y cambiado los nuevos crc32. voy a hacer las ultimas comprobaciones y creo que estoy listo para intentar flashear el nuevo firm. Espero que todo vaya bien.

Si funciona y se puede instalar sin problemas, y se soluciona el tema de las voces del gps, que era el tema principal del hilo y de los logos de las emisoras, ya os subire el archivo para el que lo quiera instalar.

Una pena no haer podido dar con el sonido de aviso de radar para tambien poder modificarlo. Seguiere investigando a ver donde diantres esta ese maldito archivito

[yesansa]

Malas noticias chicos.

Lo he intentado y dice que textualemte. el fichero de actualizacion no es conforme. No se puede realizar una copia.

 

Seguire mirando a ver si hay algun otro archivo que compuebe y chequee mas cosas y por eso dice que no es conforme

[JesusD]

hace 3 horas, yesansa dijo:

Malas noticias chicos.

Lo he intentado y dice que textualemte. el fichero de actualizacion no es conforme. No se puede realizar una copia.

 

Seguire mirando a ver si hay algun otro archivo que compuebe y chequee mas cosas y por eso dice que no es conforme

Vaya hombre que p...da, a ver si encontramos el fallo. 

[JesusD]

Hola @yesansa he estado mirando las carpetas AUDIO_BT, AUDIO_BT_256 y NAV y he visto que todas tienen un archivo llamado smeg.inf el cual contiene un CRC que no soy capaz de saber como se calcula, puede que el error venga por ahí.

He intentado con todos los archivos de la carpeta, con los archivos descomprimidos.... y nada

El de las carpetas AUDIO_BT y NAV es igual y el de la carpeta AUDIO_BT_256 es distinto.

Habria que averiguar a que se refiere.

 

Saludos

[yesansa]

Hola @JesusD

El archivo smeg.inf ya lo habia visto yo y creo que lo tengo controlado. 

tiene unos valores BSP_CRC32 que hacen referencia al archivo vxworks.bin que se encuentra en la Carpeta /BSP/SMEG_PLUS_512/ donde hay otro archivo que se llama vxworks.bin.inf con el valor CRC32 igual que el smeg.inf. asi que por ese lado esta controlado.

El valor BSP_CRC32 del  archivo smeg.inf de la capeta Audio_BT hace referencia al vxworks.bin de la capeta /BSP/SMEG_PLUS_256

 

Y el valor BIG_QUICK_CRC32 hace referencia al archivo f_BigQuick.bin que se encuentra en las caprtas /NAV/Appbin: Audio_BT/AppBin y Audio_BT_256/AppBin que tiene un archivo asociado F_BigQuick.bin.inf con unos valores CRC32 iguales que en los smeg.inf de las carpetas correspondientes.

 

Esos archivos no los he tocado para nada y su crc no ha cambiado, de todas formas ya los tenai comrobados sus crc y coincidian

 

Asi que a la hora de flashear el maldito firmware, el instalador debe comprabar algo que se nos esta escapando.

Quiza puede que sea el tamano de los archivos sd_dir.bin y los system.bin una vez recomprimidos que no son exactamente iguales que los originales. Si que he actualizado los .inf con los nuevos valores size, pero a lo mejor estos valores estan en algun otro sitio reflejados.

 

Por que tambien hay otro archivo asociado a los archivos modificados que se llama sd_dir_ctrl.bin y system_ctrl.bin, pero con el editor exadecimal solo parece ser que es como una lista de todos los archvos que hay dentro de los bin, pero los nombres no los hemos modificado, asi que no deberia de haber problemas.

Pero me hace pensar que es posible que a lo mejor haya otro archivo ctrl que controle el tamano de los archivos

[JesusD]

hace 15 horas, yesansa dijo:

Hola @JesusD

El archivo smeg.inf ya lo habia visto yo y creo que lo tengo controlado. 

tiene unos valores BSP_CRC32 que hacen referencia al archivo vxworks.bin que se encuentra en la Carpeta /BSP/SMEG_PLUS_512/ donde hay otro archivo que se llama vxworks.bin.inf con el valor CRC32 igual que el smeg.inf. asi que por ese lado esta controlado.

El valor BSP_CRC32 del  archivo smeg.inf de la capeta Audio_BT hace referencia al vxworks.bin de la capeta /BSP/SMEG_PLUS_256

 

Y el valor BIG_QUICK_CRC32 hace referencia al archivo f_BigQuick.bin que se encuentra en las caprtas /NAV/Appbin: Audio_BT/AppBin y Audio_BT_256/AppBin que tiene un archivo asociado F_BigQuick.bin.inf con unos valores CRC32 iguales que en los smeg.inf de las carpetas correspondientes.

 

Esos archivos no los he tocado para nada y su crc no ha cambiado, de todas formas ya los tenai comrobados sus crc y coincidian

 

Asi que a la hora de flashear el maldito firmware, el instalador debe comprabar algo que se nos esta escapando.

Quiza puede que sea el tamano de los archivos sd_dir.bin y los system.bin una vez recomprimidos que no son exactamente iguales que los originales. Si que he actualizado los .inf con los nuevos valores size, pero a lo mejor estos valores estan en algun otro sitio reflejados.

 

Por que tambien hay otro archivo asociado a los archivos modificados que se llama sd_dir_ctrl.bin y system_ctrl.bin, pero con el editor exadecimal solo parece ser que es como una lista de todos los archvos que hay dentro de los bin, pero los nombres no los hemos modificado, asi que no deberia de haber problemas.

Pero me hace pensar que es posible que a lo mejor haya otro archivo ctrl que controle el tamano de los archivos

Hola @yesansa puede que la cosa venga por el tipo de empaquetado del .bin.

Aparte, me he fijado que cuando se introduce el archivo modificado cambian las propiedades del mismo, el usuario y el grupo, no sé si tenga algo que ver.

 

 

[yesansa]

@JesusD

Yo ya me habia fijado que cambiaba la fecha de modificacion del archivo y y me tenia un poco mosca. Asi que en una segunda intentona. me descargue el Programa NewFileTime, para cambiarlo y que coincidiera la fecha de modificacion  con el original, no solo la fecha de modificacion sino que tambien incluso la hora la puse igual. Y nada... me dio otra vez el mismo error de el fichero de actualizacion no es conforme.

 

El tipo de empaqetado del bin ya no se... aunque si compruebas las cabeceras de los archivos con un editor hexadecimal siguien siendo 1F 8B 08 00 que segun parece ser son archivos gzip y los orginales son tambien igual.

 

Si que me acabo de fijar que los archivos system.bin son exactamente iguales,

es decir el el archivo system.bin orignal y el system.bin modificando con mas lineas en el radiologo.sqlite son exactaemnte iguales a nivel hexadecimal. O por lo menos el Ultracompare eso dice.

Manana a ver si tengo un rato y pruebo a intentar flashear el firmware solo con los system.bin modificados y dejar el sd_dir.bin original a ver si es este el que da problemas.

 

Tambien he llegado a pensar que es posble que sea cosa de algun tipo de firma electronica md5  o algo asi, quiero decir que los archivos bienen firmados por peugeot y al abrirlos y modificarlos perdemos esa firma, aunque luego cambiamos los crc32 en los archivos .inf para que coincidan, asi que no se...

 

[JesusD]

hace 9 horas, yesansa dijo:

@JesusD

Yo ya me habia fijado que cambiaba la fecha de modificacion del archivo y y me tenia un poco mosca. Asi que en una segunda intentona. me descargue el Programa NewFileTime, para cambiarlo y que coincidiera la fecha de modificacion  con el original, no solo la fecha de modificacion sino que tambien incluso la hora la puse igual. Y nada... me dio otra vez el mismo error de el fichero de actualizacion no es conforme.

 

El tipo de empaqetado del bin ya no se... aunque si compruebas las cabeceras de los archivos con un editor hexadecimal siguien siendo 1F 8B 08 00 que segun parece ser son archivos gzip y los orginales son tambien igual.

 

Si que me acabo de fijar que los archivos system.bin son exactamente iguales,

es decir el el archivo system.bin orignal y el system.bin modificando con mas lineas en el radiologo.sqlite son exactaemnte iguales a nivel hexadecimal. O por lo menos el Ultracompare eso dice.

Manana a ver si tengo un rato y pruebo a intentar flashear el firmware solo con los system.bin modificados y dejar el sd_dir.bin original a ver si es este el que da problemas.

 

Tambien he llegado a pensar que es posble que sea cosa de algun tipo de firma electronica md5  o algo asi, quiero decir que los archivos bienen firmados por peugeot y al abrirlos y modificarlos perdemos esa firma, aunque luego cambiamos los crc32 en los archivos .inf para que coincidan, asi que no se...

 

Parece que tienes razón con lo del MD5. He encontrado una página que calcula el MD5  del archivo y son distintos:

system.bin original:

hex: 65d2ca161d12ce69523ad6ba7284e2b3

HEX: 65D2CA161D12CE69523AD6BA7284E2B3

h:e:x: 65:d2:ca:16:1d:12:ce:69:52:3a:d6:ba:72:84:e2:b3

base64: ZdLKFh0SzmlSOta6coTisw==

system.bin modificado:

hex: ce8f9b6a5acef6cc782d535b79989874

HEX: CE8F9B6A5ACEF6CC782D535B79989874

h:e:x: ce:8f:9b:6a:5a:ce:f6:cc:78:2d:53:5b:79:98:98:74

base64: zo+balrO9sx4LVNbeZiYdA==

 

Ahora toca investigar donde está el MD5 almacenado para ver si se puede cambiar

[yesansa]

Yo es que me acuerdo de cuando era mas joven que una vez quise modificar un juego para ps2 y habia problemas con la firma digital de los archivos, que al querer modificarlos se perdia dicha firma. Lo que ya no me preguntes que paso con aquello, creo que lo dejaria por imposble, como puede ser el caso este del firm para el coche, por que ya se me escapa de mis pocos conocimientos.

 

PD. Acabo de comprobar ahora mismo a flashear el firmware solo con la modificacion del archivo radiologo.sqlite ya que no se modificaba el tamano y los system.bin que son iguales hexadecimalmente. Pero nada, ha vuelto a dar el mismo error.

 

Voy a ver que averiguo acerca de las firmas digitales...

Editado 27 de Febrero, 2018 por yesansa

[yesansa]

@JesusD Tu, que parece que utilizas linux a lo mejor le puedes echar un ojo a esto

Info de firmas y puedes comprobar los archivos (--verify)

Tambien dice que (El documento se comprime antes de ser firmado, y la salida es en formato binario) que la verdad tiene algo de sentido.

Echale un ojo a ver si tu entiendes algo mas.

 

Aunque como dije en su dia el Usuario @j5boot parecia que controlaba bastante del tema, Lo mismo nos puede echar un cable. 

J5boot por favor, mira a ver si nos puedes echar una mano

[j5boot]

Lo puedo echar un ojo, pero no aseguro de que funcione, jejeje. Yo no me atrevo a probar, si hay alguien que quiere ser conejillo de indias.... aunque la verdad tampoco creo que haya problema, si no pasa bien la verificación no lo instalara. Lo voy mirando y os cuento algo, pero habeis avanzado ya mucho, no se si yo podre ser de mas ayuda.Me llevará algo de tiempo porque la verdad es que no me sobra mucho tiempo pero si que puedo sacar huecos.

[yesansa]

Muchas gracias @j5boot . Si tienes un rato echale un ojo.

Yo ya he intentado instalarlo en mi coche pero me djo que el archivo no era conforme y eso que cambiamos los valores crc32 de los archivos.inf para que coincidieran con los nuevos, pero de haber algo mas que se nos escapa 

[JesusD]

El 27/2/2018 a las 16:09, yesansa dijo:

@JesusD Tu, que parece que utilizas linux a lo mejor le puedes echar un ojo a esto

Info de firmas y puedes comprobar los archivos (--verify)

Tambien dice que (El documento se comprime antes de ser firmado, y la salida es en formato binario) que la verdad tiene algo de sentido.

Echale un ojo a ver si tu entiendes algo mas.

 

Aunque como dije en su dia el Usuario @j5boot parecia que controlaba bastante del tema, Lo mismo nos puede echar un cable. 

J5boot por favor, mira a ver si nos puedes echar una mano

Siento defraudarte pero no utilizo linux, aunque si que tenía una MV con Ubuntu por ahí.

He estado mirando y... puede llevar tiempo... iré mirando cuando pueda. Llevo una temporada muy liado, más de lo que me gusta.

Pero iré mirando y a ver si encuentro algo.

[JesusD]

Bueno, pues algo he descubierto.

Dentro del archivo upgrade_256.out he encontrado esto:

 

  ReadContentInBinaryFile (%s) CRC readed = 0x%X..flasher.inf.vxWorks.bin.dbsystem.bin....(manageBootRomUpdateAndReboot): field (%s) found !!.(manageBootRomUpdateAndReboot): field (%s) not found !!.(manageBootRomUpdateAndReboot): CRC of dbsystem.bin is OK...(manageBootRomUpdateAndReboot)

 

Parece que los CRC están en una archivo pero no sé donde se encuentra.

¡¡¡A seguir investigando!!!

[j5boot]

Supongo que los CRC estan en los archivos .INF. Es lo que estoy mirando ahora, la primera linea de los archivos .INF, que es el checksum del archivo sin el .inf. El tema es que no consigo dar con la verificacion de redundancia que usa. En un principio es CRC32 pero no me cuadra. Si no conseguimos esto de nada sirve modificar los archivos de dentro, porque no podra comprobar el checksum y no continuara la instalacion.

[j5boot]

Vale, conseguido el CRC de los archivos .INF. Nos hace falta el calculador CRC del RT6. Con ese ejecutable, lo tenemos todo, pero hay que hacer dos pasos.

 

Calcular el CRC del archivo .OUT

RTXcrc -v Fichero.out

Nos dara un checksum de 4 letras/numeros. Esas 4 letras/numeros las metemos en la primera linea del archivo .INF (con todos los sizes correctos, por supuesto). Una vez guardado el INF con el checksum del .OUT,  ejecutamos el mismo comando pero esta vez sobre el .INF. De esta forma nos da otras 4 numeros/letras que van delante del checksum que hemos metido en el INF anteriormente.

 

RTXcrc.exe -v UpgPlugin.out
RTXcrc v01.00: by mira308sw. RT4/RT5 crc calculator.

CRC = a295


DEJAMOS EL ARCHIVO UpgPlugin.out.inf ASI
a295
VER:SMEG_5.4x.B.R1_kok
TYPE:RELOCABLE
ID:0
COMPRESSED:NO
SIZE:168902
ENTRY:YES
SUBVER:APP_5.2.0


RTXcrc.exe -v UpgPlugin.out.inf
RTXcrc v01.00: by mira308sw. RT4/RT5 crc calculator.

CRC = 988c

EL CRC FINAL QUEDA 988ca295 QUE ES EL QUE TIENE EL ARCHIVO.  

Ahora con esto, a seguir modificando. Voy a intentar hacer unos scripts que automaticen todo. Lo malo es que lo hare para Linux porque me resulta mas sencillo. Intentare migrarlos a sistemas Windows, pero primero tengo que hacerlo...

RTXcrc (v01.00).zip

[j5boot]

El 27/2/2018 a las 9:28, JesusD dijo:

Parece que tienes razón con lo del MD5. He encontrado una página que calcula el MD5  del archivo y son distintos:

system.bin original:

hex: 65d2ca161d12ce69523ad6ba7284e2b3

HEX: 65D2CA161D12CE69523AD6BA7284E2B3

h:e:x: 65:d2:ca:16:1d:12:ce:69:52:3a:d6:ba:72:84:e2:b3

base64: ZdLKFh0SzmlSOta6coTisw==

system.bin modificado:

hex: ce8f9b6a5acef6cc782d535b79989874

HEX: CE8F9B6A5ACEF6CC782D535B79989874

h:e:x: ce:8f:9b:6a:5a:ce:f6:cc:78:2d:53:5b:79:98:98:74

base64: zo+balrO9sx4LVNbeZiYdA==

 

Ahora toca investigar donde está el MD5 almacenado para ver si se puede cambiar

 

Sobre esto, para calcular este checksum, es un simple CRC32 del archivo. El tema es que el resultado te lo da en Hexadecimal y hay que pasarlo a decimal:

javier@xps ~/dev/SMEG/Firmware/SMEG_PLUS_UPG/NAV $ cksfv system.bin
; Generated by cksfv v1.3.14 on 2018-03-04 at 23:18.44
; Project web site: http://www.iki.fi/shd/foss/cksfv/
;
;     24902910  11:30.56 2017-09-19 system.bin
system.bin 14B00FA9
 

javier@xps ~/dev/SMEG/Firmware/SMEG_PLUS_UPG/NAV $ cksfv system.bin
; Generated by cksfv v1.3.14 on 2018-03-04 at 23:18.44
; Project web site: http://www.iki.fi/shd/foss/cksfv/
;
;     24902910  11:30.56 2017-09-19 system.bin
system.bin 14B00FA9

Si paso a decimal 14B00FA9 me da 347082665, que es lo que tiene el archivo system.bin.inf en la primera linea. No creo que haya problemas con alguna comprobacion MD5, porque al fin y al cabo siempre se podria comprobar. Estoy revisando todo y parece que solo tienen checksums CRC32, el de RTxCRC y poco mas, pero cada archivo es de su padre y de su madre.

[JesusD]

Bueno, bueno, parece que vamos avanzando algo...

Pero, no entiendo una cosa, @j5boot, ¿porque hay que calcular el CRC del archivo .OUT, si la modificacion la hacemos en el system.bin que está dentro de las carpetas AUDIO_BT, AUDIO_BT_256 y NAV?

Editado 5 de Marzo, 2018 por JesusD

[j5boot]

Ya tengo una primera modificacion (El PI de los 40, para que aparezca el logo. El PI que tengo yo es el E235, supongo que sera en todos los sitios el mismo y tambien he modificado unas imagenes de lo de Peugeot Connect APPS, porque ya puestos a probar...), tan solo me falta calcular los SIZE_xx del archivo .inf

No deberia ser dificil pero me esta dando algun dolor de cabeza. Sigo con ello, espero tener una primera modificacion en breve.