NefMoto > Technical > Flashing and Chipping > Open Source Checker for ME7...
Pages: 1 [2] 3 4 ... 10
« previous next »
Author Topic: Open Source Checker for ME7...  (Read 94163 times)
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #15 on: December 30, 2012, 05:07:56 PM »
oh, also the .dll

i'll be working on the makefile as well. i'll be targeting cygwin/gcc and linux initially.

I'm sure i can get cygwin/vc working, but i dont want to deal with nmake etc. so ... i hope that isn't an issue going forwards. if people really want a vc/msvs environment, i figure they're on their own and can deal with it themselves.

also cloned your tree and opened a pull request for a few things.

Thanks so much for making the source available, I've been waiting a long time for an excuse to get a proper checksummer.
Logged
ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

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

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #16 on: December 30, 2012, 08:33:43 PM »
Here is what i have for C-box (from andy's site)

Code:
[ignition]
# main rom checksumming
rom_firmware_start=0x800000
rom_checksum_block_start=0x1fc20
rom_checksum_block_len=0x10
rom_checksum_offset=0x01bfe6
rom_checksum_final=0x07ffe0

# boot sector validation
rom_boot_Startaddr=0x00800000
rom_boot_Endaddr=0x00803fff
rom_boot_Chksum=0x0fd90a11
rom_boot_InvChksum=0xf026f5ee

Here is what i have for mbox

Code:
[ignition]
# main rom checksumming
rom_firmware_start=0x800000
rom_checksum_block_start=0x1fbd2
rom_checksum_block_len=0x10
rom_checksum_offset=0x01e75a
rom_checksum_final=0x0fffe0

# boot sector validation
rom_boot_Startaddr=0x00800000
rom_boot_Endaddr=0x00803fff
rom_boot_Chksum= 0x0ff728a4
rom_boot_InvChksum=0xf008d75b
my clone is here

https://github.com/nyetwurk/ME7Sum
« Last Edit: December 30, 2012, 09:25:30 PM by nyet » Logged
ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

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

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #17 on: December 30, 2012, 10:01:32 PM »
Question: why is the rom boot checksum hardcoded in the ini? the m box location (for example) appears to be at 1fbda in the multipoint area..

is that just a sanity check?

Also, is there code for the rolling XOR crc32? it is missing from your code (and obviously andy's)

Code:
The ME7.1 also contains a 3 stage CRC32 based checksum.

For each address range, the ME7.1 uses the following algorithm:

    Create a 32bit rolling checksum variable and initalise it with 0xffffffff

    FOR(STARTADDRESS TO ENDADDRESS)

    1    read byte at current address
    2    XOR the value in (1) with the LSB of the rolling checksum
    3    shift left by two bits the value (2)
    4    use (3) as an offset to the address of XOR Seed table within the ECU
    5    read the 32bit value referenced by this address
    6    shift right the rolling checksum by 8 bits
    7    XOR the value from (5) with that from (6)
    8    store this value (7) as the rolling checksum

    ENDFOR

    After the address range is calculated, invert the rolling checksum to give you the final XOR checksum.

This is the very well known crc32 algo. Andys' analysis is rather silly, since it can be summarized as:
Code:
while (size--)
                crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8);


Also, see this thread: http://www.nefariousmotorsports.com/forum/index.php?topic=343.0

I have the CRC code written (including reading the seed table, which is pointless, since they are known constants) but i can't figure out what blocks to apply it to, and where the values are stored... can anybody help?
« Last Edit: December 31, 2012, 12:58:56 AM by nyet » Logged
ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

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 experience.
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235
« Reply #18 on: December 31, 2012, 08:05:46 AM »
Wow, you've been busy!

Great work.

I'd not even remembered about this pesky CRC checksum.

I am very familiar with CRC's having used them a lot before. The easiest way to detect their position is to take a known dump and simply modify some bytes at various points and then got some to use a working tool to re-calculate the crc's. Then all thats required is a binary 'diff', you'll easily identify the bytes which changes (and where re-calculated). These will be a very good starting point to derive the address ranges used too.

Alternatively (more work) from the other threads people quote addresses of the functions in the machine code,  if you provide me with exact firmware they where talking about (or point me to the location to d/l it) I'll fire up the old C16x dissassembler and reverse it.

T
Logged
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235
« Reply #19 on: December 31, 2012, 11:10:25 AM »
Just added another VERY simple open source project. Bdiff to my git repositories.

https://github.com/360trev/bdiff

Quite simply this is a VERY simple tool written in 5 minutes. It can be used to generate difference reports for checksum calculated files. I.e. If you have the file with a bad checksum and then get it corrected by a checksum tool you can see the byte offset in the file and the differences it made.

This is a great start to understand exactly what bytes where changed when a checksum has been calculated by some other tool.

Best way to use this is take 2 files from the requests for checksums folder and run it on them. You will see the exact bytes that have been changed. Also attached initial checked in version with compiled for win32 (windows cli) to this reply for people whom don't have a toolchain installed and just want to use the app from the CLI.
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #20 on: December 31, 2012, 11:14:22 AM »
Still can't work out the purpose of the rom boot checksum in the ini... can I remove it? Or omit it for files that already have it as part of the multipoint checksum?

thanks for your work, btw!
Logged
ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

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 experience.
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235
« Reply #21 on: December 31, 2012, 11:17:13 AM »
yep. It was originally just to validate the boot before proceeding further.. by all means knock yourself out..

Here's an example of the bdiff tool I just wrote against 2 files from the checksum requests folder...
---
The original 2 files (chosen at random from that folder, both 1mb each)
http://nefariousmotorsports.com/forum/index.php?topic=2665.0title=

And the output...

binary difference tool - 0.1
Last Built: Dec 31 2012, Time: 18:37:46

þ Opening 'My_Stock_B_BOX_ECU_Firmware_EMISSION_DELETE.bin' file
þ Getting length of 'My_Stock_B_BOX_ECU_Firmware_EMISSION_DELETE.bin' file
þ Allocating buffer of 1048576 bytes
þ Reading file to buffer
þ Validating size correct 1048576=1048576
þ Closing file

þ Opening '8D0907551B - 0261206109 - 352738 CRC corrected' file
þ Getting length of '8D0907551B - 0261206109 - 352738 CRC corrected' file
þ Allocating buffer of 1048576 bytes
þ Reading file to buffer
þ Validating size correct 1048576=1048576
þ Closing file


0x0001fc1a (  130074): be -> c3
0x0001fc1b (  130075): b4 -> 81
0x0001fc1e (  130078): 41 -> 3c
0x0001fc1f (  130079): 4b -> 7e
0x0001fc3a (  130106): 25 -> 1c
0x0001fc3b (  130107): c1 -> 7c
0x0001fc3e (  130110): da -> e3
0x0001fc3f (  130111): 3e -> 83
0x0001fc4a (  130122): 86 -> 2f
0x0001fc4b (  130123): fe -> e0
0x0001fc4c (  130124): d7 -> d9
0x0001fc4e (  130126): 79 -> d0
0x0001fc4f (  130127): 01 -> 1f
0x0001fc50 (  130128): 28 -> 26
0x0001fd9a (  130458): e1 -> d8
0x0001fd9b (  130459): b6 -> 50
0x0001fd9c (  130460): 86 -> 85
0x0001fd9e (  130462): 1e -> 27
0x0001fd9f (  130463): 49 -> af
0x0001fda0 (  130464): 79 -> 7a
0x00073ae6 (  473830): be -> 9c
0x00073ae7 (  473831): 4e -> 62
0x00073ae8 (  473832): 14 -> 8a
0x00073ae9 (  473833): ff -> 69
0x00073af2 (  473842): 26 -> f3
0x00073af3 (  473843): f0 -> 7b
0x00073af4 (  473844): 94 -> 6a
0x00073af5 (  473845): b8 -> 48
0x000fffe0 ( 1048544): 13 -> 0a
0x000fffe1 ( 1048545): fa -> 94
0x000fffe2 ( 1048546): 13 -> 12
0x000fffe4 ( 1048548): ec -> f5
0x000fffe5 ( 1048549): 05 -> 6b
0x000fffe6 ( 1048550): ec -> ed

Total byte differences: 34 (22) bytes


þ All Done...
Logged
prj
Hero Member
*****

Karma: +915/-426
Online Online

Posts: 5836
« Reply #22 on: December 31, 2012, 11:20:11 AM »
Once you get this working decently I can make a TPro plugin out of it...
I am worried it might piss off MTX though.
Logged
PM's will not be answered, so don't even try.
Log your car properly.
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235
« Reply #23 on: December 31, 2012, 11:21:43 AM »
Quote from: prj on December 31, 2012, 11:20:11 AM
Once you get this working decently I can make a TPro plugin out of it...
I am worried it might piss off MTX though.

Lol. They've been MILKING this for far too long if I'm totally honest!
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #24 on: December 31, 2012, 11:25:40 AM »
Quote from: prj on December 31, 2012, 11:20:11 AM
Once you get this working decently I can make a TPro plugin out of it...

Yea, for sure. The key question is if you want to autodetect the checksum table locations by pattern recognition, or make a lookup table for the various binaries.

Also, I could use your help finding the CRC tables Smiley
Logged
ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

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 experience.
prj
Hero Member
*****

Karma: +915/-426
Online Online

Posts: 5836
« Reply #25 on: December 31, 2012, 11:33:09 AM »
Pattern recognition... if it was my way of doing it.
Adding every binary based on EPK's is going to drive you insane.
Logged
PM's will not be answered, so don't even try.
Log your car properly.
jibberjive
Hero Member
*****

Karma: +23/-2
Offline Offline

Posts: 536
« Reply #26 on: December 31, 2012, 11:41:15 PM »
I can't do anything but be a cheerleader and say this is awesome. Slowly but surely I'll learn programming/disassembly and hopefully be able to contribute. Until then, I can just say that I appreciate the work.
Logged
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709
« Reply #27 on: January 01, 2013, 05:29:39 PM »
Quote from: nyet on December 30, 2012, 10:01:32 PM
Question: why is the rom boot checksum hardcoded in the ini? the m box location (for example) appears to be at 1fbda in the multipoint area..

is that just a sanity check?

Also, is there code for the rolling XOR crc32? it is missing from your code (and obviously andy's)

Code:
The ME7.1 also contains a 3 stage CRC32 based checksum.

For each address range, the ME7.1 uses the following algorithm:

    Create a 32bit rolling checksum variable and initalise it with 0xffffffff

    FOR(STARTADDRESS TO ENDADDRESS)

    1    read byte at current address
    2    XOR the value in (1) with the LSB of the rolling checksum
    3    shift left by two bits the value (2)
    4    use (3) as an offset to the address of XOR Seed table within the ECU
    5    read the 32bit value referenced by this address
    6    shift right the rolling checksum by 8 bits
    7    XOR the value from (5) with that from (6)
    8    store this value (7) as the rolling checksum

    ENDFOR

    After the address range is calculated, invert the rolling checksum to give you the final XOR checksum.

This is the very well known crc32 algo. Andys' analysis is rather silly, since it can be summarized as:
Code:
while (size--)
                crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8);


Also, see this thread: http://www.nefariousmotorsports.com/forum/index.php?topic=343.0

I have the CRC code written (including reading the seed table, which is pointless, since they are known constants) but i can't figure out what blocks to apply it to, and where the values are stored... can anybody help?

This should be accurate...

Check zone 1:
Addresses 0x810002 - 0x813FFF
176 bytes at a time + remaining 13
Checked at 0x87A866

Check zone 2:
Addresses 0x814252 - 0x817F4F
176 bytes at a time + remaining 125
Checked at 0x87A86C

Check zone 3:
Addresses 0x818192 - 0x81FBB1
176 bytes at a time + remaining 111
Checked at 0x87A872
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #28 on: January 01, 2013, 05:49:32 PM »
Wow. That is rather bizarre. Are those read from a descriptor someplace, or hardcoded?
Logged
ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

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 experience.
phila_dot
Hero Member
*****

Karma: +171/-11
Offline Offline

Posts: 1709
« Reply #29 on: January 01, 2013, 06:05:15 PM »
Quote from: nyet on January 01, 2013, 05:49:32 PM
Wow. That is rather bizarre. Are those read from a descriptor someplace, or hardcoded?

Hardcoded. I did some coding and logging to confirm as well.
Logged
Pages: 1 [2] 3 4 ... 10
  Print  
« previous next »
 
Jump to:  

Navigation
Personal Tools
  • April 19, 2024, 02:32:20 PM
  • Welcome, Guest. Please login or register.
    Did you miss your activation email?

    Login with username, password and session length
Search
 
Advanced Search
About Disclaimer
All Rights Reserved 2010 Nefarious Motosports
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.041 seconds with 16 queries. (Pretty URLs adds 0s, 0q)