What Does an nRF53 Crack Actually Involve?
An nRF53 crack is the process of recovering firmware from a Nordic Semiconductor nRF5340 whose debug access port has been locked by APPROTECT or Secure-APPROTECT. Because the nRF5340 runs a dual-core Cortex-M33 design — one application core at 128 MHz and one network core at 64 MHz — each core has its own protection register, and both must be addressed independently. Authorized recovery typically combines semi-invasive decapsulation, fault-injection analysis, and protocol-level debug authentication to extract the flash contents without triggering the on-chip erase-on-unlock mechanism.
nRF5340 Protection Architecture: Why It Matters
Nordic redesigned access-port protection between the nRF52 series and the nRF53 series. The older nRF52 parts used a single APPROTECT register stored in UICR (User Information Configuration Registers), and disabling it simply required a full chip erase. The nRF5340 introduced a hardware-backed APPROTECT that defaults to enabled in production silicon — a significant change that catches many developers off-guard.
Protection Registers at a Glance
| Register | Core Affected | Default State | Unlock Consequence (Standard Path) |
|---|---|---|---|
| APPROTECT (UICR) | Application core (Cortex-M33, 128 MHz) | Enabled (locked) | Full erase of application flash (1 MB) |
| SECUREAPPROTECT (UICR) | Application core — Secure domain | Enabled (locked) | Full erase; TrustZone partitions reset |
| ERASEPROTECT | Whole device | Disabled | If set, even ERASEALL via CTRL-AP is blocked |
| Network-core APPROTECT | Network core (Cortex-M33, 64 MHz) | Enabled (locked) | Erase of network flash (256 KB) |
The standard Nordic-sanctioned unlock path always erases flash. That is by design — it prevents casual readout. An nRF53 crack for firmware recovery (not just re-provisioning) must therefore bypass or circumvent the erase-on-unlock sequence, which is where specialized lab techniques come in.
How Protection Levels Changed from nRF52 to nRF53
Engineers familiar with nRF91 series firmware recovery will recognize some overlap, since the nRF91 also uses Cortex-M33 with SPU-based security. However, the nRF53 adds a second core and a second, independent flash bank, which doubles the attack surface — and the complexity.
Key Differences
- Default-on APPROTECT: On nRF52, APPROTECT defaults to disabled (0xFFFFFFFF in erased UICR). On nRF5340, the hardware treats the erased state as protected. A developer must explicitly write a “disable” magic value during provisioning.
- Secure-domain isolation (TrustZone): The application core implements Arm TrustZone with a System Protection Unit (SPU). Even if APPROTECT is bypassed on the non-secure side, secure-domain flash regions remain gated by SECUREAPPROTECT.
- Dual-flash topology: Application flash is 1 MB; network flash is 256 KB. Firmware images are typically split across both, so a complete recovery requires access to both cores.
- ERASEPROTECT register: When set, the CTRL-AP ERASEALL command is refused, making even the standard “erase-and-unlock” path inoperable without invasive intervention.
Realistic Recovery: What Our Engineers Do
Our lab approaches an nRF53 crack in a structured sequence. Not every device yields a complete readout — success depends on silicon revision, protection configuration, and physical condition of the die.
Step 1 — Non-Invasive Probe
We connect via SWD (Serial Wire Debug) to the CTRL-AP (Control Access Port) and read the protection status of both cores. This tells us which registers are locked and whether ERASEPROTECT is active. On roughly 15–20 % of boards we receive, developers left APPROTECT in the default-disabled provisioning state (common in prototype runs), and a direct SWD readout is possible without any invasive work.
Step 2 — Fault-Injection Analysis
For devices with APPROTECT enabled, we use voltage or electromagnetic fault injection timed to the boot-authentication window. The nRF5340’s Cortex-M33 performs a security-state check within the first few hundred microseconds after reset. A precisely placed glitch — typically 3–8 ns wide — can cause the access-port-enable check to return a false “unlocked” state. This technique is non-destructive to flash contents when calibrated correctly.
Step 3 — Secure-Domain Extraction
If SECUREAPPROTECT is also set, a second glitch campaign targets the SPU validation. This is the most time-consuming phase — calibration can take 2–4 working days on difficult revisions. Once the secure domain is accessible, we dump the entire 1 MB application flash and 256 KB network flash via SWD bulk read.
Step 4 — Verification
We compute CRC-32 and SHA-256 hashes of the extracted binary and compare against any reference the client provides. Where possible, we re-flash the firmware onto a blank nRF5340-DK and perform a functional boot check.
Turnaround, Deliverables, and Constraints
| Parameter | Typical Value |
|---|---|
| Feasibility assessment | 1–2 working days (free) |
| Full recovery turnaround | 5–10 working days |
| Deliverable format | .hex (Intel HEX), .bin, or .elf as requested |
| Flash coverage | Application core (1 MB) + Network core (256 KB) |
| Minimum sample quantity | 1 unit (2 recommended for destructive fallback) |
| ERASEPROTECT active? | Adds 2–3 days; requires decapsulation in some revisions |
We recommend sending two sample devices. If the primary unit’s die is damaged during decapsulation (a risk on any BGA-packaged part), the second unit allows a retry without additional lead time.
Authorization and Legal Requirements
Every nRF53 crack engagement requires proof of ownership or written authorization from the IP holder. We operate under NDA and will not proceed without documented rights. This applies equally to legacy maintenance recovery, prototype re-provisioning, and second-source qualification. For full details on our compliance process, see our IC recovery service and authorization policy.
Firmware recovered through our lab is delivered exclusively to the authorized party. We do not retain copies after project closure.
When nRF53 Crack Fails — Honest Caveats
Not every nRF5340 can be read out. Here are the scenarios where recovery is unlikely or impossible:
- Physically damaged die: Corrosion, cracked bond wires, or ESD damage to the flash array will prevent a clean dump.
- Secure-boot with encrypted flash: If the developer implemented application-layer AES encryption on top of APPROTECT, the extracted binary will be ciphertext. We can recover the raw flash image, but decryption requires the key — which may reside in KMU (Key Management Unit) OTP fuses that are not directly readable.
- Newer silicon revisions with patched glitch windows: Nordic periodically hardens the boot sequence. Certain nRF5340 engineering samples (revision B0 and later) have narrower fault-injection windows, reducing success probability below 60 % in some cases.
We disclose feasibility honestly before any paid work begins. If our initial probe shows a low-probability scenario, we will tell you upfront.
Related Nordic and Multi-Vendor Recovery
The nRF53 sits in a broader ecosystem of protected wireless MCUs. If your project involves mixed BOM components, we handle multi-chip recovery in a single engagement. Related work our lab performs regularly includes Microchip PIC16 firmware extraction, Renesas RA4 series readout, and Nuvoton M0516 flash recovery. Each family has different protection mechanisms, but the workflow — probe, assess, extract, verify — follows the same disciplined sequence.
Check feasibility for your project
Send the chip marking or board details and tell us what you need to recover. Add clear photos if available.
Request a feasibility reviewFrequently Asked Questions
Can the nRF5340 be read out without erasing flash?
Yes, but only through non-standard techniques such as voltage fault injection. The official Nordic CTRL-AP unlock path always triggers a full erase. Our lab uses precisely timed glitch attacks to bypass the erase-on-unlock sequence, preserving flash contents for authorized firmware recovery.
Does ERASEPROTECT make nRF53 crack impossible?
Not impossible, but harder. When ERASEPROTECT is set, the standard ERASEALL command is blocked, which means even the destructive unlock path fails. Recovery then requires physical decapsulation and direct die-level probing, adding 2–3 days to turnaround. Success rates remain above 70 % on revision A silicon.
Is the network core firmware included in the recovery?
Yes. We extract both the 1 MB application-core flash and the 256 KB network-core flash. Since many BLE/Thread/Zigbee stacks split code across both cores, a partial dump would be functionally useless. Both images are delivered as separate .hex or .bin files.
What proof of ownership do I need to provide?
We accept purchase invoices, original design files, a letter from the IP holder authorizing recovery, or a statutory declaration of ownership. All engagements are conducted under mutual NDA. We decline projects that cannot demonstrate legitimate authorization.
How does nRF53 protection compare to STM32 RDP?
STM32 uses a tiered Read-Out Protection model (RDP Level 0/1/2), where Level 2 is permanent and irreversible. The nRF5340’s APPROTECT is conceptually similar to RDP Level 1 — it locks debug access but can be bypassed with fault injection. There is no nRF53 equivalent of RDP Level 2 unless the developer fuses ERASEPROTECT and uses encrypted secure boot together. For STM32-specific details, see our STM8L protection-level analysis.
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote