technic
Full Member
Karma: +18/-5
 Offline
Posts: 227
|
 |
« Reply #45 on: November 12, 2014, 12:48:59 PM »
|
|
|
I have tested some more: Immo status 1 using E2PA with only eeprom changes (but original flash) for A6 TFSI, A3 TFSI and S3 TFSI. So these works ok.
With your original eeprom+flash I also get 005642, checksum error on my ecu, without running it thru any tool.
I have a 4F2 907 115 on the bench, yours is a 1K0 907 115 - unsure if that matters.
Your eeprom seems to be somehow different. I need to investigate this more.
To clarify - this is the ori eeprom? Tom eeprom immo on With E2PA 2.0.0 CS Correction.rar
|
|
|
|
« Last Edit: November 13, 2014, 02:26:53 AM by technic »
|
Logged
|
|
|
|
MK2-VRT
Full Member
Karma: +2/-10
Offline
Posts: 131
|
|
« Reply #46 on: November 12, 2014, 01:08:22 PM »
|
|
|
Hmm okay,
Yes, that eeprom file is the Original from that ecu..
Flash is Original and not changed.
I test with your tool and other tfsi file with the same no, but also no succes..
In this file is only 2 bits changed + checksums ?
I have 3 more eeproms files from the same ecu no, only different year ( 2005 - 2008 ) and al these files are complete different.
So i dont know where the immo is stored.
When you make me first file ( Tom eeprom immo on with E2PA ) off with your tool, your file is the same as mine ?
Thanks for helping..
|
|
|
|
|
Logged
|
|
|
|
|
|
technic
Full Member
Karma: +18/-5
Offline
Posts: 227
|
|
« Reply #48 on: November 13, 2014, 01:48:15 PM »
|
|
|
thank you for this great app   @MK2-VRT : Yes, they are identical. I'm unsure if this is some kind of encryption. @dd : Do you know if 4F2 and 1K0 differs hw wise? |
|
|
|
|
Logged
|
|
|
|
MK2-VRT
Full Member
Karma: +2/-10
Offline
Posts: 131
|
|
« Reply #49 on: November 14, 2014, 04:14:28 AM »
|
|
|
I'm curious about what the problem is..
@All other people that used this tool, did you see all a 1 in ch91 ( 01-Engine / 10-Adaptation )
|
|
|
|
|
Logged
|
|
|
|
MK2-VRT
Full Member
Karma: +2/-10
Offline
Posts: 131
|
|
« Reply #50 on: November 21, 2014, 10:40:55 AM »
|
|
|
Today i'v another TFSI ecu, From BWA engine, The same ecu nr as before ( 1K0 907 115 )
I load the eeprom file and do immo off, solder it back, test is with VCDS and voila, works great.
I dont understand why that other ecu dont work in eeprom..Sie post above..
|
|
|
|
|
Logged
|
|
|
|
technic
Full Member
Karma: +18/-5
Offline
Posts: 227
|
|
« Reply #51 on: November 23, 2014, 03:59:58 PM »
|
|
|
Glad it worked. Will try to find some time to dig in to the previous problem also.
|
|
|
|
|
Logged
|
|
|
|
Shaheenem
Newbie
Karma: +1/-0
Offline
Posts: 2
|
|
« Reply #52 on: February 19, 2015, 12:09:19 AM »
|
|
|
Great tool technic!
I especially like the edit inventory feature! Used it to code the new ECU i replaced on a car using the VCDS coding.
Thanks again. Great work. Keep it up!
|
|
|
|
« Last Edit: February 19, 2015, 12:12:07 AM by Shaheenem »
|
Logged
|
|
|
|
technic
Full Member
Karma: +18/-5
Offline
Posts: 227
|
|
« Reply #53 on: March 26, 2015, 03:02:19 AM »
|
|
|
New small uppdate of the E2PA tool. Now NOREAD tag is automatically applied and the FLASH checksums are corrected for the patches made by the tool. (It will NOT checksum a complete binary) Update is here : http://nefariousmotorsports.com/forum/index.php?topic=5833.msg54763#msg54763Also looking for info/hints about RSA checksumming in MED9. What algorithm is used, what ranges are checksummed etc. For now I'm assuming it's the same as ME7. I'm also trying to figure out what checksums are calculated below. I understand HOW it is calculated but the range doesn't make sense. 001c33c0h: 00 5C 2E 00 00 5C 33 BF 00 BF FC 90 FF 40 03 6F 001c33d0h: 00 5C 20 00 00 5C 22 3F 00 BC 90 28 FF 43 6F D7 001c33e0h: 00 5C 2E 00 00 5C 7F FF 0A 1B 3F 8D F5 E4 C0 72 ... It seems to checksum from address 5C2E00 to 5C33BF, which appears to be outside FLASH area. |
|
|
|
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
Offline
Posts: 192
|
|
« Reply #54 on: March 26, 2015, 03:19:42 AM »
|
|
|
Excellent work!
Does this help at all? It's an extract from an MED9.1 *.a2l file (they're all the same in this respect).
Basically I understand it to mean that the data at 0x1C2000 (size 0x2E000) is 'mounted' at 0x5C2000. So when working with the data, the processor should look at 0x5C2000. But it's one and the same as 0x1C2000.
/begin MEMORY_SEGMENT Dst1C2000 "" DATA EPROM EXTERN 0x1C2000 0x2E000 -1 -1 -1 -1 -1
/begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x902000 /*length:*/0x2E000 /end IF_DATA
/begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*length:*/0x2E000 /end IF_DATA
/begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*length:*/0x2E000 /end IF_DATA
/end MEMORY_SEGMENT
|
|
|
|
|
Logged
|
|
|
|
technic
Full Member
Karma: +18/-5
Offline
Posts: 227
|
|
« Reply #55 on: March 26, 2015, 03:32:17 AM »
|
|
|
That is a good find! It seems to cover parts of the calibration protocol firmware. Very interesting! Will do some tests this afternoon Thanks a lot David. I need to read more in the a2l files it seems |
|
|
|
|
Logged
|
|
|
|
technic
Full Member
Karma: +18/-5
Offline
Posts: 227
|
|
« Reply #56 on: March 26, 2015, 11:40:55 AM »
|
|
|
You were correct Calculating cs:es from 0x1C2000 for each of the 6 segments are correct. And I found two additional checksums too Now I'm stuck at this : 38 21 00 08 4E 80 00 20 01 36 19 80 FE C9 E6 7F Again, this is out of flash area. |
|
|
|
« Last Edit: March 26, 2015, 11:44:53 AM by technic »
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
Offline
Posts: 192
|
|
« Reply #57 on: March 26, 2015, 01:46:41 PM »
|
|
|
38 21 00 08 is instruction "addi r1, r1, 8" (restoring the stack aka popping the stack) 4E 80 00 20 is instruction "blr" (jumping back to the calling function) Basically it looks like the tail end of some function. 01 36 19 80 FE C9 E6 7F is pretty random though and doesn't translate to any opcodes. I'd say you could ignore the addi & blr maybe and just concentrate on 01 36 19 80 FE C9 E6 7F ? Here's a similar thing in a bin I had open in IDA: 
|
|
|
|
|
Logged
|
|
|
|
technic
Full Member
Karma: +18/-5
Offline
Posts: 227
|
|
« Reply #58 on: March 26, 2015, 02:19:47 PM »
|
|
|
Yes, true. I'm disassembling it now to try to understand where comparison of the 01 36 19 80 takes place.
The cs:es I have found so far are built up according the pattern :
AA AA AA AA BB BB BB BB XX XX XX XX YY YY YY YY
where
AA = Start address
BB = End address
XX = Calculated Checksum
YY = !Calculated Checksum
So in this case, even if the start and stop address is elsewhere, I'm pretty sure the 01 36 19 80 is part of a checksum (and FE C9 E6 7F - its negated part)
|
|
|
|
« Last Edit: March 26, 2015, 02:23:21 PM by technic »
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
Offline
Posts: 192
|
|
« Reply #59 on: March 27, 2015, 06:42:21 AM »
|
|
|
Hi Lars,
I had another look and there’s actually a reference in code to the start of that checksum. IDA doesn’t immediately show it as a cross-reference, but a bit of detective work tracked it down
In my random bin, the checksum in the picture I attached is at memory location 0x4BA284. No convenient cross-references in IDA, but if you use the search function (search sequence of bytes) and look for just A284, you’ll find this instruction:
3D 40 00 0C lis r10, 0xC
81 4A A2 84 lwz r10, -0x5D7C(r10)
The above instructions refer to memory location 0xCA284. You can ignore the 0x400000 offset, since that just the way I loaded up IDA and I’ve seen many times before the 0x10000 offset (B vs C), just the way it is.
|
|
|
|
|
Logged
|
|
|
|
|
