Dumping the original firmware/bootloader

[martonmiklos]

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.

[bm16ton]

ok so decrypting the firmware first worked on my oldone!! how awesome!! No more qemu-i386!! Im tempted to change your code to allow mode 4 for uploading but Im afraid Ill kill it. :(

[bm16ton]

Heres A dump of the new ones usb endpoints in dfu mode, looks identical as the old one, I didnt know iif the mode 3/4 thing was actually talking about the dfu interface but I guess its more complicated then that

Bus 001 Device 127: ID 0483:374d STMicroelectronics STLINK-V3 Loader Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0483 STMicroelectronics idProduct 0x374d STLINK-V3 Loader bcdDevice 2.00 iManufacturer 1 STMicroelectronics iProduct 2 STM32 ST-LINK/V3 iSerial 3 001D00335632500A20313236 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 DFU Config bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 5 ST-LINK/V3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1

[bm16ton]

patched stlink-tool to take mode 4 but this is what i got;

Firmware version : V3J8S0 Loader version : 14157 ST-Link ID : 33001D000A50325636323120 Firmware encryption key : 7510B4EFCAF4AE8A1C0687870DFC7494 Current mode : 4 Loaded firmware : firmware.bin, size : 132096 bytes Erasing... USB transfer failure Erase error USB transfer failure

works great on my others. I also had usbsnoop running during a couple quick attempts, uploaded to my github

[GabyPCgeeK]

Looking at the updater code it seems that for bootloader ver 4 it sends a part of the firmware file for authentication (the v3+ firmware file seems to have a 16 byte header with some offsets) and continues to update if it passes ok.

[GabyPCgeeK]

Also looking in this thread it seems that people are trying to decrypt the v3 firmware as is. You need to check 4th byte (0x3) and (byte << 5) + 96 + 16. Remove this many bytes from the start of file and then decrypt the remaining. (Tested on 2.38.27 don't know about other versions)

[GabyPCgeeK]

the v3 firmware file seems to have a 16 byte header, 64 bytes (unknown probably some hash), sha-256 hash of sha-256 list, list of sha-256 hashes (1 per every 1024 bytes of encrypted firmware), encrypted firmware.

16 byte header [53 47 00 XX YY 00 04 00 00 00 00 00 00 00 00 00] XX = lsb of number of 1k sectors YY = msb of number of 1k sectors.

So find the usage of the unknown 64 bytes and theoretically it is possible to create a firmware image that can be swapped in the updater and flashed.

Bootloader ver 3 doesn't seem to use the sha-256 list but the ver 4 does.

[bm16ton]

Im so jelous of your skills and knowledge. Old dog new tricks im afraid but im getting along slowly. Ill do my best to research the many things u said i didnt totaly understand, but i have a handhold now to work from. Thank you! This is very helpful

On Mon, 8 Nov 2021, 12:45 pm GabyPCgeeK, @.***> wrote:

the v3 firmware file seems to have a 16 byte header, 96 bytes (unknown probably some hash), list of sha-256 hashes (1 per every 1024 bytes of encrypted firmware), encrypted firmware.

16 byte header [53 47 00 XX YY 00 04 00 00 00 00 00 00 00 00 00] XX = lsb of number of 1k sectors YY = msb of number of 1k sectors.

So find the usage of the unknown 96 bytes and theoretically it is possible to create a firmware image that can be swapped in the updater and flashed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/issues/1#issuecomment-963405435, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP7Z5O7KMENZ2I2NCX3ULAECPANCNFSM4JBU3CLA .

[UweBonnes]

Could people please try https://github.com/UweBonnes/stlink-tool/tree/stlinkv21. It adds Suglovers V3 handling to my additions to handle StlinkV21 so that no different stlink-tool versions are needed.

[bm16ton]

unfortunately it doesnt see myoldie but goodie stlink v3 i get ./stlink-tool firmware.bin No ST-Link in DFU mode found. Replug ST-Link to flash!

And with no changes suglovers sees and flashes it fine :( But this is awesome,so relieved to have these tools thankyou!

On Mon, Nov 8, 2021 at 2:39 PM UweBonnes @.***> wrote:

Could people please try https://github.com/UweBonnes/stlink-tool/tree/stlinkv21. It adds Suglovers V3 handling to my additions to handle StlinkV21 so that no different stlink-tool versions are needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/issues/1#issuecomment-963507664, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMPZ5JEU36UY676Q3FLLULARO7ANCNFSM4JBU3CLA .

[bm16ton]

nevermind im an idiot it worked fine, god i need rest

On Mon, Nov 8, 2021 at 3:22 PM benjamin maddocks @.***> wrote:

unfortunately it doesnt see myoldie but goodie stlink v3 i get ./stlink-tool firmware.bin No ST-Link in DFU mode found. Replug ST-Link to flash!

And with no changes suglovers sees and flashes it fine :( But this is awesome,so relieved to have these tools thankyou!

On Mon, Nov 8, 2021 at 2:39 PM UweBonnes @.***> wrote:

Could people please try https://github.com/UweBonnes/stlink-tool/tree/stlinkv21. It adds Suglovers V3 handling to my additions to handle StlinkV21 so that no different stlink-tool versions are needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/issues/1#issuecomment-963507664, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMPZ5JEU36UY676Q3FLLULARO7ANCNFSM4JBU3CLA .

[Disasm]

Thanks for the dumps! From their diff I can see that stlinks with 0x04 "version" use different memory layout for metadata: now everything is stored in sector 3, but for version 0x03 sectors 2 and 4 were used. Erasing old sectors may potentially break the bootloader, so be careful.

[bm16ton]

Wow thats way more information then i had before thankyou! This thread has been a treasure trove of new things to.explore and learn. Trying to play catchup. Still unclear what exactly can cause issues in terms of writing what to where, also ive seen it said in passing (here in this thread) a new firmware load could be used to disable rdp2. Thats a hard thing to find any info on. I havent found it written anywhere that rdp2 uses OTP's, and no info at all about leaving any bootloaders with sum sorta backdoor the needed registers to turn it off, the papers seem clear those are no longer reachable...but thry would say that so i dunno. I would try power fuzzing but damn those decoupler caps are tiny! Plus not entirely sure the process to remove the protection if i did manage to get a boot with rdp2 not enabled. Oh hell ill probly try anyway.

On Thu, 11 Nov 2021, 2:15 pm Vadim Kaushan, @.***> wrote:

Thanks for the dumps! From their diff I can see that stlinks with 0x04 "version" use different memory layout for metadata: now everything is stored in sector 3, but for version 0x03 sectors 2 and 4 were used. Erasing old sectors may potentially break the bootloader, so be careful.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/issues/1#issuecomment-966558340, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP2D7LSWJXVGTYXJMZDULQI4RANCNFSM4JBU3CLA .

[Disasm]

You can't disable level2 protection officially. The only theoretically possible thing is level2->level1 downgrade with power glitch (quite a complex attack), and then level1->level0 downgrade via mass erase. Between these two actions you will have to hack into the firmware somehow to dump all the data in order to re-upload it later.

[bm16ton]

Ironically the power glitch attack is probly the one thing i can actually do or at least try to do. Jumping into programming and mcus in your 40s has been tuffer for me then i even expected. But i did take the black magic probe firmware and started at bottom and made the led accesible via usb and wrote a ljnux kernel driver "led class". Been using only linux since 1998 and never once asked if i could make the capslock led etc do crazy things. Now the stlinks led can show me dizens of things like net traffic, battery percentage etc. Then i moved onto gpio and have a kernel driver for those (no irqs yet dunno how to send a software triggered irq from interupt endpoint data that works on all architectures yet) next will be i2c tho the f7 uses a different i2c version of libs then the f1/f4 so porting i2c star will be difficult for me and i cant find shit for howto setup the i2c clock for f7s using any libs really let alone libopencm3. And i have a usb to spi firmware that sorta works on the f1 with kernel driver that ill finally swing over to the f723. Boy its been a lot of fun, but i still dont know the names of programming terms etc. All my kernel/firmwares are from seeing as many examples/commits as i can find and figuring the syntax out based on that. Christ it was just last week i figured out sum comments are parsed by compile IE / fallthru / . But you guys have been a huge help! Cant thank you enuff!

On Fri, 12 Nov 2021, 11:04 am Vadim Kaushan, @.***> wrote:

You can't turn level2 protection officially. The only theoretically possible thing is level2->level1 downgrade with power glitch (quite a complex attack), and then level1->level0 downgrade via mass erase. Between these two actions you will have to hack into the firmware somehow to dump all the data in order to re-upload it later.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/issues/1#issuecomment-967229755, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMPYOIWL376AXJYMODTTULU3KTANCNFSM4JBU3CLA .

[UweBonnes]

With my stlink-tool branch and a B-U585 IOT board after reset of the STLINK:

Firmware version : V3J8S0
Loader version : 14157
ST-Link ID : 1B001D000450414733373820
Firmware encryption key : 866AE415D4031F8AB7F14BE19CEC3037
Current mode : 4
ST-Link dongle is not in the correct mode. Please unplug and plug the dongle again.```

[GabyPCgeeK]

Can someone test this firmware file (it's for the ST-LinkV3 v4) f3_2.zip (it's the YAB binary from the git) using the latest STLinkUpgrade.jar. It has the header, hashes and encrypted firmware. There's still 64 bytes I don't know what they are used for but if it works they are probably the same everytime.

Also there seems to be a V3 variant that uses a F74x or F75x (Device ID 0x449) 1MB Flash microcontroller.

[martonmiklos]

Also there seems to be a V3 variant that uses a F74x or F75x (Device ID 0x449) 1MB Flash microcontroller.

Maybe the ST parts shortage affected the ST itself ;)

[bm16ton]

@GabyPCgeeK I tried your f3_2.bin and it did load successfully, but It still had the original stlink firmware with no sign of yab bootloader. For fun I replaced f3_1 with it as well but got the sme error msg as the other past failed attempts.

[GabyPCgeeK]

Can you try this one f3_1.zip.

[bm16ton]

Unfortunatly still doesnt like f3_1 :( Firmware version detected: V3J8M3 Exception in thread "main" java.lang.SecurityException: SHA-256 digest error for com/st/stlinkupgrade/core/f3_1.bin at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:239) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:243) at java.util.jar.JarVerifier.update(JarVerifier.java:230) at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:484) at java.io.FilterInputStream.read(FilterInputStream.java:133) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read(BufferedInputStream.java:265) at com.st.stlinkupgrade.core.c.h(SourceFile:984) at com.st.stlinkupgrade.app.b.b(SourceFile:277) at com.st.stlinkupgrade.app.b.a(SourceFile:136) at com.st.stlinkupgrade.app.MainApp.main(SourceFile:16)

[GabyPCgeeK]

It seems the latest updater jar is signed so any file modification is detected. Try this updater STLinkUpgrade.zip (tested it with modified f2_4.bin and works).

[bm16ton]

well i tried it, i assume i didntneed to readd the f3_1 and received the following libusb: error [udev_hotplug_event] ignoring udev action bind Firmware version detected: V3J8M3 Firmware authentication error issue. Upgrade canceled, corrupted firmware data. Upgrade is successful. libusb: error [udev_hotplug_event] ignoring udev action bind Version read: V3.J8.M3.B0.S0.P0

[GabyPCgeeK]

So it seems that the unknown 64 bytes are hashes or some kind of cryptography data but I haven't been able to find their use. Maybe we'll need to wait until a new firmware update is released or even until someone manages to dump the bootloader. I'll try to buy a V3 to experiment with but it may take some months.

[bm16ton]

Man you are awesome cannot thank you enuff! Anything i can do just let me know.

On Sat, 20 Nov 2021, 2:00 pm GabyPCgeeK, @.***> wrote:

So it seems that the unknown 64 bytes are hashes or some kind of cryptography data but I haven't been able to find their use. Maybe we'll need to wait until a new firmware update is released or even until someone manages to dump the bootloader. I'll try to buy a V3 to experiment with but it may take some months.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioOperator/CMSIS-DAP_for_STLINK-V3MINI/issues/1#issuecomment-974696159, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP5DEH3D645E7GPTVYTUM7V3PANCNFSM4JBU3CLA .