NefMoto

There seem to be four CRC32 checksum values stored at:

6:BD8Ah for the C-box 
9B 2F 40 22  DB 00 49 D5   59 E3 DB 00   05 E2 37 3E 

7:A866h for the M-box   
72 D2 4C 21   DB 00 53 0F   B9 17 DB 00   83 13 E9 7D 

The  "9B 2F 40 22" seems to be for the data range of 810000-813FFF for the C-box. This is not true for the M-box. What areas are code are checked for each of these four checksum? I could only find the one.

The other checksums, the "2-byte wide" checksums, the data ranges for the C-box are well defined. They can be found between 1FC000-1FE1F. Each line has the data start address, the data end address, the checksum, and the complimented checksum.

Can anyone help define the data ranges for the four CRC32 checksums? Assuming there are only four? Thanks in advance.

In my experience it appears as though these ranges are different for each ECU type.

Looks like. After I found the first one, I thought it would not be too hard to find the other data ranges. I was wrong. I tried the obvious combinations and could not find any more.   >:(

There are only three CRC32 checksum values for C-Box:
9B 2F 40 22   DB 00   49 D5 59 E3   DB 00   05 E2 37 3E
For the M-Box it are also THREE crc32 checksum values, but this image uses another
checksum algorithm version with slightly different ranges. Some images also use just a
normal wordwise checksum for the data area instead of the CRC32 algorithm.
Fortunately the number of different data checksum algorithms and checksum ranges in the ME7 is not endless.

To start, you can analyze the function at 6:BEDCh of C-Box to find the ranges and the way the checksums are calculated.

A typical 512Kb S4 bin file has a total of 38 checksums saved in various parts of the file (on 1M files I have found 72 checksums) and for many of the fixed checksums there are also complement's of the checksum saved.. There are a total of  7 distinct algorithms used and 7 small lookup tables.

To do proper checksum calculation you can not use fixed addresses for all checksum locations because between different bin files these have some differences in location and for the multipoint checksums the quantity changes based on file size because this is calculated every # bytes repeated for blocks of data.

So far I have found probably about 8 or so different bin files with slight changes in structure that require adjustments for proper checksum calculation if you want to covert all VAG ME7 ecu's but I suspect that there are more... The good news is that there are ways though use some internal structures of the bin file to help you locate all checksum regions.

Up to today I must say that this ecu used with VAG vehicles has the strongest & longest checksum algo. I've seen. For example the BMW ME7 checksum algo. although similar uses only half the algorithms but to compensate they use up to 1K lookup tables.

Thanks setzi62. I missed the "DB 00" separating the three checksums.  I did look at the code. By searching for occurrence of "XOR", I was able to find the code where the actual CRC32 conversion was done. I have had no luck finding the address range for each of the checksums.   >:(

You first have to search for the function that uses the CRC32 table, I think that is what you already found.
This function updates the crc32 checksum for a small memory block and gets called in a loop at several
places.  Locate where the checksum calculation function itself gets called (you will find e.g. for the
C-box image three locations).  About 20 opcodes before the call you will see something like the following
which shows you the used range:
0880              ADD     R8, #0
16F98100       ADDC   R9, #0081h              ; START = 81'0000
46F98100       CMP     R9, #0081h
3D02             JMPR    cc_NZ/NE, L_skip_compare
46F84F3F       CMP     R8, #3F4Fh              ; END = 81'3F4F
Analyze the code to see how the checksum calculation continues for the following sections,
it is not a separate crc32 for each section, but the result of last calculation is used in the next section.

Which stock BIN file are you guys using?

I have been looking at files for 8D0907551C checksum-6294 and 8D0907551M checksum-E157.

OK, perfect... First of all a small correction the lookup tables are 10 and not 7 like I was saying in my previous post. I forgot to add in the tables used in these three crc32 functions.

Using the 8D0907551M bin file as reference the start address is 1E76A. It is the same address for all 3 checksums.

You will notice that I'm only telling you the start address used for the calculation, do you know why I don't give you an end address?

I can tell you why if you want... or you want to figure it our yourself...

Your decision... This took me a while to figure out :)

Not sure what you mean?
We discussed about the CRC32 table in http://www.nefariousmotorsports.com/forum/index.php?topic=343.0title=
This table you will find in all ME7.1/ME7.5, but it does not define the checksum data ranges.

That's where you are wrong. The table has two uses:

1) it is used as a seed table for CRC calculation
2) it is used to calculate the address to fetch data for the current CRC calculation.

So you don't calculate CRC from start addr. to end addr. but instead you have an offset (0x1E76A) to the data to be verified and the next address to use is calculated using the value stored in the current position of the seed table.

:) Tricky CRC calculation isn't it...

A CRC calculation itself is not tricky, you can use one of the many available example
implementations. The ECU uses exactly the standardized CRC32 algorithm.
What is tricky, is to figure out which starting values for crc calculation the ecu uses and for
which data areas crc's get calculated. These things are NOT stored in tables,
you will have to look up these details in the code  ;).

Look at the table at address 81'E76A in the M-box image, it is just the standard CRC32
table with 256 entries. Exactly the same table you would use when you implement a table
driven crc32 calculation algorithm on your PC. This table does not contain information about
the data areas of the ecu that are protected with crc32.
The address of the table itself also does not reveal the ranges of data that the ecu verifies
against crc32 checksum(s).

You can find an implementation of the table driven CRC32 algorithm in the ecu code,
e.g. for the M-box this function starts at address 87'A94A. It has input parameters
R14=number_of_bytes and R13,R12=bufferaddress.
It takes the last calculated CRC32 value from memory and returns the updated checksum
in R5,R4. It is just a general checksum function which updates a crc32 for a block of
memory. Which memory blocks get summed up in total you will only find when inspecting
the code that calls this function.

If somebody wants to start a database of locations, i'd be more than happy at taking a shot at making a completely free checksum corrector.

I confused the lookup table address (0x1E768) with the start address (0x10002)...

There are two CRC32 functions. Both very similar except that one will calculate data from a start address to a end address (and in some cases the complement of the result is used). The other will use the start address as an offset to which the value read from the CRC lookup table is xor'ed with a seed and added to this offset. This is done for all 16380bytes (in the case of the first CRC, other have different lengths) and final result is added together with the other 2 CRC's calculated and saved as one 32bit value.

Also in the case of this BIN file you have only one lookup table but some other files will use a different lookup table for each of the CRC32's.

Finding the start address of the data is not that hard because there is a function that will return a pointer to a 32bit value, if you take this value and xor with a fixed seed it will reveal the start address. Every time you call this function it will return the next start address, you can call it 72 times and get all start addresses.