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.

Comments

  1. Brad Snow says:

    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. rmos says:

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

    • MikrySoft says:

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

    • hans says:

      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.

    • SavannahLion says:

      I didn’t know feeding Trolls did anything useful either, but people still do it. ;)

  3. Brian Smith says:

    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. Necromant says:

    Just one word to ST: pwned.
    Now, we’ll see dozens of STLINK v2 clones from china hitting the market.

  5. mikeselectricstuff says:

    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.

    • tuxfool says:

      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.

      • hans says:

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

        • tuxfool says:

          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…)

    • Bob Paddock says:

      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…

  6. Nathan says:

    Very nice hack. Need more stuff like this on HAD

  7. Dodo says:

    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.

  8. hans says:

    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?

    • eagmo says:

      just don’t use ST firmware lib, it’s horrible anyway.

      • hans says:

        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.

        • mabl says:

          Have a look at ChibiOS :-)

          • trevin says:

            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?

          • Galane says:

            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?

        • ijopo says:

          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

  9. steaky says:

    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

    • maegop says:

      use Keil, it sucks but it works.

    • hans says:

      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.

  10. Galane says:

    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.

  11. ChromeB says:

    Isn’t the F303 a M4?

  12. simonqian says:

    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.

  13. emblocks says:

    @simonqian

    That’s exactly what I was thinking of. Keep the API equal so we can use the already functional GDB stub.

  14. Srikanth Ala says:

    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

Follow

Get every new post delivered to your Inbox.

Join 96,311 other followers