Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Adding Encryption to Secure DFU SDK v15

I am attempting to add encryption to the secure DFU process with SDK 15.2. I am following the process described in this post, however am running into an issue related to the firmware type. 

I have made all of the changes to nrfutil as described in the original post, including regenerating the proto messages for both the python files (dfu_cc_pb.py) and the .c/.h files (dfu-cc.pb.c and dfu-cc.pb.h). I am able to generate an unencrypted package, unzip it, encrypt the app.bin file, and rezip the package for use in the dfu. After doing that, I can run 

nrfutil pkg display tmp/app_firmware-encrypted.zip

and receive the following output, suggesting that the package has been created and the new nonce value has been included:

DFU Package: <tmp/app_firmware-encrypted.zip>:
|
|- Image count: 1
|
|- Image #0:
   |- Type: application
   |- Image file: app.bin
   |- Init packet file: app.dat
      |
      |- op_code: INIT
      |- signature_type: ECDSA_P256_SHA256
      |- signature (little-endian): 991c0df5b6e175fbbd416491104d409f6148935d70af9cb3af8d1b8965e5f62e2d6e727d26e34454522530f2f4ae9aaff2a95f2c5b74d1b554d4609d892d49b2
      |
      |- fw_version: 0x00000001 (1)
      |- hw_version 0x00000034 (52)
      |- sd_req: 0xAE
      |- type: APPLICATION
      |- sd_size: 0
      |- bl_size: 0
      |- app_size: 440540
      |
      |- hash_type: SHA256
      |- hash (little-endian): 5932e4b93f5abcee9b5fc7701727067e7e598b3478063e6e235895df9e34711f
      |
      |- is_debug: False
      |- nonce (little-endian): 0df22086afa07264c4bb3c03

As you can see, this output suggests that the init packet knows I am attempting to do a DFU of "type: APPLICATION".

However when I try to actually preform the DFU with my new bootloader, I am running into an error in the function nrf_dfu_ver_validation_check(). When the function checks fw_type_ok(p_init), it is giving me an error. I've edited error logging to see what type I am getting back (see below), and somehow the init pointer has registered a type of 62, when it should in fact be 0 (corresponding to the dfu_fw_type_t enum, from dfu-cc.pb.h, also displayed below)

// nrf_dfu_ver_validation.c
nrf_dfu_result_t nrf_dfu_ver_validation_check(dfu_init_command_t const * p_init)
{
    nrf_dfu_result_t ret_val = NRF_DFU_RES_CODE_SUCCESS;
    if (!fw_type_ok(p_init))
    {
        NRF_LOG_ERROR("Invalid firmware type of %d", p_init->type); \\ telling me 62, but should be DFU_FW_TYPE_APPLICATION = 0
        ret_val = EXT_ERR(NRF_DFU_EXT_ERROR_INIT_COMMAND_INVALID);
    }
...
}

// dfu-cc.pb.h
typedef enum
{
    DFU_FW_TYPE_APPLICATION = 0,
    DFU_FW_TYPE_SOFTDEVICE = 1,
    DFU_FW_TYPE_BOOTLOADER = 2,
    DFU_FW_TYPE_SOFTDEVICE_BOOTLOADER = 3
} dfu_fw_type_t;

I am somewhat stumped here, I'm not sure exactly how this init packet is being loaded into memory from the zip file, and what to do to debug this issue. I've tried to add the minimum amount of code necessary to debug this, but if there is more I need to add please just request it and I will upload it. Generally I am following the linked tutorial line by line, however the line numbers of the tutorial are a bit outdated so I may have misplaced something (particularly in the nrfutil revisions). Note that I am using the code from nrfutil repository, version 4.0.0.

Parents Reply Children
No Data
Related