USB DFU Customised

[zoro7117]

Posted on August 30, 2012 at 01:00

Hi,

I would like to create a USB DFU device and host that can only talk to each other. What I want to do is to put a sort of flag such that my device will not be able to send its device descriptor to the host unless a special packet is received my the device. On the other hand, the host (PC app) will not be able to download the firmware to the device unless a special acknowledgement is sent by the device. In other words, short of having a handshake between the device and the host (PC app) before the DFU enumeration will happen. I would appreciate any thoughts or ideas on how to go about this. I have looked into the USB DFU 1.1 protocol and other documentations but it might be an information overload that I do not know where to start, or I am just bit clueless of where to go. Anyway, point of direction would be much appreciated. Thank you very much. #usb #dfu

[stforum.tormod9]

Posted on September 01, 2012 at 09:52

Hi Zoro,

Maybe you can share with us why you want to do this and what is the real problem you need to solve? Maybe there are alternative approaches that would make more sense. By ''device descriptor'', do you mean the Runtime or DFU mode descriptors? Are you writing the DFU firmware from scratch or do you base it off an existing implementation? You could require the host to set some magic bytes in the DFU detach request without which the device will refuse to switch to DFU mode. Then you could require the device to return a ''password'' in a DFU upload request, before the host will try to download the firmware. Tormod

[zoro7117]

Posted on September 02, 2012 at 21:10

Hi Tormod,

Thanks for the reply. I appreciate it very much. Below are answers to your questions. Maybe you can share with us why you want to do this and what is the real problem you need to solve? Maybe there are alternative approaches that would make more sense. >>> I would want for my device and the host PC application to be able to only talk to each other, in this case, I would want my host PC application to be able to download the firmware only to my specific device. Addiditionally, I would like my device to be able to receive the DFU file only from my PC application. By ''device descriptor'', do you mean the Runtime or DFU mode descriptors? Are you writing the DFU firmware from scratch or do you base it off an existing implementation? >>> To be honest, I do not quite have a good understanding of the the device descriptors, but the ''device descriptors'' that I mentioned in my earlier e-mail is the DFU mode descriptors. I based my DFU firmware from ST Micro DFU example. You could require the host to set some magic bytes in the DFU detach request without which the device will refuse to switch to DFU mode. Then you could require the device to return a ''password'' in a DFU upload request, before the host will try to download the firmware. >>> This is exactly what I hope to achieve. >>> Now, the main problem to be honest is that I do not know how to send this magic bytes from the host PC application (ST Micro DfuSe). I think I can be able to follow the DFU firmware code but would have great difficulty in doing it on the PC application side. Again, thank you for your reply. If it is not too much to ask can you please give me a code snippet on how to send the magic bytes from the PC host application to my device. Thank you very much. By the way, I did bump into your dfu-util, and looking into it, hopefully, I can get some inputs from it. Also, the bin to dfu python script is a great help. I was able to use it to convert my .bin files to .dfu. Again, any thoughts would be greatly appreciated. Thank you very much. Best regards, Zoro

[zoro7117]

Posted on September 03, 2012 at 01:16

Hi Tormod,

You could require the host to set some magic bytes in the DFU detach request without which the device will refuse to switch to DFU mode. Then you could require the device to return a ''password'' in a DFU upload request, before the host will try to download the firmware. >>> Would I be able to do this with the current DfuSE PC demo application and the ST Micro USB-FS firmware demo? I have been trying to do this but I cannot get to get it to work, at some point I have been barrage with BSOD with a bad_pool_header. Looking forward for your reply. Thank you very much. Best regards, Zoro

[stforum.tormod9]

Posted on September 08, 2012 at 00:58

But again, why? The more context you can provide, the better solutions we can suggest.

You can't do this with the ST USB-FS example because it runs in permanent DFU mode and does not implement the ''detach'' from run-time mode. When it comes to the ST DfuSe Demo I have never looked into it further than noticing that it is built on a closed-source library only running on Windows, and that there is a long forum thread about the pains of trying to use it. You can maybe learn something from the dfu-util code, but do not base your work on it if your strategy is security-by-obscurity: If you distribute a modified dfu-util you are required to provide the source code to the customer/user if he asks for it. Tormod

[gary239955]

Posted on December 21, 2015 at 16:52

I'd like to re-open this thread. I am now able, thanks to clive1, to use DfuSe (v3.0.5) to upgrade my main application from boot code which goes into DFU mode when I power up with switches in a unique position. As the switches and the USB port are available on the outside of the unit (an EBike Controller), I don't have to open the sealed unit to upgrade firmware. However, there is no password protection, so anybody could use DfuSe to read and write my application code. I, too, would like to fix this as simply as possible. I'd be surprised if no one else had done this before.

[re.wolff9]

Posted on December 21, 2015 at 23:34

First, if you set the flash protection bits, then your buyers will not be able to read the flash. If anything, they might be able to erase the chip, but not read your code. 

If you do not want to send ''field-upgrades'' with the firmware in plaintext, you could do as ST has done with the firmware for STLINK devices: Distribute and send to the device encrypted. However, do not do as ST has done with the firmware for STLINK devices: Decrypt and reencrypt in the PC application that downloads it to the device. Ideally you'd have a ''public key'' on each device, and you'd have the private key that allows authenticating and encryption of firmware modules. To send the firmware encrypted, you'll have to (re)implement the DFU part yourself. Or design a different protocol. Even having say an AES key inside each chip that authenticates each block of firmware would be much better than just sending the firmware in plaintext. Worst case someone circumvents the ''no reading of the flash'' or ''no debugging when flash is unreadable'' and they get your key. If you implement the whole public key thing, then all they get is your public key so that they too can verify that your update is valid... (but they can then also decode the update).  

[Tesla DeLorean]

Posted on December 22, 2015 at 17:41

I'd be surprised if no one else had done this before.

No doubt, I'd just be surprised if many were open, or didn't need PC side coding skills.