IC reverse engineering, as most people mean it when they search for it, is the process of getting the program and data memory out of a locked microcontroller or memory device and handing it back as a .hex or .bin file you can flash into a fresh part. Sometimes it also means going deeper — die imaging, gate-level analysis, identifying an unmarked part. This page covers both, but leads with the first, because that is what nine out of ten inquiries are about.
If you have a board on your bench with a dead MCU and no source code, keep reading. That’s the case this page was written for.
What you actually get back, and in what format
The deliverable is a binary image of the chip’s non-volatile memory. Depending on the part, that memory is split into several distinct regions, and we hand them over separately rather than mashing them into one file:
- Program flash / code memory — the main image, delivered as Intel HEX (.hex) or raw binary (.bin), with the base address stated so you know where it belongs in the memory map.
- Data EEPROM — on AVR and PIC parts this is a separate array, and it often holds calibration constants, run hours, motor learn values, or a serial number. Lose it and the board boots but behaves wrongly.
- Option bytes / configuration words / fuse settings — clock source, watchdog, brown-out level, boot pin behavior, oscillator startup time. A perfect code image programmed with the wrong config bytes gives you a chip that does nothing at all.
- External memory contents, when the design keeps parameters, a display font, or a lookup table in a serial EEPROM or SPI flash sitting next to the MCU.
- A readback report — chip marking as found, package, which regions were recovered, checksums, and a note on how the result was verified.
Verification is the part that separates a data dump from a usable job. We program a blank part of the same type, put it into your original board or an equivalent unit, and confirm it powers up and behaves the way the good unit does. A checksum match between two independent reads is a good sign. A board that runs is proof.
What we do not deliver
We don’t hand back C source code. Nobody can — the compiler threw that information away. What you get is the binary the compiler produced, which is enough to reproduce the product, keep a legacy line alive, or replace a failed chip. If you need to understand the logic, that’s a separate disassembly and analysis effort, priced by the hour, and it’s slow work on anything larger than a few tens of kilobytes.
How IC reverse engineering proceeds on the bench
Identification and mapping
The first step is knowing exactly what part you have. Top marking, package, date code, and a look at how the chip is wired — which pins run to a programming header, whether a boot or test pin is strapped a particular way, whether the OEM left a debug connector populated. Sanded, relabeled, and blacktopped parts show up more often than you’d expect; when the marking lies, package pinout plus power and ground topology usually settles the question. On a fine-pitch QFN with no readable marking, this stage can take longer than the extraction itself.
Reading the security state
Next we determine how the part is locked, not just whether it is. That means something different in every family: read-out protection level on STM32 — where RDP Level 1 and Level 2 are completely different situations — lock bits on AVR and the many 8051 derivatives, code-protect configuration bits on PIC, the JTAG fuse and bootstrap loader password on MSP430, and boot-ROM readback restrictions on various ARM parts. The answer at this stage decides both feasibility and price, which is why we won’t quote a firm number from a part number alone.
Extraction
Where a non-invasive route exists, it gets tried first, because it leaves the chip intact and you keep a working sample. When no electrical route exists, the work moves to direct memory readout at the die level, which means decapsulation, probing, and in some cases optical readback of the array. That path consumes the sample, needs a longer bench slot, and costs more. We tell you which route we expect to use before you commit, and we tell you if the route we expect will destroy the part.
Reconstruction and verification
Raw data is rarely the finished job. Bit order, page and sector layout, ECC bytes, wear-leveling artifacts, and vendor-specific scrambling all have to be undone before an image will run. We reassemble, program a donor chip, run it, and iterate when it misbehaves. Only after a chip built from the file behaves like the original does the file get released.
Which chips are easy, which are hard, and which we may decline
Honest answer first: feasibility depends on the specific silicon revision, not the family name. Two parts with nearly identical markings can behave differently because the mask changed mid-life. With that caveat, here’s how the landscape generally looks.
| Device group | Typical difficulty | What drives it |
|---|---|---|
| Classic 8051 (AT89C, STC, W78E) and older AVR | Usually straightforward | Simple lock-bit schemes, well-mapped test modes, enormous installed base |
| PIC10 / 12 / 16 / 18 | Straightforward to moderate | Code-protect behavior varies a lot across sub-families and revisions |
| STM8, older STM32 F0 / F1 | Moderate | Depends heavily on the protection level actually set in production |
| MSP430 | Moderate to hard | JTAG fuse state, BSL password length, flash versus FRAM generation |
| Serial EEPROM and SPI/NOR flash | Usually easy | Often unprotected; the work is desoldering and correct dump alignment |
| CPLD and small FPGA | Case by case | Whether the bitstream is readable and whether it can be retargeted |
| Recent Cortex-M with hardware isolation | Hard, sometimes not feasible | Secure boot, per-device flash encryption, no readback path at any level |
| Secure elements, smart cards, automotive security modules | Generally declined | Purpose-built countermeasures; effort rarely justifies the outcome |
Beyond the silicon itself, a few practical things make a job harder: a single sample with no spare, a board that has been potted in epoxy, a chip that has already been damaged by an over-voltage event or a failed rework attempt, and previous attempts by another vendor that left the die exposed or the package cracked. Tell us up front if a part has been through any of that. It changes the plan, and finding out halfway through costs both of us time. If your part isn’t obvious from the table, the list of device families we currently support is a better starting point than guessing.
What to send us, and what you get back before you pay anything
The quote stage is short and specific. Send this:
- Clear photos of both sides of the board on a dark background, whole board in frame, plus one close-up of the target chip where the marking is legible. Diffuse light, no flash glare across the package.
- The full chip marking, typed out line by line, including the date code and any suffix letters. The suffix is often the part that decides difficulty.
- Board dimensions and, if you have it, layer count — useful if the job might extend into board work.
- How many samples you can supply, and whether any of them can be consumed.
- One line on what you need: code only, code plus EEPROM and config, blank chips programmed and returned, or a full firmware-plus-board package.
Back from us: a feasibility assessment naming the likely route, a realistic lead time, and a price. Simple locked 8-bit parts are typically a matter of days once the sample lands. Parts that need die-level
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