Voltage Glitching the Nordic nRF52: How a Zap Resurrected the Debugger

In the world of embedded systems, we rely on a specific contract with the hardware manufacturer: if we burn a specific bit in the configuration memory, the chip locks its doors. For Nordic Semiconductor's ubiquitous nRF52 series—powering everything from AirTags clones to FIDO2 security keys—this feature is called APPROTECT (Access Port Protection).

The promise is simple. You write 0x00 to the APPROTECT register in the User Information Configuration Registers (UICR), and the device disables the Serial Wire Debug (SWD) interface. No more J-Link. No more dumping flash. The firmware is sealed in amber, safe from prying eyes.

But here is the cynical reality of hardware security: logic is abstract, but silicon is physical. Logic says "If A is 0, Disable B." Physics says "If I starve the electrons powering the gate that checks A, maybe B stays enabled." CVE-2020-27211 isn't a buffer overflow; it's a reminder that digital security relies entirely on analog stability. And analog stability is remarkably easy to break with a $50 crowbar circuit.

To understand the exploit, we have to look at how the nRF52 boots up. It doesn't just wake up knowing it's locked. It has to learn it's locked.

Here is the simplified boot choreography:

1. Power On Reset (POR): The chip wakes up.
2. Internal Housekeeping: Regulators stabilize, clocks start.
3. Read Configuration: The hardware controller reads the UICR flash area to check settings like voltages and... protection status.
4. Enforce Protection: If APPROTECT is enabled, the hardware sends a signal to the Debug Access Port (DAP) to sever the link.

See step 3 and 4? That is a temporal gap. There is a finite amount of time—nanoseconds—between the chip reading the "Lock" command and actually locking the door. The vulnerability is simply that the logic responsible for this check is sensitive to voltage fluctuations.

If we can induce a voltage glitch (a sharp drop in VDD) exactly when the internal logic is transferring the value 0x00 from the UICR to the protection controller, we can corrupt the data or the instruction. The controller reads 0xFF (or garbage), assumes protection is disabled (the default state), and leaves the SWD port wide open. It is effectively a race condition between the security logic and a power supply interruption.

There is no C code to patch here initially, this is a hardware behavior. However, we can visualize the attack logic compared to the hardware state using a diagram. The attacker's code runs on an external FPGA or microcontroller (like a ChipWhisperer) controlling the glitch.

Here is the logic flow of the attack:

The "Code" involved is usually a Python script driving the glitching hardware. It looks something like this:

# Pseudo-code for the glitch loop
scope.glitch.repeat = 1
scope.glitch.width = 100 # ~200ns pulse
 
for offset in range(1000, 5000): # Scan timing offsets
    target.reset()
    scope.glitch.ext_offset = offset
    scope.arm()
    
    # The magic happens here: VDD drops to 0V for 200ns
    # ideally hitting the exact clock cycle of the UICR read.
    
    try:
        # Try to resurrect the debugger
        if target.connect_swd():
            print(f"BOOM! Unlocked at offset {offset}")
            target.dump_flash("firmware.bin")
            break
    except Exception:
        pass # Reset and try again

The target code (the firmware on the nRF52) doesn't even know it's being attacked. It thinks it just had a slightly rough morning booting up.

Let's get our hands dirty. How does a researcher actually pull this off? This was brilliantly demonstrated by LimitedResults and later Fraunhofer AISEC.

Phase 1: Board Preparation Voltage glitching requires sharp edges. If the target board has massive decoupling capacitors (which good engineers add to prevent voltage drops), the glitch will be smoothed out into a gentle wave. The attacker must desolder the capacitors on the DEC4 or VDD lines. This makes the chip power-unstable, which is exactly what we want.

Phase 2: The Setup We connect a glitcher (like a ChipWhisperer or a simple MOSFET crowbar circuit) to the voltage rail. We trigger the glitch based on the rising edge of the RESET line.

Phase 3: The Campaign The attack is statistical. We don't know the exact nanosecond delay required. We script the glitcher to delay 100ns after reset, glitch, check SWD. Then reset, delay 101ns, glitch, check SWD.

Eventually, we hit the "Goldilocks zone." The voltage drops low enough to corrupt the logic state but not low enough to trigger a Brown-out Reset (BOR) or crash the CPU entirely. When this hits, the SWD interface, which was supposed to be dead, suddenly responds to a DPIDR read request. The device is unlocked. We can now read out the entire flash memory, including AES keys, Bluetooth mesh secrets, and intellectual property.

Why is this terrifying? Because it breaks the "Hardware Root of Trust" assumption.

FIDO2 Keys: Many open-source security tokens (like earlier versions of SoloKeys) used the nRF52840. An attacker who steals your physical key could use this method to dump the flash, extract the private keys, and clone your 2FA token.

IoT Secrets: Smart locks, medical devices, and sensor nodes often store global encryption keys in flash. Extracting one key from one stolen device could allow an attacker to decrypt traffic for the entire fleet.

IP Theft: For vendors, this means your compiled firmware—your secret sauce—is readable. Reverse engineering becomes trivial when you have the binary.

Crucially, this vulnerability is unpatchable in software for existing silicon. The flaw is in the hardware bootrom/logic sequence. You cannot OTA (Over-The-Air) update the physics of the silicon die.

Nordic Semiconductor responded with Informational Notice IN-133. The remediation falls into two buckets: "Buy new chips" and "Harden the software."

1. The Real Fix (Hardware) Nordic released a new silicon revision (Revision 3). This hardware logic was altered to be resilient against this specific glitch vector. If you are building a new product, you check the laser markings on the chip. If it's old stock, it's vulnerable.

2. The Software Workaround (Legacy) For devices already in the field or old stock, Nordic introduced a concept called Secure APPROTECT.

Instead of relying solely on the hardware UICR bit, the firmware itself (in the bootloader) checks if the device should be locked. If it detects the debug port is open but shouldn't be, it executes a loop to disable it or shutdown.

> [!NOTE] > Cynic's Note: This software fix moves the goalposts but doesn't remove them. If the firmware is checking the lock state... we can just glitch the firmware instruction that does the checking. It turns a "Single Glitch" attack into a "Double Glitch" attack (one to bypass hardware lock, one to bypass software check). It raises the bar, but it doesn't close the bar.