The hex file looks like noise because it is noise. A team desolders the serial flash from an STM32H7B0ZBT6 board, reads it in a programmer, and gets a plausible-looking binary with no valid vector table and no recognisable opcodes. The part is a 280 MHz Cortex-M7 value-line device whose 128 KB internal flash is a boot area, and whose external Octo-SPI application is encrypted. To recover secured STM32H7B0ZBT6 source code, accept that the external chip alone will never produce a runnable image.
Step one: identify what is on the board
The ZBT6 is the LQFP144 version, 20 x 20 mm, with the SWD pads exposed along the package edge. That makes the board-level attach far easier than on the 169-ball sibling. Record the fitted serial flash, its density, and whether one or both Octo-SPI ports are used. Photograph the boot straps. The internal 128 KB is organised in 8 KB sectors, so a bootloader, a key table and an OTA slot can each occupy their own protected block.
Step two: read the small internal array
The internal dump is only 128 KB but it carries the Octo-SPI configuration, the OTFDEC region boundaries, the secure boot material and the version marker that ties this unit to one external image. There is also 1 KB of OTP and a 96-bit unique ID; both survive a mass erase and both are commonly used for binding a firmware image to a specific device. Include them in the deliverable rather than assuming they can be regenerated.
RDP on this family is 0xAA for level 0, 0xCC for level 2, and any other value for level 1. Writes go through FLASH_OPTSR_PRG and need an option-byte reload plus reset. Level 2 disables SWD, JTAG and the system bootloader permanently. A SECURITY option bit can additionally define a hidden delivery protection area, and AN5601 notes that CubeProgrammer requires RDP at 0xAA with SECURITY unchecked before a full erase is allowed.
Step three: treat the external dump as ciphertext
AN5281 specifies AES-128 in counter mode for OTFDEC on this family, with two engines mapped to the two Octo-SPI interfaces. The key is held inside the MCU and is not sent to the serial device. An external programmer therefore reads exactly the encrypted bytes, and no amount of file-format conversion will turn them into code. Secure boot and SBSFU add signature verification in the MCU, so even a successful field update never exposes a plaintext binary on the programming lines.
Step four: build two evidence packages
One package holds the internal flash, OTP, option bytes and the OTFDEC region configuration. The other holds the raw external contents, the serial flash part number and the board revision, explicitly labelled as encrypted. A customer rebuilding a product needs both, plus a statement of which firmware revision this unit carried. The bypass methodology page describes how those layers are separated in practice; the STM32F407IG source code dump is a contrast where the whole application was on-chip and a single read sufficed.
Step four-b: OTA slots and the 8 KB map
Eight-kilobyte sectors are what make a two-slot over-the-air layout practical on a 128 KB array. One slot can hold the active bootloader and application stub, another the incoming image, with a small marker sector deciding which one starts. Read every sector, including the ones the running firmware appears to ignore, and record the write-protection bitmap with the image. A dump that omits the inactive slot loses the previous firmware revision, which is often the version a customer actually needs for a repair or a failure analysis.
Step four-c: a plaintext dump can still be wrong
Even where an image is readable in the clear, the memory-mapped Octo-SPI window, the encrypted region boundaries and the order in which external banks are presented are all defined by registers inside the MCU. Reassembling a runnable binary from a serial-flash dump without that configuration produces an image with the right bytes in the wrong places. Our notes on protection bypass cover this class of reassembly error more generally.
Step five: verify before delivery
Read the internal array twice, compare, and confirm the reset vector points into the recovered range. Check the 8 KB write-protection bitmap and note any sector that refused a read. Flash ECC makes marginal cells fail loudly, so a moving failure points at the supply rather than the array. The encrypted STM32F302RD cloning example covers a similar evidence chain on an M4 part.
For the UFBGA169 version of this line, see STM32H730ABI6Q flash access and the wider chip-level service when the debug port is already closed.