Reverse engineering ST-Link/V2 firmware

reverse-engineering-stlink-v2

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

  1. 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

    ps here’s an example of the format:

    https://skydrive.live.com/?cid=19a1917914ba2ee2&#cid=19A1917914BA2EE2&id=19A1917914BA2EE2!147

  2. i hate ARM microcontrollers becuase they are not compatible with 8 bit PICs and ATMEGAs, also, they are too complicated to be useful.

    1. 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++)

        1. If you know what you are doing C code is as fast as asm (not counting using registers as variables and similiar tricks, though they are possible in c, just require more code)

        2. 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.

    2. 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.

  3. 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.

  4. How retarded does a company have to be to be using encrypted/undocumented protocols on a devboard? Way to put people off buying your chips ST.

    1. Well, they are dirt cheap.

      Plus it is only the debugger. See if you get access to the firmware of, say, a J-Link dongle.

      1. 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 :-).

        1. Most dev boards (from any manufacturer) never offer the source to the debugger firmware, this goes for ST,TI etc.

          Plus, if the closed nature annoys you can always hook up an open debugger directly via JTAG or SWD (the ST boards even helpfully offer a pin header to do so…)

    2. ST has a long history of not supplying code for their development boards.

      When they first came out with MEMS Accelerometers years ago, I got one of their first Eval. Boards. It has many cool demos to show off the fancy ways you could use an Accelerometer.

      When I asked for the source code for the demos, to learn now to initialize and read the chip, I was told “Sorry, that is proprietary information and will not be released”.

      Me: “You are showing me that your part can do all of these fancy things, however you will not tell me how to do them in my own projects?”

      Them: “Yes.”

      Me: “Which one of us does not understand the purpose of Evaluation Boards?”

      Them: Silence…

      Bottom line is don’t buy ST parts. In that same vane don’t buy Honeywell parts either…

  5. No need to hack it, just flash the STM devboard with the versaloon firmware, it already includes usb to serial, as wel as SWD debugging. It also works properly with windows 7 x64 and linux.

  6. 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?

      1. 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.

          1. 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?

          2. When there’s a ChibiOS build specifically made for the F3 board, I’ll give it a try. Are there any LCDs and keyboards that’ll connect to this board?

        1. CMSIS – registers, the good one, made by ARM
          Standard Peripherial Library – the ugly one, made by ST, bloated, horrible piece of shit built on CMSIS

  7. 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

    1. 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.

  8. 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.

  9. 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.

  10. Hi Every one,
    I am new to this blog, but we are building STM32F407 based development board for Educational purpose.

    We want to add STLINK_V2 Hardware on the Board. I understood that somebody hacked the firmware. can any one help me to get the firmware file.

    Thanks

    Srikanth Ala

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s