Retrieving ST-Link/V2 Firmware from Update Utility

Introduction

The STM32F3DISCOVERY is a small circuit board with a great microcontroller. The ARM Cortex-M4 chip has 256 KB of flash memory, 48 KB of RAM, USB and more. The board has huge amounts of header pins connected to the microcontroller and has a gyroscope, accelerometer and compass on board. For the 11 USD that this board costs, you definitely get a lot of functionality.

ST-Link/V2 chip is next to Crystal

The board also has 2 USB ports, one which is connected directly to the microcontroller, and the other connected to the smaller microcontroller pictured above (STM32F1) and is used for programming and debugging the device. STMicroelectronics calls the programming solution ST-Link/V2. When used with the proper software, it works quite well. However Linux support was initially lacking, but texane and OpenOCD were able to create working drivers. My goal was to dump the firmware.

So why get the firmware?

While ST-Link/V2 has many great features, there are a few features lacking. The STM32F1 microcontroller has a pair of USART lines running to the STM32F3 which are unconnected by default. STMicroelectronics however was kind enough to provide solder bridges on the reverse side of the board (SB13 and SB15 in the picture below) that should be simple for even an amateur to solder.

SB15 and SB13 (on the right) can be soldered to connect USART lines

The problem is that even if these lines are connected, it is not clear whether the firmware will support talking to the STM32F3 over USART or not. So by analyzing the firmware, we can find out if there is a built in ST-Link/V2 command for talking through USART or not. Additionally, it would be nice to modify the firmware so that the board shows up as a USB-to-serial device also, so that no development drivers or software are needed to interact with the STM32F3.

Sniffing USB

So how do you go about getting the firmware for the ST-Link/V2 anyway? The chip is designed to send and receive firmware from the STM32F3, not itself. However, looking at the STMicroelectronics website, you can find a ST-Link/V2 firmware update file. When you extract it there is a readme, a dll and an executable, no firmware file. So my solution for getting the firmware is to sniff USB while the firmware update is taking place. 

There are a number of USB sniffing programs out there, but many are designed specifically for Linux, others are very out of date and designed for Windows XP, and still others are not widely known and may contain malware or might not provide the functionality I need. My solution is to hook the bulk send and receive requests in the firmware update utility.

Detours

While I have written programs that manually hook functions before, that approach is very cumbersome and messy. I decided to look at hooking libraries and came across a free library by Microsoft called Detours. This library was very easy to use and took about 30 lines of coding on my part.

To use the library, you create your own function with the same calling convention and arguments as the one you want to hook and place your code in it. You can optionally call the original function from inside your function. Then in DllMain, you call DetoursAttach() to specify your hook function and the original function and that is basically it!

Detours works good for functions that are part of the Win32 library, however if you are trying to hook a function that is not part of Win32, or one that you do not have a .lib file for, Detours also works great in that situation! For instance I wanted to hook the functions WinUsb_WritePipe() and WinUsb_ReadPipe(), which are part of the Windows Driver Kit, which I did not have. Luckily, the names were exported in the WinUsb.dll file, so I was able to use DetoursFindFunction() to get the address of the function.

To inject the dll file into the executable is also made simple by Detours. One of the example programs in the Detours library is called "withdll" and basically it launches an executable of your choosing with a dll of your choosing. Using this method is wonderful because it makes my hook dll very portable. The next time I want to hook something from the WinUsb library, I can use the exact same dll with the program "withdll".

The firmware

Once the functions were hooked, I had their buffers dumped to a file that I could read in a hex editor. Below is an image of the result. The format of the file is the word "ReadPipe" or "WritePipe", followed by the 1 byte endpoint number, followed by 4 bytes describing the length of the data, then the data itself. In the image below, the last WritePipe contains the start of the firmware. However at first glance the data does not appear as it should.

Dump file from hooked USB calls

Decrypting the firmware

If I tried to run the firmware image captured above though a disassembler, I would get a bunch of garbage. I ran the USB dump file through a program I wrote in order to concatenate all of the firmware together. It was simple to recognize the firmware in the dump file because it was always sent in 1 KB chunks. While the image was begin concatenated together, I ran statistics and found that there was about 100 bytes of each character 0x00 through 0xFF. This typically means that the file is encrypted or compressed, otherwise there would be a higher concentration of values like 0x00 and 0xFF than any other value. 

My first guess was that it was encryption rather than compression because the file length was a multiple of 1 KB exactly. More than likely a compressed file would not be a multiple of 1 KB chunks because the whole point of compression is to make things smaller! 

So then I needed to figure out how the firmware was encrypted and if I could decrypt it. I knew that the firmware was stored in the firmware update utility (because where else would it be?) so I tried looking at the file with a hex editor with no luck. From all of the firmware images I have examined, STMicroelectronics always puts their name in unicode in the firmware file near the end. That did not exist in this executable, so it was likely that it was encrypted within the file.

Disassembling and debugging

Knowing that the firmware image was most likely encrypted, my instinct was to look for the encryption function in the executable file, if it existed at all. So I opened up the executable in IDA Pro and got something  that looked like the image below. All of the function and variable names are my own, but the identification of the start and end of the function were the work of IDA Pro. At the top of the image IDA Pro shows all of the functions which it has identified in blue. The light blue are functions are functions which it has found names for. The dark blue functions are functions IDA Pro does not have names for. These are most likely the meat and potatoes of the program.

After looking at the light blue functions, it looked like the majority were Windows MCF functions, not encryption functions, so they were ignored. I then started at the beginning of the program looking for some dark blue functions that looked like they might be encryption functions. The very first function at address 0x401000 turned out looking very suspicious. It looked suspicious because it had a lot of bit logic in it, particularly exclusive-or operations (in yellow) which seem to be very common in encryption algorithms.

So I opened up the firmware updater in the OllyDbg debugger and placed a break point on 0x401000 and a few other functions. As soon as I tried to send the firmware, the breakpoints were going off left and right. In the function 0x401000, one of the arguments that was passed to it was "I am a key, wawawa". So thank you STMicroelectronics for making it very obvious what the key is and what function uses it.

Identifying the encryption method

While it is not necessary to identify the encryption method to get the unencrypted firmware from memory, it is necessary if I want to upload my own firmware to the ST-Link/V2 chip. I am not an expert in encryption and it would definitely be difficult for me to identify the algorithm just by looking at it, so I had to figure out a way to identify the algorithm in a simpler manner.

Having worked briefly with Blowfish and some open source implementations, I knew that Blowfish used an array of bytes called an S-Box. I have no idea what a S-Box is, but I know the bytes are standardized, not just random digits. I also know that changing them to something else could weaken the algorithm, so the majority of the time they are not changed. So I wondered if whatever this encryption was also had S-Box's, which, again, are a large array of unchanging bytes.

So I looked at the disassembly of the function at 0x401000 (which I named genkey) and noticed a lot of references to an array starting at 0x435000. I looked at the the contents of the array and saw the following bytes: 52 09 6a d5 30 36 a5 38 bf 40 a3 9e 81 f3 d7 fb. When I googled those numbers, I found a Wikipedia entry confirming that this function was used for AES-128 encryption.

Getting the decrypted firmware

To get the decrypted firmware was simple. Once I identified the encryption key, I simply put a breakpoint on that data in order to identify any encryption functions that used the key. I then monitored what data came in and what data went out of the functions which caused to breakpoints to trigger in order to find the function that actually decrypted data. Once I found the decryption function, I simply copied the decrypted data out of memory after the function executed.

Analysis

So I now have the decrypted firmware, but an interesting question is why the firmware was ever decrypted in the first place. It turns out that the firmware uploader stores the firmware in encrypted state, decrypts it and send re-encrypts it with a different key before sending it to the ST-Link/V2 chip. Why they do this, I have no idea. The firmware would be much more secure if it was encrypted with the key that the ST-Link/V2 used in the first place and put that image in the firmware uploader executable.

The re-encryption key

The key which is used to encrypt the firmware again is actually (possibly) dynamic. When the firmware updater first starts, it communicates with the ST-Link/V2 chip and sends the command 0xF3 0x08. The chip then responds back with 20 bytes of data. The first 4 and last 12 bytes are then encrypted with the key "best performance". These 16 encrypted bytes are then used as the encryption key for sending the firmware.

Firmware sending protocol

Before sending the actual firmware image, the firmware updater tells the ST-Link/V2 chip where it wants to upload the data. In the USB long pictured above, this starts at 0x03BB. 0xF3 is a byte that means that this is a Device Firmware Update (DFU) command. 0x01 most likely tells the chip that it will be sending a firmware image next. 0x0002 I believe is a transaction number. 0x752F is sort of a simple checksum, it is the summation of all of the bytes being sent. Finally 0x0400 is the size of the chunk of firmware being sent.

None of these actually tell the ST-Link/V2 the location to upload the firmware. I believe these occur in earlier requests. One request contains the 5 bytes 21 00 40 00 08, with 0x08004000 being the location the firmware is most likely uploaded to. I do not know what the 0x21 means, however this byte is sometimes also 0x41. This will need to by analyzed further. 

It is interesting that data is uploaded to 0x08004000 and each upload is spaced 1 KB after the last until it reaches 0x0800AC00. Then the last 1 KB of the file is uploaded to 0x08003C00. 0x08000000 and up is all flash memory, however it is interesting that the code is not uploaded to the beginning of the flash memory. This could be because code is possibly executing in the earlier portion of the flash and should not be overwritten. Maybe at some point the code will be copied over to the beginning of the flash? Or maybe the beginning of the flash is supposed to be a failsafe in case the firmware arrives corrupted. Or maybe it is just a boot loader for the uploaded flash. It will be interesting to see what the flash memory looks like when I get access.

Upcoming work

Now that I actually have a copy of the firmware, I will need to analyze it. I have taken some initial glances at the firmware, but will need to study it more in depth. I am familiar with x86 assembly, but ARM assembly is completely new to me. Also, I am not quite sure how to work IDA Pro with ARM firmware. It will not automatically identify the beginning and ends of the functions, I must identify individual bytes as code, then IDA Pro will be able to tell me more. So right now I am just making guesses at which parts are code and seeing what IDA Pro does with it. It seems to be working, but since I can't yet understand ARM assembly, I don't know if the data is being interpreted properly or not. If anybody has a more methodical way of marking functions in IDA Pro, I would love to hear it. Particularly if somebody knows how to locate the main routine.

I did look around in the firmware and saw that it contained the same AES-128 S-Box array. It also contained the string "USBC", something that was used in the ST-Link/V1 firmware based on texane's code. Using that, it should be easier to identify the AES-128 functions and other functions in the firmware.

So my goal now is to analyze the firmware and eventually add functionality to it. Eventually I would like to modify it so that it will use the USART on the STM32F3DISCOVERY that is currently unconnected. Or maybe identify code in the firmware that already uses the the USART, and I just need to know the command. The firmware image is 28 KB and the STM32F1 chip which is used for the ST-Link/V2  has a 64 KB flash, so there should be more than enough room to add a few routines.