For the most part, I agree. Binary diffs are useless. However what I'm mostly interested in is a better way of managing the bins, logs, etc. for each revision I make to the map and to be able to store a comment on that whole set of data explaining what I did/changed and why. That would entail changes to the tune just from log runs as well as changes to the tune due to vehicle modifications. That way I could look back over time and see what changes I made to the tune to compensate for vehicle mods.

I definitely thought about a system like you're describing. My initial thought was to keep it simple and use the offsets for the maps to dump them as hex (or even to apply the conversions and calculations on them) before committing. With Git I could do that in an automated fashion using pre-commit client side hooks.

However, I'm not at the moment interested in taking the time to do that. I'd go the simple route and just dump the entire binary in with a good set of comments.

Thanks so much for your take on this, I'm sure at some point I'll eventually get around to writing something like that. When/if I do I'll be sure to let you (all) know.

This is not a big deal, but when I check the attached bin I get some interesting results. I am not sure if it is the bin or the checker and I can't even remember where I got this bin from. What caught my attention was the VAG part number. This is an original bin that I have in my files. Is this file not for a 2001 S4?

=================================================
me7check v1.05 (c) mki, 06/2004-10/2010
Checking file 8D0907551L_0261206562_1037352815.bin (size=1048576)
Reading Version Strings...
-> Bootrom Version = embedded in CPU, asume 05.12/05.32
-> EPK = 42/1/ME7.1/5/6005.01//X22kb/Dstf1o/101299/
-> Contents of ECUID data table:
   - '0261206562'         (SSECUHN)
   - '1037352815'         (SSECUSN)
   - '4B0907551L  '       (VAG part number)
   - '0004'               (VAG sw number)
   - '2.7l V6/5VT     '   (engine id)

-> No errors found. File is OK.   *********************


Edit : I am an idiot.

Hard to get to a point, but in general, you have to analyze the code of the image to find all the information  .
At first step you have to (manually) disassemble the code of different images, then find
what is similar between all images.  After this, you can determine matching patterns to
locate the code/tables you want to find in any image.
Since there are only two bootrom main streams used on ME7, you can find some
addresses which get used in all images. For example, there is a pointer variable in RAM
at E242/E244 for the 05.XX bootroms which is set to point to the ecu identification table
in flash. If you locate the code where this pointer gets set, you can extract the table address
out of the code, for example:
82'0224: E6F41E2F       MOV     R4, #ECUIdentificationDataTable ; == 81'AF1E
82'0228: E6F50602       MOV     R5, #0206h (81'8000)
82'022C: F6F442E2       MOV     [ptr-ECUIdentificationDataTable], R4   
82'0230: F6F544E2       MOV     [00E244h], R5
Then you can parse the table and extract the identification strings, here is an excerpt of this table:
ECUIdentificationDataTable:
81'AF1E: 0000   DW      0000h                   ; len = 0, tag = 00
; [90] = VIN
81'AF20: 0000   DW      0000h                   ; ptr = NULL
81'AF22: 0000   DW      0000h
; [91] = VMECUHN
81'AF24: 0600   DW      0006h                   ; len=0, tag = 06 (ascii)
81'AF26: 0000   DW      0000h                   ; ptr = NULL
81'AF28: 0000   DW      0000h
; [92] = SSECUHN
81'AF2A: 060A   DW      0A06h                   ; len = 10, tag = 06 (ascii)
81'AF2C: B203   DW      03B2h                   ; ptr = 81'83B2 (string_SSECUHN)
81'AF2E: 0602   DW      0206h
; [93] = SSECUHVN
81'AF30: 0000   DW      0000h
81'AF32: 0000   DW      0000h
81'AF34: 0000   DW      0000h
; [94] = SSECUSN
81'AF36: 060A   DW      0A06h                   ; len = 10, tag = 06 (ascii)
81'AF38: BC03   DW      03BCh                   ; ptr = 81'83BC (string_SSECUSN)
81'AF3A: 0602   DW      0206h
....
For checksums it is basically the same. Partly there are fixed memory locations to look at
in all images or there are fixed patterns which you can search to find them.
For the data checksums you need to locate the checksumming function and then look into
the code to find out which type of checksum algorithm is done and which memory ranges are used.
At least I found the ranges only embedded in the code.  A table-based method as brought up in the thread
http://www.nefariousmotorsports.com/forum/index.ph/topic,353.msg2216.html#msg2216
I could not find in the code.

Hi Julex,

I looked up the addresses of the M-box, checksums are located at following fileoffsets:
0x08038 - 0x0803F
0x1B9B0 - 0x1B9B3
0x1FBB2 - 0x1FFD1
0x7A866 - 0x7A875
0xFFFE0 - 0xFFFE7

Great idea, this will make it much easier to distinguish hidden changes like shifted maps. But, aren't there about 70 checksums on the 1Mb flashes? That's what I recall from other series of posts and from my conversation with MTX Electronics when I bought their plugin.

Next epic question. Using IDA, what a correct entry point for M-box?

XDF with these locations defined is attached. Thanks for the info!