Uploading a corrupted .bin file should cause the target device to complain about it before it actually applies the FW on the device
ksidirop-laerdal opened this issue · 2 comments
Is there some sort of integrity check performed on the uploaded .bin file that I'm missing? I have intentionally corrupted the firmware .bin file using a hex editor and uploaded it over to a BLE device that runs on Nordic's stack (McuMgr) and the device applied the FW just fine without sweating about it.
Shouldn't the .bin file contain some sort of checksum-check to be 100% sure that the firmware that just got uploaded to the device is indeed healthy, before proceeding to install it?
Please let me know if McuMgr stack actually supports such a feature in a some non-obvious way.
Hello,
There are several checks in place.
If you're using imgtool to sign your app, like described here, the binary gets wrapped in an envelope containing a magic number and some key-value pairs, one of which contains the signature of the image. The full signed binary is transfered to the device and McuBoot verifies the signature and other optional prerequisites before swapping the images or marking the new one as active.
Did you modify the signed binary, or the compiled hex? Also, ensure you have McuBoot compiled with the correct verification options, which should be enabled by default.
For more information, please ask the question on Nordic DevZone as the question is outside the scope of the the library. Our Support Team knows more about the firmware and build system. Thanks!
You're absolutely right @philips77 - it turns out that we had overlooked the return code and we misled ourselves. Upon closer inspection it turned out that changing a single byte in the firmware being uploaded results in the device returning an error: 'Slot Image has no hash TLV' (state=confirming)
Appreciate the prompt response and the info shared.