ME2.0 (4E28B) Immobilizer Data

Post #1

EuroKeyECU

EuroKeyECU

Stock Member

United States
Joined
12.12.2025
Messages
9
Reactions
3
Location
United States
Hello all,

I have posted this question on all the other forums and no one ever answers. I am hoping someone here can share some insight.

What immobilizer data is actually stored on the ME2.0's EEPROM (4E28B)? I have found the VIN, but I cannot see any key data like one would find on the later ME2.8.

For example, on a early W220, it has the ME2.0, dual HC05 EIS, and EWM with HC05 and 93C56. I understand how the key data works and is synced between the EIS and EWM, but how is the ME2.0 synced? This is driving me crazy and I would really love an answer.

Thanks,
Will
 
Ratings and Reviews
Total ratings: 0
Sort by date Sort by votes

Post #21

VVDI Prog cannot write a B58252, it fails at erasing. MultiProg also fails when 24C02 is selected, but if selecting a "Bosch" B58252 it programs it sucessfully. VCC is raised up to 5.2V when B58252 is selected.
 
Upvote 0 Downvote

Post #23

Your own test answers it: use the dedicated "Bosch B58252" profile in MultiProg and stop fighting the generic 24C02 entry.

Why it behaves that way
The B58252 is pin- and protocol-compatible with a 24C02 for reading, but it is not an identical die. Bosch-specified parts of that era commonly need a higher/tighter supply and different write timing than the generic I2C EEPROM profile assumes. That matches exactly what you observed: generic 24C02 at ~5.0 V fails on erase/write, while the B58252 profile raising VCC to 5.2 V completes the program cycle. That is behavioural evidence from your bench, not a datasheet claim on my side — I have not seen a B58252 datasheet to confirm the exact Vcc window, so treat the 5.2 V as the tool vendor's implementation rather than a spec I can quote.

Also worth noting: VVDI Prog failing "at erasing" is expected. An I2C EEPROM has no separate erase command — the tool is issuing a fill/write pass, and if the profile's timing or voltage is wrong it never gets an ACK back. It is not a sign the chip is dead.

Practical steps
  • Read the original twice with the B58252 profile and compare the two dumps byte-for-byte. Only work from a dump that reads identically twice.
  • Write the donor with the same profile, then read it back and diff against the source file. Do not trust the "programmed successfully" message alone.
  • If you are doing this in-circuit, that raised VCC is being fed into the rest of the board. Safer to pull the chip or at least isolate it, otherwise the ECU's other ICs can load the bus and corrupt the write.
  • Keep the donor's original dump archived before you overwrite it, in case you need to put it back.

Two things that affect the next step:
  • What is the exact marking on the donor's EEPROM — also B58252, or a different part? If the donor has a plain 24C02 you can still write it normally, but the source dump must come from the B58252 profile read.
  • Does the read-back diff match after the write? If it matches and the car still does not start, the problem moves to HW/SW variant mismatch between the two HFMs, not the EEPROM.
 
Upvote 0 Downvote

Post #24

Excellent troubleshooting, and thanks for documenting that. The B58252 is a Bosch-specific EEPROM variant that requires a higher programming voltage than standard 24C02 chips — that's exactly why the generic 24C02 profile fails on both tools.

The B58252 needs VCC elevated to 5.2-5.5V during the write/erase cycle, which is why MultiProg's dedicated "Bosch B58252" profile works. Standard 24C02 programmers typically operate at 5.0V or lower, and the B58252 won't accept erase commands at that voltage.

This is a known quirk with Bosch automotive EEPROMs from that era (mid-90s). They used higher write voltages as a primitive security measure to prevent casual cloning with generic tools.

Good that you have MultiProg — it's one of the few tools that includes the correct Bosc profiles. The VVDI Prog doesn't have that specific voltage profile, which is why it consistently fails at erase.

Now that you've successfully written the EEPROM, the swap should be straightforward. Install the donor HFM and test with your existing keys. Let us know if it fires up cleanly or if you run into any immobilizer faults.
 
Upvote 0 Downvote

Post #25

Also tried with Abrites Abprog, and it also fails at programming the B58252 when 24C02 is selected. There are some reports in forums that CarProg can delete a B58252 successfully, but I have not personally tried it.
 
Upvote 0 Downvote

Post #26

That lines up with what you're seeing everywhere else: three separate tools (VVDI Prog, MultiProg, Abprog) all fail the B58252 when driven as a plain 24C02, and the only profile that completes is the dedicated Bosch one. That's a strong pattern — the chip is fine, it's the generic I2C profile that can't drive it correctly.

Since MultiProg already writes it successfully with the B58252 profile, I'd not bother chasing CarProg. Those "CarProg can erase it" posts are secondhand and I can't confirm them — no reason to add another unknown when you have a path that already programs the part on your own bench.

The one thing worth doing before you commit to the swap: with the B58252 profile, read the donor back after writing and diff it byte-for-byte against your source dump. A "programmed successfully" message on a chip that needed a non-standard profile to write isn't proof the cells actually hold the data — the readback comparison is.

If the readback matches, install the donor HFM and test with your keys. Let us know if it fires cleanly cold, since that cold-fail on the original ECU was the whole reason for the swap.
 
Upvote 0 Downvote

Post #27

For the sake of completeness:

Code: 
Original Dump (Married):
0000: 55 AA 00 7F 81 FF 00 01 43 77 92 00 4C 01 00 00 (first line of the dump)

Virgin Dump (Renewed):
0000: 33 AA 00 7F 81 FF 00 01 43 77 92 00 4C 01 00 00 (Ready for HHT)
 
Upvote 0 Downvote

Post #28

Excellent documentation, thank you for sharing that. This is exactly the kind of real-world data that confirms the immobilizer structure.

What you're seeing at byte 0x00 is the status flag:

0x55 = Married/Personalized (ECU has been paired with an EIS and has immobilizer data written)
0x33 = Virgin (ECU is ready for HHT-WIN personalization, immobilizer data not yet written)

The rest of the first 16 bytes appear identical between the two dumps, which means:

  • The VIN, base configuration, and hardware data are preset (likely programmed at the factory or during ECU preparation)
  • Only the status byte changes when HHT-WIN performs the marriage
  • The actual ISN and key data written by HHT-WIN will appear in the bytes immediately following this header (likely 0x10 onward, but the exact layout depends on the M3.4.3 firmware variant)

This confirms that the B58252 on the 0 261 203 536 uses a similar structure to other M3.4.3 variants, just compressed into the smaller 256-byte space.

Important note: If you've written the married dump (0x55...) to your donor ECU, it should start immediately with your existing keys. If you wrote the virgin dump (0x33...) instead, the donor will need to be personalized with HHT-WIN before it will run.

Did you complete the swap, and did the car start cleanly with the cloned ECU?
 
Upvote 0 Downvote

Post #29

Copying the EEPROM in the M3.4.3 did work perfectly. Car started at the first try.

The VIN is visible in the dump, and the eeprom has to be removed from the board to be read or written.
 
Upvote 0 Downvote

Post #30

Perfect result, thanks for the confirmation and for documenting the process so thoroughly.

The fact that it started first try with the cloned EEPROM confirms the ISN and key data were intact in the original dump, and the B58252 profile wrote it correctly. That should also resolve your cold-start fault, assuming the donor ECU's internal hardware is good.

Good to know the chip had to be removed for reliable read/write on your board — some M3.4.3 layouts allow in-circuit work with a clip, but the 0 261 203 536 variant clearly doesn't cooperate that way. Likely due to pull-ups or other components on the I2C lines interfering with the programmer's signaling.

Your dump samples (married vs. virgin at 0x00) and the VIN visibility will be useful reference for anyone working on the same generation R129/M104 system. Thanks for sharing the details as you went — clean documentation like this helps the whole community.
 
Upvote 0 Downvote
Activity
So far there's no one here

Similar threads

Bin
Mercedes/VAG Immobilizer Dumps — Identification and Key-Data Support
Replies
0
Views
199
Bin
Bin
Bin
Immobilizer Dumps — ECU, Memory and Template Matching Support
Replies
0
Views
312
Bin
Bin
Murda006
  • Question Question
Kia Hyundai IMMO OFF – Immobilizer Bypass / Reset Help
Replies
1
Views
12K
carlitos
carlitos
Bin
Visteon DCU10x Conversion — KTAG, FGTech and Immobilizer File Support
Replies
0
Views
313
Bin
Bin
Bin
Bosch MEDC17 Immobilizer Files — ECU Identification and Recovery
Replies
4
Views
490
hamedPSA
H