Author Topic: Dumping and reverse-engineering ST-Link v2/2-1 bootloader  (Read 46774 times)

0 Members and 2 Guests are viewing this topic.

Offline lujjiTopic starter

  • Contributor
  • Posts: 29
  • Country: 00
Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« on: October 16, 2016, 02:17:18 pm »
All the documentation and software is available on github.
Part1: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/
Part2: https://lujji.github.io/blog/reverse-engineering-stlink-firmware-part2/

This is what we can do so far:
  • decrypt and encrypt firmware images from the updater utility
  • upload and execute any code on the programmer
  • dump the bootloader of ST-Link v2 or v2-1
  • clone ST-Link onto an empty micro
  • disable protection (allows debugging)
The official StLinkUpgrade utility contains the firmware binaries. You can use it to flash your own encrypted images as well.
Encrypting/decrypting firmware binaries: st-decrypt.
Dumper firmware: st-link-dumper.

So what do you think? Any ideas on what we can do with it? There are a few things I'm interested in:
  • being able to convert any st-link into st-link + VCP
  • adapt a generic open-source bootloader to support st-link firmware
  • reverse-engineer the protocol and come up with an st-link compatible programmer?
Given the fact that we can now use a debugger, last option seems doable.

P.S.: I can't share binary dumps for obvious reasons. But if you own an ST dev-board, you can easily obtain one yourself.

Big thanks to eliocor for providing useful insights and advice!
« Last Edit: October 17, 2016, 09:02:51 pm by lujji »
 
The following users thanked this post: oPossum, eliocor, Rasz, bingo600, thm_w, edavid, Benik3, eck, test2, Krakenwak, Jacon, brainstorm

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #1 on: October 16, 2016, 03:02:45 pm »
Quote
So what do you think?

it was done over a year or so ago.

there is also a jlink v10 source code, binary + schematic available.
================================
https://dannyelectronics.wordpress.com/
 
The following users thanked this post: Signal32

Offline lujjiTopic starter

  • Contributor
  • Posts: 29
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #2 on: October 16, 2016, 03:17:02 pm »
Not exactly. I think you're referring to the article that covered extracting the firmware from the updater utility. The firmware itself is of little value without the bootloader. I also haven't seen any replicas of ST-Link v2-1 (mbed and VCP) so far.
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #3 on: October 16, 2016, 03:31:08 pm »
Btw:

The  F103C8 i have , do have 128k flash  ;)

/Bingo
 

Offline lujjiTopic starter

  • Contributor
  • Posts: 29
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #4 on: October 16, 2016, 03:39:54 pm »
Not as cool as my F101 having a USB :D
By the way, have you checked that all the pages can be written without errors? We should come up with some memtest utility to check how much 'spare' flash MCU has.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #5 on: October 16, 2016, 03:47:24 pm »
Quote
Not as cool as my F101 having a USB :D

Check the ghetto thread here. it is not just limited to STM32 chips.
================================
https://dannyelectronics.wordpress.com/
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #6 on: October 16, 2016, 04:33:50 pm »
Quote
Not as cool as my F101 having a USB :D

Check the ghetto thread here. it is not just limited to STM32 chips.

URL ?

/Bingo
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #7 on: October 17, 2016, 04:31:15 pm »
Complexity is the number-one enemy of high-quality code.
 

Offline lujjiTopic starter

  • Contributor
  • Posts: 29
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #8 on: October 17, 2016, 04:41:59 pm »
I finished part 2 of the writeup - link in the first post.. I also changed 'firmware' to 'bootloader' in the title to be fair (since I haven't done much about the actual firmware).
A proof-of-concept dumper firmware is on github (https://github.com/lujji/st-link-dumper). Most convenient solution would be to use USB instead of UART, but I just didn't have time for that. For some reason ST-Link 2-1 refused to enter DFU mode after I flashed it and just kept booting into the user-code, so make sure that you have another programmer to flash back the original bootloader once you dumped it. No such problem on ST-Link v2. Use at your own risk.

And yes, I can confirm that by flashing 2-1 bootloader on an stm32f103c8 and updating it to "STM32+Audio" I was able to get st-link with UART support.
Have fun.
 
The following users thanked this post: eliocor

Offline eliocor

  • Supporter
  • ****
  • Posts: 519
  • Country: it
    • rhodiatoce
Re: Dumping and reverse-engineering ST-Link v2/2-1 firmware
« Reply #9 on: October 17, 2016, 10:23:25 pm »
Quote
Quote from: dannyf on Yesterday at 16:02:45>
there is also a jlink v10 source code, binary + schematic available.


Hi, dannyf
will you be so kind to give me some references about what are you referring to?
I tried to make some searches, but with no avail.
Even from Segger documentation, last HW release of J-Link is 9.2
Any link?
 

Offline devan

  • Contributor
  • Posts: 13
  • Country: us
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #10 on: December 14, 2016, 05:20:57 am »
If anyone's interested I've worked out what changes are necessary to port whatever (open-source) debugger firmware you want to work with the STLink/v2-1 bootloader:

  • The vector table has to be relocated manually to 0x08004000 - the bootloader doesn't change it for you
  • The bootloader also leaves the USB and TIM1 interrupts enabled - you may need to disable them
  • To return to DFU mode, trigger a software reset - the bootloader will check the RCC CSR flag and run in DFU mode

With these changes, you should be able to load your custom debugger firmware and roll it back without any JTAG/SWD access.
 
The following users thanked this post: laneboysrc

Offline Krakenwak

  • Newbie
  • Posts: 3
  • Country: gb
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #11 on: December 24, 2016, 01:58:40 pm »
Superb work, I wish I could have thought of it.

For those who like me, who are nervous about extracting the bootloader,
I've put some useful  files here: https://github.com/Krakenw/ST-Link-Bootloaders
which can be used with many of the STM32F1 series that you have lying around like
the ebay maple & Minimum System Development Module.
 
The following users thanked this post: bingo600, Benik3, lujji

Offline lujjiTopic starter

  • Contributor
  • Posts: 29
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #12 on: February 16, 2017, 08:21:50 pm »
I ported Black Magic Probe firmware to native bootloader (because why not?).
The idea is that you can install BMP without destroying the bootloader, so that you can revert to the original firmware if needed.

Links:
1. write-up: https://lujji.github.io/blog/installing-blackmagic-via-stlink-bootloader/
2. firmware source: https://github.com/lujji/blackmagic/tree/stlink-bootloader
3. updater utility: I'm not sure I can upload it.. but someone did, so here's a link https://mega.nz/#!cNV0wIAY!LNNj7xzZtjN3xP8R1LSStnhrumnam_hGSrnPlPEOvRo.
If someone objects I'll edit the message and remove it.

You'll need to create udev rule under linux, texane/stlink is needed:
Code: [Select]
# /etc/udev/rules.d/99-stlink.rules
ACTION=="add", SUBSYSTEM=="usb", \
               ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", \
               MODE="0666", RUN+="/usr/local/texane/st-info --probe"
 
The following users thanked this post: cdev, Lizerd, thm_w, laneboysrc

Offline ass20

  • Contributor
  • Posts: 32
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #13 on: April 23, 2017, 07:48:58 am »
hi
 can i dump fw from another stm32 devices with this dumper?
 

Offline dotnfc

  • Newbie
  • Posts: 3
  • Country: cn
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #14 on: January 13, 2018, 12:23:11 pm »
hi, here is my thought for step further:  using stlink-btl to boot stlink-app and cmsis daplink.

this is the bootup flow:
Code: [Select]
               +-->    DFU Mode    <-------------------------------+
    STLink-BTL |             +-->  PB6 is low  (force DFU mode)  --+
               +--> PrjCode  |-->  STLink-APP
                             +-->  DAPLink-APP (VolumeName ==  'DAPLink')
we can use  'java -jar STLinkUpgrade.jar -volume "DAPLINK    " -force-prog' to change VolumeName

here is the memory map:
Code: [Select]
    +------------------------------+ 0x0800 0000
    |      STLink-BTL cracked      |
    +------------------------------+ 0x0800 3400
    |      this project code       |
    +------------------------------+ 0x0800 3C00
    |        STLink-APP CFG        |
    +------------------------------+ 0x0800 4000
    |          STLink-APP          |
    +------------------------------+ 0x0801 3000
    |      DAPLink Admin CFG       |
    +------------------------------+ 0x0801 3400
    |          DAPLink-APP         |
    +------------------------------+ 0x0801 FC00
    |      DAPLink User CFG        |
    +------------------------------+ 0x0802 0000

and, How to upgrade APP FW:
Code: [Select]
    -  STLink-APP: stsw-link007.zip (ST-LinkUpgrade.exe or STLinkUpgrade.jar)
    - DAPLink-APP: STLinkUpgrade.jar modified f2_4.bin ( 'STLink-APP' + 'DAPLink Admin CFG' + 'DAPLink-APP')

 By doing so, we can hold STLink/DAPLink on one singe STM32F103C8/B chip, and choose one of them on the fly.
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #15 on: January 13, 2018, 01:44:09 pm »
All the documentation and software is available on github.
Part1: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/
Part2: https://lujji.github.io/blog/reverse-engineering-stlink-firmware-part2/

This is what we can do so far:
  • decrypt and encrypt firmware images from the updater utility
  • upload and execute any code on the programmer
  • dump the bootloader of ST-Link v2 or v2-1
  • clone ST-Link onto an empty micro
  • disable protection (allows debugging)
The official StLinkUpgrade utility contains the firmware binaries. You can use it to flash your own encrypted images as well.
Encrypting/decrypting firmware binaries: st-decrypt.
Dumper firmware: st-link-dumper.

So what do you think? Any ideas on what we can do with it? There are a few things I'm interested in:
  • being able to convert any st-link into st-link + VCP
  • adapt a generic open-source bootloader to support st-link firmware
  • reverse-engineer the protocol and come up with an st-link compatible programmer?
Given the fact that we can now use a debugger, last option seems doable.

P.S.: I can't share binary dumps for obvious reasons. But if you own an ST dev-board, you can easily obtain one yourself.

Big thanks to eliocor for providing useful insights and advice!

Just a simple question:  The purpose fo all this is... ?

You better invest your time in telling those damned Chinese manufacturers to include an SWO pin on their damned cloned STLINKs.

You better invest your time into making OpenOCD at least half usable as a tool.

Thanks. We already have cheap enough programmers/debuggers already. There is no point in working on that.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #16 on: January 13, 2018, 02:59:46 pm »
Those little ST-link v2 clone dongles in their colorful metal cases make nice little micros for small projects.


For example, this looks like my next project for one.

https://github.com/danielkucera/st-link-dht11
"What the large print giveth, the small print taketh away."
 

Offline lujjiTopic starter

  • Contributor
  • Posts: 29
  • Country: 00
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #17 on: January 16, 2018, 05:11:11 pm »

Just a simple question:  The purpose fo all this is... ?

You better invest your time in telling those damned Chinese manufacturers to include an SWO pin on their damned cloned STLINKs.

You better invest your time into making OpenOCD at least half usable as a tool.

Thanks. We already have cheap enough programmers/debuggers already. There is no point in working on that.

It's entirely up to me to decide where I invest my time.
 
The following users thanked this post: thm_w, horo, therwp, crossroad

Offline Benik3

  • Contributor
  • Posts: 31
  • Country: cz
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #18 on: January 17, 2018, 10:23:58 pm »
Hello.
Doesn't anyone have problem with the chinese clones after FW update?
If I use V2.J27 or V2.J29 version, the programmer keep "disconnecting" from windows.
When I simply go into ST-Link Utility in Target->settings on first run I see the programmer, but after click on Refresh, it freeze for a while and then it show OLD ST-Link Firmware/ ST-Link already used.
If I downgrade to V2.J19 everything seems OK :/
I have two programmers with F101 and F102 MCU, both do it. I tried also flash the unlocked bootloader into the F101 and still the same.

BTW maybe I will have board with ST-LINK/V2-B programmer. If yes, I will dump the bootloader...
 

Offline stj

  • Super Contributor
  • ***
  • Posts: 2153
  • Country: gb
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #19 on: January 18, 2018, 05:37:12 pm »
all the clones i'v seen are st-link 2.0
and the cpu is slower and smaller than needed for 2.1
 

Offline Benik3

  • Contributor
  • Posts: 31
  • Country: cz
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #20 on: January 18, 2018, 08:01:16 pm »
Yes, st-link v2.1 need MCU with 128kb flash. I don't know if the higher performance is also needed.
I'm still not able to get working the chinese clones with newer firmware :/
Today I tried flash another bootloader+firmware from one russian forum, which (what I get from translator) should be original from ST-Link programmer.
No change, the bootloaders looks same, there is only small difference at 0x000021B0, which is the protection...
 

Offline Signal32

  • Frequent Contributor
  • **
  • Posts: 251
  • Country: us
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #21 on: January 18, 2018, 10:33:00 pm »
Excellent work ! Havent looked extensively into this, but , in code, how do you output to the stlink UART ?
 

Offline stj

  • Super Contributor
  • ***
  • Posts: 2153
  • Country: gb
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #22 on: January 19, 2018, 01:54:34 pm »
from the pc side?
it i.d.'s as a usb>serial adapter
 

Offline dotnfc

  • Newbie
  • Posts: 3
  • Country: cn
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #23 on: January 19, 2018, 02:48:26 pm »
ST should open stlink2-1 for mbed platform, or porting daplink to STM32 chip(s) officially. NXP did well than ST on this.  :D
 

Offline Signal32

  • Frequent Contributor
  • **
  • Posts: 251
  • Country: us
Re: Dumping and reverse-engineering ST-Link v2/2-1 bootloader
« Reply #24 on: January 19, 2018, 04:12:26 pm »
from the pc side?
it i.d.'s as a usb>serial adapter
No, from the Firmware/micro side.
On the host PC it does identify as  a COM port indeed. Question was how do I output data from the micro so that it would reach this com port ?

all the clones i'v seen are st-link 2.0
and the cpu is slower and smaller than needed for 2.1
What exact micro is used on the official 2.1 if anyone knows, I'm curious, pls.
« Last Edit: January 19, 2018, 04:14:12 pm by Signal32 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf