#275 ST-Link v3 refuses to work with non-ST targets, RE help needed
For the reasons yet to be discovered, ST-Link v3 is not connecting to the Cortex-M targets not produced by ST. There's likely a way to fix this by patching the firmware, and thanks to the amazing effort by some community members patching and uploading patched versions of the firmware is now relatively easy.
First, a word of warning: V3J6M2 firmware will enable permanent protection level 2, so you won't be able to debug ST-Link itself over SWD on this chip ever (reflashing via the bootloader would still be possible though). V3J2-V3J5 are known to not enable any additional protection.
How to patch the firmware:
1. Download an official zip archive, the rest of this post refers to http://mobisys.silla.ac.kr/yjkim/es-lecture/-/raw/3b6768d46ed0fe4ee1acd820b0fd7d07bdf4aed2/en.stsw-link007_V2-36-26.zip (or you can get en.stsw-link007_V2-36-26.zip from the official ST website if you are ready to register with them);
2. Clone https://github.com/lujji/st-decrypt and use it to decrypt (and later encrypt prior to uploading) file f3_1.bin from STLinkUpgrade.jar, the key is ' .ST-Link.ver.3.';
3. Start radare2 like this: r2 -a arm -b 16 -m 0x08020000 f3_1.bin.dec (of course, you can use any other RE tool you like, just set it to assume Thumb* instructions and 0x08020000 base address);
4. Start browsing around and doing your cool RE magic as you're used to. Of specific interest might be the function at 0x08023df8 (called from functions at 0x08025c90 and 0x08025b8e). It checks values located at 0xE0042000 (IDCODE of certain F1, F2, L1, L4, G4 devices), 0x40015800 (certain F1, L0, G0 parts), 0x5C001000 (H7 parts). I've checked the latter address and it's present just once in the whole binary and is referenced only from this single function. So chances are this is the one doing the dirty job and so it (or its call sites) can be easily patched to improve interoperability with all Cortex-M contollers.
I'm lacking v3 hardware to test it myself but I'm ready to assist with digging and trying things.
Paul Fertser via OpenOCD-devel writes:
Rejecting non-ST MCU probably has also a deeper impact. The need to
read the MCUID! This has often problems when in sleep or even when in
reset. Even with stprog, STLINKV3 often does to to a board the
STLINK-V2(1) had no probblem.
There is also a patched bootloader available that does not protect the
F723.
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
Related
Tickets: #275
On Mon, Jul 27, 2020 at 11:21:00AM +0200, bon@elektron.ikp.physik.tu-darmstadt.de wrote:
I'm surprised I get no constructive feedback on this ticket. Now that
it's trivial to try a firmware with patched-out IDCODE check why isn't
anybody trying that? Probably in fact I'm wrong to bother at all and
nobody just gives a damn and it's a non-issue?
From reading that github ticket thread I got an impression that the
protection is performed by the main firmware. And it's probably
checking some byte that's flashed with the bootloader, right, but
nobody has tested it yet, and also nothing prevents ST from ignoring
that byte in the new not-yet-released versions of the firmware, so I
wouldn't count on it.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
Paul Fertser writes:
This is caused probably by different interpretations of "trivial" ...
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
On Mon, Jul 27, 2020 at 12:03:12PM +0200, bon@elektron.ikp.physik.tu-darmstadt.de wrote:
I'm not sure what is the possible misunderstanding here. OpenOCD is
targetted at developers and surely it shouldn't be problematic for a
developer to unpack/pack zip files or to run a java utility for
encryption/decryption? And stlink users are of course targetting
cortex-m MCUs, so STM32F7 firmware is not something alien to them.
Am I missing anything essential?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com