Firmware extraction is the recovery of the program and data stored inside a microcontroller, flash device or SoC. The straightforward cases — an unprotected serial flash, an MCU with read-out protection disabled — are routine. The interesting cases are the protected ones, and those are decided by which attack path is appropriate rather than by brute force.

We approach every extraction by first identifying the protection mechanism actually present, then choosing the least destructive method that will defeat it. That ordering matters: an invasive attack that is unnecessary is a device destroyed for no reason.

Protection mechanisms we encounter

Method selection

Non-invasive

Exploits the debug interface, bootloader, firmware update path or a documented silicon erratum. Nothing is physically altered, so the original device survives and can be returned to you intact. This is always tried first.

Semi-invasive

The package is opened and the die is accessed with UV, laser or optical fault injection while the device is running. Typical uses are clearing a security fuse or forcing a branch inside the protection routine.

Invasive

Micro-probing or focused ion beam work on the die to read the array directly or to reach internal signal lines. Reserved for parts where the protection is implemented in hardware with no exploitable interface.

What you receive

• The extracted binary, delivered as a raw dump with a checksum and, where the physical address space map is known, as a structured image split by region
• A disassembly-ready load address and memory map note
• A record of the method used, the protection mechanism found, and the confidence level of the extraction
• Verification: where a working sample is available, the extracted image is compared against observed behaviour

Turnaround

Frequently asked questions

Will the device survive the extraction?
For non-invasive methods, yes — the device is returned unmodified and still functional. Semi-invasive extraction usually leaves the device usable but with the package opened. Invasive methods generally make the part non-functional. We tell you which category applies to your device before starting.

My MCU is read-out protected. Is extraction guaranteed?
No, and any vendor who guarantees it is not being straight with you. Protection implementations differ between silicon revisions of the same part number, and a method that works on one revision may be fixed on the next. We assess the specific die revision first and report the realistic probability, including the case where we recommend against proceeding.

Do you need the whole product or just the chip?
Either. In-circuit extraction is often preferred because the board supplies the clock, power and boot environment the protection routine expects. If the board is not available, a bare part can be placed in a test fixture, but this occasionally changes the behaviour of the protection logic.

What about encrypted external flash?
That is a two-part problem: recover the key from the SoC, then decrypt the off-chip image. We handle both, but the two stages are scoped and quoted separately because the key recovery is usually the harder half.

Can you extract from a device that is already damaged?
Often yes, provided the die itself is intact. Package damage, broken leads or a dead board are not obstacles. If the die is physically cracked or the memory array has been electrically destroyed, extraction may become impossible and we will say so after inspection.

Send a device for assessment

Tell us the part number, the package, whether you can supply the whole board or only the chip, and what you need the binary for. We will confirm the protection mechanism, the realistic method, the probability of success and the turnaround before any destructive step. We accept work only where the requester can demonstrate ownership or written authorisation.