On Mon, Jul 27, 2020 at 12:03:12PM +0200,
b...@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?
>
> This is caused probably by different interpretations of "trivial" ...
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:fercer...@gmail.com
---
** [tickets:#275] ST-Link v3 refuses to work with non-ST targets, RE help
needed**
**Status:** new
**Milestone:** 0.9.0
**Created:** Fri Jul 24, 2020 04:26 PM UTC by Paul Fertser
**Last Updated:** Fri Jul 24, 2020 04:26 PM UTC
**Owner:** Paul Fertser
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.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
