[rx_tx]

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]

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]

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