Differences

This shows you the differences between two versions of the page.

--- disassembled_devices:vcds_clone_cable [2025/10/05 22:10] – [Hex V2] admin
+++ disassembled_devices:vcds_clone_cable [2025/10/26 01:01] (current) – [Patching RDP2 theoretically] admin
@@ Line 43: / Line 43: @@
 > 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 - [[https://www.digital-kaos.co.uk/forums/showthread.php/99750-VAG-COM-VCDS-EVERYTHING?p=4732973&viewfull=1#post4732973|Source]]. It is uncertain how the firmwares and loaders differ, the credentials are all the same ones of Fly (?!). \\
+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 ([[https://www.digital-kaos.co.uk/forums/showthread.php/99750-VAG-COM-VCDS-EVERYTHING?p=4732973&viewfull=1#post4732973|Source]]). This is no ad: Do not support clones. \\
 __DO NOT UPDATE FIRMWARE__ on a clone cable (e.g. from aliexpress) using VIIPlusLoader 08.023.04 or newer!
 Viiplusloader [[https://www.digital-kaos.co.uk/forums/showthread.php/1028175-Repair-locked-VCDS-STM32F405?p=4561596&viewfull=1#post4561596|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. \\
+Blue LED will flash shortly on USB connect and then USB disconnects automatically.
 [[https://stm32world.com/wiki/STM32_Readout_Protection_(RDP)|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). \\
+Note: Tripped RDP2 with no key or bl access is a bad player's move - there are other ways to prevent people from updating.. could have at least made a challenge/"game" out of it :/ expand minds & learn how to //fly// :) think about it. \\
 Summary of RDP:
    * RDP1: ST-Link / SWD access and Bootloader access is blocked (read&write). You can erase & reflash using ST-Link, but only after a full mass erase (resets to RDP0). \\
-   * RDP2: External access (read&write) (ST-Link, JTAG, SWD, UART, USB bootloader) → permanently disabled. Cannot be undone! Option bytes → permanently locked. You cannot downgrade back to RDP1 or RDP0. \\
+   * RDP2: External access (read&write) (ST-Link, JTAG, SWD, UART, USB bootloader) → permanently disabled. Cannot be undone! Option bytes → permanently locked. No, you cannot "downgrade" back to RDP1 or RDP0. \\
 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. \\
@@ Line 86: / Line 88: @@
-==== How to update/unbrick cable? ====
+==== How to unbrick cable? ====
-Updating can be done over USB if your cable is updateable (be aware of fly-loader bricking cables intentionally!) \\
+Updating can be done over USB if your cable is updateable and not bricked (be aware of fly-loader bricking cables intentionally!) \\
-Flashing can be done via SWD programming interface if RDP2 is not set. If RDP2 is set and your cable is bricked, the easiest choice is to replace the STM32 MCU. You can get STM32F405VGT6 [[https://aliexpress.com/item/1005006862646663.html|e.g. on aliexpress for ~3€]] (probably clones?). Desolder bricked RDP2 MCU and replace with fresh one //(use the Flux, Luke!)// - better flash a RDP0 firmware. \\
+Flashing can be done via SWD programming interface if RDP2 is not set. "brick-by-fly" sets RDP2. If RDP2 is set and your cable is bricked, the easiest choice is to replace the STM32 MCU. You can get STM32F405VGT6 [[https://aliexpress.com/item/1005006862646663.html|e.g. on aliexpress for ~3€]] (probably clones? it works fine). Desolder bricked RDP2 MCU and replace with fresh one //(use the Flux, Luke! Always flush&Wash, this time with Isopropanol)// - better flash a RDP0 firmware then. \\
-Tip: To remove LQFP64 package without hot air rework station, take a rotary tool and cut through all pins carefully, then clean each pad on PCB. \\
+Tip to remove LQFP64 package without hot air rework station: take a rotary tool and cut through all pins carefully, then make PCB clean.
 Alternative: Coat wire with tin and solder nonstop to all pins to be able to desolder all pins concurrently with a soldering iron - [[https://www.youtube.com/watch?v=Vou2xlJkuoU|see this random YT video]] \\
+The ways I have seen people up most with: ripping of pads by lifting pins tediously one by one. Well, there is always "ugly" pcb-wire to the rescue, right?
 ==== Patching RDP2 theoretically ====
-🗒️ Note: I have not tested/flashed this yet!
+🗒️ Note: I have not tested/flashed this yet! This is a theoretical approach you could follow with the upper files. \\
 ⚠️ Always dump your firmware if it is in RDP0! \\
-❌ Only write something with RDP set if you are really sure - RDP2 cannot be reversed! \\
+❌ Only write something with RDP set if you are really sure - RDP2 cannot be reversed! Better have your soldering skills ready and a fresh MCU.\\
-❌ Writing dump with RDP will probably not work as there are no RSA keys for OTP on the internet (AFAIK). \\
+❌ Writing dump with RDP might still not work as there are no RSA keys for OTP on the internet (AFAIK). \\
 ✅ Get a dump with RDP0 (or RDP1?) - Share your RDP0 dumps. \\
-❓ 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 (?). \\
+❓ Theoretically, it should be possible to write back dump if you patch RDP2 first (I have not tried it yet). I don't know if you might still need the RSA key in OTP or need to also patch security functions in dump using the key in 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?**
+**How to theoretically remove RDP2 from dump? idk, I have not tried myself (only had one spare MCU after brick-by-fly) - I imagine the easiest first approach to try it could be like this:** \\
 . Load the Dump into a Disassembler like Ghidra, Binary Ninja, Radare2 or IDA Pro. \\
@@ Line 124: / Line 127: @@
 </code>
-Search for:
+Search for sth like:
 <code>
 LDR  R0, =0x40023C14   ; FLASH->OPTCR
@@ Line 136: / Line 139: @@
 . Repack the Binary \\
 Save your modified binary. \\
-Reflash it to a (clean) MCU (no RDP2 must be set). \\
+Cross your fingers that this is sufficient and reflash it to a (clean / RDP0) MCU __on your own risk__ and write up your methods -(I have no spare MCU atm, do you take the risk?:). \\
 Use STM32CubeProgrammer or OpenOCD to flash to unlocked MCU with ST-Link V2 or J-Link as programmer. \\