Pages: [1]
Author Topic: Re-enabling ME7.1.1 Immo 3  (Read 15872 times)
G60Dub
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 25


« on: August 02, 2013, 10:04:15 AM »

Hi all

First post so be gentle.  Smiley

I have an R32 equipped Golf 4 Motion that when the original conversion was done (by a previous owner) the Immo3 in the ME7.1.1 ECU was 'switched off'  

Now for a friend who has recently performed an R32 conversion into his 4 Motion I recently pulled the SKC from the ME7.1.1 ECU in order that we could match the ECU to his 4 Motion intrument cluster, which incidentallly worked without issue.   Grin

Now this got me thinking regarding my own existing Immo 3 'Off' Me7.1.1 ECU.  Can I simply read the existing PIN from my Me7.1.1 Immo3 EPROM bin file, re-enable the IMMO3, update the checksums, write the bin file back to the EPROM and then match the now reenabled ME7.1.1 ECu to my instrument cluster?

This seems very simple in principle so what am I overlooking here and what should I be wary of?

Just had a look at the bin from the Immob EPROM and all the fields are blank with the PINs being set at FF FF and no VIN or IMMOB ID info.

Furthermore can I clarify - Are the RFID chip in the keys queried by the instument cluster or by the ENGINE ECU?

I also have a thought that the ECU has an aftermarket tune on it - I've read that the calibration is typically locked to the car - so is this accomplished using the IMMO3 3 EPROM data meaning in short I'm hence unable to re-enable my Immo 3?
« Last Edit: August 02, 2013, 12:24:32 PM by G60Dub » Logged
Rocket
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 15


« Reply #1 on: August 10, 2013, 11:02:14 AM »

It works this way in immo3 Me7:

The ECU starts the engine, then asks the cluster via k-line and/or can: Am I allowed to start?

There are 3 possible answers:

1- Yes (the car stay running)
2 - No (the car stalls)
3 - No answer (the car stalls)

To make his answer, the cluster will check if it shares the same immo data as the ecu, then read the transponder and compare it with his list of 8 allowed key spots in cluster eeprom.

When a key is matched, it gets locked to the cluster/immo data is was maried. That transponder is now unusable on any other immo data than original cluster/ecu.

So if you keep immo data from either original ecu or cluster, yes you can match everything.

If you plan to match ecu/cluster with anything else than your original immo data, you need new transponders.

Logged
G60Dub
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 25


« Reply #2 on: August 12, 2013, 10:03:55 AM »

Ah now things start to make more sense.  So I given my keys and cluster match if I were to flash the ME7.1.1 IMMO 3 EPROM with the correct data or a 'virgin' flash (e.g. ECU Immo3 thinks it's never been matched) I could essentially re-enable my Immo3 if I know my instrument clusters SKC?

I have cluster and ME7.1.1 and cluster EPROM binaries from matched cars so I can hopefully use these as a point of reference.

I've read the aftermarket flashes are 'copy' protected and I'm assuming this is somehow tied down to the data stored on the IMMO 3 EPROM?  If this is the case and I am at present running a tuned calibration I will be unable to re-enable my Immo3 by altering the data stored on the ME7.1.1 Immo3 EPROM unless I figure out (highly unlikely) how they tie it down to one ECU? I suppose another, drastic, option is to re-flash back to a stock ME7.1.1 calibration and then flash with a virgin Immo3 binary and then pair the cluster and the now standard ME7.1.1 ECU?

From what I've read there are at least two types of Immo3 IC used and I've seen data structures for the other type bandied about on this forum and also a virgin flash data structure but not the type for the R32 ECU unless I'm not looking properly.




Logged
ddillenger
Moderator
Hero Member
*****

Karma: +641/-21
Offline Offline

Posts: 5640


« Reply #3 on: August 12, 2013, 10:34:59 AM »

Read your eeprom (easier said than done, may very well need a test clip). Assuming they just turned off your immobilizer, not flashed a generic immo-off. Then change the values at 12 and 22 from 02 to 01, and correct the sums (increase the value at 1E and 2E by 1), and reflash the now immo-on eeprom image.
Logged

Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
G60Dub
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 25


« Reply #4 on: August 12, 2013, 01:19:20 PM »

I've read the EPROM but it looks like a blank immo off file has been written.   What are the chances of success if I re-enable, write a new pin inc backup location and update the checksums then flash it back?  Would I then be able to log in and match it to the cluster?

If it flashes or I stuff it up can I flash the original back without having caused any ill effects?

Here is a working copy on the left from another mates car and one very similar to mine on the right:

There's no transponder info, Immobiliser ID or VIN Number and the SKC are set to FF FF...  Looks to me like it may possibly be a blank/virgin cluster file that has been Immo offed! ?


Is there a data structure outlined anywhere for this?
« Last Edit: August 12, 2013, 02:12:18 PM by G60Dub » Logged
MK2-VRT
Full Member
***

Karma: +2/-10
Offline Offline

Posts: 131


« Reply #5 on: August 12, 2013, 02:57:06 PM »

I think you calculated the checksums wrong..

4A = 4B
49 = 80
Logged
G60Dub
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 25


« Reply #6 on: August 13, 2013, 03:46:28 PM »

I think you calculated the checksums wrong..

4A = 4B
49 = 80

The file shown on the right is from a running vehicle and nor have I modified the checksums in the first two pages!
Logged
ddillenger
Moderator
Hero Member
*****

Karma: +641/-21
Offline Offline

Posts: 5640


« Reply #7 on: August 13, 2013, 03:56:37 PM »

The file shown on the right is from a running vehicle and nor have I modified the checksums in the first two pages!

Ignore him. All the sums in those files are good.
Logged

Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
G60Dub
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 25


« Reply #8 on: August 13, 2013, 04:45:30 PM »

Ignore him. All the sums in those files are good.

Cool... Running this though excel at the moment and having a little difficulty calculating the checksums as its years since I've done any checksum stuff:

I'm obviously missing something somewhere: I sum the first 14 bits and then subtract from FF FF?  However there seems to be an incrementing subtraction in each subsequent page and it all goes haywire come page 7 or so - I thought the subtraction was page number but its not.  What am I missing?
Logged
ddillenger
Moderator
Hero Member
*****

Karma: +641/-21
Offline Offline

Posts: 5640


« Reply #9 on: August 13, 2013, 05:36:41 PM »

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
Logged

Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
G60Dub
Jr. Member
**

Karma: +1/-0
Offline Offline

Posts: 25


« Reply #10 on: August 14, 2013, 01:44:12 PM »

Aha...   Roll Eyes

I'll have a look at this shortly - very much appreciated but in the meantime I have more pressing issues...  I stuck a spare unmatched ME7.1.1 ECU on the car earlier tonight and then read the EEPROM from it (using VAG_CAN 2.5) and subsequently decoded the skc.  I then matched it to my cluster using VCDS thinking that I'd be sneaky and afterwards I'd re-read the IMMO EPROM and do a direct comparison of the data that changed post matching.  However once it was matched I was unable to pull any data from it - the car starts and runs but I'm unable to read the EPPROM - is this because the cluster and immo3 are now paired and I assume I have to pull the EPPROM and read it directly?   Can I work around this any way in the vehicle?  e.g temporarily disconnecting the instrument cluster pre Immo 3 read?
Logged
ddillenger
Moderator
Hero Member
*****

Karma: +641/-21
Offline Offline

Posts: 5640


« Reply #11 on: August 14, 2013, 01:52:43 PM »

Look at your examples.

12 and 22 on the ON file are 01.
12 and 22 on the OFF file are 02.

That's the immobilizer. ON is 01. OFF is 02. Then, just correct the checksums. If you ADD to the page, SUBTRACT the number you added from the checksum of that page.

The checksums for those pages are at 2E and 3E.

So, say this is your setup:

        0   1   2   3   4   5   6   7   8    9   A   B   C   D   E   F
10 : XX XX 01 XX XX XX XX XX XX XX XX XX XX XX FE XX
20 : XX XX 01 XX XX XX XX XX XX XX XX XX XX XX FD XX

Is IMMO ON

You would change it to:

       0   1    2   3   4   5   6   7   8    9   A   B   C   D   E   F
10 : XX XX 02 XX XX XX XX XX XX XX XX XX XX XX FD XX
20 : XX XX 02 XX XX XX XX XX XX XX XX XX XX XX FC XX

which is IMMO OFF.
« Last Edit: August 14, 2013, 01:57:30 PM by ddillenger » Logged

Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.022 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)