A medical pump manufacturer asked us to clone the secured firmware binary of its own legacy controller, built around an STM32F407ZET6: 168 MHz, 512 KB of flash, 192 KB of SRAM, and a full 144-pin LQFP that brings out nearly everything the die has. The 20 by 20 mm package is a gift after years of 48-pin work: the SWD pair sits on dedicated pads, the boot pin is reachable, and the risk of damaging a board that must go back into service is low. This note records how the job actually proceeded.

The 144-pin advantage and its limits

Pin count does not open the flash; it only opens the bench. The F407’s protection model matches the rest of the F4 line: option bytes at 0x1FFFF800, RDP level 0 at 0xAA, level 1 closing debug, SRAM boot and bootloader access behind bus errors, level 2 irreversible. What the package does change is the ability to test hypotheses quickly, because spare GPIOs let us instrument the running system while the probe stays attached. The first probe session placed the part at level 1 with no PCROP windows, which is the friendliest realistic state and one that appears often on parts whose firmware was flashed by a production tool rather than hardened deliberately.

Mapping what level 1 still allows

With RDP at level 1, the main array refuses the probe but not the CPU. Firmware running from flash can read its own memory, and on a pump controller that firmware is rich: a display driver, a motor loop, a USB device stack, and usually a maintenance interface for service technicians. Each of those is a potential read-out channel if it can be coaxed into echoing memory regions. Our method on jobs like this mirrors what we documented for the a 128 KB RL78/G13 exercise and the firmware restored for a GD32F303VE case: enumerate the command surface, probe the boundaries of each handler, and look for an off-by-one or an unindexed region that turns a diagnostic into a dump. It is painstaking work measured in sessions, not minutes, and it is the reason microcontroller reverse engineering exists as a discipline of its own.

The backup domain and the 4 KB that matters

The F407’s 192 KB of SRAM splits into a 112 KB main block, a 16 KB block and a 64 KB core-coupled region, and none of that is the interesting part of a clone job. The backup SRAM, 4 KB in the battery-backed domain, is protected together with the flash under RDP, and on this board it held calibration constants written during factory commissioning. Those constants are exactly what a bare flash copy misses and what a clone needs to behave like the original, which is why our deliverable checklist always asks whether the customer’s process wrote to the backup domain. The same distinction recurs in the partial program-data recovery on an RX62T note, where parameter data survived separately from code.

Assembling the clone

The flash came back as a contiguous 512 KB image once the read-out channel was working; the backup domain required a short second phase through the same channel. Reconstruction followed our usual sequence: sector-map verification, vector-table sanity, peripheral initialisation compared against the schematic, and a bench run on a known-good board. For a medical customer the acceptance test was functional, not bitwise: the clone had to pass the pump’s own self-test across the flow range. It did, on the second fixture, after one constant in the backup image was corrected for a battery-age drift the original unit had accumulated.

One practical note belongs in any 144-pin plan: the pump board grounded its boot pin through a pull-down that only sampled at reset, so a controlled reset while holding the boot pin high required a fixture modification. Twenty minutes of soldering saved two days of guessing why the probe occasionally found the array in a different state, and it is exactly the kind of detail a written plan should surface before the first power-up.

Where this leaves similar projects

A clone is a chain of small verifications, and each link leaves evidence. Customers considering the same work on other silicon will find the pattern holds in the microcontroller extraction workflow description, the the RX62G high-resolution PWM family family notes, and the reading a chip in the lab service page, which covers the cases where the package or the protection level forces a physical route instead. If your STM32F407ZET6 board still boots, the correct first step costs nothing: read the option bytes, and the shape of the whole job follows from one register value.