This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Buttonless DFU Example broken

Hi there,

I know you guys are very busy and I appreciate your quick response on Devzone.

I'd like to make a request for a more polished example of Buttonless DFU using SDK 12.1 with nRF52.

We are nearing production and if there's anything I'd like to get in concrete, it's a reliable way to upgrade firmware in the field.

The current example is not working out of the box, and the documentation doesn't offer a complete start to finish of how to upgrade. For example, what should we do after we send a 0x01 to the characteristic?

Thanks, Paul

Parents
  • I'm interested by the topic and I guess I'm not the only one! Can you please share the developments with the community..?

  • Hi Hung,

    Thanks for the reply. It is good to know that sharing of bonding information will be supported in the upcoming SDK release. Any idea when the SDK will be available?

    I understand that anyone who gets the .zip DFU package might be able to reverse engineer the FW even though bonding information is shared between the App and the Bootloader. Yes, my concern about the replay attack is exactly what you mentioned above. Someone can just replay the OTA DFU packets (since they currently go unencrypted on air and hence are easy to sniff on air for any malicious user) and force the costly operation of firmware update on the device. As you mentioned, I can change the default bootloader behavior to reject DFU if the FW version is the same to avoid such situation.

    Thanks, Sam

Reply
  • Hi Hung,

    Thanks for the reply. It is good to know that sharing of bonding information will be supported in the upcoming SDK release. Any idea when the SDK will be available?

    I understand that anyone who gets the .zip DFU package might be able to reverse engineer the FW even though bonding information is shared between the App and the Bootloader. Yes, my concern about the replay attack is exactly what you mentioned above. Someone can just replay the OTA DFU packets (since they currently go unencrypted on air and hence are easy to sniff on air for any malicious user) and force the costly operation of firmware update on the device. As you mentioned, I can change the default bootloader behavior to reject DFU if the FW version is the same to avoid such situation.

    Thanks, Sam

Children
No Data
Related