cancel
Showing results for 
Search instead for 
Did you mean: 

Looking for an open source USB DFU protocol programmer application

Robmar
Senior III

I'd like to be able to distribute secure code updates (encrypted) to clients along with an application that can program the STM32H743 over USB.

The STM32CubeProgrammer works well with our board, but does not provide any security as far as I know for the code files, .elf or others.

The idea is to have an application in which we can add code to decode our encrypted source and program the MCU over the USB link in boot mode.

I am sure this would be useful to other developers needing to securely distribute code updates to clients or remote machines.

12 REPLIES 12
Amine_Jridi
ST Employee

Hello @Robmar,

To establish a USB_DFU connection with your MCU via application, you can refer to the application example located in the STM32Cube repository. You'll find it under the following path:

....\STM32Cube\Repository\STM32Cube_FW_H7_V1.11.2\Projects\"Your_Board"\Applications\USB_Device\DFU_Standalone

You can use this example  as a starting point for creating a secure application tailored to program your STM32H7 over USB.

Thanks.
Amine.


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks I've found the sample application you reference, but the application is to run on the ST MCU, and we need an application that will run on Windows 10 to download the code to the standard H743V MCU when its on boot mode, boot pulled high.

So we intend to use the default MCU DFU code, but we need to have a windows app like Cube Programmer that can decrypt our binary files - which is were we need to add our decoder routine.

Amine_Jridi
ST Employee

I understand, in this case I suggest exploring the SFI (Secure Firmware Installation) mechanism offered by ST with STM32CubeProgrammer, which should serve your needs.

For further information, you can refer to the AN4992 Application Note available on ST.com.

Thanks,

Amine.


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks, I looked at the SFI web page, its really not very user-friendly, I came away with more doubts that answers. STM32Trust - STMicroelectronics

For example it states "The STM32CubeProgrammer includes the STM32TrustedPackage Creator tool which allows the generation of SFI and SMI encrypted images" but the SFI tab is greyed-out, and it states the tab feature only "supports STM32U5 series!"

It looks like it was all written by someone who was paid by the word.

This is not the first time STM docs do not tally with STM software.

Do you know of a clear guidance on how to get STMCubeProgrammer encoding our files?  Ideally without us needing to use memory cards, we just want to send an encrypted firmware update to a client and give them a link to download the CubeProgrammer.

Looking at Ap Note AN4992 the H743 is not in the supported list (Table 1) which is surprising given that its a new device.  Encoding data does not need special encryption hardware and is easy to do, but we really would expect STM to support the H743.

You completely miss how programming differ from security. You prepare secure bin file and use it in classic Programmer. Flash to some address. When you plan stay on MCU DFU internal boot , any mini hacker download your image from MCU without trouble. Exist many ways, but all is based on own used bootloader code placed into start flash area and some protection this part of flash. For example read about SBSFU...

Try explain what you need protect and we can provide info maybe

We use ROP to make it difficult to read our code off the MCU, I know it can be hacked, but its good enough.

We don't want to distribute readable binary code for programming, we need it to be encrypted, which is what SFI does, unfortunately it seems someone at STM in their wisdom decided to not have it work with the H743!

So I guess we will need to write a Windows app that will decrypt our binary and send it to the MCU, or add a boot loader that will use our encoded format, which would be more secure.

Just silly that STM don't support the H743, and a waste of time of a lot of customers.

ROP is turned off for flash new fw then you can use own app and decrypt ... flash and activate RDP , but if  mini hacker break your process before RDP and use normal app for DFU , then can read fw or siply sniff interface used to connect ... You waste time with this method. I repeat read SBSFU is you asked opensource.

 

You maybe shouldn't assume you know more than the person posting the question, and maybe also you should read what was written.

I can write all the code needed but we are a busy company and expect STM to have the basic support code available so we don't all have to waste valuable time re-inventing the wheel.

In this case, STM decided not to support the H743 MCU under SBSFU, so RTFM or in this case the app note AN4992, which does not list the H743 in table 1 as a supported MCU.

I am looking for a way to send encrypted binaries to clients to update an H743-based device.

If you don't know of any app, source code, etc., that can do that, please don't tell me I can write it myself.

 

Im not expert for H7 , but you miss SFI and SBSFU is different tech. SBSFU is supported on any STM, limit is only flash size and for best security external safe chip. You still not write for what is your security ? No copy your device ? No read dissasembly code ? 

Any security solution based on level isnt simple windows app for you. 

One example for custom (not tested only idea) .

1. you split flash to app and update area

2. over STMProgrammer your user write into update area encrypted bin

3. app in normal arrea on start check existence in encrypted ... validate  ... decrypt and flash into app area

4. erase header part of update for skip repeat updates or leave and only compare decrypted ver = little slow start require decrypt header in update and compare with actual on every boot

...