Bypassing Readout Protection in Nordic Semiconductor Microcontrollers | Hacker News Reader

Bypassing Readout Protection in Nordic Semiconductor Microcontrollers

emproof.com

57 pointsserhack_19 comments

Link should be https://www.emproof.com/bypassing-readout-protection-in-nord...

(2021)

Noo! I thought I pasted the correct URL, sorry

You didn't do anything wrong. The page claims the canonical url is "./index.html" (through the link rel="canonical" tag in the middle of the header). If a page specifies a canonical URL HN respects that and uses it instead of the submission URL.

Getting the canonical URL wrong is somewhat common, but this one is so comically wrong that it feels intentional. Or somebody misconfigured their wordpress.

That's more curious.. I guess they used some extension to save Wordpress website as a static website (like html pages) but they misconfigured it..

Very good guess! Thank you for this comment, this makes tracking the problem down much easier.

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.

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.

Great method.

Unless I misunderstood the article [1], it describes this very same HW-based method of power glitching the chip at a crucial time using an external STM32F0 controlling the Vcore going to the nRF. Basically preventing it from checking if it's correctly locked or not at boot.

After managing to connect through glitching, they dump the FW, then turn off APPROTECT, reflash, and have open debug access.

>Our attack setup thus consists out of 1) a transistor connected to the CPU core supply voltage and ground, 2) a dev board to control the glitch timing, and 3) a debug probe to try to access the debug interface.

[1]: https://www.emproof.com/attacking-microcontroller-readout-pr...

Just for clarification, the TFA is about the nRF51 which can be attacked via a debugger only. No glitching or other hardware was needed.

Your link is a different attack on the newer nRF52 series which no longer has the same weakness in its debug handling.

Thanks. I guess the top link pointing to the team's homepage and not the specific article is definitely confusing.

Aw, it'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's an nRF53 available, and nRF54 now/soon), but the nRF52 is still what I see most in the field today.

Yeah, that is the blog post about the newer nRF52 series. From what we were told, Nordic updated the silicon to counter the fault attack we were using. Retesting with newer devices is on our todo list.

Some more links, also in the blog post, are [1], demonstration on a dev board, and [2] the airtag attack.

[1] https://limitedresults.com/2020/06/nrf52-debug-resurrection-... [2] https://www.youtube.com/watch?v=_E0PWQvW-14

So..they read my article from 2017 [1] where i described precisely this, and then did it... cool i guess

[1] http://dmitry.gr/?r=05.Projects&proj=23.%20PSoC4

Thanks for the link, I will give it a proper read first thing tomorrow morning. From my very quick skim your attack is far more advanced than what I did. It was enough to just set some registers via the debugger and single step an instruction. With just a single load gadget I could dump the entire ROM. I did not bother with a write gadget as for the Nordic SoC you can just reflash the extracted image without enabling protection and then go from there.

I personally did not know about this article, I have not touched the Cypress eco system much, if at all. I linked to a previous article that this project was based on [1].

What I find interesting is that Cypress uses a similar split ROM as Nordic for some kind of system code and data like calibration values. Really neat to see how other vendors do this.

[1] https://blog.includesecurity.com/2015/11/firmware-dumping-te...

> specialized solutions are needed that provide protection even after the code was extracted.

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)?

Neither of these seem effective nor practical.

Without going into details, we can make the extracted binary hard to analyze via, e.g., obfuscation or other methods. You are correct, just using a decryption key in ROM without other countermeasures does not provide much security as it can also be read with the same method. You need to assume the entire flash image is known and built from there. As you said, traditional code obfuscation is not practical on these small devices, but this is exactly the problem we wanted to tackle!

can you go into details, please?

Thanks for the reply! I'd love to read more about your obfuscation techniques, I was under the impression that obfuscation is largely ineffective.

It'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.

Reply on news.ycombinator.com