We’re not sure why [lujji] would want to hack ST’s ST-Link programmer firmware, but it’s definitely cool that he did, and his writeup is a great primer in hacking embedded devices in two parts: first he unpacks and decrypts the factory firmware and verifies that he can then upload his own encrypted firmware through the bootloader, and then he dumps the bootloader, figures out where it’s locking the firmware image, and sidesteps the protection.
[lujji]’s project was greatly helped out by having the firmware’s encryption keys from previous work by [Taylor Killian]. Once able to run his own code on an intact device, [lujji] wrote a quick routine that dumped the entire flash ROM contents out over the serial port. This gave him the bootloader binary, the missing piece in the two-part puzzle.
If you’ve ever broken copy protection of the mid-1990’s, you won’t be surprised what happened next. [lujji] located the routine where the bootloader adds in the read protection, and NOPped it out. After uploading firmware with this altered bootloader, [lujji] found that it wasn’t read-protected anymore. Game over!
We glossed over a couple useful tips and tricks along the way, so if you’re into reversing firmware, give [lujji]’s blog a look. If you just want a nice ARM programmer with UART capabilities, however, there’s no reason to go to these extremes. The Black Magic Probe project gives you equal functionality and it’s open source. Or given that the official ST-Link programmers are given away nearly free with every Nucleo board, just buying one is clearly the path of least resistance. But a nice hack like this is its own reward for those who want to take that path. Thanks, [lujji] for writing it up.
Didn’t you guys state a perfectly good reason in the Black Magic Probe article? You can put the BMP firmware on a ST-Link…
You don’t need to go to the effort to cracking the protection on the bootloader if you just want to use the Black Magic firmware. Plug it into another STM programmer and then select the full erase option and it’ll blow away everything on the chip in one go. Once you’ve done that, all the various locks will be disabled again and you can upload whatever you want.
^^ This. The trick is getting into the protected code/bootloader without flashing the chip and blowing it away. And that’s a skill that’s useful in _many other_ situations.
“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.”
LOL.
I like the LED in jumpers trick!
Every time I see that, I think we should write it up in an article. We covered it once in “Links” I think.
Still, it’s a great trick, and needs more eyeballs. Thanks for reminding me.
I fail to grasp what the fine gentleman had accomplished. As GotNoTime mentioned, you can always erase and re-program the chip to run any code you want. Also the article mentioned the firmware was extracted and decrypted previously from the PC programmer package. I feel I’m missing something.
“What use is a newborn baby?” — Every dead scientific genius ever.
There’s a complementary EEVBlog forum post that discusses a little bit more of the “why”, rather than the “how” that the article covers:
http://www.eevblog.com/forum/microcontrollers/dumping-and-reverse-engineering-st-link-v22-1-firmware/
For me, the interesting use case is to analyze the bootloader so that you can modify your preferred debugger firmware to work with the bootloader. Keeping the bootloader intact (and accessible) makes it possible to load new firmware and rollback to the original STLink firmware without needing direct JTAG/SWD access.
Of course, it’s not that hard to crack open the case and solder/probe some jumpers, but I don’t think anybody would say no to a hands-free solution.
I just wish someone would do this to SAM ICE so we would have free Atmel Studio compatible programmer.
It’s one of the reasons I’ve moved on.
Microchip has had a cheap development platform for years & years.
Atmel tools have almost all been too expensive for hobbyists or unreliable (dragon).
Second (first was Breadboard on LPT) AVR programmer I built was an Atmel AN910.
Later I’ve been happy for years with Fischl’s usbASP.
Never understood why atmel didn’t support a < USD10 programmer (Such as usbASP usbISP).
Now I'm getting my feet wet wit STM32. Very nice chips. ST-Link-V2 for < USD2 with an aluminimum casing, etc.
Did a tutorial from pandafruits for stm32 and it seems that even debugging works nicely with gdb.
Atmel had also been silenly ignoring GCC for about 10 years untill they couldn't any more and now they're trying to turn it into a windows only ide.
Look at CooCox or mbed. there are a gazillion platforms to choose from nowaday's.
A big advantage of STM32 is it's use in a lot of cheap Chinese products. I find them in lots of products from Ali/Ebay, such as for example the SMPS with color display recently here on Hackaday. Goper(t) 3005 also has one.