An audio-processing manufacturer inherited a product line whose code flash was locked on every shipped unit, and asked us to unlock and recover the locked code flash of its reference design, an STM32F413VHT6: 100 MHz Cortex-M4F, 1.5 MB of flash, 320 KB of SRAM, 100-pin LQFP. Audio firmware is a good case study for this generation because the valuable intellectual property is not only code: it is coefficient tables, filter designs and room-correction data, and those live in flash regions the application treats as data.

Protection state and the data-region problem

The option-byte session read RDP level 1 with the four lowest sectors under write protection and no PCROP. Level 1 closes debug, SRAM boot and the system bootloader against the array with bus errors, leaves user code free, and protects the backup SRAM and registers alongside the flash. That is the standard F4 posture, and on this design it produced a specific tension: the coefficient tables were written by a desktop tuning tool through the running firmware, which means the firmware contains a complete, legitimate write path to its own array, and the readback half of that path had been disabled in production. Re-enabling a disabled half is a different order of work than finding an unintended hole, and it is the cleaner route when the customer owns the design. The a 192 KB RL78/G13 replication note describes the mirrored situation on a Renesas part where a calibration write path survived while its readback did not.

Reconstructing the readback path

The tuning protocol’s write command accepted region, offset and payload; the read command existed in the development build and was reduced in production to a stub that returned a fixed acknowledgement. Static analysis of the stub and its development-build sibling showed the difference was a single branch constant. Exercising the write-side logic confirmed the framing layer still worked bidirectionally, so the readback loop was re-derived from the write-side framing rather than patched into the running code. That reconstruction method, deriving the missing half from its surviving complement, is the theme of our an RL78 part locked through its option bytes case and recurs in the boot-mode access on an RX24T boot-mode note.

Coefficient regions need more than copying

Once the array streamed out, the 1.5 MB image raised the question every audio job eventually asks: which sectors are code and which are data. The 128 KB-sector map makes coarse separation easy, but the tuning tool had packed coefficient sets into regions interleaved with the application’s own structures. Our recovering data from a secured part workflow handles this classification as a first-class deliverable, and the resulting map let the manufacturer’s new developer regenerate tuning files without touching code. The firmware restored for a GD32F303VE report on a GigaDevice part shows the same classification exercise with a different protection mechanism behind it.

How the tuning protocol was mapped

Reconstructing the readback half began with the desktop tool. The manufacturer still owned an old laptop with the tuning application installed, and a passive serial capture during a live tuning session gave the framing, the region grammar and the acknowledgement pattern in an afternoon. That capture mattered more than any amount of static analysis: it pinned the byte order, the checksum policy and the retry behaviour, and the re-derived read loop matched it on the first bench test. Where a protocol capture exists, we request it before starting; where it does not, deriving framing from firmware alone roughly doubles the calendar.

Code-versus-data classification in detail

The classification pass used three signals: disassembly reachability from the vector table, the linker map fragment the customer supplied, and the access patterns observed in the recovered write-path logs. Regions touched only by the tuning protocol were marked data; regions with instruction fetch traces stayed code; two regions were ambiguous and were labelled as such rather than guessed. The honest label preserved the customer’s option to re-examine those sectors later, and one of the two turned out, months on, to hold an in-development filter bank that a confident guess would have misfiled.

What we delivered

The package contained the verified 1.5 MB image, a code-versus-data region map, the re-derived readback documentation so future units could be serviced without us, and a bench-verified boot of the recovered build. If your STM32F413VHT6 fleet is locked and the design was tuned in the field, audit the firmware’s own write path before considering anything invasive; the microcontroller reverse engineering service description and the a 128 KB RL78/G13 case both illustrate how much of the job disappears once a legitimate in-chip channel is identified.