VW MID EU / RCD310 HELP

**adecode** · 26th December, 2010, 02:39 AM

Hi vlk69

Thanks for the files. Taking in consideration the files, it seems that the checksum is at 0x0B48 and not at 0x0AE0, so initial assumption should be ok. What do you think siti?

The addresses and the calculations that siti mention are very interesting, so tired of making XORs calculations in windows calculator, I decide to write a program that make the calculations for us. Please find attach the XORs calculator. You just need to open a window command line (go to start->run and type cmd). This will open a console window. At that point, just go to the folder where you save the checksum.exe file and run it with the parameter equal to the e2prom file. Ex: checksum rcd510.bin.

I decide to make a final XOR between the results, and in siti example the result is 0xFFFF in both cases, something that is interesting also. With old files the 0xFFFF appears in the first calculations.

The carradio ideia about the counter, is interesting also, but you mark the green bytes wrong, it is D7 80 C3 F1. Why do you thing is a counter and not a checksum.

I would like to ask also vlk69 if he introduce a complete wrong code or only one digit, because the "counter" only misses the XOR calculations in one byte.

Why do you think last byte of "counter" is a CRC carradio2001?. Any ideias how to calculate it? From what I understand you decide to multiply the 31 by 2 and then reverse the XOR in order to calculate the next safe. Why by two, and not just add 1 to 32.

Does someone knows how to calculate the old algo? Could give me ideias for the new one. There is one post in another thread talking about an old algo for code 1119, but I did not understand how the second four bytes are calculated. In that example, the first XORs give 0xFFFF

Hope you enjoy the XOR calculator

**carradio2001** · 26th December, 2010, 09:39 PM

Originally Posted by adecode

The carradio ideia about the counter, is interesting also, but you mark the green bytes wrong, it is D7 80 C3 F1. Why do you thing is a counter and not a checksum.

Why do you think last byte of "counter" is a CRC carradio2001?. Any ideas how to calculate it?

Hi Adecode,

Well, this dump it is like Opel dumps (95640 eeprom). The counter in Opel dumps is 00 11 22 and a checksum XX. I never know how is calculate it, only use it as it is.
About D7 80 C3 F1, it is the bytes like the safe0 and safe1 dumps from our member #vlk69, maybe one digit left or right.

These "new" algos have everytime the "T23J" code in ASCII. All known new algos by me, have the code everytime on the line with the "T23J", after that is everytime checksums and counter and maybe another checksums. I marked the interesting area up this message.

Carradio2001.

**siti** · 26th December, 2010, 10:40 PM

Does someone knows how to calculate the old algo? Could give me ideias for the new one. There is one post in another thread talking about an old algo for code 1119, but I did not understand how the second four bytes are calculated. In that example, the first XORs give 0xFFFF

Hope you enjoy the XOR calculator

[/QUOTE]

is very simple old algo VW,a single op math with XOR

**carradio2001** · 27th December, 2010, 09:45 AM

Originally Posted by siti

is very simple old algo VW,a single op math with XOR

It is NOT so simply !

Carradio2001.

**adecode** · 27th December, 2010, 10:41 AM

Hi Carradio2001

Any help with the old algo.

It is possible to any one to use a digital analyser and check the e2prom addresses that are read during a enter code procedure by the user. Basically is try to understand what bytes the MCU is reading to make the calculations for the algo.

From what I understand the old algo use a constant to XOR with the address 0AE0. I do not know if it is one constant or several.

What I want to prove is that there is a table of constants inside the E2PROM that is equal for all E2PROM.

Based on some information inside the E2PROM (some calculations based on the addresses mention before (AE0, B00 and B20)), the MCU calculates the offset of that table, and than make the xor of that constant with the code at 0AE0.

To prove this, I need to know the addresses that MCU access the E2PROM and then check if this addresses contain the constant information for the XOR.

Any more ideias?

**vlk69** · 27th December, 2010, 10:16 PM

Hi, this is what i will do when have little bit more time, look what CPU do on I2C before & after enter CODE.

Originally Posted by adecode

Hi Carradio2001

Any help with the old algo.

It is possible to any one to use a digital analyser and check the e2prom addresses that are read during a enter code procedure by the user. Basically is try to understand what bytes the MCU is reading to make the calculations for the algo.

From what I understand the old algo use a constant to XOR with the address 0AE0. I do not know if it is one constant or several.

What I want to prove is that there is a table of constants inside the E2PROM that is equal for all E2PROM.

Based on some information inside the E2PROM (some calculations based on the addresses mention before (AE0, B00 and B20)), the MCU calculates the offset of that table, and than make the xor of that constant with the code at 0AE0.

To prove this, I need to know the addresses that MCU access the E2PROM and then check if this addresses contain the constant information for the XOR.

Any more ideias?

**adecode** · 27th December, 2010, 10:48 PM

Hi vlk69

I will be waiting for that

**alexics** · 28th December, 2010, 01:06 AM

Originally Posted by adecode

Hi vlk69

I will be waiting for that

The old algo uses a ten bye lookup table but thrree of the code addresses are xored. I should know I cracked it in the first place years ago.

**carradio2001** · 28th December, 2010, 09:41 AM

Originally Posted by vlk69

Hi, this is what i will do when have little bit more time, look what CPU do on I2C before & after enter CODE.

I think your I2C analyzer not help you. Inside is a SPI eeprom: 95128.

Carradio2001.

**carradio2001** · 28th December, 2010, 11:22 AM

Originally Posted by carradio2001

#adecode,
...not move away from the main solution, which is discover the algo)

As I said, why not believe me ? The code is on address 0AE0 and is matter of mathematics. Need to work on the table with any kind of formula. Good luck and keep in touch !

Carradio2001.

**alexics** · 29th December, 2010, 04:28 PM

The 'code area' does start at 0AE0 and the patterns in that area are based on a previous algo but that won't help trust me on this. In the old algo the interlocking checksums were the same across different models. This is one stage further on. The data is likely encrypted by a unique key stored in the processor. Once the key is known then decoding would be simple. Apply the key then use the old algo. They haven't reinvented the wheel because they want an easy solution for them that makes it very difficult for us.

Also a possible calculator would be based on the Blaupunkt calcs but be modified to make it difficult to work out for us but stupidly simple for them. It's a game of cat and mouse and they are winning it.