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

[Øyvind]

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

[Norbert H.]

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

[Øyvind]

Hello, and thanks for the elaborate answer. I don't have a good answer for you right now, but let me forward this internally and discuss with out modem experts. I hope to have an answer by end of tomorrow or Thursday. 

Kind regards,
Øyvind

[Øyvind]

And just to clarify, you are targeting DECT NR+ modem FW?

[Norbert H.]

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.