VBF versions 2.4+

[PelsonBM]

I did not modify the whole "texts" because it's pointless untill I will make it work in cluster . The workout is - I need to change one of the languages inside to my native one , this IPC doesn't have "built in" all languages , so asbuilt changes etc does not make difference . And for now I don't know if I need TTF table with pointers to "special characters" to show up on cluster , maybe it has built in TTF

EDIT :

Firmware im working on + Software for unpacking all known FIRMWARES from 2.2 up to 3.6 (VBF) and 5.0 MAZDA in uploaded attachment . Im looking for CRC16 in all of those Files and HOW TO PROPERLY CALCULATE THEM - KT4T and NT4T are like twins but with different offsets , NT4T is a updated version of KT4T , GT4T is the older version of those files that lands together with SBL in one Flash , NT4T and KT4T are MCU based but they are almost the same . Its about proper language ID and translation of text that shows up on cluster - like SETTINGS - TESTXXXX , every text inside is UTF-16 LE , S.E.T.T.I.N.G.S . there is a reference image inside package that contains (how probably CRC 16 CITT are handled) I know that routine control is checking for them and if the CRC is BAD , the module is bricked . If anyone with more knowledge than me can help that would be awesome, im almost month about gathering all informations from those files and cant bypass it for work with cluster . After repacking in HexView the original file - Decompress - Export to BIN - Import- Compress - Export to VBF again - it works like original , just one byte change, programming goes to 100% and IPC is Bricked . KT4T can be flashed into NT4T and it works .

PCMHACKING.rar

[oldtinfords]

I've opened your vbf in Hex Editor Neo & bin in Hexview, so you can see them side by side & highlighed the checksum value in the original files.

Open your bin in Hexview

Menu > Edit > Create Checksum
Checksum is over the entire file
Set checksum type to option 14 (14:CRC-16 (CCITT Table) BE-Out)
Hit calculate & you should see the bin CRC matches the vbf in Hex Editor Neo, as expected because it's the original file.

GT4T-14C026-CB Original CRC.png

Make your edits in the bin...as shown in the second image
Calculate the CRC in the edited bin, don't insert.
Replace the CRC in the repacked vbf as per image below & save the vbf

GT4T-14C026-CB Original Edited Bin CRC Calculate.png

[PelsonBM]

I've opened your vbf in Hex Editor Neo & bin in Hexview, so you can see them side by side & highlighed the checksum value in the original files.

Open your bin in Hexview

Menu > Edit > Create Checksum
Checksum is over the entire file
Set checksum type to option 14 (14:CRC-16 (CCITT Table) BE-Out)
Hit calculate & you should see the bin CRC matches the vbf in Hex Editor Neo, as expected because it's the original file.


GT4T-14C026-CB Original CRC.png


Make your edits in the bin...as shown in the second image
Calculate the CRC in the edited bin, don't insert.
Replace the CRC in the repacked vbf as per image below & save the vbf


GT4T-14C026-CB Original Edited Bin CRC Calculate.png

Is that the only one checksum ? Have you seen the headers and footers in all 3 bin files ? , look for example inside NT4T , the Checksum place (as seen on your photos) there is 00 or FF at the end of the block . After repacking vbf the CRC 16 for VBF (compressed) are automatically calculated with HexView , the problem is that I have to calculate checksum INSIDE bin , data block has internal checksum that processor routine checks for it after flashing . For example (text changed- flashing- brick ,because processor calculates CRC for data block not for vbf CRC 16)

[jakka]

Up until 2022MY they are using LZSS compression in VBF files, post MY2023 a different kind of compression is used. The files are not encrypted.

[PelsonBM]

but there are still CRC16 CITT inside BIN , not those CRC16 that are calculated with HexView trough compression of BIN file

[PelsonBM]

So the routine check does not start the application for me :/ what the hell is going on here