Pages: 1 2 [3] 4 5 ... 9
Author Topic: ME7Check: Checksum checker for ME7  (Read 255870 times)
ElementalVoid
Jr. Member
**

Karma: +9/-0
Offline Offline

Posts: 43


« Reply #30 on: March 25, 2011, 03:45:15 PM »

Any chance you could cross compile for ARM? (gnu target: arm-linux-gnueabi)
Try if this works for you.

Works great. Thanks. (both the statically and dynamically linked versions work)
Logged
ElementalVoid
Jr. Member
**

Karma: +9/-0
Offline Offline

Posts: 43


« Reply #31 on: March 25, 2011, 03:50:46 PM »

Has anyone used an SCM to manage binary files before? If so, maybe you've had better luck with another system?

If i find i *really* need to maintain a binary in an SCM, I try to find a process by which i can generate that binary using some sort of text-based instructions, which CAN be maintained in a sane fashion.

For example, start with a stock binary, and come up with a document that can describe (in plain text - e.g. table tag, offset, value difference, etc) the changes you wish to make to it.. make a tool that can apply those changes, and just keep the change document in the SCM.

Anything else is foolishness IMO, since the diffs will never make any sense.

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.
Logged
nyet
Administrator
Hero Member
*****

Karma: +607/-168
Offline Offline

Posts: 12270


WWW
« Reply #32 on: March 25, 2011, 03:55:08 PM »

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.

IMO, if you don't need to worry about useful diffs or merging, any SCM is as good as another for just revision tracking of binaries Smiley

I agree that tracking revisions alone is a great reason to use an SCM...
Logged

ME7.1 tuning guide
ECUx Plot
ME7Sum checksum
Trim heatmap tool

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
phila_dot
Hero Member
*****

Karma: +173/-11
Offline Offline

Posts: 1709


« Reply #33 on: March 26, 2011, 08:47:54 PM »

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.
« Last Edit: May 20, 2011, 12:53:01 AM by phila_dot » Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +132/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #34 on: March 28, 2011, 05:40:28 PM »

Setzi, can you share some info on how you find all of the information in the bin and how you locate the checksums?
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #35 on: March 29, 2011, 09:33:53 AM »

Hard to get to a point, but in general, you have to analyze the code of the image to find all the information  Tongue.
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.
Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #36 on: May 06, 2011, 08:43:06 PM »

can you let me know offsets for all checksums in 8d0907551M S4 M-box file so that I can set up them as known maps in Tunerpro. I am trying to compare bins and some of the regions I suspect to be checksums but I am not sure.

PM me if possible,

Thanks.
Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #37 on: May 09, 2011, 01:19:39 AM »

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
Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #38 on: May 09, 2011, 07:21:44 AM »

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


Thank you!
Logged
ElementalVoid
Jr. Member
**

Karma: +9/-0
Offline Offline

Posts: 43


« Reply #39 on: May 09, 2011, 08:33:05 AM »

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.
« Last Edit: May 10, 2011, 01:12:10 PM by Tony@NefMoto » Logged
mtx-electronics
Full Member
***

Karma: +11/-1
Offline Offline

Posts: 66


WWW
« Reply #40 on: May 09, 2011, 11:14:31 AM »

Yes, normally on 1MB files there are slightly more then 70 checksums but on this file I can only find very few... I have no idea where all the checksum locations are in this file because my automatic checksum search routines can't find them.
Logged
julex
Hero Member
*****

Karma: +79/-4
Offline Offline

Posts: 923


« Reply #41 on: May 09, 2011, 11:34:59 AM »

Next epic question. Using IDA, what a correct entry point for M-box?
Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #42 on: May 10, 2011, 12:55:03 AM »

All checksums are contained in the memory ranges that I posted.
Some of the memory ranges contain multiple checksums, therefore
there are only five different ranges for all the checksums.

Regarding disassembly using IDA, there are some threads in Reverse Engineering
handling this. Tony described settings of addresses and DPP registers in
http://www.nefariousmotorsports.com/forum/index.php/topic,35.msg976.html#msg976

As bootrom file you can also use this file that Tony posted once
http://www.nefariousmotorsports.com/forum/index.php?action=dlattach;topic=198.0;attach=214
or you take the first 32kB of an 1.8T flash file which shows bootrom version = 05.12 in ME7Check.
This is a copy of the bootrom file, you load it with address 0x000000, the flash file with adress 0x800000.
Processor starts working at address 0 in bootrom after reset.
But I don't think you can give just one start address and then IDA automatically detects all
code sections. Lot's of the code gets called via pointers found in data sections.
Logged
ElementalVoid
Jr. Member
**

Karma: +9/-0
Offline Offline

Posts: 43


« Reply #43 on: May 20, 2011, 12:20:04 AM »

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

XDF with these locations defined is attached. Thanks for the info!
Logged
hot2trot
Newbie
*

Karma: +3/-0
Offline Offline

Posts: 19


« Reply #44 on: May 22, 2011, 02:07:40 PM »

Hi setzi62 ,

Think I must be an Idiot !
I have all the files in my home directory but when i run the ME7Check tool in cmd "ME7Check.exe nameofmyfile.bin" It lists the version 1.08 and date and the next command line Usage: ME7Check <bin-file> and thats it !
There is no info about the bin file i wish to  check.

Please advise,
Cheers
Logged
Pages: 1 2 [3] 4 5 ... 9
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.029 seconds with 17 queries. (Pretty URLs adds 0s, 0q)