NefMoto

Looking for some help with a US 2.0 Beetle. Early 2000's model. I believe it is IMMO2, something has happened with the key so the car is starting and shutting off with the immo block and blinky light in dashboard. Can someone help me with the attached file? I would like to turn the immo off completely. I have dug around several forums, mostly I find people using files from other box codes that have been disabled. I don't want to change anything else in this file so any help would be appreciated! Thanks.

Comparing the two files posted in this immo-off-thread (http://nefariousmotorsports.com/forum/index.php?topic=3066.msg30350#msg30350), I can see that the file structure matches yours, and that the only values changed were 00C-00F (and again at the repeats at 06C-06F), but I have no clue why the new values were chosen.  

hopefully in addition to helping you immo this file off, we'll also hear about how it's done, and it can be included in the "understanding/retrofitting immobolizer" thread?

If you're a member of ecu connections then this post (whole thread really) (http://www.ecuconnections.com/forum/viewtopic.php?p=35729#p35729) may be helpful...

-sorry I couldn't be more helpful myself
-Cyril

edit to add some detail:
------------------------------------------------
Address 01: Engine Labels: 06A-906-018-AEG.lbl
Part No: 06A 906 018 JN
Component: 2.0l R4/2V MOTR AT V01
Coding: 00033

you now type of ecu??

2000 beetle=5.92. I'll off your file shortly.

Thanks Cyril, I actually read that thread on ECU connections. I spent a few hours looking around, comparing various files etc. I couldn't figure out what other people were using and why, so I decided to reach out over here and see what help I could find. I want to understand the changes so we can have a how-to posted on here like the ME7 guides.

try and report please .

I can certainly off it, but for older eeproms (yours included) I run it through software. I'd like to understand the rationale behind the changes as well, and will certainly add it to the sticky when it's made clear to me :)

Update with what I tried:

Looking through one of the threads cyril posted I found an orignal and an immo off file. So I compared the changes. Three were made and repeated. At 0C00, A0 went to 50, at 0E00 CF went to 20, and at 0F00 FB went to FC. These changes where repeated at 0C60, 0E60, and 0F60.

A0 to 50 is a simple inversion. A0 = 1010000 50 = 0101000
FB to FC is a simple increment FB = 251 Decimal FC = 252 Decimal

The question lies in the change of CF to 20
CF = 11001111 or 207 decimal, 20 = 00100000 or 32 decimal
It is almost an inversion with an increment as well.
1101111 invert to 0011000 = 30 subtract 1 from the first digit = 20 = 00100000

This is the only thing that made sense to me, so for my file instead of CF, I had 34
34 = 00110100 invert to 11001011 or CB, subtract from first digit to get BB or 10111011

So for my file I tried 50, BB and FC at the locations mentioned above. The car started right up and did not care about the immo issue with the dead key fob. Great, but I got a fault that returned with every key cycle for internal module error. Guessing a checksum issue. Can anyone help out here, I am assuming the one value which I was guessing at is incorrect and must be based on something else?

glad to hear you're figuring it out

a0 to 50 is probably the immo-off change (for me7.1 and others it's 01 to 02 then correct the checksums), and both f and e columns are probably checksums for the row. I'm off to dinner or I'd try to work on it more, but I expect that the increment of the e and f bits together are a factor of the a0 to 50 difference, similar to this (http://nefariousmotorsports.com/forum/index.php?topic=1168.msg19455#msg19455).

I've found that the last two columns (of all rows) are = FFFF - sum(octets)
the rule works for the first twelve lines of both original files
(maybe more, I didn't check beyond the first six, which repeat at 60)

assuming that 50 is the immo-off value of 0C and 6C, then your off'd line should look like the "sean's 24c02 off" image below.

these findings don't match the immo off file provided in the thread linked earlier, which could suggest several things.
1, I have grossly oversimplified the immo off process for this chip
2, that second file of the other thread has checksum issues (with no feedback we don't know for sure)

(http://i83.photobucket.com/albums/j318/Cyril279/24c02_checksums_zps2f3f9d00.png)

Maybe i'm missing something, but that is the definition of a checksum..

For some reason I edited your post rather than replying-lol

I fixed it. Sorry about that.

Anyway, each line is checksum'd just like immo-3, that part I'm clear on. It's the changes required for the immo-off that I'm hazy on. If PRJ is right and otocheck just substitutes a new file, comparing the changes is fruitless, so I haven't bothered. I'm hoping if this thread stays active someone will chime in.

you're the VET here NYE, so I am probably the one that's missing something

I'm under the impression that checksums are subject to the coding that calculates them.
the checksums for 24c02 are calculated differently than those for the 95040.
therefore I didn't recognize ffff-sum(octets) as any global definition of a checksum.

the checksums for 95040 are ifferent for each line, skipping the backup page.
starting with line 10.  ffff-sum(octets)
line 20 fffe-sum(octets)  [or something like that]

there was a better description in another thread, prolly the argdub-tool thread, but I don't know the technical side of it at all, only that the checksums for 95040 are not ffff - sum(octets) for all rows, as it seems to be in this 24c02.

(http://i11.photobucket.com/albums/a162/laurentpotin/EEPROM/95040Beetle.jpg)

I just meant the format of the checksums is similar, as in each line sum'd individually. Here's the checksum guide for immo-3.

ME7 EEPROM Checksum-Guide
=========================

The ME7 EEPROM contains 512 bytes and is divided into 32 pages with 16 bytes per page.
In the ME7 code you will find a table with 32 entries that contains one descriptor word for
each eeprom page. The index into this table is the eeprom pagenumber (00..31).

The descriptor word is a bitmask, the following bits are relevant for the checksum calculation:
 bit 0 = checksumPresent(CS)   1 -> page has checksum,  0 -> page has no checksum.
 bit 6 = cksumBit(CB)          this bit is subtracted from the pageNumber to get the
                               same checksum in backup page as in original page.
 bit 7 = backupPage(BP)        1 -> page has a backup page.

Here is how the eeprom page info table looks like:
PAGE   DESCR-WORD  -> CHECKSUM-BITS
-----------------------------------
00      FF18       ->    --
01      0017       ->   (CS)
02      0117       ->   (CS)
03      0207       ->   (CS)
04      0307       ->   (CS)
05      0437       ->   (CS)
06      0533       ->   (CS)
07      06B7       ->   (CS) (BP)
08      06F7       ->   (CS) (BP) (CB)
09      07B3       ->   (CS) (BP)
10      07F3       ->   (CS) (BP) (CB)
11      08B7       ->   (CS) (BP)
12      08F7       ->   (CS) (BP) (CB)
13      09B3       ->   (CS) (BP)
14      09F3       ->   (CS) (BP) (CB)
15      0AB3       ->   (CS) (BP)
16      0AF3       ->   (CS) (BP) (CB)
17      0B32       ->    --
18      0B10       ->    --                           
19      0B10       ->    --                           
20      0B10       ->    --                           
21      0C37       ->   (CS)
22      0D33       ->   (CS)
23      0E33       ->   (CS)
24      0F33       ->   (CS)
25      1033       ->   (CS)
26      1133       ->   (CS)
27      1233       ->   (CS)
28      1235       ->   (CS)
29      1235       ->   (CS)
30      13B7       ->   (CS) (BP)
31      13F7       ->   (CS) (BP) (CB)

If the checksumBit(CS) is set for a page, this page has a checksum.
Calculate the checksum as follows:
- sum up the first 14 bytes of the eeprom page in a 16bit variable.
- add the page number to the sum.
- if the checksumBit(CB) is set, subtract 1 from the sum.
- negate the sum (this is not the same as complement!).
- store the resulting value in the last two bytes of the eeprom page,
  first the low-byte, then the high-byte.

Disclaimer: this information was collected to the best of one's knowledge, but I won't give
any guarantees for the correctness of my information. If you find any errors, please correct.
Have fun, mki

thanks everyone, cyril i came to same conclusions last night after you linked me to that me7 thread. I worked all of them out by hand and found the slight difference in the one untested file.

ddilenger I can confirm that the AO to 50 change takes care of the immo blocked start even if the checksums aren't correct. I will have to test the checksums now. I have already fixed the car I was playing with, perhaps we can check this on a bench ECU I think I have a spare somewhere.

You worked them out by hand? you're way cooler than me, I made excel do the work.
I'm certainly glad it's working out for you, please let us know if the checksum correction gets rid of the "internal module error"

here is what i do and what worked every time

https://www.dropbox.com/s/p11wthkjscq4xc1/Anleitung.jpg

^^exactly. where were you last week? :D
thanks AEF.

(http://i83.photobucket.com/albums/j318/Cyril279/Anleitung_zps77fe61d7.jpg)

(http://i83.photobucket.com/albums/j318/Cyril279/24c02_off_zps9216f180.png)

Great thread. i just have a few Q's


1. How do i know if a ECU is Immo 1, 2 or 3?
2. Are we saying that we have to reduce the value in 000C to 50 or by 50? as the example of A0 is a double of 50.
3. Do we have to modify the checksum in the last two columns and back up pages?
4. In the eeprom i have noticed it has the ECU number, now if i was to clone the eeprom chip and solder to another ECU of corresponding numberical digits, would i have to modify the flash in that ECU to tie up with the eeprom.

I have Immo Universal decoder 3.2
in that software for all Bosch M3.8.x eeproms it has two options, version 1 and 2
And for both it calculates the immo off differently , i believe for 1 it sets 000C to 50 and 000E to 9E

Which doesnt make sense to me

so i would prefere to do the calculation manually in a hex editor. as descibed above.

Here's a new one:

99.5 jetta, I'll assume ME 3.8, part number 06A906018BH
I knew this one would be an odd bird when I saw the Soft coding = 00000

Instead of A0, it has F0 at 0x0C for the immo byte
(F0h = 11110000b)
Checksum bytes = 29 FA (FA29h)

What I tried (correcting the checksum each time):

Change F0 to 50 (checksum becomes FAC9)
Sometimes in edc15 for example you will see 33, sometimes it is F3. Changing to 60 turns off immo in both cases, so maybe that bit needs to say 50h regardless of what the original value is
Well, that didn't work,

so figured maybe it was the 50 decrement not the value that makes the difference, so
Change F0 to A0 (F0 - 50 = A0)
Didn't work either

then reading this thread again, maybe it's the reverse bitmask, so we'll try
the inverse mask of F0 = 0F (11110000 vs 00001111)
Didn't work either.

Next try inverting ONLY the first 4 bits so (F0 change to 00 and cksum becomes FB19)
that didn't work either.

Every time VCDS adaptations block 91 says 4, not 1 like it does when immo = off

Anyone know how to shut off the immo in this ecu?


Another interesting thought. A0h/2 = 50h so maybe F0h/2 = 78h is the answer... what I will try next. (edit- that didn't work either)

I notice that M38x & M592 immo & it checksumm calculations are based in sums, according to the info I have collected. I checked with some ECUs and worked everytime quite good. In general I have done by substract 50h to make immo off and correct checksumm by adding 50h too.

Take a look.

It did not work that way in my case.
Instead of A0h the immo byte is F0h in the weird eep file.
Subtracting 50h (so the immo byte = A0) the adaptation channel 91 still = 4. If the immo was off, adaptation channel 91 would = 1
Even changing immo byte to 50h does not work.

So here's what did not work so far:

1) Change immo byte to 50h
2) Change immo byte to A0h (subtract 50h from original value)
3) Change immo byte to inverse bits (F0 = 11110000 change to 0F = 00001111)
4) Change only high bytes to inverse (F0 =11110000 change to 00)
5) divide by 2 (F0/2 = 78)
6) divide only 'F" by 2 (F0-> 70)

So for this particular ecu, there must be some (as of yet unknown) value that makes it immo off.
 

that file is correct

That is a weird dump. Soft coding is 0000. DTCs are FF FF ........ seems like was manipulated before. What DTCs do you have? Can you read it again directly from ECU in car?

Don't have the car unfortunately.

Agreed, it is a very strange dump. Not quite sure what to do with it. immo byte should be A0 and not F0

VCDS says soft coding 00000 is correct for that particular ecu. manual transmission with brake electronics I think it was.

I just wrote a complete eeprom from a different 5.9.2 ecu, with known immo off. Verified the first 5 bytes sequence is the same so it should be compatible.
ECU boots up in vcds, but STILL 4 in channel 91

I give up on this one. Something's just not standard.

Ended up using an FA box. (06A906019FA) it's the same make/model/year except it has cruise while the weird ones do not have cruise.

It looks like the 2 part numbers with the weird "F0" immo value are:

06A906018BH
06A906018BJ

there may be others
I would love to figure this one out.