Jabe UD-1200 vs. Jabe UD-1200 PRO vs. JBC CD-2SQE - need Firmware for UD-1200

[DavidAlfa]

If you had to hack the Tap ID, then it's a clone, so it makes no sense to attack it, you want to extract the fw from a genuine stm32.

Maybe a glitch attack?
https://github.com/CTXz/stm32f1-picopwner


Edit: I tried it. Had some baffling issues, which I got around.
When it finally worked, it gave me a perfect firmware dump.

For this to work you'll likely need to modify the board, as the stm32 is powered by a Pico pin, you will need at least to remove all the capacitors and everything connected to VDD, otherwise the glitch will be filtered out or it might consume too much for the pico.
The easiest would be to desolder the stm32 and put it into a breakout board.

[JimKnopf]

I ordered some pico H/WH devices and some breakout boards for 32 to 100 pin chips. The pico devices will arrive next week. Looks like a cheap and reliable solution. No need to use the chipwhisperer (maybe next time).

[DavidAlfa]

I tested it with a J-Link V8 clone from aliexpress, which seem to use a relabeled CKS32F103 (CPUTAPID =  0x2ba01477).
It also worked! But I had to apply the patch, adding set CPUTAPID 0 to target/stm32f1x.cfg.
In my case the openocd folders lived in /usr/share/openocd/scripts.

[JimKnopf]

@DavidAlfa And how did you do that? Can you provide the secrets?

[DavidAlfa]

I mean I extracted the firmware from the Jlink clone using this same attack.

[DavidAlfa]

JimKnopf, regarding your PM, did you follow the fixes I made here? (Posted in an earlier message).
https://github.com/CTXz/stm32f1-picopwner/issues/2

Buepill boards normally have two jumpers for boot0/boot1.
For boot0, remove the jumper and connect the cable in the pin at the middle of the 3.
For Boot1, don't use any resistor, just place the jumper to "1" position.

Just like shown in the github repo (Click for larger pic):

[JimKnopf]

@DavidAlfa

It's wired up correcly. The blue-pill is powered by the pico. I can set/unset RDP and programm the blue-pill with the ST-Link V2 clone.

Each device is recognized, config files are present, openocd works, every thing is fine and should work.

The only thing is, it doesn't work. I didn't remove any component from pico/blue-pill. I added a 10k resistor to the blue-pill boot1/3,3V pin. I guess it's more software related. I also tried external powered USB hub.

I'm running the stm32f1-picopwner on a Arch system which means it's a rolling release.
  openocd-git 0.12.0.r73.g1998b1e5a-1
  python 3.11.5-1
  python-pyserial 3.5-5

I got an error each time i execute the dump.py script:

Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9)
2: USART2 - RX: PA3  TX: PA2)
3: USART3 - RX: PB11 TX: PB10)
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Traceback (most recent call last):
File "/media/root/Daten/...[...].../stm32f1-picopwner/dump.py", line 479, in <module>
    upload_target_fw(get_target_fw_bin(args.targetfw, sram_entry_point, usart))
File "/media/root/Daten/...[...].../stm32f1-picopwner/dump.py", line 295, in upload_target_fw
    raise Exception(
Exception: Failed to load target firmware to SRAM
openocd output: Error: Invalid command argument

It's the first time i use a RP pico board. I just pressed the button and connected to usb port. It show up as drive. I put the attack.uf2 file on it which leads to a reboot of the pico. Seems it works as expected.

[JimKnopf]

Tried the ST-Nucleo board as target. It gave me this errors:

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
Traceback (most recent call last):
  File "/...[...].../stm32f1-picopwner/dump.py", line 419, in <module>
    rdp_status = get_rdp_status()
                 ^^^^^^^^^^^^^^^^
  File "/...[...].../stm32f1-picopwner/dump.py", line 255, in get_rdp_status
    raise Exception(
Exception: Could not determine read protection status
openocd output: TARGET: stm32f1x.cpu - Not halted

[DavidAlfa]

The problem is clear:

openocd output: Error: Invalid command argument

Something might have changed in newer versions of Openocd.

Try Ubuntu 20, boot a live system and try there.
It seems to me your Linux it's too new. Like always happens.

In your last case, I had the same error.

I repeat, did you modify the dump.py script as I explained?

EDIT: It turns out OpenOCD 0.10 and 0.12 have some differences.
My fix should not be applied for OpenCD 0.12!

You can make some tests. Connect the STlink to the target (BluePill / STM32 Nucleo):

In one window, run:
    openocd -f interfaces/stlink.cfg -f target/stm32f1x.cfg

Should start a debug session. Now open another window:
    telnet localhost 4444

And you should be in the openocd shell.

Try running these commands:
init 
reset halt
stm32f1x options_read 0

Code: [Select]

> init                   
> reset halt             
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000200 msp: 0x20005000
> stm32f1x options_read 0
option byte register = 0x3fffffe
write protection register = 0xffffffff
read protection: on
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff


[JimKnopf]

@DavidAlfa
There was no need to change dump.py. I got the stlink.cfg in place. Works great if i start openocd with stlink v2 clone manually. I can flash the blue-pill and read RDP status in openocd:

> stm32f1x options_read 0
device id = 0x20036410
STM32 flash size failed, probe inaccurate - assuming 128k flash
flash size = 128 KiB
option byte register = 0x2a92bfe
write protection register = 0xffffffff
read protection: on

As you can see, the original typing "read protection: on" from dump.py is correct in my case (for my openocd version).

I tried the openocd commands by hand and compared the response message from openocd.

The command from dump.py line 266:

["init", "reset halt", "exit"],

should give the output "pc: 0x20000" used in line 270.
When i do this manually in openocd i get this:

> init
> reset halt
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000200 msp: 0x20005000
>

Could this cause the error?

[DavidAlfa]

pc: 0x08000200 means it's booting from flash, so BOOT1 is set wrong. Forget the resistor. Just:

- Set BOOT1 jumper to 1.
- Remove BOOT0 jumper, connect to pico GPIO5.
- Press reset button on the Bluepill / Nucleo board.

And try the openOCD test again.

[JimKnopf]

@DavidAlfa

> init
> reset halt
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x20000108 msp: 0x20005000

Now it matches to dump.py.

[JimKnopf]

Loading the image file works.

> load_image /...[.\ \..].../stm32f1-picopwner/target/target_108_usart1.bin 0x20000108
2104 bytes written at address 0x20000108
downloaded 2104 bytes in 0.140170s (14.659 KiB/s)

Something must be wrong with line

479: upload_target_fw(get_target_fw_bin(args.targetfw, sram_entry_point, usart))

I have a blank in the path name which i had to escape when loading the file manually in openocd.

[JimKnopf]

Oh noooo. The path was causing the error. I moved the whole directory to my home dir and started again. No longer a blank in the path name let me start the process.

Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware

 00 50 00 20 01 02 00 08 ef 01 00 08 f1 01 00 08
 f3 01 00 08 f5 01 00 08 f7 01 00 08 00 00 00 00

...
 70 6f 73 75 65 72 65 2c 20 65 6c 69 74 20 6d 61
 67 6e 61 20 6d 6f 6c 6c 69 73 20 64 6f 6c 6f 72
 2c 20 76 65 6c 20 63 6f 6e 76 61 6c 6c 69 73 20
 6c 65 6f 20 6c 65 63 74 75 73 20 61 74 20 6e 69

...
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Target has stopped sending data, assuming dump is complete
Dumped 65536 bytes
Output saved to dump.bin

[JimKnopf]

@DavidAlfa

The dump.bin matches your 103_test.bin file until the last few bytes.

[DavidAlfa]

I could replicate the issue, seems to happen sometimes when connecting the STLink VDD to the target board.
But only happened few times. No idea otherwise. Maybe loose wires.
And never connect the debugger unless you're told to do so.

Now, for the nucleo board, there must be a jumper somewhere to isolate VDD, you should open it.

The dump.bin matches your 103_test.bin file until the last few bytes.

It's fine. The original file doesn't use the entire 64KB, so the rest is padded with FF.

[JimKnopf]

@DavidAlfa

Today i tried the trick with the Jabe UD-1200 PRO board. At the moment, i get this error:

Traceback (most recent call last):
  File "/.../stm32f1-picopwner/dump.py", line 419, in <module>
    rdp_status = get_rdp_status()
                 ^^^^^^^^^^^^^^^^
  File ".../stm32f1-picopwner/dump.py", line 255, in get_rdp_status
    raise Exception(
Exception: Could not determine read protection status
openocd output: TARGET: stm32f1x.cpu - Not halted

When connecting the ST-Link V2 clone (Vcc included), i can read the RDP status. To me it looks like the pico can't power the target board. This is one of the mentioned issues on github project page:

The power draw of the target board is too high for the Pi Pico to handle (Try buffering the power pin with a BJT or MOSFET)

I connected external 3,3V to the board Vcc pin1 on the JTAG pin-header and powersupply GND to the pico GND. I swapped the pico-GND connector from UD-122 Pro board to the Emiter pin of a BD139 NPN transistor, pico GP2 (Vcc) pin via 10k resistor to BD139 base pin and it's collector pin to GND on the UD-1200 PRO board. I also connected the ST-Link V2 clone GND to the pico GND.
With this NPN transistor as a switch, i get the same error.

Edit: I added one connection from 3,3V via 1k resistor to pin 28/PB2 that is not visible in the image.

[DavidAlfa]

Are you sure BOOT0 isn't connected directly to gnd? I see that a lot.
But yeah, the problem is probably the capacitance.
Even if you add a transistor, the problem remains, the capacitors will filter out the ultra short power cut.

Better you transfer it to the breakout board.

[JimKnopf]

@DavidAlfa Boot0 was indeed connected to GND. I ordered some breakout boards and placed the STM on it and wired up the connection to the pico and ST-Link probe. I first tried only VDD_1/VSS_1. Then i connected the other VDD_2/VSS_2 to VDD_4/VSS_4 pins to power the STM32F103.

SWDIO is connected to PA13/Pin46 and SWCLK to PA14/Pin49.  Dump.py is waiting for debug probe to be connected. Light on ST-LinkV2 is on, not flashing. Something is missing i guess.

I tried to connect via openocd directly without the pico. But openocd telling

Info : STLINK V2J42S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.213132
Error: init mode failed (unable to connect to the target)

Do i need additional connections on the STM32F103? Never used to run a chip off the board.

[DavidAlfa]

First connect vdd and gnd directly to power. Then try making the stlink talk to it.
It should really work like that.
Make sure you're connecting SWD to the right pins!

[JimKnopf]

@DavidAlfa OK, i added VBAT and VDDA to VDD pins. Still no luck with pico/stm32f1-picopwner.

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
Traceback (most recent call last):
  File "/...[...].../stm32f1-picopwner/dump.py", line 419, in <module>
    rdp_status = get_rdp_status()
                 ^^^^^^^^^^^^^^^^
  File "/...[...]...stm32f1-picopwner/dump.py", line 255, in get_rdp_status
    raise Exception(
Exception: Could not determine read protection status
openocd output:

But, if i connect the STLinkV2 without the pico, i could start openocd and read the readprotection status (NRST and VDD connected to STLinkV2, GND and VDD disconnected from pico).

> init
> reset halt
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080001cc msp: 0x20002308
> stm32f1x options_read 0
option byte register = 0x3fffffe
write protection register = 0xffffffff
read protection: on
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff

Small progress, chip seems to work. I was afraid i could have burned the chip during desoldering. I will try another breakout board with 64 pins. This one is for up to 100 pins. I double checked the wires. But maybe the board has an issue.

[DavidAlfa]

The automatic debugger detection might mess things up, it does a closed loop checking for the debugger, waiting for 1 second between, but a check migh run while you're still messing with the wires and fail in the next step.

Try this code at line 411:

Original:

Code: [Select]

# Wait for debug probe to be connected to the STM32F1 target
print("Waiting for debug probe to be connected...")
wait_dbg_probe_connect()
print("Debug probe connected to STM32F1 target")

Modified:

Code: [Select]

# Wait for debug probe to be connected to the STM32F1 target
input("Connect the debugger and press Enter")
wait_dbg_probe_connect()
print("Debug probe connected to STM32F1 target")

So you must press enter to continue after connecting the debugger, the connection will be solid.


Or, adding a delay after the debugger was detected to ensure everything is properly connected already:

Code: [Select]


# Waits until the debug probe is connected
def wait_dbg_probe_connect():
    while not debug_probe_connected():
        time.sleep(1)  # Wait for 1 second before retrying   
    time.sleep(2)  # Wait for 2 second after detected


[JimKnopf]

@DavidAlfa All the dump.py tweaks doesn't help. The problem seems to be in another direction. I swapped the chip to the 64pin breakout-board, wired up all connections. Same story. Then i tried this:

1. Started dump.py
2. Connected pico to USB
3. Removed NRST from pico GPIO4 (yellow wire) and connected it to the STLinkV2 RST
4. Connected the STLinkV2 to USB

and the script started.

When ordered to remove the STLinkV2 from target, i reconnected NRST to the pico first before removing the wires from STLinkV2.

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
STM32F1 target is confirmed to be read protected
Detected SRAM entry point offset: 0x108 (0x20000108)
Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9)
2: USART2 - RX: PA3  TX: PA2)
3: USART3 - RX: PB11 TX: PB10)
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware


Timeout: No data received from target
Please consult the README for troubleshooting steps

I compared voltage level on NRST pin, connected to pico vs. STLinkV2.
NRST to STLinkV2 i read 3,26V whereas the pico has 1,17V. A bit too low i guess. But i don't know why. I tried another pico. Same voltage on this pin. Strange behavior.

[DavidAlfa]

Mine sits at 2.7V, consuming 63uA. This is indeed very strange.

Edit: It seems the Pico sets the inputs in pull-down mode by default. So this might explain it. Whe have the STM32 pullup fighting the Pico pulldown.
Quick fix: Add a 1K pullup resistor between nRST and VDD. STM32's VDD, not PICO's! Otherwise it'll affect the voltage glitching.
Proper fix: Correct this in code. But setting up the toolchain, fixing the usual 1834 errors to compile, which indeed happened, so f***m it I'm going to sleep, just use the resistor!

[JimKnopf]

@DavidAlfa I added the two lines to attack.c and rebuild it. No errors during build (Arch linux).

I tried both variants. With the pull-up resistor in place (tried 1k and 10k) it runs the script but fails at dump state with a timeout.

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Connect the debugger and press Enter
Debug probe connected to STM32F1 target
STM32F1 target is confirmed to be read protected
Detected SRAM entry point offset: 0x108 (0x20000108)
Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9)
2: USART2 - RX: PA3  TX: PA2)
3: USART3 - RX: PB11 TX: PB10)
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware


Timeout: No data received from target
Please consult the README for troubleshooting steps

Using the fix with the two lines in attack.c, i get the same error. Even if i use both, attack.c fix and pull-up resistor, i get alway the timeout error. Only the voltage level varies. Maybe it's time to replace the chip to the Jabe board to test if it's still alive.