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)





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…





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)



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?




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

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

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 !

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.

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

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?

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.

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