NRF52 DFU ERROR

[cool__looc]

I am setting up the DFU example based on NRF52832.

I tried with different version of SDKs (SDK13, SDK15 and SDK16) and all based on armgcc. All toolchains are the same version as it indicates in the Makefile.posix.

But all of them encounter a same problem in nrf_crypto_ecdsa_verify_hash .

I have done the following:

1. generate key: nrfutil keys generate own_test.key

2. generate public key: nrfutil keys display --key pk --format code own_test.key --out_file public_key.c

3. copy public key to bootloader:

4. git clone micro-ecc and build uECC with armgcc;

4. build bootloader;

5. erase whole device, program softdevice, bootloader;

Till here everything is fine and also DfuTarg showed up with "nRF Connect";

Then I generated a test application and generate dfu update zip file with cmd: nrfutil pkg generate --hw-version 52 --application-version 1 --application _build/nrf52832_xxaa.hex --sd-req 0x98 --key-file own_test.key dfu_update.zip

Then try to using dfu_update.zip for the dfu process. It always give the same error

err_code = nrf_crypto_ecdsa_verify_hash(sig_info_p256, &crypto_key_pk, &init_packet_hash, &crypto_sig);

nrf_crypto_ecdsa_verify_hash() returns NRF_DFU_RES_CODE_INVALID_OBJECT.

Then debug with gdb, this function called uECC_verify, the following are the public key:

(gdb) p/x *public_key@64
$4 = {0x5a, 0x9e, 0x44, 0xf, 0x27, 0x89, 0x9, 0x3d, 0x61, 0x87, 0x4c, 0xe, 0x95, 0x60, 0x0, 0xb6, 0x39, 0xc, 0xbf, 0x34, 0x57, 0xbc, 0x63, 0x40, 0x2b, 0x2e, 0x60, 0xb2,
0xfd, 0x87, 0xe0, 0xbe, 0x2c, 0x15, 0x15, 0x52, 0x2c, 0x90, 0xd4, 0x4c, 0xf1, 0xd6, 0x12, 0x9b, 0xf5, 0xb5, 0x87, 0x52, 0x4, 0x2e, 0xca, 0x8e, 0x7f, 0x7a, 0x53, 0x47,
0x95, 0x3c, 0x3b, 0x97, 0x3d, 0xf9, 0xf3, 0xe9}

Compare with generate open key:

/** @brief Public key used to verify DFU images */
__ALIGN(4) const uint8_t pk[64] =
{
0x5a, 0x9e, 0x44, 0x0f, 0x27, 0x89, 0x09, 0x3d, 0x61, 0x87, 0x4c, 0x0e, 0x95, 0x60, 0x00, 0xb6, 0x39, 0x0c, 0xbf, 0x34, 0x57, 0xbc, 0x63, 0x40, 0x2b, 0x2e, 0x60, 0xb2, 0xfd, 0x87, 0xe0, 0xbe, 0x2c, 0x15, 0x15, 0x52, 0x2c, 0x90, 0xd4, 0x4c, 0xf1, 0xd6, 0x12, 0x9b, 0xf5, 0xb5, 0x87, 0x52, 0x04, 0x2e, 0xca, 0x8e, 0x7f, 0x7a, 0x53, 0x47, 0x95, 0x3c, 0x3b, 0x97, 0x3d, 0xf9, 0xf3, 0xe9
};

That means the public key is right file.

Get all ecc parameters out and create a bare project with nrf52832. The uECC_verify is not right.

int main(void)
{
        uint8_t public[64] = {0x5a, 0x9e, 0x44, 0xf, 0x27, 0x89, 0x9, 0x3d, 0x61, 0x87, 0x4c, 0xe, 0x95, 
                              0x60, 0x0, 0xb6, 0x39, 0xc, 0xbf, 0x34, 0x57, 0xbc, 0x63, 0x40, 0x2b, 0x2e, 0x60, 
                              0xb2, 0xfd, 0x87, 0xe0, 0xbe, 0x2c, 0x15, 0x15, 0x52, 0x2c, 0x90, 0xd4, 0x4c, 
                              0xf1, 0xd6, 0x12, 0x9b, 0xf5, 0xb5, 0x87, 0x52, 0x4, 0x2e, 0xca, 0x8e, 0x7f, 
                              0x7a, 0x53, 0x47, 0x95, 0x3c, 0x3b, 0x97, 0x3d, 0xf9, 0xf3, 0xe9};
        uint8_t hash[32] = {0x11, 0xa4, 0xc9, 0x1b, 0xdd, 0x12, 0x8b, 0x97, 0xdf, 0x27, 0xb2, 0xcc, 
                            0x38, 0x92, 0x53, 0xe2, 0xdd, 0x69, 0xd4, 0x7c, 0xcb, 0xde, 0x96, 0x78,
                            0x92, 0x43, 0xc, 0x35, 0xab, 0x7e, 0x66, 0xe8};
        uint8_t sig[64] = {0xb9, 0xa, 0x63, 0xd3, 0xd6, 0xd0, 0x1f, 0x77, 0x85, 0xf0, 0x53, 0xb4, 0xa0, 
                           0x25, 0x1e, 0xb0, 0x84, 0xfb, 0x48, 0x2d, 0xa0, 0x8e, 0x78, 0xca, 0x18, 0x3, 
                           0xd6, 0x35, 0xd5, 0xba, 0xf3, 0xfe, 0xa8, 0xd7, 0x76, 0xf1, 0x6c, 0xba, 0x76, 
                           0xd4, 0x5d, 0x75, 0x1b, 0x2, 0xf, 0x35, 0x8a, 0x13, 0x53, 0xe1, 0x3a, 0x34, 0x5d, 
                           0xb, 0x46, 0x43, 0xee, 0x4b, 0xb8, 0x5e, 0x8d, 0x4d, 0x5f, 0x63};
        const struct uECC_Curve_t * curve;

        curve = uECC_secp256r1();
        int re = uECC_verify(public, hash, sizeof(hash), sig, curve);
        if (!re) {
                PRINTF("uECC_verify() failed %d\n", re);
                return 1;
        } else {
                PRINTF("uECC_verify() ok\n");
        }   
}

But the public key matches with public_key.c and signature are also matched with cmd:

nrfutil pkg display dfu_update.zip

|
|- Image count: 1
|
|- Image #0:
   |- Type: application
   |- Image file: nrf52832_xxaa.bin
   |- Init packet file: nrf52832_xxaa.dat
      |
      |- op_code: INIT
      |- signature_type: ECDSA_P256_SHA256
      |- signature (little-endian): b'b90a63d3d6d01f7785f053b4a0251eb084fb482da08e78ca1803d635d5baf3fea8d776f16cba76d45d751b020f358a1353e13a345d0b4643ee4bb85e8d4d5f63'
      |
      |- fw_version: 0x00000001 (1)
      |- hw_version 0x00000034 (52)
      |- sd_req: 0x98
      |- type: APPLICATION
      |- sd_size: 0
      |- bl_size: 0
      |- app_size: 46952
      |
      |- hash_type: SHA256
      |- hash (little-endian): b'e52511d2c57fb1aa9f3bd1177bed871ac5f2d3a5037c51cbfff07b3f75fe1fd2'
      |
      |- boot_validation_type: ['VALIDATE_GENERATED_CRC']
      |- boot_validation_signature (little-endian): [b'']
      |
      |- is_debug: False

So basically it means the hash is wrong. But what are the possibilities for this?

Thanks,

cool^^looc

[Vidar Berg]

Hi,

Are you using the pre-release of nrfutil v6 by any chance? I had a similar case yesterday that turned out to be caused by a bug in the latest nrfutil release. Please take a look at the other thread and let me know if you're indeed encountering the same issue: https://devzone.nordicsemi.com/f/nordic-q-a/54202/error-of-invalid_object-when-using-nrf-connect-desktop-after-generating-dfu-zip-file-with-new-keys. 

[cool__looc]

Hi,

This is really wired. The package generated with nrfutil5.2 does work. After that both nrfuit5.2 and nrfutil6.00a are fine for the signature. :(

I tested both for signature are fine. That means there was something were wrong.

Btw, I tested both sdk13 and sdk16. Both of them can perform dfu update but sdk13 stuck in bootloader mode while sdk16 runs to new application.

Thanks,

[cool__looc]

Hi,

It falls back to dfu mode. Need more time to debug that.

[Vidar Berg]

Hi,

It might be failing in dfu_req_handling.c::nrf_dfu_postvalidate() then. This is where the received image is verified against the hash from the init packet.

[cool__looc]

Hi,

The execution of nrf_dfu_postvalidate is successful. No error, but still falls back to dfu mode.

[Vidar Berg]

Hi,

Ok, that's good. Then I would check whether the bootloader is entering DFU mode because nrf_dfu.c::nrf_dfu_enter_check() returns true, or because nrf_dfu_app_is_valid() is returning false. 

[cool__looc]

Hi,

Found the problem it is because the bootloader always tries to check the BOOTLOADER_BUTTON which is not the case in my hardware platform. Now I comment out this check then it is fine.

Thanks,