Cluster Dump Checksum

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
ironduke
Posts: 579
Joined: Thu Feb 13, 2020 11:32 pm
cars: Mainly GM trucks, a Cruze and an Equinox for dailys..

Re: Custer Dump Checksum

Post by ironduke »

I checked my cache files and I don't have any of them, checked a few other numbers once I knew where they were in the bins.. I'll keep looking.. Maybe Tazzi has something ready to pull them from the server?
yoda69
Posts: 1215
Joined: Sun Mar 15, 2009 10:20 am
cars: 2004 VYII Acclaim Wagon V6 Auto LPG/Petrol
2004 VYII Berlina sedan V6 Auto
2005 VZ Monaro CV8 manual
Location: Geelong, VIC

Re: Custer Dump Checksum

Post by yoda69 »

I've only had a quick look, but it looks like an 8 bit checksum stored at either $0D4 or $0D5 as already stated.
I checked several 1kb bins and if add $0D4 and $0D5 together you get FF in all that I checked.
I've seen this done before so whatever the checksum these 2 always add to FF so the checksum can actually be included in the area being checked.
Next step is to work through start finish locations and find out which 8 bit checksums equal what is stored in either $0D4 or $0D5 and see if it consistent across all files.
Out of time but hopefully this gives some more direction.
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: Custer Dump Checksum

Post by VX L67 Getrag »

ironduke wrote:What hex editor are you using?? Looks interesting, I'm using neo and it's working ok but yours looks interesting..
It's called Hex Workshop, the latest version is 6.8.x unfortunately it's a pay for item... there is other options out there though.
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: Custer Dump Checksum

Post by VX L67 Getrag »

j_ds_au wrote:Well, those bytes do look to be an 8-bit checksum, as they're a one's complement of each other.

Joe.
O.k. thank you I'm not sure how that works but guessing it has something to do with what Yoda was saying later in the thread about adding them both together to equal FF FF, I didn't even think of 2 8Bit checksums I just assumed because of the size of the location it was stored at was 16Bit checksum.

EDIT; how do you know that’s what it is, is there something that shows you what to look for with checksums?
Last edited by VX L67 Getrag on Sat Jan 16, 2021 11:48 am, edited 1 time in total.
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: Custer Dump Checksum

Post by VX L67 Getrag »

kur4o wrote:I did some preliminary digging and almost figured the file structure.

Too bad I cant find a gm files to confirm start-end of segment. ALso not sure if there is some missing data.

Here is some of the dumps. There is a chance that there is multiple checksums or only one.

DUMP 8

Module Part Number CVN
Operational Software 92260731 Unknown
Fuel Calibration 92226843 0000D7F6
Service Calibration 92226842 0000E5D6
Temperature Map 92226837 0000E4EC
DTC Calibration 92234355 000028DB

VIN: 6G1EK8EV59L333437

and

DUMP 5 6
$34
$42 PN ONLY
$48 VIN
$5E

Operational Software 92262631 Unknown 057FD0E7
Fuel Calibration 92254799 Unknown 057FB24F $150
Service Calibration 92226842 0000E5D6 057F451A $117
Temperature Map 92247713 0000234F 057F96A1 [A0]$83
DTC Calibration 92244999 00008166 057F8C07 $1A4

VIN: 6G1EK8EV5BL547734

Part of the vin is also in the file.

If anyone can source some of these p/n figuring the rest will be easy.


VX L67 Getrag do you know if these files are stock dump or modified.
WOW thats pretty cool I do have further mapping data of those files which may help I'll try & dig them up in a little bit, the very first file I posted I know is complete factory & can try & find some more I can make sure are 100% stock, obviously with odometre reading in there they will be changing that part & won't be factory & guessing the checksum has to roll because of that changing too.
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: Custer Dump Checksum

Post by VX L67 Getrag »

yoda69 wrote:I've only had a quick look, but it looks like an 8 bit checksum stored at either $0D4 or $0D5 as already stated.
I checked several 1kb bins and if add $0D4 and $0D5 together you get FF in all that I checked.
I've seen this done before so whatever the checksum these 2 always add to FF so the checksum can actually be included in the area being checked.
Next step is to work through start finish locations and find out which 8 bit checksums equal what is stored in either $0D4 or $0D5 and see if it consistent across all files.
Out of time but hopefully this gives some more direction.
Thanks heaps thats a great starting point for looking into!
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: Custer Dump Checksum

Post by VX L67 Getrag »

Turns out the mapping I had was for the series 1 which I got from CarModder years ago so it's not really relevant to these files but here's that info anyway...
Memory Location Value Description
0x0030 - 0x0034 14060808F0F7 Omega Cluster (Part # 92222121)
0x0030 - 0x0034 070806087EF7 Calais Cluster (Part # 92198636)
0x0030 - 0x0034 0404080889F9 HSV Cluster (Part # 92222129)

0x0142 - 0x0143 9FFD Omega 4 Speed Auto - LY7 engine, 4L60 transmission
0x0142 - 0x0143 EBFC Calais 6 Speed Auto - L98 engine, 6L80 transmission
0x0142 - 0x0143 43FD HSV - LS3 engine, Unknown transmission

0x0346 - 0x0347 9FFD Omega 4 Speed Auto - LY7 engine, 4L60 transmission
0x0346 - 0x0347 EBFC Calais 6 Speed Auto - L98 engine, 6L80 transmission
0x0346 - 0x0347 43FD HSV - LS3 engine, Unknown transmission

0x0330 - 0x0331 AEFE Omega - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)
0x0330 - 0x0331 B3FF Calais - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)
0x0330 - 0x0331 AFFE HSV - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)

0x0337 - 0x0339 13457F Omega - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)
0x0337 - 0x0339 0DB57E Calais - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)
0x0337 - 0x0339 13457F HSV - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)

0x033C - 0x033F 24010101 Omega - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)
0x033C - 0x033F 531B0202 Calais - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)
0x033C - 0x033F 561B0101 HSV - Unknown (Affects ABS, Speed Alert, Single / Triple LCD Settings)

0x005D - 0x0064 VIN NUMBER Last 8 Digits of the Chassis VIN Number Stored as ASCII UPPERCASE
0x0295 - 0x029C VIN NUMBER Last 8 Digits of the Chassis VIN Number Stored as ASCII UPPERCASE

0x0010 - 0x0013 ODO READING Odometer reading - Memory Location 1
0x0014 - 0x0017 ODO READING Odometer reading - Memory Location 2
0x0036 - 0x0039 ODO READING Odometer reading - Memory Location 3
0x003A - 0x003D ODO READING Odometer reading - Memory Location 4
0x0050 - 0x0053 ODO READING Odometer reading - Memory Location 5
0x0054 - 0x0057 ODO READING Odometer reading - Memory Location 6
0x0080 - 0x0083 ODO READING Odometer reading - Memory Location 7
0x0084 - 0x0087 ODO READING Odometer reading - Memory Location 8
0x00A4 - 0x00A7 ODO READING Odometer reading - Memory Location 9
0x00A8 - 0x00AB ODO READING Odometer reading - Memory Location 10
0x00AC - 0x00AF ODO READING Odometer reading - Memory Location 11
0x00D8 - 0x00DB ODO READING Odometer reading - Memory Location 12
0x00DC - 0x00DF ODO READING Odometer reading - Memory Location 13
0x00E0 - 0x00E3 ODO READING Odometer reading - Memory Location 14
0x0109 - 0x010C ODO READING Odometer reading - Memory Location 15
0x010D - 0x0110 ODO READING Odometer reading - Memory Location 16
0x0111 - 0x0114 ODO READING Odometer reading - Memory Location 17
0x0126 - 0x0129 ODO READING Odometer reading - Memory Location 18
0x012A - 0x012D ODO READING Odometer reading - Memory Location 19
0x0160 - 0x0163 ODO READING Odometer reading - Memory Location 20
0x0164 - 0x0167 ODO READING Odometer reading - Memory Location 21
0x0168 - 0x016B ODO READING Odometer reading - Memory Location 22
0x017C - 0x017F ODO READING Odometer reading - Memory Location 23
0x0180 - 0x0183 ODO READING Odometer reading - Memory Location 24
0x0184 - 0x0187 ODO READING Odometer reading - Memory Location 25
0x0198 - 0x019B ODO READING Odometer reading - Memory Location 26
0x019C - 0x019F ODO READING Odometer reading - Memory Location 27
0x01B4 - 0x01B7 ODO READING Odometer reading - Memory Location 28
0x01B8 - 0x01BB ODO READING Odometer reading - Memory Location 29
0x01EE - 0x01F1 ODO READING Odometer reading - Memory Location 30
0x01F2 - 0x01F5 ODO READING Odometer reading - Memory Location 31
0x0228 - 0x022B ODO READING Odometer reading - Memory Location 32
0x022C - 0x022F ODO READING Odometer reading - Memory Location 33

0x014E 69 High Brightness LCD (Omega, RED, GREEN LCD Illumination)
0x014E 6B Standard Brightness LCD (Calais, HSV, White LCD Illumination)

NOTE: 0x0331 to 0x0332 enables / disables a number of features including support for Single or Triple LCD Displays, as well as Automatic Sport Mode Display !
This memory location depends on other memory locations which are currently unkown.
User avatar
j_ds_au
Posts: 384
Joined: Sun Jan 25, 2015 4:21 pm
Location: Sydney

Re: Custer Dump Checksum

Post by j_ds_au »

VX L67 Getrag wrote:EDIT; how do you know that’s what it is, is there something that shows you what to look for with checksums?
Well, I noticed that the two byte locations in question were a one's complement of each other (ie. each bit is inverted), so they effectively both provide the same data, and that data is 8 bits in size (not 16 bits as assumed). This is a technique sometimes used to ensure the validity* of a key piece of data, particularly a checksum.

* Mathematically, there is only a 1:65536** chance that this data can be corrupted and yet maintain a one's complement relationship; practically, the chance is significantly even lower.

Joe.

** Edit : Actually, there's no simple way to calculate the chance of corruption that can evade detection with this checksum scheme, because there's no way to know the chance for both bytes to be corrupted. Often when multiple bytes are corrupted, the same value may be written to consecutive bytes, which will certainly fail this checksum test.
Last edited by j_ds_au on Wed Jan 20, 2021 1:05 am, edited 3 times in total.
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: Custer Dump Checksum

Post by VX L67 Getrag »

Ahh ok that makes sense, I guess it makes it easier when you know where the checksum is.

Is there a way of finding the range for checksum, I’m assuming you’d use a dissasembler but even with that what gives you directions?
User avatar
j_ds_au
Posts: 384
Joined: Sun Jan 25, 2015 4:21 pm
Location: Sydney

Re: Custer Dump Checksum

Post by j_ds_au »

VX L67 Getrag wrote:Ahh ok that makes sense, I guess it makes it easier when you know where the checksum is.

Is there a way of finding the range for checksum, I’m assuming you’d use a dissasembler but even with that what gives you directions?
Yeah, if you have a copy of the code and suitable tools, that's the most reliable way to go.

Otherwise, you can take guesses at the address range and calculate a checksum and see how that compares. However, that assumes a simple checksum and a contiguous block of data to calculate against (for example, I've seen software that used a pseudo-random selection of addresses to include in it's integrity check, presumably to reduce the time it would have taken to check (almost) all the code, while being sufficient to frustrate tampering).

A potential clue in your collection is that the 05 and 06 files have the same checksum bytes, despite a good scattering of different data.

Joe.
Post Reply