• State Suggested Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 74 subscribers
  • Views 239 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 347092
Options

FMFU segments SHA

Norbert H.

We are currently working on a custom modem firmware update. For this, we would like to use the CBO file you provided. Updating the segments with the CBO file is working so far. However, we have some questions regarding the SHA of the segments. When we read the SHA for the segments from the firmware, we get the same result as in firmware.update.image.digest.txt. However, if we calculate the SHA using the binary data of the segments, we get a different result. The question is now how you calculate the SHA from the binary segments.

The following logs are based on the file mfw-nr+_nrf91x1_1.0.2.cbor

firmware.update.image.digest.txt with
SHA256 of all ranges in ascending address order: 337BAFF20F63F4CA9E897BE505F662134F523DAE14947386FAC8D88FA304A5DA
Range: 0x00006000--0x0000FFFF SHA256:            6BAA1B103E6690618B50A3C526E17B8905BFAF7810FBACAEB5A91C7D7DD5F27D
Range: 0x00038000--0x000B3FFF SHA256:            7D90AE6D6753C5B7774F455A359032EC1FEABE62A23DAD086BDC4FBE51F1A415
Range: 0x0027C000--0x0027FFFF SHA256:            9811C05B95FE6AFC46572E260E8A6228BC2439F7E101011BE1419A3B8A1136C4


Verifying segment 3/5: 0x6000 - 0xFFFF
Expected SHA256: 381f4d5f573f49fe4997248fe48a2a4d195957b3f084857e1a63091a18629d53
Readout  SHA256: 6baa1b103e6690618b50a3c526e17b8905bfaf7810fbacaeb5a91c7d7dd5f27d

Verifying segment 4/5: 0x38000 - 0xB3FFF
Expected SHA256: ddc13d26c04af3a63f07adf4929a76ce0807e8f7af83bfd278a31ee5c9396a7d
Readout  SHA256: 7d90ae6d6753c5b7774f455a359032ec1feabe62a23dad086bdc4fbe51f1a415

Verifying segment 5/5: 0x27C000 - 0x27FFFF
Expected SHA256: 7ad69832acf0460b4eac112677839c0b0db184f4acc5fdc777a55aae1dd0a8ab
Readout  SHA256: 9811c05b95fe6afc46572e260e8a6228bc2439f7e101011be1419a3b8a1136c4

Parents
  • 0

    Hello, could you please provide more details to your problem. What exactly are you trying to achieve? What are you basing this "custom modem fw update" on? What version of the nRF Connect SDK are you using? 

    Thanks.

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    We adapted your FMFU over SMP (UART) to work with SPI.
    docs.nordicsemi.com/.../README.html

    In your example, you provide the mfw_xxxx.zip file to the non-public library at pynrfjprog. To have full control, we reimplemented the functionality in Python by parsing and processing the cbor-file. The update is working. Now, we want to verify the FW update. To do this, we want to compare the SHAs from the segments. This is similar to what you do under the hood in pynrfjprog. To do this, we calculate the SHA of a segment from the cbor-file and read the SHA of the segments from the modem (via SMP). The SHA that we read over SMP is the same as that in the firmware.update.image.digest.txt file. However, the calculated SHA of the segment from the cbor-file/binary does not correlate to it. Therefore, the version of the nRF Connect SDK is not necessary for resolving this issue. You provided a documentation for the cbor-file. The COSE_Sign1_Manifest with the binary blob of the segments. The blob_hash is the SHA for the whole binary-blob, but how can we calculate the SHA for the segments? So that we can get the same result as in your firmware.update.image.digest.txt file?

    docs.nordicsemi.com/.../fmfu_fdev.html

  • 0 in reply to Øyvind

    Yes we are targeting with the DECT NR+ modem FW. But the SHA calculation of the modem segments should be the same for LTE or DECT. The big question is can we calculate the sha's from the binary blob (cbor-file) or do we need the pre-calculated sha's from the firmware.update.image.digest.txt.

    I think the binary bob (in the cbor-file) is encrypted and if the SHA is returned from the modem via the unencrypted content, it would not be possible to calculate from the cbor file.

  • 0 in reply to Norbert H.

    HI, I have not received any updates on this, but we are still working with an answer. I hope to have an answer by end of Tuesday.

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Hello, sorry the late answers on your inquiry. Our team working on this have a high workload and are not able to provide answers at quick as they want. There might not be any answers until end of July/beginning of August, but I hope to get answer within this week.

    Sorry for any inconvenience this may cause.

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Hello again, 

    the modem team informs me that the file firmware.update.image.digest.txt refers to digests of plaintext modem firmware FLASH contents, whereas the transfer image contains encrypted firmware.

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Thanks for the response! 

    To come back to my question. So it is not possible to generate the hashes for a verification from the cbor-file. This is because the image in the cbor-file is encrypted, and the hashes that can be read from the modem are generated from the decrypted image. So i have to use the hashes from the firmware.update.image.digest.txt to verify a successful update.

    Is this correct?

Reply Children
No Data
Related
Terms of service