Firmware extraction means reading the program code out of a locked chip and handing you back a usable binary or hex file. Feasibility depends almost entirely on the exact part number and how the protection was set — an 8-bit 8051 or an AVR with lock bits is a different job from an ARM part with its highest protection level engaged. Send us the chip marking and we’ll tell you within a day whether it’s doable, roughly what it costs, and how long it takes.
Which chips we can actually read, and which ones fight back
The honest answer is that the part number decides everything. There’s no universal method. A mature 8-bit microcontroller from the early 2000s, a modern ARM Cortex-M with a hardware-enforced debug lockout, and a CPLD holding a bitstream in on-chip fuses are three unrelated engineering problems that happen to share a name in the search box.
Here’s how we group things internally when a request comes in:
| Chip family | Typical difficulty | What usually determines the answer |
|---|---|---|
| Serial EEPROM (24Cxx, 93Cxx) | Usually straightforward | Whether the write-protect or a host-side scheme obscures the contents; contents may still need interpretation |
| SPI NOR flash (25xx / 25Qxx) | Usually straightforward to read | Reading is easy; the real work is whether the image is encrypted or bound to a unique chip ID |
| 8051-derived MCUs (AT89C, STC, W78E, N76E) | Often feasible | Which lock level was programmed, and whether the part has an OTP or mask-ROM boot area |
| AVR (ATmega, ATtiny) | Often feasible | Lock bit combination, fuse settings, and whether the die generation is one we’ve characterized |
| PIC (PIC12F/16F/18F, dsPIC) | Varies widely by sub-family | Code protect configuration and the specific silicon revision — two PIC18F parts can behave very differently |
| STM8 / STM32 and pin-compatible clones | Depends heavily on RDP level | Read-out protection level; the top protection level permanently disables debug access and is often not feasible |
| MSP430 | Depends on the fuse | Whether the JTAG security fuse was blown, and whether a BSL password is in play |
| CPLD / FPGA (MAX II, XC95xx) | Specialized, case by case | Bitstream storage, security bit state, and whether an equivalent JEDEC file is what you actually need |
| TMS320 DSP, Renesas, NXP LPC/Kinetis | Case by case | Password-based or level-based protection schemes; newer parts are generally harder |
For memory devices specifically, we publish part-level pages with the details — 24C64 code readout and 25Q128 flash extraction are good examples of what the answer looks like once you get down to a specific device.
Where we tell people no
Modern secure elements, smart card ICs, and parts with active die shielding plus encrypted flash are generally outside what we’ll take on. So are ARM devices where the highest read-out protection level has been set and the debug interface is permanently fused off — in a lot of those cases the correct engineering answer is that the code is gone and you should plan a rewrite instead. We’d rather say that in the first email than take your money and stall for three weeks.
What happens to your chip, step by step
Most jobs run non-invasively first, because it’s faster, cheaper, and leaves the part working. Only when that route is exhausted do we consider anything physical.
- Identification. We read the full top marking under a microscope — base part number, package code, silicon revision, date code. The revision matters. A part from 2007 and the same part number from 2019 can have different protection hardware.
- Protection state check. We attach to the programming or debug interface and read the configuration and lock registers. This tells us what level of protection is actually set, which is frequently not what the customer assumed.
- Non-invasive attempts. Interface-level and glitch-class techniques appropriate to that family, run in a controlled sequence, with the part powered and monitored. We don’t publish the specifics, and we don’t publish recipes for defeating a given security mechanism.
- Escalation, if you approve it. For some older parts, optical or physical access to the die is the only viable path. That means the chip is consumed. We quote it separately and never do it without written sign-off, because you lose the sample.
- Verification. This is the part competitors skip. We check the dump for structural sanity — reset vector pointing somewhere legal, interrupt table intact, code and constant regions where the memory map says they should be, no long runs of 0xFF where executable code belongs.
- Functional confirmation. Where you’ve supplied a spare blank part of the same type, or a spare board, we program the dump into a fresh chip and confirm the board boots and behaves. That’s the only test that really settles it.
If the goal is a full working replacement board rather than just a binary, the firmware work usually runs alongside board-level reverse engineering. Getting both from one lab avoids the classic failure mode where the dump is fine and the cloned hardware isn’t.
What we need from you before we can quote
A quote request that takes you four minutes to assemble saves a day of back-and-forth:
- The exact chip marking — a sharp macro photo of the top of the package, all lines legible including the revision and date code. Angle the light; don’t use flash straight on.
- Package and quantity — DIP, SOIC, QFP, QFN, BGA, and how many chips or boards you have. Spares change what we can attempt.
- Whether the part is on a board or loose. If it’s soldered down, tell us the package and whether we’re allowed to desolder it.
- What you need back — a raw binary, a hex file, a programmed set of chips, or a documented memory map. Say it in one line.
- Any history you have. Did a programmer ever report the part as locked? Was the protection set deliberately by your own team? Is there an external EEPROM or serial flash alongside the MCU? Those details often shorten the job.
- Photos of both board sides on a dark background, whole board in frame, plus board dimensions — needed only if hardware work is part of the scope.
What comes back from us: a feasibility statement (feasible / likely / uncertain / not feasible), the method class we’d use, whether the sample survives, a price, and a lead time. If we’re uncertain, we say uncertain and explain what would resolve it.
What drives the price
We don’t publish a rate card because a single number would be wrong for most jobs. These are the factors that actually move it:
- Chip family and protection level. The single biggest driver. A commodity EEPROM readout and an ARM part with aggressive protection aren’t in the same price bracket.
- Whether the method is non-invasive or physical. Physical work involves sample preparation, microscope time, and consumed parts.
- Package. Fine-pitch QFN and BGA add handling and rework cost compared with a DIP or SOIC part.
- Number of devices. Setup dominates on a single chip, so per-unit cost drops sharply on batches.
- Deliverable depth. A raw dump costs less than a dump plus verified programmed replacements plus a documented memory layout.
- Extras. External memory devices on the same board, a bootloader that needs separating from the application, or calibration data that must be preserved per unit.
One thing worth weighing before you spend anything: if the product is being redesigned anyway, or the MCU is obsolete and you’d need to migrate to a current part, recovering old binary code may buy you less than you think. Binary firmware for a discontinued MCU doesn’t port. In that situation a fresh implementation against recovered schematics is sometimes the cheaper path, and we’ll tell you when we think that’s true.
How long each family takes
Serial EEPROMs and standalone SPI flash are typically the fastest — the read itself is quick, and most of the calendar time is shipping. Well-characterized 8-bit MCUs are usually measured in a small number of business days. Parts where we need to work through several method classes take meaningfully longer, and anything requiring die-level access runs longer again because sample preparation can’t be rushed.
CPLD and DSP work sits at the long end. Feasibility assessment on the chip marking alone, though, is normally same-day or next-day, and that’s the number most people actually need first so they can decide whether to ship.
Two things stretch a schedule: chips arriving without spares, and markings that turn out to be relabeled or sanded. We flag both immediately rather than letting the clock run.
Legitimate use, and who’s responsible for what
The work we take on is maintenance-driven. Recovering firmware you own after the source or the hex file was lost with a departed engineer or a dead build server. Keeping out-of-production industrial equipment alive when the OEM is gone. Migrating a design off an obsolete MCU. Failure analysis on a returned unit. Authorized security assessment of your own product. You confirm you hold the rights to the design or have the owner’s authorization, and you remain responsible for compliance with applicable IP law; every project runs under NDA, and we delete customer images and dumps on request after handover.
For jobs framed around a locked microcontroller rather than a memory device, the same engineering group handles MCU unlock requests, and the escalation path for older parts is described under die-level decapsulation if you want to understand what
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