[pantalaimon]

That is if they have been locked in the first place.

Also with a lot of devices being firmware upgradable, there is little point in enabling read-out protection if you can just download the firmware off the internet. (Unless you want to go through all the hassle of encrypting the firmware image, but most devices won't be doing anything so special to make this worthwhile)

[SwaraLink]

Nordic provides some easy-to-use tools and examples for encrypting and signing firmware images when using a bootloader for in-field updates. I would expect that most products based on the nRF52 that support firmware updates encrypt the image.

[agustamir]

Nordic's off-the-shelf firmware upgrade process has signed image verification only. The image itself sent over BLE is not encrypted. So anyone using that right off the bat is in for a nice surprise.

[pantalaimon]

Why would anyone be surprised? I'd be very surprised if my firmware was encrypted without setting any encryption key.

[agustamir]

Partially because they call their firmware upgrade process "secure Device Firmware Update (DFU) functionality" (lifted from their documentation). Obviously, an engineer needs to go see the source to see what is actually happening under the hood.

[pantalaimon]

Why do you need Encryption for security? A signature should be enough.

(Don’t conflate security with confidentiality)

[agustamir]

Not in the context of enabling trusted binaries being used for updates, but to your original point about reverse engineering unencrypted firmware