|
nyet
|
 |
« Reply #30 on: January 01, 2013, 06:12:36 PM »
|
|
|
HRPMPH... the values aren't matching up.. here is what i have zone 1: calc=0x412a5cc2 read=0x214cd272 zone 2: calc=0x0d75b941 read=0x17b90f53 zone 3: calc=0x8bcc3b89 read=0x7de91383 AH nvm ETA: those are non-inclusive ranges?  zone 1: calc=0x214cd272 read=0x214cd272 zone 2: calc=0x17b90f53 read=0x17b90f53 zone 3: calc=0x7de91383 read=0x7de91383 |
|
|
|
« Last Edit: January 01, 2013, 06:15:50 PM by nyet »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #31 on: January 01, 2013, 06:17:35 PM »
|
|
|
Not sure how we're going to autodetect those ranges... going to need prj's help for that.
For now i'll hard code them into my .ini
|
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
 Offline
Posts: 235
|
|
« Reply #32 on: January 01, 2013, 06:35:36 PM »
|
|
|
Hardcoded. I did some coding and logging to confirm as well.
Q. Did you check this against the stock 360 firmware I uploaded? (uploaded in the firmware section?) Here.. http://nefariousmotorsports.com/forum/index.php?topic=2992.0title=...These boundaries quoted don't seem to map against any regions and obvious boundary ends like the end of a block of 'ff ff ff's and start of '00 00 00's. Also the check code addresses quoted are filled with ff's in my dumped image when I looked, not a CRC32 routine or any C16x assembly. What's the physical byte offset where the checksums are done? I will reverse it if need be... |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #33 on: January 01, 2013, 07:00:57 PM »
|
|
|
Those are specific to S4 2.7t mbox
have you had a chance to check out my code?
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #34 on: January 01, 2013, 07:30:06 PM »
|
|
|
What i dont get is that ALL the multipoint checksums are stored in one of the blocks checked by the multipoint checksum itself!
i.e. M-box multipoint is stored from 0x1fbd2-0x1ffc2, which is in block #8 (0x1c000-0x1ffff)...
so how does one set up the checksums for that block, if the checksum itself is included in its own checksum area?
or am i missing something?
Also, i see that the main checksum is stored at fffe0, which is in the block 64 (fc000-fffff).. but thats ok, i can store that first, before doing multipoint, since the main checksum doesn't cover the multipoint area.
|
|
|
|
« Last Edit: January 01, 2013, 07:33:03 PM by nyet »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #35 on: January 02, 2013, 12:30:21 AM »
|
|
|
Oh well. I am going to ignore it since it seems to magically work! I have just finished the part which actually corrects the binary image. * I ONLY HAVE CRC LOCATIONS FOR MBOX * The checked in code works under linux and cygwin. Currently trying to get a build working for windows using visual studio If you have linux or cygwin, please try it out! https://github.com/nyetwurk/ME7Sumprj, i could use your help figuring out how to autodetect stuff. I am pretty sure I can auto-detect the multipoint descriptors by pattern (they're obvious) The main checksum ones are also kind of easy (at least the block descriptors.. the checksum location might be harder to detect) The hardest part will be finding the CRC locations. ** MAKE A BACKUP OF ANY IMAGE YOU RUN THROUGH THIS! it does not make a backup of your image.. it modifies it in place! ** |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #36 on: January 02, 2013, 05:35:41 AM »
|
|
|
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
Which software revision are you referring to? M-Box? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #37 on: January 02, 2013, 05:38:11 AM »
|
|
|
Never mind, I see it.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #38 on: January 02, 2013, 05:42:57 AM »
|
|
|
Ok so I checked a few different images.
The locations are mostly the same, but in some there are 3, in some there are 4 and the 29F400 ones are a different story.
But I think I can come up with an algorithm to detect these fairly reliably...
But really for this tool to be any good all the checksums have to be found via pattern search.
Per-ECU revision ini files will make it completely useless as a real tool.
|
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #39 on: January 02, 2013, 06:42:26 AM »
|
|
|
Ok so I checked a few different images.
The locations are mostly the same, but in some there are 3, in some there are 4 and the 29F400 ones are a different story.
But I think I can come up with an algorithm to detect these fairly reliably...
But really for this tool to be any good all the checksums have to be found via pattern search.
Per-ECU revision ini files will make it completely useless as a real tool.
prj, Could you do me a huge favour and see if you can see the checksum locations in the 360 dump I posted? Also i've re-merged the changed back in and got it re-working under Mingw again in a win32 environment. All sync'd back into github. |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #40 on: January 02, 2013, 06:46:21 AM »
|
|
|
Per-ECU revision ini files will make it completely useless as a real tool.
Agreed, just too many variations on location otherwise, a different config for every rom would be very silly. |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #41 on: January 02, 2013, 08:38:41 AM »
|
|
|
nyet... I've done a few changes to your work as it no longer compiled under Win32 mingw env.
At first I managed to find an emulation/remapping function for mmap() [since this isn't part of MinGW and isn't supported natively by Windows without remapping to other api call equivalents under the nt kernel libs]. While this WORKED and is simple enough to do I didn't realize it actually caused infection with a bloody GPLv2 license so I have now completely removed it all, and replaced with simple memory loader/save functions. So its back to BSD compliant again. The happy consequence of this is it continues to works across multiple platforms again now (ones without mmap() support, i.e. non linux environments) as its using simple stdio read/writes.
Also I have updated the cli arguments now to specify a destination for the crc updated file. This now means it does NOT overwrite your original rom file so you are free to compare the diffs now with my bdiff tool (or other linux equivalent tool).
Trev
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #42 on: January 02, 2013, 09:06:20 AM »
|
|
|
prj,
Could you do me a huge favour and see if you can see the checksum locations in the 360 dump I posted?
The routines are completely different in this ... I am looking though. |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #43 on: January 02, 2013, 09:14:03 AM »
|
|
|
The routines are completely different in this ...
I am looking though.
Thx! Very much appreciated!  |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #44 on: January 02, 2013, 09:22:20 AM »
|
|
|
Thx! Very much appreciated! Not familiar at all with other variants of ME7 other than VAG. I could not find any similar routines in 10 minutes. The routines for the CRC checksumming in the VAG ECU's are in the flash, not in the processor ROM. I don't know how this is solved on the Ferrari ECU. It is possible it has the CRC check, but implementation can be completely different. Or maybe I am just blind. |
|
|
|
|
Logged
|
|
|
|
|
