Moreover, when I unplugged and reattached st-link, CDC interface was gone. The official flash utility failed with ‘ST-Link USB error’ and openocd refused to see the programmer at all. Then I connected a dev-board and tried flashing it with my upgraded st-link. Hah, piece of cake! I tried opening /dev/ttyACM2 - no errors. After a few attempts I detached st-link from the virtual box and dmesg greeted me with the following: I fiddled around with various conditional jumps and was able to ‘help’ the program flash a different firmware into the programmer. It was implemented as a switch statement and the disassembly looked like a simple jump table. I searched for string references and soon found a part of code that decides which firmware to flash based on the ID of the programmer. At first I tried following the author’s approach and disassembling the windows executable. There is an article by Taylor Killian written in 2013, which covers extracting ST-Link firmware from the updater executable. Being able to unsecure the chip by erasing the flash contents suggests that Level 1 protection is active (more on that in Part 2). Apparently, J-Link linux utility was ‘kind’ enough to remove option bytes without even asking the user.ĭespite the fact that I lost my programmer, I still learned some useful information. Flash was completely erased and I lost my ST-Link. Note: Unsecuring will trigger a mass erase of the internal flash. This could cause problems during flash download. 1Īctive read protected STM32 device detected. I launched J-Link Commander, typed ‘connect’ and was very surprised. Initially, I tried connecting to the MCU with J-Link and see if we get anything useful. Looking at windows drivers reveals a number of different PID combinations. Presumably, A, B and 2-1 versions all have UART support and a different bootloader. According to the ST employee, there are 4 versions of ST-Link 2: ST-Link/v2, ST-Link/v2-A, ST-Link/v2-B and ST-Link/v2-1. He pointed me towards this discussion on the ST forums. ResearchĮEVBlog forum user eliocor was kind enough to help and did a lot of research on the topic. That made me think if there are any ways of getting UART on a ‘regular’ ST-Link. The only big difference is that v2-1 uses an MCU with 128k of flash versus 64k on v2 programmer. After studying the schematics I realized that the programmer is pretty much identical to a regular ST-Link v2 in terms of hardware. Sweet! Although I wasn’t very excited about the drag-n-drop thing, having UART for debugging on the same board comes in real handy. Recently, I came across a Nucleo board with an ST-Link v2-1, which in addition to all the regular features acts as a virtual COM port (VCP) and supports drag-n-drop upload. The more I use it, the more I seem to forget about this abomination. It can program, debug and even supports SWO Trace. This is the first part of ST-Link reverse-engineering, where I cover analyzing and decompiling the updater utility, decrypting and encrypting firmware binaries and running custom code on ST-Link v2/2-1 programmer.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |