DFU Update: "Upload Failed: Unknown Command" & Signature-less Bootloader

[tkstreet]

I am trying to package a firmware update and flash it over BLE DFU and I keep getting the following error on the nRF Toolbox app:

"Upload Failed: Unknown Command"

I cannot figure out why this is happening and I can't find anyone else having this error on here.  Here are the commands I used to create the initial bootloader and settings (flashed over J-Link).

Generating the Settings hex:

nrfutil settings generate --family NRF52 --application ../AKDP/BUILD/AKDP_RevE.hex --application-version 20 --bootloader-version 1 --bl-settings-version 1 akdp_bl_settings.hex

Generated Bootloader DFU settings .hex file and stored it in: akdp_bl_settings.hex

Bootloader DFU Settings:
* File:                 akdp_bl_settings.hex
* Family:               nRF52
* Start Address:        0x0007F000
* CRC:                  0x9F32BF67
* Settings Version:     0x00000001 (1)
* App Version:          0x00000014 (20)
* Bootloader Version:   0x00000001 (1)
* Bank Layout:          0x00000000
* Current Bank:         0x00000000
* Application Size:     0x0003EEB8 (257720 bytes)
* Application CRC:      0xD62A0BD6
* Bank0 Bank Code:      0x00000001

Merging the settings hex with the bootloader hex:

mergehex -m akdp_bl_settings.hex ./bootloader_secure_ble/pca10040_debug/armgcc/_build/nrf52832_xxaa_s132.hex -o akdp_bl_with_settings.hex

Parsing input hex files.
Merging files.
Storing merged file.

After flashing the softdevice and the bootloader, here is what I used to generate the package file:

nrfutil pkg generate --application ../AKDP/BUILD/AKDP_RevE.hex --application-version 21 --hw-version 52 --sd-req 0x9D,0xA5 AKDP_RevE_with_BL_pkg.zip

Other information:

• Device: nRF52832
• SDK: 14.2.0
• Board: Custom

I cannot understand why this isn't working.  It all looks fine to me.  The bootloader build completed without any problems.  Any help would be greatly appreciated.

[Einar Thorsrud]

Hi,

From the log it seems that the nRF receives an unsigned command (log says "Handling unsigned command"). Referring to the implementation in dfu_req_handling.c in SDK 14.2.0, this always leads to a "Unknown command" response. I have a a few more questions:

• Which version of nRF Toolbox are you using?
• Do you get the same behaviour if you use nRF Connect (for mobile and/or desktop?

[tkstreet]

Yes, I get the same response from nRF Connect.  I'm using whatever the latest version is for Android nRF Toolbox.

Am I required to use PGP key signing for DFU?  I think this is where the problem lies.  When I am compiling the bootloader, even though I am using the NRF_DFU_DEBUG_VERSION, it is still compiling the dfu_public_Key.c file and thus signing the bootloader with the public key.  When I am generating the package, I would like to not have to sign it with a private key.  I need to do this in order to maintain backward compatibility with firmware that was compiled and packaged without key signing.  It seems that now, even in debug mode, I am required to do key signing.  Is this correct?  If so, why is it even possible to generate DFU packages that are unsigned?  It seems that the BLE DFU depends on the dfu_req_handling driver (as well as crypto and crc32).

I can't find any documentation on non-signed bootloaders, nor are there any examples in the SDK.  But what's strange is that the warning in nrfutil suggests it's possible:

|===============================================================|
|You are not providing a signature key, which means the DFU     |
|files will not be signed, and are vulnerable to tampering.     |
|This is only compatible with a signature-less bootloader and is|
|not suitable for production environments.                      |
|===============================================================|

Can you point me in the right direction to make a signature-less bootloader?  Thank you.

[Einar Thorsrud]

You are right, signing is needed even in debug mode. However, in that case the default configuration of the example is to use a example public key that can only be used with the prebuild .zip distributions in the SDK, as we do not provide the private key. You need to replace the public key with your own public key in order to test the bootloader with your own DFU .zip files, even with the debug bootloader.

SDK 15 introduced a bootloader which does not use signing (called "open bootloader"). This is intended specifically for the nRF52840 dongle, so the only example we provide uses USB transport. However, it should be possible to replace the transport layer with BLE (though I have not tested).

I am a bit unsure about what you mean when you say:

I would like to not have to sign it with a private key.  I need to do this in order to maintain backward compatibility with firmware that was compiled and packaged without key signing.

I assume this older firmware packages were made for the legacy bootloader (no signature verification)? If so, there are also many other differences, so you cannot use these packages with the new bootloader. You anyway need to re-pack it for use with the new bootloader, therefore I do not see a significant issue with using signed images for the new bootloader and non-signed images for the old. Or am I missing something? I would also like to emphasize the risk of having an open bootloader, as this makes it very easy for an attacker to change the firmware of a device in the field, modifying its behavior or bricking it.

[tkstreet]

I have a number of nRF52832 devices in the field where the bootloader was created with SDK 11.  They were created in the most liberal format, using the 0xFFFF codes in all fields (using the old nrfutil version) and no key signing.  I would like to flash an entirely new set to these devices - new bootloader, S132, and new application - but I cannot find any way to do this using either packaging format with the old nrfutil (v0.3.0, I believe) nor the new nrfutil (v3.5.0). I have tried just about every combination and permutation I could think of to no avail.