Comparing the two files posted in this immo-off-thread, 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) 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

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

try and report please .

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?

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)

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.

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