NefMoto

For those of us that like the correct vin's in our immo-off'd ebay ecus!

Free for personal use.

Usage is the same as ME7sum, and 95040sum:

MED9sum [input.bin] [output.bin]

Failure to specify output will result in the file being named [input]-CHKOK

Thanks go out to Mazer for making this happen, and n0ble for reigniting my interest in the project.

Excellent work ddillenger, you are a true credit to this forum :-)

so true! :D

Just tested on my Serial E2Prom and it works a treat.

Very nice work  ;D

plus 1 to both of you!

Nice work, ddillenger. For those of you who prefer a GUI, I made a similar tool a couple of years ago. Maybe it could be useful for someone  :)
It has a few additional functions also, but I developed it for the sole purpose of checksum correction.

Software is attached here. No install, just an executable. Note that this is still under development and probably full of bugs. But checksum correction is well tested ;)

License is free for personal use.

V1.0.0 - First version. (eeprom.exe)

V1.0.1 - Corrected bug in checksum calculation. Appears it wasn't so well tested after all :)
         - Improved file and error handling
         - Minor GUI fixes

V1.0.2 - Corrected checksumming for 2k size

V1.1.0 - Released IMMO OFF. (Beta)

V2.0.0 - Immo off now only needs EEPROM. (Thanks to forum member for info)
         - OBD Read protection added. This stops most tools from reading over OBD.
         - Bugfix. 7:th byte in component protection was sometimes erroneously marked as not available.
         - Bugfix. Donation now shows correct amount.

V2.1.0 - Added NOREAD tagging when running OBD read protection
         - Now FLASH checksum for OBD protection and NOREAD is calculated (BETA)
         - Bugfix in IMMO off.
        
V2.1.1 - Added 8 new checksums
         - Improved detection of cs block start to cover more software versions
         - Some improvments to error handling
         - Small GUI updates

a+

github project? :)

Also, any chance you guys can help me fix ME7Sum :(

Yes im very interessted to create a universal me7sum tool (for flash).
me7sum tool for eeprom we already have done, if you want i can share it here.

No i mean my ME7Sum (flash, not eeprom) still has some limitations I have not figured out.

I have adopted the role of Mazer's secretary :P

I clarified for you.

excellent  :)

I'll consider github. If I can find the time I'll have a look at ME7Sum also.

You have MED9 e2p immo off right? If you're interested in adding it, PM me.

Hello guys, just checked the GUI version of this with a med9.1.1 eeprom and it says that all checksums were corrected but when I save the file it stays just like ori.... If you need any other info for debugging just let me know.
About med9sum.exe I tried with the same file and the output made the file 1Kb longer/bigger. Eeprom is 95160.
I´m attaching the ori file.

Regards.

Here the ori file and the result using med9sum.

Regards.

Yes, there is a bug in the GUI version :/ I'll fix and upload new version.

Great, I´ll be glad to test again ;)

Cheers.

Diego, Please post the file you used for testing the GUI version. I cannot reproduce error.

Edit:

Never mind. I assume your changes was made to a higher address than 0x280...
E2PA (GUI Tool) didn't correct checksums from 0x280 (Block1) and 0xA80 (Block2) and forward, because these areas are not used by the E2PA program itself.
 
I have corrected this bug and a few other bugs. Now _all_ checksums are corrected. Thanks for the heads up!

New version : http://nefariousmotorsports.com/forum/index.php?topic=5833.msg54763#msg54763

Haven't noticed this thread until now. Have a spare MED9.1 ECU from Ebay won today and will be playing with immo off, so it will definitely be needed. Thanks!

Hello technic, thanks for following up, I just downloaded the new version (1.01)and run the checksum correction... the output file is still the same as ori... I´m attaching both files before and after and a few screenshots, hope it helps.

Regards.

Hmm.. yes indeed. There is something fishy when file is 2k. Will check now.

About immo off for MED9.1 I share this 2 files that proved to work, they have not been made by me, I just looked at it and saw that data was changed from 6C00h to 6FFF in flash and  42h to 7Fh in eeprom. I´ll let some of the more experienced find out and hopefully share the findings.

Regards.

The error with 2k files is now corrected, and I have decided to release the (or at least one way to do it) IMMO OFF solution as well since it is open to the public anyway. Still beta version. Please report if it works or not for you.

Sorry for hijacking your thread, ddillenger  :-\

Ok, now seems not to mess with the file, not sure if this used to be a file with P0601 error on it (my bad not to save it with the filename), but chcks seem to be fine now.
About the inmo, sorry, not sure if it was not supposed to be released or was taken care of in another thread...

Cheers-
Diego.

No hijack, this is awesome.

Thanks for this software. When one tries removing immo, there is a warning that flash checksums will remain uncorrected. If I load the immo-off flash into winols as a version of the stock file, the immo-off section is readily visible as modified but winols says there are no checksums for this section of the flash. My winols does correct checksum when I edit maps for example. Is there really no checksum required for this immo data? I thought the entire flash would have a checksum.

This is for the eeprom, not the flash.

I'm not sure if I understand you, but eeprom1.1.0 by technic modifies both flash and eeprom but does checksums only for the eeprom. I was under the impression both flash and eeprom needed modification to remove the immobilizer. If so, why does winols behave as described in the previous post when I try to correct the immo section that's been modified in flash?

You are wrong :P


It probably gives you a message about the virtual eeprom.

As dd says, there is a way to disable the immo by eeprom only - but I haven't found out how yet, so I had to make it possible to load the actual flash also for the time being, so the name of the program is a bit misleading atm  :-\

I don't recall the immo area in flash being covered by any checksum, but I will check that later tonight. The warning is there as a reminder. You cannot - for example - make a tuning file, de-immo it in this software and expect the checksums to be corrected.

Also,  read protection needs a couple of flash changes. Don't think that it is doable in eeprom only. So, maybe this software will change name or split into two different softwares. Have to think a bit about that

If anyone have info about eeprom immo off, you are welcome to pm me 8)

Never heard of immo off through eeprom only, but with immo off file (flash), there´s no checksum error, so probably the checksum block that the MCU looks for is only for maps related to engine control, not sure if I´m clear enough.
I´ve used the above method for immo off and never had any problems with checksum. WinOLS has it covered pretty well, so if no check correction is made, you can trust it.

Regards,
Diego.

Thanks for the clarification folks!

E2PA is now version 2.0.0.

See : http://nefariousmotorsports.com/forum/index.php?topic=5833.msg54763#msg54763

Have anyone test it to make a MED9.1 immo off in only the eeprom ? If yes, it works or not ?

Why don't you try? VCDS channel 99 ;)

It works ...
Technic from who You have this solution ? DD ?

Does it matter? I would probably have found solution sooner or later myself anyway. But, no, it wasn't dd.

Edit: I didn't mean to be arrogant, but I had an idea how to solve it myself :)

I cant try because i'm not have a MED9.1 at home at the moment.

But whats the solution ?

I have a off file for eeprom and flash, with only that eeprom file it dont work.

End what about ch 99 ?

Do you mean ch 91 ? There you see the immo status..1 for off, 4 = immo on..

Sorry, yes, 91

Tommorow i'v a MED9.1 ecu, i have read the same ecu last week, and have the eeprom file here.

I have load the file into the version 2.0.0 and save it.

Tommorow i load the 'eeprom off' file into the ecu and check ch 91 with vcds ( I dont have te car for real testing ).

I let you now guys..

In Att

1) Original file from ecu
2) Eeprom off from E2PE 2.0.0
3) Eeprom off file Winols
4) Flash off file Winols

3 and 4 works also, but now i will test it wih 2) only in eeprom..

Your immo off files, flash+eep must be used together. eep file from E2PA will be enough for immo off, doesn't matter what flash you use.

 

I would be great if this work, i report tomorrow  ;D

I test and not working..

Immo status ch 91 : 4 ( Immo on )

Also DTC 005642 Checksum error and 005696 eeprom faulty.

Ori eeprom is 1) ( post above ) and eeprom off 2)

Is the checksum not correct or ... ??

Works for me. I'll check your file soon

Thx mate..

I have tested with this file in att..

Also Immo status Ch 91 : 4

But now the faults : 005642 and 005696 are gone..

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

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..

thank you for this great app :)  8)

:)

@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?

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 )

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..

Glad it worked. Will try to find some time to dig in to the previous problem also.

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!

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#msg54763

Also 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.

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

That is a good find!
It seems to cover parts of the calibration protocol firmware. Very interesting! Will do some tests this afternoon  8)

Thanks a lot David. I need to read more in the a2l files it seems :)

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.

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:

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13233;image)

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)

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.

I think I’ve managed to find the start and end addresses of that block. Using my own bin as an example, here’s what I did.

Here’s the sequence of bytes, both disassembled in IDA and also in a hex editor (I use HxD)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13263;image)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13265;image)

This sequence is at memory location 0x4BA104 (using memory locations as shown by IDA)

Next I did a search in IDA for byte sequence 0xA104. The search result gives me an instruction that’s loading 0xA104 into the low word of R10, preceded by an instruction loading 0xC into the high word of R10. At this point R10 (high and low) now contains the value stored in flash at 0xCA104. As I mentioned earlier, ignore the 0x400000 offset and weirdly there’s sometime a 0x10000 offset as well that I don’t understand, so B0000 sort of refers to C0000…

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13267;image)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13269;image)

In the code you can see R10 (our checksum suspect) is compared to R9, where the value in R9 has been loaded from RAM address 0x7FBBDC. Stands to reason that 0x7FBBDC is very likely to contain a checksum if it’s being compared to the checksum value in the flash! Let’s see how 0x7FBBDC is calculated. Clicking on 0x7FBBDC and looking at cross-references, you can see where it’s set (stw) and read (lwz)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13271;image)

Here’s the interesting bit. In IDA, just above 0x45AB8C (stw) and 0x45AB64 (lwz) are a few instructions that look very familiar…

0x1C2000 and 0x1EFFFF. Start and End address?

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13273;image)


Now I go back to my HxD editor, I select a block starting at 0x1C2000 and ending at 0x1EFFFF (which happens to be size 0x2E000, anyone remember that a2l mapping from a few posts back…). The HxD editor has got some checksum capability build-in (they all do), so selecting Checksum-32 as the algorithm gives me a checksum of 01361903 which is exactly the same as the byte sequence in the flash

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5833.0;attach=13275;image)

As usual, impressive work. Not only that you took time to help, but also writing it down in a detailed manner :)

I'll haven't had time to do anything the last couple of days but tomorrow I'll fire up IDA again :)

Kudos to you

Now this checksum is added to the tool. (thanks David) Another 7 checksums are also found and added.

I believe the only checksum left is the RSA.
For NOREAD/OBDPROT (and other changes not covered by the RSA) it should work fine.

Update is here : http://nefariousmotorsports.com/forum/index.php?topic=5833.msg54763#msg54763

Cheers
/Lars

RSA in MED9 very similar to ME7.
Look at http://nefariousmotorsports.com/forum/index.php?topic=6457.msg67541#msg67541
But i calc RSA in MED9.5
In MED9.1 very strange algorithm :)

Hello i found that tool and i want to say thank you to ddillenger and technic for posting.

i have dont try but i will ! the adresses for immo off med9 i was knew but in that tool shows me the security access too !

someone tryed if that works too ??

absolut great tool !!

thanks friends !

@ozzy_rp : Thanks. Will look into it.
@Dobermann : I haven't actually tried the security access. It is coded based on info I got from looking on how it is done in another tool. If you try it, please report back.

Thank you for the great tool! Do you think it's possible to implement a function for immo on (after immo off) and for immo new?
It's easier to adapt a "new" ECU against a used one.

guys, correct me if Im wrong. to use this tool I need to have eeprom file. is there a way to get eeprom via OBD (as with 95040 tool) or only desolder eeprom option with 9.1.1?  Also  - according to Rosstech its possible to swap ECU if you have both pins...  (thats what I need to do, actually) Where I can see the current PIN in this tool? Under Edit Inventory? in this case which field exactly? Thanks in advance

Read eeprom with BDM. Pin is under edit inventory. Unencrypted eeprom only

What is BDM stands for? (sadly, search on forum does not work - it would eliminate a lot of stupid question, I think)...  actually - nevermind - found post about it - reading at the moment :) ... but if I dont have time to BDM - can I just unsolder eeprom - read it - use your tool to defeat immo or get pin and solder it back? Which field in Inventory stands for PIN then? Security access or manufacturer number?

I got an used ME9 and want to use it as a spare so i flashed in a new .bin file and tried to immo defeat but i failed.
I tried to use the tool supplied by technic but my immobilizer is still active on the MFD but it shows '4' in adaptation block 91.
I've read through this thread several times and know that the tool from technic is only 'correcting' the eeprom, i've heard from others that the flash has to be edited as well so im lost.
I've attached the immo off file, could anyone shed some light here?

did you find a solution?

Trying to do the same thing and stuck at the same point.  Using original flash from 8P0907115B on an a 3C0907115S with eeprom defeated using eeprom_v2.2.1.  Surely missing something simple.
 
Am I correct that the flash does not need to be modified?

  Little confused about swappability of eeproms files. Maybe the two ecus have eeproms of different sizes? Both are 8P0907115B.   Trying to avoid cracking open the original ECU.

 Once read,  defeated and  coded correctly, could I be writing any MED9.1 eeprom file if of the correct size?

Thanks for whatever info you can share.

EPROM needs a few hex changed

Thanks for the hint.  Can you elaborate or suggest where to read?  I interpret this to mean the immo off eeprom program is not working for my eeprom, flash combo.


Sent from my iPhone using Tapatalk

Well, minor progress.  Used version 1.1.0 of the program where both flash and eeprom are modified and car now starts.  When using an unpaired key, I still get "safe" displayed in mfd and I am unable to do a throttle body adaptation as errors appear immediately after trying to clear. Got some work to do.

this program would not work for me, if you dig around youll find the two addresses that need -1 and +1 ;)

First versions needed both flash and eeprom.

Later versions work with eeprom only on unencrypted eeproms. It's making a simple mathematical operation on a couple of bytes (and checksum of course). Not addition / subtraction.

So, what is the +1 and -1 you are talking about? And on what addresses?

Skickat från min SM-G800F via Tapatalk 2

Keep searching the forum. No you can't replace the whole EPROM but need to hex 4 addresses.

...or you could just tell me what the addresses you are talking about are used for and their function and location - and I'll add it to the tool? Are they in IMMO1 or IMMO2 block for example?

It's two locations in EPROM. Then checksum. The tool would not work for
Me. I'm a b7 9.1 . People don't really like to post immo info on here. I can pm you when I get back on my pc , I can test it on my spare ecu before to verify. If someone knows more than me I'm sure they'll chime in. Basically you -1 two hex addresses.

Really hate the super secret handshake stuff.  I found this http://mhhauto.com/Thread-MED9-eeprom-immo-off-checksumm-tool  It describes address locations and possible issues with the tool.  Sad I had to go to another forum to make progress.

All it takes is one person willing to gather, organize, and publish.

The addresses shown on mhhauto is nothing special. It is what V2.1.1 does, including checksum. But it doesn't do +1,-1,+3 or -3.... it does one single math operation that should cover all cases.

However - if someone have discovered a MED9.1 that V2.1.1 doesn't support - but you have a solution - then please post both ori and "your" immo off eeprom - maybe I have a bug or missed something.

I'm aware that on some MED9.1 - which has eeprom encrypted - this tool doesn't work, and I don't have any solution for it.

I use bdm

What the hell does that have to do with anything?

Edited

"EPROM encrypted this tool dosent  work" aka I use Bdm"  let me know if I am lost also.

"Doesn't "

The tool never worked for me. Med9.1 Audi b7

Tool works for me.  I ended up cloning my original ECU and the doing the immobilizer off on my original  eeprom, then flashing to a new ECU.

I was trying to not open up my original ECU and only modding the eeprom on the new ECU.  This did not work unless I modded both the flash and eeprom.  While the car started, it gave throttle body errors.  I don't know why this is the case but my Newby guess is my eeproms from the new and orginal ecus where somehow mismatched.  I thought that once immo offed, the eeproms would be interchangeable but appears I was wrong.

I was doing all of this to: (1) have a spare ECU to tune without fear of bricking it and (2) be able to use a spare key that I bought off ebay and had cut to match.  Car only came to me with one key and dealer wanted about $400 to provide a spare. 

All seems to be working but the spare key, while functioning, shows "safe" in the MFD.  Now trying to figure out how to get rid of this message in the MFD.

Sorry if this digressed from the thread topic but hoping to help others along the path.

I think it's normal the "safe" on Mfd with unpaired key. The dash does not recognize the key, but ecu let engine starting, because is immo-offed

Thanks.  Trying to adapt key now.  Is the security access code provided by this tool the same thing as the SKC?

Also is this a Vw or Audi? Apparently Audi ecru is a tougher nazi "9.1"

I know mpps v16 also works well for Audi 9.1 I've been told via obd

This is a 2006 Audi A3 w/ immo4c.  Thinking immo4c needs the transponder pre-programmed by Audi or least that's what I've been reading.   so I'm gonna just secure my good transponder inside the steering column and call it good enough for getting rid of the "SAFE" in the MFD when using any key.  Wouldn't even had to immo-off the ECU if taking this approach.

ive read this trick in my bmw days also.... GL

It does need to be pre-programmed, but not necessarily by Audi...   ;)

Thanks, works perfectly on audi S3!

Thanks @technic
Are you still working on the tool?

I hope the question ist not stupid and hope someone can explain it.  ::)

I read eeprom of MED9.1 (1K8 907 115 F) via BDM, result = 4kb. If i read the same eeprom via Galep, result = 2kb.

According to datasheet

https://www.mouser.de/datasheet/2/389/m95160-a125-1156156.pdf

the memory array is 16 Kbit (2 Kbyte) of EEPROM = 16 kbit / 8 = 2kb.

If i split the 4kb file ($000 - $7FF) and ($800-FFF) the parts are identical. Why BDM double the content?

I assume you are using a Ktag...? I think only tool development can explain why it double eeprom. Some other tools read correct size from MED9.

I use CMD BDM clone like the most people here, i think. ;)

There are 2 EEPROMs that mirror each other. Some tools just read it once but the protocol is clever enough to ensure both EEPROMs are written. Other tools will back up verbatim and read both in serial.

From my understanding there just one physical eeprom type 95040 2Kbit (if I remember correctly) and the other 2Kb portion is inside microprocessor. Then my question is which tools can read both in serial? 

Could someone tell me how the eeprom checksum calculation is done in me9 95080?
Thank you:
Peter

Facepalm! The only reason pasta tools read 2 and save the eeprom twice is because they're ret@rded, especially when it says black on white in the datasheet of the physical eeprom that it only contains 2kb worth of data.

Today I do a tests of eeprom dump 95160 (2kb) from MED9.1 8E0910155J 0010. Ktag (clone) is reading this memory as 95320 (4kb) only, can't read as 95160 protocol.
When I do immo off via eeprom_v2.1.1 that file and then wrote eeprom via ktag, immo is still ON. Ktag (clone) wrong read and write that file in my opinion.
So i desolder 95160 from ECU PCB, read via programmer as 95160, then do immooff and solder again to ecu PCB, after that immo is off.

Sorry for m y english, it is not my native language.

Enjoy  ;)

I test this program and try to kill immo on 9.1.1 but immo is still on.
Read with original KTAG --2 kb value

Try to desolder and read immo eeprom via external programmer and then do immo off.

Yeah but my KTAG ORI read 2kb dump, not 4 kb.
I can try..

I don`t know what KTAG do you use, ORI or Clone but my KTAG - even pizza / pasta and whatever you want is reading 4kb of data and never had any issues with IMMO off, or ,when i had, was my personal fault, not KTAG.

Yes, Flex Bench mode is reading 2kb....

This is 100 % true story.
Today I was desolder ST95160 and read with programmer any found there some missing parts.
After immo off solutuion written by KTAG damage eprom then KTAG won't comunicate with ecu again.
I will try to fix my eprom manually and write by probrammer and try first to get comunicate with car/diag
This is first time in my life when KTAG makes me shit day/week

NEWS

As I said before, first ecu stop working,why,I don't know,don't have idea..first time in my life.I think MPC was broken
Today i buyed spared ecu-same HW,another SW and flash backup from previous ecu.
After I try once more time this software, put .EPR read by KTAG, write after IMMO off solution also with KTAG and now solution working.
Adaptations---> immo status---> 1(deactivate)
Car running proper.

I don't know why solution doesn't work first time on first ecu. Read/write with KTAG ORI

May this help something...
Regards

Is there a Github for this or opencode to make updates? looks like MED9.1.1 has differences in the S5 and other platforms where there are 3 sets of Vins and its not picking it up right. Would like to update it if possible, without recreating the whole thing...

Do you know how to immo off the s5 med9.1.1? The eeprom is encrypted and standard immo off methods dont work.,

I have 2 blocks  MED9.5.1 on my table. And both blocks contain 95080. Ktag counts them as 95320. This is certainly not true for our purposes. So I'm reading this block mode BDM programmer TNM5000

share eeprom to Crc we will count for you

HELP Please

I have a problem with TTRS MED9.1.2
I wrote by autotuner OBD and VR, then after some miles the dreaded P0601 error appears (internal memory checksum error)

After some research it says this is a problem because of anti tuning protection and RSA key calculation not done correctly with autotuner.

I have read back with KTAG and then used MED9 sum to redo chk, and i wrote back to ecu, but this problem still exists.

I have another full dump from an 8J0907404M 0020 ecu with older sw version , can I modify this EEP with vin data and IMMO off and write this version to my ecu which have a newer sw version?

Thank you

why didn't you share the eeprom here

Hey , I am not so sure how to attach files.

In the meantime Ive discovered that the FLS and MPC needs to be tuned and ck must fixed then you write by BDM

file is available here

Hello guys.
I´m new in this and honestly, i dont know what really is checksum and how it works or how to calculate...
But i want to know if someone can help me out...

I´m working on replacing a 2007 Volvo S40 ECU (original was lost) and i need to sync CEM and ABS info with this ECU.
I got this ECU but info was damage and i was able to get some file and recover it (flash + eeprom).
Now, i already found where is CEM and ABS Sync Data, but i need to calculate checksums on this...

Can anyone help me out?
Thanks

insert the file I will help you