Long story short
I bought this cable to try to clear an error on my car but ended up opening it and exploring the hardware.
And after reading and searching for a while I acknowledged that the software should never be able to reach the internet nor we should try to update the firmware of the software, otherwise the cable would become a "brick", unusable! But in this area, we know that "bricked" or unusable may always mean some fun research and work.From the place I bought the cable, there are red warning to never use different software, turn on internet and keep antivirus software off, or the software could become unusable or the firmware on the cable to be updated and through some security measures, the update to "kill" the chip and turn the cable into a brick.So, before I try anything crazy, I tried to check if it was possible to make a backup of the chip so that if anything goes wrong, I could flash it back and revive the cable.So, after some research, digging through the datasheet and reference manual, I came to the conclusion I needed to dump at least 2 things:Complete FlashOption BytesAnd also check the RDP (Read Protection) state in FLASH_OPTCR register. It should be 0xaa in bits 08:15 (in RM0090, page 107) so that the chip can be read.
Hands on job now
So, the first thing, connections to be made.
1 - Configure OpenOCD to start the server for this scenario. I use almost always the same options. Start openocd in a terminal, like this:
$ src/./openocd -s tcl -f interface/jlink.cfg -c "transport select swd; adapter speed 2000; reset_config srst_only srst_nogate" -f target/stm32f4x.cfg
Open On-Chip Debugger 0.12.0+dev-01390-gb4518ab78 (2026-02-09-18:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V9 compiled Sep 1 2016 18:29:50
Info : Hardware version: 9.60
Info : VTarget = 3.290 V
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x2ba01477
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : [stm32f4x.cpu] Examination succeed
Info : [stm32f4x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections2 - In another terminal we start gdb.
$ gdb-multiarch -nx
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)The -nx options are only to avoid gdb-multiarch to run any startup scripts (have have one from another project that was interfering with this one)
3 - Change the architecture in gdb to arm
(gdb) set architecture arm
The target architecture is set to "arm".
(gdb)4 - Connect to the target
(gdb) target extended-remote :3333
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x08032ca8 in ?? ()
(gdb)You'll see this in OpenOCD terminal:
Info : accepting 'gdb' connection on tcp/3333
[stm32f4x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08032ca8 psp: 0x200067d0
Info : device id = 0x20016419
Info : flash size = 512 KiB
Info : Single Bank 512 kiB STM32F42x/43x/469/479 found
Info : flash size = 512 bytes5 - Halt the cpu of STM32F429VET6
(gdb) monitor halt
(gdb)6 - Dump the entire flash of the chip.From the RM0090, page 71, we check memory regions of interest to dump
We know the chip has 512Kb
(gdb) x/1uh 0x1FFF7A22
0x1fff7a22: 512
(gdb)from 0x0800 000, adding 512Kb which is 524288 bytes, so in hex is 0x0808 0000. So these are the beginning and end of the flash memory we want to dump.
(gdb) dump binary memory hex_vii_full_flash.bin 0x08000000 0x08080000
(gdb)and we get a hex_vii_full.bin file.
$ ls -lah hex_vii_full_flash.bin
-rw-r--r-- 1 user user 512K Apr 1 17:39 hex_vii_full_flash.bin7 - Dump the Option bytes
To find the Option Bytes, it's always kind of a cat and mouse chase.First, let's look at the memory map, RM0090, page 65, we see that the base address starts at 0x4002 3c00
then we find Flash Interface Registers, we click and we jump to page 99 and we scroll down until we find FLASH_OPTCR for STM32F429VET6
In the register information we see the offset is 0x14, so, in gdb we are going to read this piece of information at the base address + offset:
(gdb) x/1xw 0x40023C14
0x40023c14: 0x0fffaaed
(gdb)We can confirm that bits 8:15 are 0xaa, which means the RDP is level 0, no read protection, which is great.While the critical data resides in the 8 bytes of FLASH_OPTCR and FLASH_OPTCR1, I performed a 28-byte dump starting from the base address 0x40023C00. This provides the full context of the Flash Interface, including the Status Register (SR), ensuring that we aren't reading the Option Bytes during a pending write operation.
(gdb) dump binary memory hex_vii_options.bin 0x40023C00 0x40023C1C
(gdb)This command dumped 28 bytes of information as we can see:
$ ls -lah hex_vii_options.bin
-rw-r--r-- 1 user user 28 Apr 1 17:39 hex_vii_options.bin8 - Dump the OTP area
Many clone manufacturers of these cables use the OTP area to write an Hardware ID or a Digital Signature. If this was the case we would have this information also saved.Where is the OTP area. Back to the RM0090, we search the term OTP and we cycle through the several occurrences until we find the memory address at page 75:
So, we dump the memory from the start plus 28 bytes.
(gdb) dump binary memory hex_vii_otp.bin 0x1FFF7800 0x1FFF7A10
(gdb)and we end up with another bin file:
$ ls -lah hex_vii_otp.bin
-rw-r--r-- 1 carlos carlos 528 Apr 1 17:39 hex_vii_otp.binSo, we are done with the dumps.
From now on is only curiosity. We explore the contents of these files.3 files
hex_vii_full_flash.bin
hex_vii_options.bin
hex_vii_otp.binSo, I ran a strings command on the full flash memory file, for curiosity:Of course, the output is enormous so I paste here the interesting strings I found:
Custom HID Config
Custom HID Interface
STMicroelectronics
Ross-Tech HEX-V2
0000001For the OTP, I used hexdump to see the contents:
$ hexdump -C -v hex_vii_otp.bin
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000110 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000150 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000180 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000190 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000210This means the area contains no data. If there was data here, contents would be different from 0xff all over the place.For Option Bytes, the expected:
$ hexdump -C -v hex_vii_options.bin
00000000 03 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 80 ed aa ff 0f 00 00 ff 0f |............|
0000001cWith these, if someone bricks his cable, with an accidental firmware update, chances are quite good to revive the cable with the full flash. That's all that can be done, at least form my level of knowledge!
Edited;
I have been looking into the binary file of the full dump, just to confirm things make sense when it comes to look to the RM0090 and looking into the file, for instance, printing the first 64 bytes, I can see the Initial Stack Pointer (0x2001 6fe0) and the Reset Vector (0x0800 019d), which are inside RAM and Flash, respectively.
$ hexdump -v -C -n 64 hex_vii_full_flash.bin
00000000 e0 6f 01 20 9d 01 00 08 cd 68 00 20 d7 4d 00 20 |.o. .....h. .M. |
00000010 ed 5f 00 20 71 15 00 20 1f 9d 00 20 0c d6 00 08 |._. q.. ... ....|
00000020 10 1e 00 00 d4 ff 00 00 60 d4 eb e7 9d 6f 00 20 |........`....o. |
00000030 79 1d 00 20 00 c0 01 20 bb 69 00 20 91 74 00 20 |y.. ... .i. .t. |
00000040Then, with a little more digging with the command `strings`
$ strings -n 10 -t x hex_vii_full_flash.bin
52f7 !hHbS !hHb
543d !hHbS !hHb
5557 !hHbS !hHb
6026 nHahHcmHahIkH`lHahIk
819b @../Src/main.c
8fa7 Custom HID Config
8ff3 Custom HID Interface
9033 STMicroelectronics
906f Ross-Tech HEX-V2
95a7 ../Src/usbd_conf.c
bc93 =j&&LZ66lA??~
d1aa Dlexpand 32-byte kexpand 16-byte k
d24d 6i!Xfffffffffffffffffffffffffffffff
d3b0 cccbcccbcccbcccb
d600 0123456789
f47a 001.00.03
fff0 !TEST CODE TEST!
10911 !00000000#(,
23ef9 p!hHa h@i
23f05 p!hHa h@i
23f11 `!hHa h@i
23f1d `!hHa h@i
23f6d p!hHa h@i
23f79 p!hHa h@i
23f85 `!hHa h@i
23f91 `!hHa h@i
2b3f2 h@h8C!hH`
2c277 !hHbS !hHb
2c395 !hHbS !hHb
2c4af !hHbS !hHb
2f67f ..\Src\hw_kline_layer.c
2f803 ..\Src\hw_kline_layer.c
30b75 H H H!H!H"H
328af #H$H$H%H%H&H&H'H'H(H(H)H)H*H*H+H+H,H,H-H-H.H.H/H/H0H0H1H1H2H2H3H3H4H4H5H5H6H6H7H7H8H8H9H9H:H:H;H;H<H<H=H=H>H>H?H?H@H@HAHAHBHBHCHCHDHDHEHEHFH
32d30 uC/OS-III Idle Task
33c6c uC/OS-III Stat Task
33daf 44 a g`g``
345bc uC/OS-III Tick Task
34708 uC/OS-III Timer Task
353cf @../Src/main.c
37121 xE@ yE@ z@
371f9 x u(y`uhibk
3838f Custom HID Config
383db Custom HID Interface
3841b STMicroelectronics
38457 Ross-Tech HEX-V2
389f7 ../Src/usbd_conf.c
3e397 =j&&LZ66lA??~
3f8ae Dlexpand 32-byte kexpand 16-byte k
3f951 6i!Xfffffffffffffffffffffffffffffff
3fab4 cccbcccbcccbcccb
3fc44 tLktMonitorTask
3fc5c tInteractCommTask
3fc74 tTxInteractCommTask
3fc90 tDxControllerTask
3fca8 tUdsControllerTask
3fcc0 tTp20ControllerTask
3fcd8 tKLineControllerTask
3ff48 59233FED922564F5
46cca UT*%/b<wuZ
6c56c |BC3j#G"f:;-
6d30f KafS`5gPT*
78db9 atm[(L#A.2
7aa0e ^'4>1u$bW]BAnd we find multiple evidences of what this firmware is and/or do
For instance, from offset 0x0000 to 0xFFFF, is probably the bootloader where we find probably a leftover of developers "signature" - !TEST CODE TEST!. this marks the end of Sector 3 and the start of sector 4, the main application.
Operating system is uC/OS-III and its tasks
32d30 uC/OS-III Idle Task
33c6c uC/OS-III Stat Task345bc uC/OS-III Tick Task
34708 uC/OS-III Timer TaskThis seems to be cable specific tasks
3fc44 tLktMonitorTask
3fc5c tInteractCommTask
3fc74 tTxInteractCommTask
3fc90 tDxControllerTask
3fca8 tUdsControllerTask
3fcc0 tTp20ControllerTask
3fcd8 tKLineControllerTaskSome USB descriptors for update, inside the bootloader
8fa7 Custom HID Config
8ff3 Custom HID Interface
9033 STMicroelectronics
906f Ross-Tech HEX-V2
and again USB descriptors for diagnostics, I guess. It suggests that the system treats the device identification separately, adding redundancy in case of OS failure we can still detect the device for reflash.
3838f Custom HID Config
383db Custom HID Interface
3841b STMicroelectronics
38457 Ross-Tech HEX-V2This seems to be the version either of the bootloader or the OS itself
f47a 001.00.03I think that's all
Thanks once more! I'll attach files later!


Comments