Open martonmiklos opened 5 years ago
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.
0x08020000
base address.st-decrypt
f3_{1,2}.bin
files inside the official updater with the encrypted binary.java -jar STLinkUpgrade.jar -force_prog
to 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.
@Disasm many thanks for this info!
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:
@RadioOperator
@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.
@RadioOperator I bought another v3mini a week ago and it had quite an old firmware (V3J2M1 if I recall correctly). Also v3set has much more reliable (compared to v3mini) SWD connector, I use it currently for development.
I think it's possible to replace the bootloader even with Level2 protection enabled. You will have to flash the firmware that replaces it.
@Disasm HI, I'm Win10 user, I have tried on st-decrypt and stlink-tool, both are not succeed. Too many issues I do not have time to handle.
I have generated 2 DAP firmware files (starting address from 0x08020000), could you help to encrypt it, then I will test it using ST-Link-007 (V2J3M1? pls tell me). Thanks. STLINKv3_firmware.zip
@RadioOperator try this: STLINKv3_firmware_enc.zip
I used this command:
st-decrypt -i STLINKv3DAPv1_HID+VCP_stbl.bin -o STLINKv3DAPv1_HID+VCP_stbl.bin.enc -k ' .ST-Link.ver.3.' -e
st-decrypt
is actually a shell script with the following contents:
#!/bin/sh
dir=$(dirname $(readlink -f $0))
java -cp $dir/dist/lib/commons-cli-1.3.1.jar:$dir/dist/st_decrypt.jar st_decrypt.ST_decrypt "$@"
stlink-tool doesn't work for stlink-v3 for now, because this probe has different protocol, but it's possible to update it in a way that it will support both v2 and v3.
@Disasm Thanks. I use one of the encrypted file, replaced the f3_1 and f3_2 (same) in STLinkUpgrade.jar. The STLINK-007 prograssing bar is ok to the end, report "successful".......but seems not flashed internal ROM, the device still in STLINK-V3 and functions ok. I donot know what is wrong. Any suggestions?
@RadioOperator check that files are actually replaced in the archive. Also check that you're using java updater and not native one.
@Disasm Hi,
this time, using java -jar STLinkUpgrade.jar -force_prog
, finished a real flashing, .
but my code not work, USB cannot enum. I'll check.....
My code is using a different USB-PID, should be same as in STLINKv3 bootloader PID? I'll try on this first.
@RadioOperator check that you disable all the interrupts and set up clocks correctly. I use this sequence to clean up after the bootloader: https://github.com/Disasm/usb-otg-workspace/blob/7e92a9c4c6500d5a7ca403fb0c767d62161f5ebb/example-stlinkv3-board/src/lib.rs#L8-L21
@Disasm Hi,
Back to encrypt a bin file,
using your cmd:
$ java -cp $dir/dist/lib/commons-cli-1.3.1.jar:$dir/dist/st_decrypt.jar st_decrypt.ST_decrypt "$@"
Error: Could not find or load main class st_decrypt.ST_decrypt
and using @lujji 's README instruction:
$ java -jar st_decrypt.jar --key "encryption key" -i firmware.bin -o firmware_encrypted.bin --encrypt
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 14
at st_decrypt.ST_decrypt.str_to_arr(ST_decrypt.java:254)
at st_decrypt.ST_decrypt.encodeAndWrite(ST_decrypt.java:180)
at st_decrypt.ST_decrypt.writeFirmware(ST_decrypt.java:201)
at st_decrypt.ST_decrypt.dump_fw(ST_decrypt.java:223)
at st_decrypt.ST_decrypt.main(ST_decrypt.java:134)
do you know what happened? thanks.
"encryption key"
is 14 bytes long, you need a real key that is 16 bytes long.
@Disasm Hi, sooooo easy, Done!
Hi, @Disasm ,
What encryption key I have to use? I found, same BIN file, I cannot generate out identical encrypted file as you sent me before.
I use java -jar st_decrypt.jar --key "best performance" -i firmware.bin -o f3_2.bin --encrypt
Thanks
@RadioOperator I posted the key twice on this thread ;)
@martonmiklos FYI: I flashed the "unprotected" bootloader from https://github.com/Krakenw/Stlink-Bootloaders/pull/3 to my not-yet-locked stlink-v3mini and then updated to V3J6M2 with the utility from ST. Seems like everything is fine and SWD it still working. I used this openocd config file:
source [find interface/cmsis-dap.cfg]
interface swd
source [find target/stm32f7x.cfg]
init
halt
targets
stm32f2x unlock 0
reset halt
program Unprotected-3-Bootloader.bin 0x08000000
program v3mini2-config.bin exit 0x08010000
Note that the whole operation takes a while (erase operation is quite slow).
UPD Warning: you should have v3mini2-config.bin
(1024-byte image dumped from 0x08010000
) prior to running this script!
@martonmiklos FYI: I flashed the "unprotected" bootloader from Krakenw/Stlink-Bootloaders#3 to my not-yet-locked stlink-v3mini and then updated to V3J6M2 with the utility from ST. Seems like everything is fine and SWD it still working. I used this openocd config file:
source [find interface/cmsis-dap.cfg] interface swd source [find target/stm32f7x.cfg] init halt targets stm32f2x unlock 0 reset halt program Unprotected-3-Bootloader.bin 0x08000000 program v3mini2-config.bin exit 0x08010000
Note that the whole operation takes a while (erase operation is quite slow).
Thank you for your impressive work on this and sharing the results with us!
Btw. folks @RadioOperator , @Disasm did any of you mapped the exposed side pins (castellated pins) of the debugger? I am wondering if the QUADSPI pins could be accessed or not (and I do not have my mini at my hand atm.)
@martonmiklos have you seen this? https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/blob/master/STLINK-V3MINI/Sch/STLINK-V3MINI_GPIOs.JPG
@Disasm nope, but yes that was what I am looking for.
@Disasm @martonmiklos Hi, Please check my new repo for STLINK-V3MINI, my dream MSC Bootloader (YAB) just on board: https://github.com/RadioOperator/Yet_Another_Bootloader
New problem: By now, my YAB only can be flashed into the chip by SWD tools. If we can use "stlink-updater" to do a bootloader update on v3mini board, that will be perfect. Especially for a "Level2 locked device". I do not have enough info to do this, I think you both, or other friends here, could study on this. /Thanks.
I think it's possible to make a "main" firmware that flashes this bootloader to the first sectors and then upload this firmware via stlink updater. The same procedure could be useful for unlocking the stock bootloader.
program v3mini2-config.bin exit 0x08010000
@Disasm May I ask you to post this file as well?
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.