5 ms·

Bypassing Readout Protection in Nordic Semiconductor Microcontrollers

57 points by serhack_ 3y ago

kurtoid 3y ago
Link should be https://www.emproof.com/bypassing-readout-protection-in-nordic-semiconductor-microcontrollers/ https://www.emproof.com/bypassing-readout-protection-in-nord... (2021)
- serhack_ 3y ago
  Noo! I thought I pasted the correct URL, sorry
  - wongarsu 3y ago
    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_ 3y ago
      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 3y ago
        Very good guess! Thank you for this comment, this makes tracking the problem down much easier.
nick0garvey 3y ago
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 3y ago
  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-protections-with-fault-attacks/ https://www.emproof.com/attacking-microcontroller-readout-pr...
  - rft 3y ago
    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.
    - rx_tx 3y ago
      Thanks. I guess the top link pointing to the team's homepage and not the specific article is definitely confusing.
jamesmunns 3y ago
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_ 3y ago
  Is this related? https://www.emproof.com/attacking-microcontroller-readout-protections-with-fault-attacks/ https://www.emproof.com/attacking-microcontroller-readout-pr...
  - rft 3y ago
    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-approtect-bypass/ https://limitedresults.com/2020/06/nrf52-debug-resurrection-... [2] https://www.youtube.com/watch?v=_E0PWQvW-14 https://www.youtube.com/watch?v=_E0PWQvW-14
Zamiel_Snawley 3y ago
> 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 3y ago
  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!
  - ImPostingOnHN 3y ago
    can you go into details, please?
  - Zamiel_Snawley 3y ago
    Thanks for the reply! I'd love to read more about your obfuscation techniques, I was under the impression that obfuscation is largely ineffective.
jacquesm 3y ago
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.
dmitrygr 3y ago
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 http://dmitry.gr/?r=05.Projects&proj=23.%20PSoC4
- rft 3y ago
  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-technique-for-an-arm-cortex-m0-soc/ https://blog.includesecurity.com/2015/11/firmware-dumping-te...

57 points by serhack_ 3y ago

Link should be https://www.emproof.com/bypassing-readout-protection-in-nordic-semiconductor-microcontrollers/ https://www.emproof.com/bypassing-readout-protection-in-nord... (2021)

serhack_ 3y ago
Noo! I thought I pasted the correct URL, sorry
- wongarsu 3y ago
  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_ 3y ago
    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 3y ago
      Very good guess! Thank you for this comment, this makes tracking the problem down much easier.

nick0garvey 3y ago

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 3y ago
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-protections-with-fault-attacks/ https://www.emproof.com/attacking-microcontroller-readout-pr...
- rft 3y ago
  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.
  - rx_tx 3y ago
    Thanks. I guess the top link pointing to the team's homepage and not the specific article is definitely confusing.

jamesmunns 3y ago

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_ 3y ago
Is this related? https://www.emproof.com/attacking-microcontroller-readout-protections-with-fault-attacks/ https://www.emproof.com/attacking-microcontroller-readout-pr...
- rft 3y ago
  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-approtect-bypass/ https://limitedresults.com/2020/06/nrf52-debug-resurrection-... [2] https://www.youtube.com/watch?v=_E0PWQvW-14 https://www.youtube.com/watch?v=_E0PWQvW-14

Zamiel_Snawley 3y ago

> 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 3y ago
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!
- ImPostingOnHN 3y ago
  can you go into details, please?
- Zamiel_Snawley 3y ago
  Thanks for the reply! I'd love to read more about your obfuscation techniques, I was under the impression that obfuscation is largely ineffective.

jacquesm 3y ago

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.

dmitrygr 3y ago

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 http://dmitry.gr/?r=05.Projects&proj=23.%20PSoC4

rft 3y ago
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-technique-for-an-arm-cortex-m0-soc/ https://blog.includesecurity.com/2015/11/firmware-dumping-te...