Bypassing Readout Protection in Nordic Semiconductor Microcontrollers

Link should be <a href="https:&#x2F;&#x2F;www.emproof.com&#x2F;bypassing-readout-protection-in-nordic-semiconductor-microcontrollers&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.emproof.com&#x2F;bypassing-readout-protection-in-nord...</a><p>(2021)

Most of the attacks I see on Nordic devices are power based attacks, where cutting the power for a brief instant causes protection instructions not to run.<p>This one is entirely different, and attacks the initialization code directly. This code has no restrictions on its ability to access memory, allowing a full dump.<p>Great method.

Aw, it&#x27;s a shame this is an older post, I was wondering if there was a published attack for the relatively newer nRF52. The nRF52 is already a little long in the tooth (there&#x27;s an nRF53 available, and nRF54 now&#x2F;soon), but the nRF52 is still what I see most in the field today.

So..they read my article from 2017 [1] where i described precisely this, and then did it... cool i guess<p>[1] <a href="http:&#x2F;&#x2F;dmitry.gr&#x2F;?r=05.Projects&amp;proj=23.%20PSoC4" rel="nofollow noreferrer">http:&#x2F;&#x2F;dmitry.gr&#x2F;?r=05.Projects&amp;proj=23.%20PSoC4</a>

&gt; specialized solutions are needed that provide protection even after the code was extracted.<p>Anybody know what solutions they are hinting at here? Obfuscating binaries? Some kind of encrypted flash with on-the-fly decryption(but the decryption key would be protected by the same inadequate ROP)?<p>Neither of these seem effective nor practical.

It&#x27;d be very nice if someone managed to do this for Freescale. Their stuff is all over the place and more often than not such copyprotection is used to create a commercial moat to block interop with 3rd party hardware.