Reverse engineering the ST-Link

Post here first, or if you can't find a relevant section!
Post Reply
User avatar
ahull
Posts: 1578
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Reverse engineering the ST-Link

Post by ahull » Sun Dec 11, 2016 8:42 pm

Some of you probably already spotted this on HAD.
http://hackaday.com/2016/12/10/reverse- ... rogrammer/
- Andy Hull -

User avatar
ahull
Posts: 1578
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Reverse engineering the ST-Link

Post by ahull » Sun Dec 11, 2016 9:06 pm

Oh.. and I nearly forgot.. this looks pretty useful too.

https://lujji.github.io/blog/stlink-clone-trace/
- Andy Hull -

devan
Posts: 45
Joined: Sat May 14, 2016 1:45 am

Re: Reverse engineering the ST-Link

Post by devan » Wed Dec 14, 2016 4:35 am

Followup on some of my previous comments about the same article:
viewtopic.php?p=20925#p20925

Using the information from Lujji's article and this other article [in Chinese], I was able to figure out what's needed to make an application compatible with the STLink/v2-1 bootloader.

It's possible to use the STLinkUpgrade tool to load your application and to later restart the bootloader to use with an unmodified STLinkUpgrade tool to restore the STLink firmware.

I just tested this successfully with my custom debugger firmware :D. I'm planning to see if I can get the mbed DAPLink firmware to work with the bootloader in a bit.

Changes I had to make:
  • Linker offset to 0x4000
  • Relocate the vector table to 0x08004000, since the bootloader doesn't do it for you
  • Disable USB interrupts that the bootloader left enabled before jumping to the application
  • To rerun the bootloader, just trigger a software reset - the bootloader checks the RCC_CSR reset flags.
I'll have to do more analysis to figure out whether the STLink/v2 bootloader on the more common STLink/v2 clones can be reused, but I suspect not.

User avatar
RogerClark
Posts: 6681
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Reverse engineering the ST-Link

Post by RogerClark » Wed Dec 14, 2016 6:27 am

@devan

Oen problem with the STLInk bootloader is its size (16k), so I can't make the BMP fit in flash on the normal STLink's as they are 64k
I know that the STM32F103C8 is often 128k, but the STLink firmware upgrade tool does not allow code beyond 64k if it detects a 64k device ;-(

But perhaps some smaller programmers like DAP is smaller and will fit

devan
Posts: 45
Joined: Sat May 14, 2016 1:45 am

Re: Reverse engineering the ST-Link

Post by devan » Tue Jan 03, 2017 6:45 am

I did some more analysis on the STLink/v2 bootloader. There doesn't seem to be any way to configure it to skip the DFU mode and jump straight to the application. Specifically, I didn't see anything in the execution trace that looked like it was accessing any interesting registers or areas of flash outside of the main bootloader code.

I took a look at how the JLink firmware for STLink discovery boards arranges to launch the JLink firmware. The upgrade process rewrites the bootloader's reset handler with a stub that jumps directly to the JLink reset handler, bypassing the rest of the bootloader. Reversibly patching the bootloader to jump straight to the application seems like it would require a lot of effort to get it to work robustly, so I'm probably not going to look any further into the v2 bootloader.
RogerClark wrote:@devan

Oen problem with the STLInk bootloader is its size (16k), so I can't make the BMP fit in flash on the normal STLink's as they are 64k
I know that the STM32F103C8 is often 128k, but the STLink firmware upgrade tool does not allow code beyond 64k if it detects a 64k device ;-(

But perhaps some smaller programmers like DAP is smaller and will fit
It looks like the DAPLink build process pads it out to the maximum size, but the actual firmware size is closer to 46KiB, so it could just barely fit in 64KiB.
However, as noted above, the v2 bootloader seems to be more trouble than its worth, so it's a moot point.

The v2-1 bootloader, on the other hand, works great with the DAPLink firmware. Reversibly updating Nucleo boards seems to work reliably for me.

User avatar
RogerClark
Posts: 6681
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Reverse engineering the ST-Link

Post by RogerClark » Tue Jan 03, 2017 8:39 am

@davan

Thanks.

I think if anyone wants to update to DAPLink they would probably be better off getting hold of a cheap STLInk dongle and then completely replacing the firmware.

Of course getting back to STLink would not be easy, but it would be possible by flashing the full version of the STLink dongle which is kicking around on the web, and then hacking the updater, to replace the main part of the code with whichever specific version they want (even without using the decrypter etc)

But I suspect hardly anyone will bother, as STLink works OK.

devan
Posts: 45
Joined: Sat May 14, 2016 1:45 am

Re: Reverse engineering the ST-Link

Post by devan » Fri Feb 17, 2017 1:51 am

A follow-up article from lujji porting the BMP to use the STLink bootloader:

https://lujji.github.io/blog/installing ... ootloader/

The highlights:
  • He ported it for both the STLink/v2 and the STLink/v2-1.
  • He patched the updater jar to make it think that the F103C8 has 128KiB flash so that it doesn't abort
  • For the v2 bootloader, he made a udev rule to detect when the bootloader enumerates and send a command to exit DFU mode so that the BMP firmware can run and enumerate

User avatar
RogerClark
Posts: 6681
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Reverse engineering the ST-Link

Post by RogerClark » Fri Feb 17, 2017 3:08 am

Thanks devan

Thats really interesting.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests