CRC's..Checksums.. Reverse Engineering!

[Tazzi]

Ok. The CVN is a CRC16, and the sum is a 16 bit 2s compliment. When calculating the data you need to update the CVN first, as it IS included in the sum. The CVN is not a derivative of the sum (or directly vice versa).

Makes sense really as the scan tools (or PCs) can verify the CVN after reading the bin for warranty test purposes (that's why its in there), but the PCM only needs to do the sum which is quicker in an embedded system like a pcm. CRC can be accellerated with a lookup table, but they are probably looking at it from a space savings angle in the pcm, and its not really needed anyway.

Next steps, figure out how to ID each segment type, handle disabled sums and segments, handle differing numbers of segments, and add partnumber/ID strings.

Also, put this login in to a TP checksum plugin. Probably merge the delco checksum plugin, ls1 checksum plugin, and e38 checksumtool in to one TP5 checksum plugin.

Whos keen to help work on XDFs?

Alright! Major progress!

how to ID each segment type
I assume we simply do this via the part number in each section? Always appear between the two checksums.

handle disabled sums and segments
Again, same as above? If the ID number doesnt appear/ no checksums/ all 00's or FF's.. then that segment must not be supported?

partnumber/ID strings
I think this is something we need to get rolling. Need as many partnumbers/IDs for each segment and the OS number to find how eveything differs.


Iv got no experience in XDF's, will probably be more of a pain than help but Ill try!

[antus]

how to ID each segment type
I assume we simply do this via the part number in each section? Always appear between the two checksums.

I mean the order of the index does not match the order displayed by other apps. There must be a way to know if a segment is engine operations, engine dignostics etc. Then we can order them in a more logical way in applications. It may be a static order, I havnt had time to check yet.

handle disabled sums and segments
Again, same as above? If the ID number doesnt appear/ no checksums/ all 00's or FF's.. then that segment must not be supported?

Nope, they're there and they have sums. But other apps can say "unused". Probably they will be missing the type information (see above).

partnumber/ID strings
I think this is something we need to get rolling. Need as many partnumbers/IDs for each segment and the OS number to find how eveything differs.

That bit is easy, its just a text string in the header. Just reading it out and displaying it comes after v0.1 of my app

Iv got no experience in XDF's, will probably be more of a pain than help but Ill try!

Great! A lot of it is changing, testing, looking for changes. Entering whats figured out in to the Tunerpro XDF editor. For the amount of data, its a lot of work. But we need to decide what OSIDs are most common and hit those.

[Tazzi]

Yeah thats what I mneant, each segments "number" might be static (havent checked). Bit if the segments are there.. and other apps say "unused".. then there must be something in the index indicating it I reckon.

Haha, yes it is the easy bit, but its identifying all the possible OSID's that we could potentially support.. or finding any that dont match up/work with our current findings!

[Tazzi]

Ok. The CVN is a CRC16, and the sum is a 16 bit 2s compliment. When calculating the data you need to update the CVN first, as it IS included in the sum. The CVN is not a derivative of the sum (or directly vice versa).

Alright cool, iv got to the same point now, only difference is Im using the little algo for checksum1 instead of adding it all up as thats just what I had previously.

[Tazzi]

In the bin Im tinkering with, Iv got:
2008 VE M6
Seg1: Operating System - 12612381
Seg2: System - 92205534
Seg3: Fuel System - 92196978
Seg4: Speedometer - 92196089
Seg5: Engine Diagnostics - 92205532
Seg6: Engine Operations -92207268

2009 VE M6
Seg1: Operating System - 12633016
Seg2: System - 92246473
Seg3: Fuel System - 92241157
Seg4: Speedometer - 92241152
Seg5: Engine Diagnostics - 92241159
Seg6: Engine Operations - 92241170

Ill grab some more and see if they change

*Edit
Ant, the "unused" is transmission
Evidently manuals will not have that section.

This makes sense, since the "Index" only has 6 segments mapped into it and that is it. And these 6 segments take up most of the bin. The trans will be an entirely separate bin.

[immortality]

I'm happy to help but this stuff is over my head

I haven't done any coding since I was at tech and that was to long ago.

[Tazzi]

I'm happy to help but this stuff is over my head

I haven't done any coding since I was at tech and that was to long ago.

It all mapping out the bins now.. sort of. Just need to see if certain parameters changes their offset in their segments when opening up different bins. Hopefully, they are all in the same offsets.. will find out shortly.

[Holden202T]

when I saw the bit about mapping it out, reminded me about this .... VZ V6 5 speed auto (190kw alloytec) not sure if its any use to your stuff or not.

2010-12-31 - original file read.bin

(2.5 MiB) Downloaded 317 times

testing VZ V6 Auto.xdf

(14.77 KiB) Downloaded 331 times

most of the stuff in there is change it in HPT/efilive and see what changes in the bin using compare in tuner pro then making the XDF from there....

[antus]

Heres something for anyone who wants to play along. I dont know if it will handle all bins or not, but one way to find out......

[Tazzi]

Ah damnnn... each bin with a different OSID has to be worked out individually. Just checked three bins with varying ID's, and the parameters in each one are found at different locations in their segments. The offset from the beginning of the segment to the parameters is not the same. Guess that solves that question.