Reverse engineering ST-Link/V2 firmware

The chip seen just above the center of this image is an ARM Cortex-M3. It provides the ability to interface and program the main chip on the STM32F3 Discovery board. The protocol used is the ST-Link/V2 which has become the standard for ST Microelectronics development boards. The thing is, that big ARM chip near the bottom of the image has multiple UARTs and bridging a couple of solder points will connect it to the ST-Link hardware. [Taylor Killian] wanted to figure out if there is built-in firmware support to make this a USB-to-serial converter and his path to the solution involved reverse engineering the ST-Link/V2 firmware.

The first part of the challenge was to get his hands on a firmware image. When you download the firmware update package the image is not included as a discrete file. Instead he had to sniff the USB traffic during a firmware update. He managed to isolate the file and chase down the encryption technique which is being used. It’s a fun read to see how he did this, and we’re looking forward to learning what he can accomplish now that’s got the goods he was after.

38 thoughts on “Reverse engineering ST-Link/V2 firmware”

Hi Mike, quite an informative blog you have. I was wondering if you’d be open to being interviewed, either through audio or video (your choice) regarding your knowledge on making an EMF detector with an arduino. You’d be on a podcast called “Engineer Beat”, sponsored by Newark.com. If interested, please contact me by e-mail and I’ll go over the specifics. Thanks -Brad

You sound like “I hate computers because they are not compatibile with stone tablets and typerwiters, also, they are too complicated to be useful.”

No two families of microcontrollers are byte-compatibile with each other (are your PICs and ATMEGAs compatibile with each other?). And ARMs are not much more complicated than small micros (if you program with C/C++)

Try writing USB or TCP/IP stack solely in assembly. Then compare time effort required to write and debug the code with a C project. Assembly might be good for time-critical sections, but is not suitable for applications more complex than an alarm clock.

Not compatible? I’ve written plenty of C code that works equally well on 8 bit or 32 bit or 64 bit.
And sure, an STM is a bit more complicated, but that’s just a matter of reading the reference manual and experimenting. just like you did with your first pic or avr.
The ARM cortex is a mighty architecture, way more capable than those older chips will ever be.
You just make a fool of yourself with comments like that.

Careful. It is unlikely that a serious journalist/podcaster would post that. Instead of making a direct contact with the real author, there is an URL pointing to some data payload to possibly infect your computer. Spam and possibly infectious.

Segger makes money by selling J-Link. ST makes money by selling chips. I’m slightly frustrated by their clingyness to their software. Really, how much would it cost them to open up the firmware? Nada. They would probably gain, as it really makes their discovery kits that more attractive. And dev kits are like the ‘free sample’ of drug dealers :-).

On a sidenote, I’m working on a project with an STM32, and I was wondering about the licencing terms of the firmware library. It mentions that ST grants you a ‘non-transferable right’ to copy and adapt the code IIRC. What do they mean by ‘non-tranferable? Can I upload the project on github together with the firmware lib? It will also contain my own code (WTF license) and libnova (lgpl).
Any thoughts?

How do you access the registers then, are there other (free) header files available? Or would I have to define each register’s address myself? And what about the USB implementation? I don’t feel very motivated to implement a stack myself… I agree the lib has its shortcomings, but even then, it takes some work of your shoulders. If it’s possible to use it, I will.

I was going to try this one. Is it really that great as it seems to be? Would be great to see some positive and negative opinions. Can someone maybe give a link to thread about pros and cons? And what about NuttX?

Ii know its off topic, but I’m having real issues getting an IDE to work properly with the STM32F3 and F4 discovery boards. I’ve tried a load of the tutorials using CoIDE and Yagarto etc. I’d really like to do dev in windows, and debugging is a must. I’m not adverse to jumping through hoops but I dont want to do it blind. I know you can use Kiel and IAR, but they are both code space limited. STMicro dropped the ball with IDE support

You’re not very specific, and personally I dev in linux, but in any case, here one thing that took me a day to figure out: if you use gdb and openocd to load a file, you first have to give the command: monitor reset halt. Also, there seems to have been some recent changes in gdb, giving problems with gdb and openocd, you you might want to experiment with older versions or google for more info on that, in case the problem lies there.

I have one of those F3 boards. No peripherals out yet like there are for the F4 board. I’ve an idea to use some lengths of SCSI cable to connect the F3 board to a display and other peripherals in a sort of vambrace housing. No, not a PIP-Boy clone, though it’d be useful for that.

Mount the F3 board in the lower half and run two SCSI cables around the arm and up the hinge side to the board with the display and other components. Could utilize the LEDs on the F3 by molding custom resin pieces to hold fiber optic lines against them. I assume the sensors can be programmed to work upside down.

Combined with a GPS receiver, this board ought to be configurable as a decent navigation instrument, using the built in sensors for inertial or dead reckoning navigation.

Why not simply develop a new stllink instead of hacking the original. To fix the firmware binary for adding CDC is not that easy, but it’s not difficult to develop a new one compatbile on USB prototype.