Table of Contents

VCDS clone cable

All info are taken from the web, there is nothing new here. I've just complemented the disassembly photos.

Disclaimer

🗒️ Note: Always try to get official genuine tools and hardware to support the original developers. I do not encourage using clones in any way! Info on this page are for educational and research purposes only!

Hex V1

Hex V1 cables mostly use ATmega162 MCU, with support for cars up to 2017 - (there are other versions e.g. NEC, etc.). With the “good ATmega162 clones” you can update the firmware. Even if your Hex-cable supposedly is V2, it is V1 if it has no STM32-MCU, no matter what the sticker says.

Here some pictures of Hex V1 with ATmega:

hexv1_1.jpg
hexv1_2.jpg
hexv1_3.jpg

Search online for “Kolimer Loader 9.2” how to update Hex V1 ATmega162 cable firmware to use with official release software. Read its _Readme.pdf! It contains a guide how to update firmware.
For anything firmware related USB-power is not enough: It is necessary to connect OBD2 port to car for 12V.
VAGCOM_HWType.exe determines the hardware type - RTFM! = Read The Freaking Manual. In this case the _Readme.pdf. There are different steps to take for the different hardware versions. You can also chose the language with which the cable works.

To keep internet on, add “127.0.0.1 update.ross-tech.com” to block update in “%WINDIR%\system32\drivers\etc\hosts” file or download blockvcdshosts.rar and run .bat as admin.

Need schematics? Download schematics: vagcom_rev1_sch.pdf
Here is schematics of Hex V1 with addition of how to replace the SI9241AEY with transistors.

If you have one of the “not so good” cables, e.g. with MCU marked "HL008 ARM", see read these posts (not tested, I do not own this).

Hex V2

Hex V2 cable has a STM32F4 MCU - there are versions with STM32F405, STM32F415 and STM32F429. If it has no ARM / STM32 MCU, it is a (relabled) V1, NOT V2!
Why is V2 needed? 2017/2018 models use UDS protocol (Unified Diagnostic Services, ISO14229) and enforce new security measures - the ATmega162 is too constrained for that.
FYI: VW ID3 is supported with VCDS Beta 20.9.1.

hexv2_1.jpg
hexv2_2_pinout.jpg
hexv2_3.jpg
hexv2_4.jpg

“Real” clone cables with Viiplusloader come from FLYFVDI. There are also loaders by Kolimer and Badrax. If your hex v2 came with Badrax or Kolimer loader, then you cannot use the VIIPlus loader. To distinguish your clone cable and what loader to use, see the serial number:

VIIPlusLoader，Device serial number is 1N0XXXXX，Tag serial number is H11-002336
BadraxVIILoader，Device serial number is 2N00XXXX，Tag serial number is F33-415407
KolimerVIILoader，Device serial number is 3N00XXXX，Tag serial number is F33-415407

If you have a clone Hex v2 with Badrax or Kolimer loader you must pay a fee to unlock your hex v2 to allow future updates by FLY - Source. It is uncertain how the firmwares and loaders differ, the credentials are all the same ones of Fly (?!).

DO NOT UPDATE FIRMWARE on a clone cable (e.g. from aliexpress) using VIIPlusLoader 08.023.04 or newer! Viiplusloader 08.023.04 - 08.023.05 has set in place new measures to lock out the non-FLY clone cables and prevents to downgrade: The cable will intentionally be bricked by loader program. Blue LED will flash shortly on USB connect and then USB disconnects automatically.
As STM32 firmware has RDP2 (readout protection) set, you cannot re-flash the firmware (only if firmware allows it, which it does not in this case).
Summary of RDP:

STM32F4 has an OTP (one time programmable) memory, in which RSA keys are written. OTP is what the name says: Can only be programmed once and not be undone. So when erasing the MCU, the key persists of course. The RSA key in OTP cannot be read out, no matter the RDP level. There is a HAL (high abstraction layer) providing functions to interact with the key, but there is no direct access in this controlled environment. Before RDP option byes are set, the RSA key has to be written to OTP. The RSA key is often utilized for additional DRM protection within the firmware, enabling secure authentication, content encryption - it also unlocks external access again.

How is updating done on FLY cables then? Firmware can be updated by itself (from inside) (no matter which RDP level), but only if the running firmware was explicitly written to support self-updates (e.g. with an internal bootloader update routine). Fly uses the same method to intentionally brick other cables.

If you think you can r/w MCU with RDP2, see how to EMFI glitch STM32F4 here or read up on (less ideal) voltage glitching here and here.

The easiest way to do damage control on a bricked RDP2 MCU is to de-solder it and replace it with a brand new one, allowing you to flash the firmware. Then you either have a dump with RDP0 / RDP1 or you need to try to patch the RDP2 dump, as you probably do not have the RSA keys of OTP. W/o the RSA keys in OTP the firmware might still not work (?) (I still need to try it).

There is a dump (with RDP2 set!) on digital-kaos of Fly's FW by Badrax
If you happen to have a dump with RDP0, please share it :)

There is also a collection of FWs (RDP2) for F405 found online: 405-fw-files.zip. Hint on how to port to F429 inside (not mine).

Firmware offsets are: bootloader (0x08000000-0x08010000) and firmware (0x08020000-).
With F415 the external crypto chip (LKT4106) is now emulated and you can find the emulation code in the image present at address 0x08010000.

Pinout for SWD / ST-Link on J2-header (seen in second photo) is as follows (make sure it is 3.3V and not 5V):
From OBD2 side | | 3V3 - SWDIO - SWDCLK - GND - NP | | USB-cable-side

Alternatively, flashing over USB via DFU (“Device Firmware Upgrade”) is possible too (but only when RDP2 is NOT set):

For DFU, set the boot0 pin high and then power the STM32. This will start the internal bootloader, then it can be programmed with STM32Cube Programmer. (Select USB from the blue drop down list. Then Refresh and Connect).

Flash deadlock fix: Read this how to unbrick after bad firmware (has nothing to do with RDP!)

Generally speaking, read 99750-VAG-COM-VCDS-EVERYTHING or print version. As this thread is closed, new ones were opened like this one
German Thread on digital-eliteboard: vcds-v2-supportthread-howto-fragen-infos.492334/

patching

🗒️ Note: I have not tested/flashed this yet!

⚠️ Always dump your firmware if it is in RDP0! (is there RSA key in OTP then?)
❌ Only write something with RDP set if you are really sure - RDP2 cannot be reversed!

❌ Writing dump with RDP will probably not work as there are no RSA keys for OTP on the internet (AFAIK).
âś… Get a dump with RDP0 (or RDP1?) - If you have a RDP0 dump, please share it!

âť“ Theoretically, it should be possible to write back dump if you patch RDP2 first (I have not tried it yet). I believe that you will still need the RSA key in OTP or need to also patch security functions in dump using the key, which might be used inside firmware (?).

❌ Patching out potential security functions which use RSA keys of OTP in dump is not described here - it is probably an excessive task.

How to theoretically remove RDP2 from dump?

1. Load the Dump into a Disassembler like Ghidra, Binary Ninja, Radare2 or IDA Pro.
Use tools like Binwalk to analyze structure.

2. Search for RDP Option Byte Writes:

RDP is set by writing 0xCC to the RDP option byte address: 

For STM32F405:
    Option bytes are configured using FLASH->OPTCR (address: 0x40023C14)
    RDP value is set in the lower byte of FLASH->OPTCR
    Bootloader may use:
        FLASH->OPTCR = 0xXXXXXXXX;
        or
        FLASH_OPTCR_RDP = 0xCC

Search for: 

LDR  R0, =0x40023C14   ; FLASH->OPTCR
MOV  R1, #0xCC000000   ; sets RDP2
STR  R1, [R0]

3. Patch It
Change the write value to 0xAA (RDP1) or 0xFF (RDP0), or NOP out the instructions.

4. Repack the Binary
Save your modified binary.
Reflash it to a (clean) MCU (no RDP2 must be set).
Use STM32CubeProgrammer or OpenOCD to flash to unlocked MCU with ST-Link V2 or J-Link as programmer.