CMSIS-DAP_for_STLINK-V3MINI
CMSIS-DAP_for_STLINK-V3MINI copied to clipboard
RadioOperator
Dumping the original firmware/bootloader
Hey @RadioOperator ,
In the past there were attempts to gather the STLink V2's firmware via downloading a dumper code through the official bootloader: https://lujji.github.io/blog/reverse-engineering-stlink-firmware/ https://lujji.github.io/blog/reverse-engineering-stlink-firmware-part2/
It might be useful to check whether it is possible with the V3 because using the factory bootloader for downloading custom code would be a great possibility I think. I do not have device at hand at the moment, but I will look after the possibilities later. I just opened this issue to give you a heads up.
Well it seems that ST changed the encryption method of the firmware since @lujji worked on it (the best performance key ~~does not outputs valid binary for the old f2_1.bin binaries too~~ outputs valid binaries for the V2 firmwares and invalid for the V3 images). There is an another suspicious string "What are you doing" in their code, but it will be necessary to understand their updater changes.
What makes you think the output binary is invalid? As far as I can tell encryption and key are the same and decrypted f3_x binaries look ok in disassembly. Anyway, I should get my hands on a v3 programmer - it would be fun to play with.
Hi, lujji, glad to hear you here, your great works would be very helpful, then we could recover the factory firmware, flexible!
@lujji I just take a look on the f3 binaries and did not found any UTF strings in it, and the entropy looks weird.
Yeah, you're right, I looked at f2_3 instead of f3_2 :) Perhaps they're doing decryption on the MCU side (like they should have in the first place). edit: it does seem like the updater decrypts the binary only when version is less than 3.
Where do you see that it does not decrypts it? I am reading the decompiled java code and did not see it yet.
@martonmiklos stlinkupgrade.core.c.class: search for the decryption key - you can see that it's used only when some parameter is less than 3, otherwise the array is used as is.
@lujji Wait you are reverse engineered the native executable not the java one?
In the java codes the method to which the "best performance" key was passed appears to be called in two places with 2 args:
The "What are you doing" string is also looks something like a key :)
I think I will pull the java code to IntelliJ and start refactoring the obfuscated code and put it to somewhere to git.
Wouldn't https://github.com/jeanthom/stlink-tool be a good place to put it? Stlink-Tool works perfect to flash blackmagic debug probe reversible to an STLinkV2.
Wouldn't https://github.com/jeanthom/stlink-tool be a good place to put it? Stlink-Tool works perfect to flash blackmagic debug probe reversible to an STLinkV2.
Haha I just came across that tool in the days, I wanted to mention here. What do you mean we should put there?
I was referring to martonmiklos "I think I will pull the java code to IntelliJ and start refactoring the obfuscated code and put it to somewhere to git." So I meant if there is any work done on using the Stlink V3 bootloader, stlink-tool would probably be a good place to start.
Hi guys. Going to present this without a comment.
./st-decrypt -i f3_2.bin -o f3_2.bin.dec -k ' .ST-Link.ver.3.'
However, while working on this I kinda locked my v3mini by updating it to the latest version with the official tool. Don't repeat my mistakes.
@Disasm Nice job, the decrypted file seems to be valid. How did you locked your programmer? Have you tried to upload a cooked and encrypted firmware with the official tool?
@martonmiklos, no, the newer official firmware (V3J6M2) locks the chip to the protection level 2, effectively preventing SWD from working. With such a locked chip you can still update (and downgrade) the firmware or upload your own. But SWD is disabled forever.
And yes, I successfully uploaded my own firmware and dumped the bootloader via UART.
- Build your firmware with
0x08020000base address. - Convert it to binary and encrypt with
st-decrypt - Replace
f3_{1,2}.binfiles inside the official updater with the encrypted binary. - Update as usual (you can use
java -jar STLinkUpgrade.jar -force_progto skip gui part).
@Disasm you spared some time for me: I was just working on figuring out the app offset :D It is a bit funny to see that they reserved more than 128K for the bootloader.
The fact that ST disables the SWD makes me a bit sad, but still this is a thing.
@martonmiklos I think that the answer is flash layout: the sectors have different sizes and they are used to store 4 different things and should be erased separately. The bootloader actually uses sectors 0 and 1 (first 32kB), sectors 2, 4 and 5..7 are used for other things.
@martonmiklos I think that the answer is flash layout: the sectors have different sizes and they are used to store 4 different things and should be erased separately. The bootloader actually uses sectors 0 and 1 (first 32kB), sectors 2, 4 and 5..7 are used for other things.
That makes sense. I have forgotten that the F7 does not have uniform flash layout.
@disasm: Protection level 2 would make it nearly impossible to reprogramm the chip. Probably it is some sector protection.
Consider to offer the bootloader at https://github.com/Krakenw/Stlink-Bootloaders.git
@UweBonnes it is still possible to reprogram the chip with the ST bootloader (unless you erase it by accident). At least that's what I'm doing :) Additionally, I confirmed that Level2 protection is active on my chip by inspecting the FLASH_OPTCR register, I also found a piece of code in the firmware that enables this protection level.
I also found a piece of code in the firmware that enables this protection level.
This screams for creating a patcher tool. ;)
@martonmiklos yes, but... you can use one of the previous versions of the firmware without this code
@Disasm yeah, but after a certain release the CubeIDE required me to update and it seems that my normal V3 (non mini) had been upgraded to the V3J6M2 version :(. Fortunately I have not used my mini since then.
Here is the relevant part if you want to patch the firmware:
ROM:080298A4 CMP R2, #0xCC
ROM:080298A6 BEQ loc_80298CE
Jumping to this label skips the locking process. Firmware image: V3J6M2 (en.stsw-link007_V2-36-26.zip), file f3_1.bin
Note that this is not the only comparison. Seems like it's possible to protect your device from locking by writing S character into the config block at address 0x0801004C. It also checks the value at 0x08000204 (probably bootloader version?).
Can confirm that firmware versions V3J2 to V3J5 (inclusive) do not touch option bytes, that is, do not enable any protection levels.
I've just added an unprotected bootloader to https://github.com/Krakenw/Stlink-Bootloaders/pull/3 It skips flash protection and also has one of the bytes changed in a way that should prevent V3J6M2 firmware from protecting the flash to Level2. I haven't tested the last part yet.
@Disasm @martonmiklos , and all, Thanks. I have two questions about the Level-2 protection issue:
- Original device with factory bootloader, after the user upgraded to V3J6M2, Level-2 enabled? or not.
- In future, if new V3 device comes with Level-2 protected firmware only, that's too bad, no SWD port for flashing user code likes my CMSIS-DAP.
@RadioOperator
- I suppose yes. At least if booted at least once, and this happens right after fw upgrade.
- You can upload your CMSIS-DAP firmware via the same update mechanism stlink updater uses. This is even more convenient, as the user does not have to solder wires to the SWD connector.
@Disasm thanks. If no SWD function, we cannot debug the code under MDK environment. The current unprotected devices will be more useful for someone. Or buy a 32F723EDISCOVERY kit.
To upload my CMSIS-DAP Hex code via USB into the IC, I can rebuild the code starting from address 0x08020000, am i right? And then, do I need to encrypt it by some software tools? sorry I did not study all details on this, could you give more tips, thanks.
Btw, using the Level-2 enabled board, could we still erase/flash the first 128KB to change to a new bootloader from internal? My dream is a new bootloader with USB MSD drag and drop function.