Suggestion: leverage STM32 protected memory read attack to download fw about opendps HOT 15 OPEN

Hey,

I'm not sure that is correct at all. They are using OCD/JTAG access to trigger a full reduction of the locking mechanism to a level permitting access to code/data. They are also using a programmed STM32 board to connect to target. Could you recheck?

Also no need to desolder with the right kind of adapter/"pressure clamp". but even then it isnt too difficult to solder fine enameled coper wire to the pin pads under microscope. I have done this to access IQ sampling and other stuff in ICs for SDR.

As for triggering access: just normal functioning and going through the UI and possible scenarios (OC/OV/etc).

I have a spare 5015 I am willing to try this on.

from opendps.

It seems there is a different vulnerability that could be used to extract around 90% (depending on STM32F1 model) of the firmware in an hour:
https://blog.zapb.de/stm32f1-exceptional-failure/

However, at first glance it looks like the read out is fragmented (depending on STM32F1 model) and so cannot be used to restore the original functionality.

from opendps.

https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17-paper-obermaier.pdf
From section "3.3.3 Proof-of-Concept: Code Extraction":

The PoC was successfully tested on STM32F051R8T6
and STM32F030R8T6. Due to the very similar chip func-
tionality, we expect, that the whole STM32F0 series is
affected. Nevertheless, experiments on a few samples
indicate, that other series might not be vulnerable.

Before I read that, I tried this hack with an STM32F103 "blue" pill host on my DPS5015 V2.3 (shipped from RD in Nov. 2018). That takes a bit of "porting" (CPU definitions and startup code, system clock setup, UART, GPIO registers, ..) - I was able to compile on Windows in EmBitz (also DO_JTAG_RESET is required since F100 has JTAG - otherwise, target does not send ACK).
The client requires an older version of "prompt_toolkit" (https://pypi.org/project/prompt_toolkit/1.0.15/).

My target did not ACK, so I started digging further.
Basic information on SWD is given in the reference manual (RM0008 Rev 19 in section 31 "Debug support (DBG)") - I wish I had known this before...:
SWD select sequence:

This sequence is:

1. Send more than 50 TCK cycles with TMS (SWDIO) =1
2. Send the 16-bit sequence on TMS (SWDIO) = 0111100111100111 (MSB transmitted
   first)
3. Send more than 50 TCK cycles with TMS (SWDIO) =1

And this magic number comes in handy later. The DBGMCU_IDCODE is not the SW-DP IDCODE (aka DP DPIDR):

00 Read - IDCODE
The manufacturer code is not set to ST 
code. 0x1BA01477 (identifies the SW-DP)

Further SWD info (but start with the reference manual)
https://static.docs.arm.com/ihi0031/d/debug_interface_v5_2_architecture_specification_IHI0031D.pdf
https://www.arm.com/files/pdf/Serial_Wire_Debug.pdf

CPU Marking:

STM32F100
C8T6B
GQ20V 1393
CHN GQ 809
[ST] (?) Z

This is what ST-Link Utility says (also: Revision ID: Rev Z, Flash size: unknown):

11:02:50 : ST-LINK Firmware version : V2J27S6
11:02:50 : Connected via SWD.
11:02:50 : SWD Frequency = 4,0 MHz.
11:02:50 : Connection mode : Normal.
11:02:50 : Device ID:0x420 
11:02:50 : Device family :STM32F100xx Low/Medium density Value Line
11:02:51 : Can not read memory!
                  Disable Read Out Protection and retry.

This is what I got

swdFirmwareExtractor/cli$ sudo ./client.py /dev/ttyUSB0
[sudo] password for me: 
A0

Start address set to 0x00000000
L10000

Readout length set to 0x00010000
H

Hex output mode selected
e

Little Endian mode enabled
S

Flash readout started!

0x00000000: 

!ExtractionFailure00000080
StatusCode: 80
Fault during command execution (command error (access denied etc.))

End of data.

P

Statistics: 
Attempts: 0x00000064
Success: 0x00000000
Failure: 0x00000064

Programm finished.

This is what happens on the SWD lines as seen on oscilloscope:

It seems data sent by target is valid before rising edge of SWDCLK, so the ACK is an OK.
Also, the data read from the first register (SW-DP IDCODE, also see above) matches 0x1BA01477! - so I think it's safe to assume the SWD interface basics are working.

Of course there are plenty of other factors that could affect this. To control power to the CPU, I've cut the 3.3 V supply trace (DPS5015 V2.3) going horizontally from U4/C27 and inserted a P-MOSFET. But even when this is switched off (Gate at 3.3 V), input levels from the SWD or UART lines are enough to keep the CPU running (via protection diodes). 1k series resistors on the SWD lines did not make a difference.
Also, the F103 does not have independent pull-up/down resistors, and I did not try external ones (since the Turnover/ACK worked OK).

To see where and why exactly this fails, i.e. whether it's because of the interface or the F100 is not vulnerable, requires further digging into the SWD, so fire up your logic analyser ... (Sigrok has a protocol decoder for it, which I have not tried: https://sigrok.org/wiki/Protocol_decoders#Supported_protocol_decoders)

from opendps.

Obermaier et al have revisited the F1 and compatible devices (https://www.usenix.org/conference/woot20/presentation/obermaier), finding they could read 100% flash memory from all of them, including STM32F103.

https://www.usenix.org/system/files/woot20-paper-obermaier.pdf

7.4 H3: Shellcode Exec. via Glitch and FPB
Affected: APM32F103, STM32F103

For the attack, we employ solely an STM32F303 evaluation
board and some wires. The board provides a debug interface
for the DuT, a UART interface for serial communication with
the shell, and it controls the Reset, BOOT, and power supply
signals via its GPIO pins. Two GPIOs are connected in paral-
lel to provide sufficient current for the DuT. This experiment
shows that low-cost tools are entirely sufficient to circumvent
firmware protection in the STM32F103 and APM32F103.

https://github.com/JohannesObermaier/f103-analysis/tree/master/h3

• DUT: https://github.com/JohannesObermaier/f103-analysis/blob/master/h3/rootshell/main.c
• attack: https://github.com/JohannesObermaier/f103-analysis/blob/master/h3/attackboard/Core/Src/main.c

The "Attack board" appears to be https://www.st.com/en/evaluation-tools/stm32f3discovery.html (there are different revisions)

from opendps.

That I must try when I buy my next 'DPS. Thanks!

from opendps.

I read paper just now. It seems it only sheds light on parts of flash memory where PC or other memory instruction travels. Also, it requires de-soldering of MCU to do this attack.

I think to execute this attack, we need some special helper circuitary to ensure stock firmware travels all needed parts of flash memory by triggering proper inputs to target MCU.

from opendps.

There is absolutely not a problem to desolder TQFP48 and solder it to breadboard. I made this a lot of times with soldering iron and/or with hot air gun.
@vogelfreiheit what kind of problem you have with 5015? I using it often with opendps (version from cc branch before merging to master). I know about few little problems, but they don't too hurt

from opendps.

@vogelfreiheit Have you attempted any of the attacks that you've linked to?

from opendps.

Hey guys, due to time constraints, I did not, I was also waiting for a STM32 board to come (you need one to attack the target STM32, and a JTAG). I have both now. Need to decompress the schedule a little, have any of you experimented with this at all? Or emailed Ruideng for binaries?

from opendps.

Impressive attempt never the less @gnbl. Did you make any progress?

from opendps.

No, I did not spend any more time on this.
I assume that "our" F100 is not vulnerable, as suggested by the original authors.
In addition, I think this project already did a great job with reverse-engineering, so the time that would have to be spent on disassembling and understanding the original firmware is better used for work on opendps. But of course this is an interesting subject and it would be nice to be able to restore the original firmware if experimenting with opendps...

from opendps.

Cool you guys kept at this! @gnbl are you on IRC somewhere? I can help you out with this probably the next few days.

The useful outcome is to be able to either run the original fw after a reflash or even boot it from external NAND/EEPROM (with our own custom bootloader).

from opendps.

from opendps.

FWIW, someone on Medium thinks the stm32f103 is vulnerable...

from opendps.

@mpictor No, it's just about debug disable, and a reference to the same project regarding code protection.

from opendps.