VAG-COM/VCDS EVERYTHING

[obdcarsale]

that is the VIIPlusLoader-08.021.02 and VIIPlusLoader-08.021.03 , by VIIPlusLoader-08.020.13 test all ok.

[DYXiCZ]

VIIPlusLoader-08.021.03-EN-Installer.rar mega.nz download link:


https://mega.nz/file/Ak0FCAAZ#uOq-2e...fOFuIhRDS5wY78

Changelog: modify k2 bugs.

Hello flyfvdi Thanks for newest updates How can i contact the developer of the tool?
Me and bunch of my friends use these cables. And I, in my free time, translated the tool to our native language (Czech)
Is there a way to contact the developer? So we can maybe add our (czech) language to next releases? So other users can use it too?

Screenshot_1.pngScreenshot_2.pngScreenshot_3.pngScreenshot_4.png

Translation works without any issues for couple of recent updates
In attachments i attached AppConfig.ini file (inside zip). You can copy (and replace) this file in .\VIIPlusLoader\ConfigFile\ to activate it
To revert it back to english - open the file and edit Language=Czech to Language=English

[badrax]

A little update on my work on the upgradable 405 cable.

Did some logging of the communication to the external "crypto" chip that this cable is using and I am pretty sure that it is using i2c with address 0x50 and 0x51.
While booting, the STM32F405 send some messages to the chip for it to verify and a message can look like this.

"00 0A 80 08 00 00 05 01 01 02 03 04"

This message is of length 0x0A and is of type 0x0880. It contains some payload with a length of 5 bytes and the payload is 1, 2, 3, 4. This is one of the first message sent and I believe this is the STM saying hello.

MSG Type    : 0x0880 "Send"
MSG Length  : 0x0A
UN1         : 0x0000
Payload Len : 0x05
Payload Type: 0x01   "Test MSG ??"
Payload (without checksum):
0000 : 01 02 03 04
Payload NOT encrypted:
0000 : 01 02 03 04

The response from the chip for this message is:
"00 0E 8F 01 95 9C 4D 07 1C 71 3B 4F 40 10 90 00"

Response:

MSG Type    : 0x8F   "Receive"
Payload Type: 0x01   "Test MSG ??"
MSG Length  : 0x0E
Decrypted:
0000 : 00 02 00 00 00 00 00 00

The encryption used here is TEA in CBC mode and will be used for more or less all other messages.

Message: "00 10 80 08 00 00 0B 74 FB E7 23 87 0C 4A 2F 8D 65 C3"

MSG Type    : 0x0880 "Send"
MSG Length  : 0x10
UN1         : 0x0000
Payload Len : 0x0B
Payload Type: 0x74   "Get Version"
Checksum    : 0x65C3 "Checksum OK"
Payload (without checksum):
0000 : FB E7 23 87 0C 4A 2F 8D  | ..#..J/.

Decrypted payload:
0000 : 00 B3 2D 16 52 00 00 00  | ..-.R...

Type2    : 0x00
Nonce    : 0xB3 0x2D 0x16 0x52
Data Len : 0x00
Data field empty
Nonce resp: n1:"50 F7 39 28" n2:"E4 14 CC EC"

Response:
00 16 8F 74 6D B6 5D 8A FB 7B E3 7B 24 46 EB 5B 87 85 36 9D 41 6E 90 00

MSG Type    : 0x8F   "Receive"
Payload Type: 0x74   "Get Version"
MSG Length  : 0x16
Decrypted
0000 : 00 00 B3 2D 16 52 08 30 31 2E 30 30 2E 30 32 00  | ...-.R.01.00.02.

So I guess the SW version running on my encryption chip is "01.00.02" and that this is actually not an encryption chip but a small MCU?


Here is a message to verify my STM32F405 UID

"00 20 80 08 00 00 1B 70 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36 CB 4B"
(I have modified it to not show my UID if decrypted)

MSG Type    : 0x0880 "Send"
MSG Length  : 0x20
UN1         : 0x0000
Payload Len : 0x1B
Payload Type: 0x70   "Verify UID"
Checksum    : 0xCB4B "Checksum OK"
Payload (without checksum):
0000 : 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36

Decrypted payload:
0000 : 00 2B 80 41 FB 10 <16 byte MD5(UID + 0xFA padding) hash> 00 00

Type2    : 0x00
Nonce    : 0x2B 0x80 0x41 0xFB
Data Len : 0x10
Data:
0000 : <16 byte MD5 res like above>
Nonce resp: n1:"76 9C EC 42" n2:"24 7C 74 A4"

Response:
"0x00, 0x0E, 0x8F, 0x70, 0x2B, 0x04, 0xCA, 0xB5, 0x71, 0xE2, 0xA7, 0xBC, 0x8A, 0x08, 0x90, 0x00"

MSG Type    : 0x8F   "Receive"
Payload Type: 0x70   "Verify UID"
MSG Length  : 0x0E
Decrypted
0000 : 00 00 24 7C 74 A4 00 00

This last message is a bit more interesting coz it is sent to verify something "the UID" and will respond if verified success with modified nonce.

The calculated nonce response is now verified with the decrypted message and we see that "24 7C 74 A4" == "24 7C 74 A4" so my UID is good to go.
(But of course this is my fake UID since I am running the firmware on a different chip )

Messages I have seen is:
0x01: "Test MSG ??";
0x70: "Verify UID"
0x71: "Get RSA ??" (This one will be interesting)
0x74: "Get Version"
0x77: "UNKNOWN"; (Don't know what this one is yet)


I have been asked if I can make this firmware run on the 415 not upgradable cable and I don't see that this should be an issue.
However making it run and show up in VCDS is one ting but will it work on your car? It kind of look like the upgradable cable is using a different pin configuration then the 415. Perhaps some one can dig deeper and figure this out?


One more ting i discovered after I installed my STM back on the PCB is that when booting the bootloader will set RDP2 if other read protect levels are detected so my chip got locked again :|
But I have found and removed this code so it wont happen again. (If you are hoping to buy a cable without RDP then I am sorry to inform you that this will most likely never happen)

I have also extracted all the different firmware versions I could find to see what is changed and it looks like the firmware is recompiled for every time so they definitely have the source code for this and that it is true that they have made their own firmware.
(Unless this is the actual RT firmware an that the one extracted from the 415 is the fake one )

There is some more crypto stuff when booting like RSA1024 to extract the TEA key to decrypt part of the bootloader and this rsa data is located in the OTP area. I might also have to dump the chip one more time coz I forgot to check the RTC backup registers and if there are any data stored there.

(If you are still reading then you are probably just as interested in this then I am )

[peetr]

that is the VIIPlusLoader-08.021.02 and VIIPlusLoader-08.021.03 , by VIIPlusLoader-08.020.13 test all ok.

My cable is still on the way, but as I get it should I use 08.020.13 as loader, or the newest one?

Thank you all very much for this good stuff! There are surely many people which appreciate it even more as me. Please keep it up

[flyfvdi]

Hello flyfvdi Thanks for newest updates How can i contact the developer of the tool?
Me and bunch of my friends use these cables. And I, in my free time, translated the tool to our native language (Czech)
Is there a way to contact the developer? So we can maybe add our (czech) language to next releases? So other users can use it too?

Screenshot_1.pngScreenshot_2.pngScreenshot_3.pngScreenshot_4.png

Translation works without any issues for couple of recent updates
In attachments i attached AppConfig.ini file (inside zip). You can copy (and replace) this file in .\VIIPlusLoader\ConfigFile\ to activate it
To revert it back to english - open the file and edit Language=Czech to Language=English

VCDS hex-v2 is also available in the following languages:
Chinese, Croatian, Czech, Danish, English, French, German, Hungarian, Italian, Polish, Portuguese, Romanian, Russian, Spanish, Swedish

VCDS hex-v2 support Czech, you can directly use Czech

[obdcarsale]

recommend install VIIPlusLoader-08.020.13 version, Maybe will release new VIIPlusLoader ,fix the bugs!

[flyfvdi]

My cable is still on the way, but as I get it should I use 08.020.13 as loader, or the newest one?

Thank you all very much for this good stuff! There are surely many people which appreciate it even more as me. Please keep it up

Please directly use the latest VIIPlusLoader-08.021.03

[flyfvdi]

A little update on my work on the upgradable 405 cable.

Did some logging of the communication to the external "crypto" chip that this cable is using and I am pretty sure that it is using i2c with address 0x50 and 0x51.
While booting, the STM32F405 send some messages to the chip for it to verify and a message can look like this.

"00 0A 80 08 00 00 05 01 01 02 03 04"

This message is of length 0x0A and is of type 0x0880. It contains some payload with a length of 5 bytes and the payload is 1, 2, 3, 4. This is one of the first message sent and I believe this is the STM saying hello.

MSG Type    : 0x0880 "Send"
MSG Length  : 0x0A
UN1         : 0x0000
Payload Len : 0x05
Payload Type: 0x01   "Test MSG ??"
Payload (without checksum):
0000 : 01 02 03 04
Payload NOT encrypted:
0000 : 01 02 03 04

The response from the chip for this message is:
"00 0E 8F 01 95 9C 4D 07 1C 71 3B 4F 40 10 90 00"

Response:

MSG Type    : 0x8F   "Receive"
Payload Type: 0x01   "Test MSG ??"
MSG Length  : 0x0E
Decrypted:
0000 : 00 02 00 00 00 00 00 00

The encryption used here is TEA in CBC mode and will be used for more or less all other messages.

Message: "00 10 80 08 00 00 0B 74 FB E7 23 87 0C 4A 2F 8D 65 C3"

MSG Type    : 0x0880 "Send"
MSG Length  : 0x10
UN1         : 0x0000
Payload Len : 0x0B
Payload Type: 0x74   "Get Version"
Checksum    : 0x65C3 "Checksum OK"
Payload (without checksum):
0000 : FB E7 23 87 0C 4A 2F 8D  | ..#..J/.

Decrypted payload:
0000 : 00 B3 2D 16 52 00 00 00  | ..-.R...

Type2    : 0x00
Nonce    : 0xB3 0x2D 0x16 0x52
Data Len : 0x00
Data field empty
Nonce resp: n1:"50 F7 39 28" n2:"E4 14 CC EC"

Response:
00 16 8F 74 6D B6 5D 8A FB 7B E3 7B 24 46 EB 5B 87 85 36 9D 41 6E 90 00

MSG Type    : 0x8F   "Receive"
Payload Type: 0x74   "Get Version"
MSG Length  : 0x16
Decrypted
0000 : 00 00 B3 2D 16 52 08 30 31 2E 30 30 2E 30 32 00  | ...-.R.01.00.02.

So I guess the SW version running on my encryption chip is "01.00.02" and that this is actually not an encryption chip but a small MCU?


Here is a message to verify my STM32F405 UID

"00 20 80 08 00 00 1B 70 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36 CB 4B"
(I have modified it to not show my UID if decrypted)

MSG Type    : 0x0880 "Send"
MSG Length  : 0x20
UN1         : 0x0000
Payload Len : 0x1B
Payload Type: 0x70   "Verify UID"
Checksum    : 0xCB4B "Checksum OK"
Payload (without checksum):
0000 : 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36

Decrypted payload:
0000 : 00 2B 80 41 FB 10 <16 byte MD5(UID + 0xFA padding) hash> 00 00

Type2    : 0x00
Nonce    : 0x2B 0x80 0x41 0xFB
Data Len : 0x10
Data:
0000 : <16 byte MD5 res like above>
Nonce resp: n1:"76 9C EC 42" n2:"24 7C 74 A4"

Response:
"0x00, 0x0E, 0x8F, 0x70, 0x2B, 0x04, 0xCA, 0xB5, 0x71, 0xE2, 0xA7, 0xBC, 0x8A, 0x08, 0x90, 0x00"

MSG Type    : 0x8F   "Receive"
Payload Type: 0x70   "Verify UID"
MSG Length  : 0x0E
Decrypted
0000 : 00 00 24 7C 74 A4 00 00

This last message is a bit more interesting coz it is sent to verify something "the UID" and will respond if verified success with modified nonce.

The calculated nonce response is now verified with the decrypted message and we see that "24 7C 74 A4" == "24 7C 74 A4" so my UID is good to go.
(But of course this is my fake UID since I am running the firmware on a different chip )

Messages I have seen is:
0x01: "Test MSG ??";
0x70: "Verify UID"
0x71: "Get RSA ??" (This one will be interesting)
0x74: "Get Version"
0x77: "UNKNOWN"; (Don't know what this one is yet)


I have been asked if I can make this firmware run on the 415 not upgradable cable and I don't see that this should be an issue.
However making it run and show up in VCDS is one ting but will it work on your car? It kind of look like the upgradable cable is using a different pin configuration then the 415. Perhaps some one can dig deeper and figure this out?


One more ting i discovered after I installed my STM back on the PCB is that when booting the bootloader will set RDP2 if other read protect levels are detected so my chip got locked again :|
But I have found and removed this code so it wont happen again. (If you are hoping to buy a cable without RDP then I am sorry to inform you that this will most likely never happen)

I have also extracted all the different firmware versions I could find to see what is changed and it looks like the firmware is recompiled for every time so they definitely have the source code for this and that it is true that they have made their own firmware.
(Unless this is the actual RT firmware an that the one extracted from the 415 is the fake one )

There is some more crypto stuff when booting like RSA1024 to extract the TEA key to decrypt part of the bootloader and this rsa data is located in the OTP area. I might also have to dump the chip one more time coz I forgot to check the RTC backup registers and if there are any data stored there.

(If you are still reading then you are probably just as interested in this then I am )

VCDS Hex-V2 with main chip STM32F405VGT6 and VII PLus Loader, their engineers develop themselves firmware.

[flyfvdi]

A little update on my work on the upgradable 405 cable.

Did some logging of the communication to the external "crypto" chip that this cable is using and I am pretty sure that it is using i2c with address 0x50 and 0x51.
While booting, the STM32F405 send some messages to the chip for it to verify and a message can look like this.

"00 0A 80 08 00 00 05 01 01 02 03 04"

This message is of length 0x0A and is of type 0x0880. It contains some payload with a length of 5 bytes and the payload is 1, 2, 3, 4. This is one of the first message sent and I believe this is the STM saying hello.

MSG Type    : 0x0880 "Send"
MSG Length  : 0x0A
UN1         : 0x0000
Payload Len : 0x05
Payload Type: 0x01   "Test MSG ??"
Payload (without checksum):
0000 : 01 02 03 04
Payload NOT encrypted:
0000 : 01 02 03 04

The response from the chip for this message is:
"00 0E 8F 01 95 9C 4D 07 1C 71 3B 4F 40 10 90 00"

Response:

MSG Type    : 0x8F   "Receive"
Payload Type: 0x01   "Test MSG ??"
MSG Length  : 0x0E
Decrypted:
0000 : 00 02 00 00 00 00 00 00

The encryption used here is TEA in CBC mode and will be used for more or less all other messages.

Message: "00 10 80 08 00 00 0B 74 FB E7 23 87 0C 4A 2F 8D 65 C3"

MSG Type    : 0x0880 "Send"
MSG Length  : 0x10
UN1         : 0x0000
Payload Len : 0x0B
Payload Type: 0x74   "Get Version"
Checksum    : 0x65C3 "Checksum OK"
Payload (without checksum):
0000 : FB E7 23 87 0C 4A 2F 8D  | ..#..J/.

Decrypted payload:
0000 : 00 B3 2D 16 52 00 00 00  | ..-.R...

Type2    : 0x00
Nonce    : 0xB3 0x2D 0x16 0x52
Data Len : 0x00
Data field empty
Nonce resp: n1:"50 F7 39 28" n2:"E4 14 CC EC"

Response:
00 16 8F 74 6D B6 5D 8A FB 7B E3 7B 24 46 EB 5B 87 85 36 9D 41 6E 90 00

MSG Type    : 0x8F   "Receive"
Payload Type: 0x74   "Get Version"
MSG Length  : 0x16
Decrypted
0000 : 00 00 B3 2D 16 52 08 30 31 2E 30 30 2E 30 32 00  | ...-.R.01.00.02.

So I guess the SW version running on my encryption chip is "01.00.02" and that this is actually not an encryption chip but a small MCU?


Here is a message to verify my STM32F405 UID

"00 20 80 08 00 00 1B 70 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36 CB 4B"
(I have modified it to not show my UID if decrypted)

MSG Type    : 0x0880 "Send"
MSG Length  : 0x20
UN1         : 0x0000
Payload Len : 0x1B
Payload Type: 0x70   "Verify UID"
Checksum    : 0xCB4B "Checksum OK"
Payload (without checksum):
0000 : 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36

Decrypted payload:
0000 : 00 2B 80 41 FB 10 <16 byte MD5(UID + 0xFA padding) hash> 00 00

Type2    : 0x00
Nonce    : 0x2B 0x80 0x41 0xFB
Data Len : 0x10
Data:
0000 : <16 byte MD5 res like above>
Nonce resp: n1:"76 9C EC 42" n2:"24 7C 74 A4"

Response:
"0x00, 0x0E, 0x8F, 0x70, 0x2B, 0x04, 0xCA, 0xB5, 0x71, 0xE2, 0xA7, 0xBC, 0x8A, 0x08, 0x90, 0x00"

MSG Type    : 0x8F   "Receive"
Payload Type: 0x70   "Verify UID"
MSG Length  : 0x0E
Decrypted
0000 : 00 00 24 7C 74 A4 00 00

This last message is a bit more interesting coz it is sent to verify something "the UID" and will respond if verified success with modified nonce.

The calculated nonce response is now verified with the decrypted message and we see that "24 7C 74 A4" == "24 7C 74 A4" so my UID is good to go.
(But of course this is my fake UID since I am running the firmware on a different chip )

Messages I have seen is:
0x01: "Test MSG ??";
0x70: "Verify UID"
0x71: "Get RSA ??" (This one will be interesting)
0x74: "Get Version"
0x77: "UNKNOWN"; (Don't know what this one is yet)


I have been asked if I can make this firmware run on the 415 not upgradable cable and I don't see that this should be an issue.
However making it run and show up in VCDS is one ting but will it work on your car? It kind of look like the upgradable cable is using a different pin configuration then the 415. Perhaps some one can dig deeper and figure this out?


One more ting i discovered after I installed my STM back on the PCB is that when booting the bootloader will set RDP2 if other read protect levels are detected so my chip got locked again :|
But I have found and removed this code so it wont happen again. (If you are hoping to buy a cable without RDP then I am sorry to inform you that this will most likely never happen)

I have also extracted all the different firmware versions I could find to see what is changed and it looks like the firmware is recompiled for every time so they definitely have the source code for this and that it is true that they have made their own firmware.
(Unless this is the actual RT firmware an that the one extracted from the 415 is the fake one )

There is some more crypto stuff when booting like RSA1024 to extract the TEA key to decrypt part of the bootloader and this rsa data is located in the OTP area. I might also have to dump the chip one more time coz I forgot to check the RTC backup registers and if there are any data stored there.

(If you are still reading then you are probably just as interested in this then I am )

VCDS Hex-V2 with main chip STM32F405VGT6 and VII PLus Loader, their engineers develop themselves firmware.

[flyfvdi]

A little update on my work on the upgradable 405 cable.

Did some logging of the communication to the external "crypto" chip that this cable is using and I am pretty sure that it is using i2c with address 0x50 and 0x51.
While booting, the STM32F405 send some messages to the chip for it to verify and a message can look like this.

"00 0A 80 08 00 00 05 01 01 02 03 04"

This message is of length 0x0A and is of type 0x0880. It contains some payload with a length of 5 bytes and the payload is 1, 2, 3, 4. This is one of the first message sent and I believe this is the STM saying hello.

MSG Type    : 0x0880 "Send"
MSG Length  : 0x0A
UN1         : 0x0000
Payload Len : 0x05
Payload Type: 0x01   "Test MSG ??"
Payload (without checksum):
0000 : 01 02 03 04
Payload NOT encrypted:
0000 : 01 02 03 04

The response from the chip for this message is:
"00 0E 8F 01 95 9C 4D 07 1C 71 3B 4F 40 10 90 00"

Response:

MSG Type    : 0x8F   "Receive"
Payload Type: 0x01   "Test MSG ??"
MSG Length  : 0x0E
Decrypted:
0000 : 00 02 00 00 00 00 00 00

The encryption used here is TEA in CBC mode and will be used for more or less all other messages.

Message: "00 10 80 08 00 00 0B 74 FB E7 23 87 0C 4A 2F 8D 65 C3"

MSG Type    : 0x0880 "Send"
MSG Length  : 0x10
UN1         : 0x0000
Payload Len : 0x0B
Payload Type: 0x74   "Get Version"
Checksum    : 0x65C3 "Checksum OK"
Payload (without checksum):
0000 : FB E7 23 87 0C 4A 2F 8D  | ..#..J/.

Decrypted payload:
0000 : 00 B3 2D 16 52 00 00 00  | ..-.R...

Type2    : 0x00
Nonce    : 0xB3 0x2D 0x16 0x52
Data Len : 0x00
Data field empty
Nonce resp: n1:"50 F7 39 28" n2:"E4 14 CC EC"

Response:
00 16 8F 74 6D B6 5D 8A FB 7B E3 7B 24 46 EB 5B 87 85 36 9D 41 6E 90 00

MSG Type    : 0x8F   "Receive"
Payload Type: 0x74   "Get Version"
MSG Length  : 0x16
Decrypted
0000 : 00 00 B3 2D 16 52 08 30 31 2E 30 30 2E 30 32 00  | ...-.R.01.00.02.

So I guess the SW version running on my encryption chip is "01.00.02" and that this is actually not an encryption chip but a small MCU?


Here is a message to verify my STM32F405 UID

"00 20 80 08 00 00 1B 70 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36 CB 4B"
(I have modified it to not show my UID if decrypted)

MSG Type    : 0x0880 "Send"
MSG Length  : 0x20
UN1         : 0x0000
Payload Len : 0x1B
Payload Type: 0x70   "Verify UID"
Checksum    : 0xCB4B "Checksum OK"
Payload (without checksum):
0000 : 38 YY 0D YY D8 2F YY 6E YY BF YY YY YY 79 4C YY YY 45 D8 YY YY YY YY 36

Decrypted payload:
0000 : 00 2B 80 41 FB 10 <16 byte MD5(UID + 0xFA padding) hash> 00 00

Type2    : 0x00
Nonce    : 0x2B 0x80 0x41 0xFB
Data Len : 0x10
Data:
0000 : <16 byte MD5 res like above>
Nonce resp: n1:"76 9C EC 42" n2:"24 7C 74 A4"

Response:
"0x00, 0x0E, 0x8F, 0x70, 0x2B, 0x04, 0xCA, 0xB5, 0x71, 0xE2, 0xA7, 0xBC, 0x8A, 0x08, 0x90, 0x00"

MSG Type    : 0x8F   "Receive"
Payload Type: 0x70   "Verify UID"
MSG Length  : 0x0E
Decrypted
0000 : 00 00 24 7C 74 A4 00 00

This last message is a bit more interesting coz it is sent to verify something "the UID" and will respond if verified success with modified nonce.

The calculated nonce response is now verified with the decrypted message and we see that "24 7C 74 A4" == "24 7C 74 A4" so my UID is good to go.
(But of course this is my fake UID since I am running the firmware on a different chip )

Messages I have seen is:
0x01: "Test MSG ??";
0x70: "Verify UID"
0x71: "Get RSA ??" (This one will be interesting)
0x74: "Get Version"
0x77: "UNKNOWN"; (Don't know what this one is yet)


I have been asked if I can make this firmware run on the 415 not upgradable cable and I don't see that this should be an issue.
However making it run and show up in VCDS is one ting but will it work on your car? It kind of look like the upgradable cable is using a different pin configuration then the 415. Perhaps some one can dig deeper and figure this out?


One more ting i discovered after I installed my STM back on the PCB is that when booting the bootloader will set RDP2 if other read protect levels are detected so my chip got locked again :|
But I have found and removed this code so it wont happen again. (If you are hoping to buy a cable without RDP then I am sorry to inform you that this will most likely never happen)

I have also extracted all the different firmware versions I could find to see what is changed and it looks like the firmware is recompiled for every time so they definitely have the source code for this and that it is true that they have made their own firmware.
(Unless this is the actual RT firmware an that the one extracted from the 415 is the fake one )

There is some more crypto stuff when booting like RSA1024 to extract the TEA key to decrypt part of the bootloader and this rsa data is located in the OTP area. I might also have to dump the chip one more time coz I forgot to check the RTC backup registers and if there are any data stored there.

(If you are still reading then you are probably just as interested in this then I am )

do you want to crack VCDS Hex-V2 with main chip STM32F405VGT6 and VII PLus Loader?

[Tib82]

unnamed.jpg

I've got an original HEX-CAN cable and I would like to clone it. Is there any possibilities to do it somehow?
What is the difference between the original and Kolimer's cable content? Only the a Serial Number? If I read ot the SN from the original and I inject it into Kolimer's cable content will it work like an original?

[fantomel]

HEX CAN USB calbles are 2 models, with 2 diferent chips. Old ones are BM/BL type where all chips have same ID and after the new ones are RL/RQ ones where each chip has it's own id paired with the license inside the cable.
If you have old one then you can easy clone your cable to another one because ftdi id remains the same , but in case of rl rq cable you will need to make a loader to inject that id into the program each time you use the clone cable or will not work.

So, long story short, the most easy way is to clone HEX-COM(rs232 models) or HEX-COM-USB (BM/BL types). These you "read" and write in the new device and they work.

[nextor]

Hi guys. Which type of clone is better and why, type A or type B?
Type A.jpgType B.jpg

Thanks for your answers!

[crouchinggerbil]

Hi guys. Which type of clone is better and why, type A or type B?
Type A.jpgType B.jpg

Thanks for your answers!

Neither of them are any good.

Here is a good one.

2021 Really HEX V2 VAG COM 20.4 VAGCOM 20.12.0 VCDS HEX V2 USB Interface FOR VW AUDI Skoda Seat Unlimited VINs For 1996 2021|Electrical Testers & Test Leads| - AliExpress

[nextor]

Neither of them are any good.

Here is a good one.

2021 Really HEX V2 VAG COM 20.4 VAGCOM 20.12.0 VCDS HEX V2 USB Interface FOR VW AUDI Skoda Seat Unlimited VINs For 1996 2021|Electrical Testers & Test Leads| - AliExpress

I know about the "REAL" HEX-V2 clones, but I need an interface for older cars. Can you please tell me which one of those from my post is better and why?