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.
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.
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.
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.
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.
> 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)?
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!
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.
(2021)