[HN Gopher] Bypassing Readout Protection in Nordic Semiconductor...
___________________________________________________________________
Bypassing Readout Protection in Nordic Semiconductor
Microcontrollers
Author : serhack_
Score : 42 points
Date : 2023-07-09 13:40 UTC (1 days ago)
(HTM) web link (www.emproof.com)
(TXT) w3m dump (www.emproof.com)
| nick0garvey wrote:
| 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.
| rx_tx wrote:
| 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...
| rft wrote:
| 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.
| dmitrygr wrote:
| 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
| rft wrote:
| 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...
| kurtoid wrote:
| Link should be https://www.emproof.com/bypassing-readout-
| protection-in-nord...
|
| (2021)
| serhack_ wrote:
| Noo! I thought I pasted the correct URL, sorry
| wongarsu wrote:
| 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.
| serhack_ wrote:
| 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..
| rft wrote:
| Very good guess! Thank you for this comment, this makes
| tracking the problem down much easier.
| jacquesm wrote:
| 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.
| Zamiel_Snawley wrote:
| > 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.
| rft wrote:
| 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!
| jamesmunns wrote:
| 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.
| serhack_ wrote:
| Is this related? https://www.emproof.com/attacking-
| microcontroller-readout-pr...
| rft wrote:
| 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
___________________________________________________________________
(page generated 2023-07-10 23:01 UTC)