STM32WB Unlock: Recovering Firmware from ST’s Dual-Core BLE Microcontroller
STM32WB unlock refers to the authorized extraction of firmware from STMicroelectronics’ STM32WB series — a dual-core Cortex-M4 + Cortex-M0+ family designed for Bluetooth Low Energy 5.x, Zigbee, Thread, and proprietary 2.4 GHz applications. Because the M0+ core runs a proprietary ST wireless stack with its own protected memory region, STM32WB devices present a unique challenge that goes beyond standard STM32 readout protection. Our engineers have handled multiple STM32WB variants, and this page covers what is realistically achievable, what it costs, and how long it takes.
Why Is the STM32WB Family Harder to Unlock?
Most STM32 families use a single Cortex-M core with a straightforward RDP (Readout Protection) scheme. The STM32WB series adds complexity in three areas:
- Dual-core memory partitioning. The Cortex-M4 application processor and Cortex-M0+ network processor each have their own flash regions. The wireless stack binary on the M0+ side is managed through ST’s Firmware Upgrade Services (FUS) and is stored in a secure, non-user-accessible area.
- Shared SRAM with hardware isolation. SRAM2a and SRAM2b use IPCC (Inter-Processor Communication Controller) mailboxes and hardware semaphores, meaning raw memory dumps require careful interpretation of two independent execution contexts.
- Customer Key Storage (CKS). STM32WB55 and WB35 variants support AES-256 key storage in a one-time-programmable area accessible only by the M0+ core, adding an encryption layer that some designs leverage for firmware integrity checks.
These features mean that a successful STM32WB unlock must address both cores’ flash contents, not just the user application on the M4 side.
RDP Levels on STM32WB: What Each Means for Recovery
| RDP Level | Protection State | Unlock Feasibility | Data Preserved? |
|---|---|---|---|
| Level 0 (0xAA) | No protection — JTAG/SWD open | Trivial — standard readout | Yes, fully intact |
| Level 1 (any value ≠ 0xAA, 0xCC) | Debug access blocked; flash read via debug disabled | High — multiple proven attack vectors | Yes, if technique is non-destructive |
| Level 2 (0xCC) | Permanent — JTAG/SWD permanently disabled, option bytes locked | Low to moderate — requires invasive techniques; success depends on silicon revision | Conditional — depends on method |
The critical distinction: RDP Level 1 regression to Level 0 via option byte rewrite triggers a full mass erase of user flash on the M4 side. That is by design. Our approach to STM32WB unlock at RDP Level 1 therefore bypasses the standard regression path entirely, preserving the firmware contents. At RDP Level 2, we evaluate each case individually — the feasibility depends on the specific die revision (cut 1 vs. cut 2.1 on STM32WB55), package type, and whether the customer key storage is in use.
Which STM32WB Variants Can Be Unlocked?
The STM32WB family currently includes several sub-lines. Here is our current feasibility assessment based on lab results:
| Part Number | Core Config | Flash (KB) | RDP1 Recovery | RDP2 Recovery |
|---|---|---|---|---|
| STM32WB55xx | M4 @ 64 MHz + M0+ | 256–1024 | Proven | Case-by-case |
| STM32WB35xx | M4 @ 64 MHz + M0+ | 256–512 | Proven | Case-by-case |
| STM32WB15xx | M4 @ 64 MHz + M0+ | 128–320 | Proven | Under evaluation |
| STM32WB10xx | M4 @ 64 MHz + M0+ | 128–320 | Proven | Under evaluation |
| STM32WB5Mxx (module) | M4 @ 64 MHz + M0+ | 1024 | Proven | Limited |
| STM32WB1Mxx (module) | M4 @ 64 MHz + M0+ | 320 | Likely | Not yet attempted |
“Proven” means we have completed at least one successful extraction on that variant at that RDP level. “Case-by-case” means success depends on specific silicon characteristics we evaluate during a free feasibility check. We never guarantee RDP2 recovery upfront — any vendor who does is overpromising.
What Does the STM32WB Unlock Process Look Like?
Step 1: Feasibility Assessment (Free, 1–3 Days)
You ship us the target device or a high-resolution board photo plus the exact part number (including package suffix and date code). We identify the RDP level non-destructively using SWD probe interrogation — this tells us the protection state without triggering any erase. We then provide a written feasibility report with success probability, cost, and timeline.
Step 2: Authorization & NDA
We require proof of ownership or written authorization from the IP holder before proceeding. This is non-negotiable. STM32WB unlock is offered exclusively for legitimate purposes: recovering your own firmware from a failed development board, supporting legacy production where source code was lost, or authorized maintenance of equipment you own. We cover our authorization and IP compliance process in detail on our trust page.
Step 3: Firmware Extraction
For RDP Level 1 devices, our engineers use non-invasive fault-injection techniques that exploit voltage or clock glitching windows during the boot sequence. The STM32WB’s dual-core architecture actually creates additional timing surfaces because the M0+ and M4 boot sequences are staggered. Typical extraction time for the M4 user flash is 2–5 working days after authorization.
For RDP Level 2 attempts, the process may involve semi-invasive or fully invasive techniques (decapsulation, microprobing, UV/laser fault injection). These require 7–15 working days and carry a success rate that we disclose honestly in the feasibility report. We charge only a reduced evaluation fee if the attempt fails.
Step 4: Verification & Delivery
Extracted firmware is delivered as a raw binary (.bin) or Intel HEX file. We verify the dump by comparing CRC checksums against the flash option byte configuration and, where possible, re-flashing to a blank STM32WB device to confirm functional operation. The wireless stack binary on the M0+ side is generally not extractable (it is ST proprietary and available from ST directly), but the user application flash, SRAM snapshots, and option byte configurations are all included.
Cost and Lead Time for STM32WB Unlock
| Scenario | Typical Cost (USD) | Lead Time (Working Days) |
|---|---|---|
| RDP Level 0 readout | $100–$200 | 1–2 |
| RDP Level 1 non-invasive extraction | $400–$900 | 5–8 |
| RDP Level 2 invasive attempt | $1,200–$3,000 | 10–15 |
| Batch (5+ identical devices, same RDP level) | 30–50% discount per unit after first | +1–2 days per additional unit |
Pricing varies by flash size (a 1 MB STM32WB55RG takes longer to dump than a 128 KB STM32WB15CC), package accessibility (WLCSP packages require more careful handling than QFP), and whether the board must be preserved intact. We provide a firm quote after the free feasibility assessment — no surprise charges.
Common Failure Modes and Honest Limitations
Transparency matters more than marketing. Here is what can go wrong:
- Secure user memory (SFSA) misconfiguration. If the original developer set the Secure Flash Start Address to protect a large region, that area may be inaccessible even after bypassing RDP1 on some silicon revisions.
- Blown fuses on RDP2 devices. On certain STM32WB55 cut 2.1 dice, the JTAG fuse is physically severed. Microprobing past this requires FIB (Focused Ion Beam) work, which adds $500–$1,500 and 5+ days.
- Encrypted application firmware. Some developers store AES-encrypted firmware on the M4 flash and decrypt at runtime using keys in CKS. We can extract the encrypted binary, but without the decryption key, the raw dump is not directly usable. We will tell you this upfront.
- Package damage during decapsulation. WLCSP and UFQFPN packages are fragile. We use chemical decapsulation with controlled acid exposure, but there is a small (under 5%) risk of bond wire damage on these packages.
How Does STM32WB Compare to Other STM32 Families for Unlock?
Engineers sometimes ask whether the WB series is significantly harder than other STM32 lines. The answer depends on the protection level, not just the family. The STM32L5 with TrustZone is arguably more challenging at RDP2 because of its ARMv8-M security extensions. The STM32C0 entry-level parts are generally straightforward at RDP1. The STM32WB sits in the middle — the dual-core architecture adds complexity, but the RDP implementation shares the same fundamental mechanisms as other STM32s built on the same 90 nm process node.
If your project involves a different MCU family entirely — for example, Microchip parts like the PIC32MZ or Atmel-based devices like the ATSAM3 — we handle those as well with family-specific techniques.
Who Needs STM32WB Unlock?
Based on the cases we have handled, the most common scenarios are:
- IoT product companies that lost source code after a contractor relationship ended and need to recover BLE application firmware for continued production.
- Medical device manufacturers maintaining legacy Bluetooth-connected instruments where the original firmware engineer is no longer available.
- Industrial equipment OEMs recovering STM32WB-based wireless sensor node firmware for end-of-life support.
- Hardware startups that programmed prototypes before version control was established and need the binary back.
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 reviewCan the M0+ wireless stack be extracted during an STM32WB unlock?
No. The Cortex-M0+ network processor runs ST’s proprietary BLE/Zigbee/Thread stack, which is stored in a hardware-protected region managed by the Firmware Upgrade Services (FUS). This binary is not user-extractable and is not included in our deliverables. However, ST provides these stack binaries for free download, so you can re-flash the correct version independently.
Will the STM32WB chip survive the unlock process?
For RDP Level 0 and Level 1 extractions using non-invasive methods, yes — the chip remains fully functional. For RDP Level 2 invasive attempts, the chip may be consumed (especially if decapsulation or FIB is required). We always clarify this in the feasibility report and recommend shipping a spare device when possible.
Is STM32WB unlock legal?
Firmware extraction is legal when performed on devices you own or with explicit authorization from the IP holder. We require signed proof of ownership or authorization before starting any work. Our trust and compliance page details the documentation we accept. We do not assist with unauthorized copying of third-party intellectual property.
How do I know which RDP level my STM32WB is set to?
Connect an ST-Link programmer and attempt to communicate via SWD. If the connection succeeds and you can read flash, the device is at RDP Level 0. If the connection succeeds but flash reads return all zeros or errors, it is likely RDP Level 1. If the SWD interface does not respond at all, the device is probably at RDP Level 2. We perform this check as part of our free feasibility assessment.
What file formats are delivered after STM32WB firmware extraction?
We deliver the user application flash as a .bin (raw binary) and/or .hex (Intel HEX) file, along with a dump of the option bytes and OTP area. If SRAM contents were captured, those are provided as a separate binary. All files include a SHA-256 checksum for verification.
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