Bao'An Shenzhen China

IC Reverse Engineering | Delivered as .hex or .bin

Oct 4, 2026  /  PCB COPY

ic reverse engineering: Engineer micro-probing a decapsulated IC die for firmware extraction

What Is IC Reverse Engineering?

IC reverse engineering is the process of extracting the embedded firmware or stored data from an integrated circuit—typically a microcontroller (MCU), EEPROM, or OTP memory—and delivering it as a usable binary file. The output is a verified .hex or .bin image that can be reprogrammed into a replacement part, analyzed for debugging, or archived for legacy-system maintenance. Our engineers perform this work under NDA, and we require proof of ownership or written authorization before any extraction begins.

Why Engineers Need IC Reverse Engineering

ic reverse engineering: Engineer micro-probing a decapsulated IC die for firmware extraction

Firmware locked inside a discontinued MCU is one of the most common single points of failure in legacy equipment. When the original source code is lost, the chip vendor has exited the market, or the original design house no longer exists, IC reverse engineering may be the only viable recovery path. Typical scenarios include:

  • End-of-life component replacement — the original MCU is obsolete, and a programmed spare is needed to keep a production line running.
  • Disaster recovery — a lightning strike or power surge destroys the only programmed chip, and no backup binary exists.
  • Design migration — porting firmware to a pin-compatible successor requires reading the original code first.
  • Quality audit / failure analysis — verifying that production units contain the correct firmware revision.

How the IC Reverse Engineering Process Works

Step 1 — Feasibility Assessment

You ship us the target IC (or the entire PCB). Our lab identifies the exact die revision, reads any accessible device ID registers, and evaluates the protection configuration—read-protect bits, code-guard segments, or fuse settings. Within 1–3 working days we report whether extraction is feasible, estimated cost, and expected turnaround. This assessment is free for most standard MCU families.

Step 2 — Protection Analysis

Most modern microcontrollers ship with configurable code-protection mechanisms. Protection strength varies enormously: an older PIC16F series may use a single fuse bit that can be bypassed with well-documented glitch techniques, while a newer STM32L4 with RDP Level 2 is considered permanently locked with current methods. Our engineers classify each target into one of four practical tiers:

Protection Tier Typical Examples Recovery Likelihood Turnaround
Tier 1 — No / weak protection Many EEPROMs, some OTP parts, older 8051 clones > 95 % 1–3 days
Tier 2 — Single fuse / CRP1 PIC16F/18F, ATmega (lock bits), LPC1xxx CRP1 80–95 % 3–7 days
Tier 3 — Multi-level / encrypted STM32 RDP1, Renesas RH850, some Infineon XMC 40–75 % 7–20 days
Tier 4 — Hardened / anti-tamper STM32 RDP2, CC2640 with JTAG disabled, secure-boot SoCs < 30 % Case-by-case

We are transparent about Tier 4 parts: if current techniques cannot recover the firmware without destroying the die, we tell you before any charges apply.

Step 3 — Extraction

Depending on the protection tier, extraction may involve non-invasive debug-port access, voltage or clock glitching, UV exposure (for older EPROM-style fuses), or semi-invasive micro-probing after decapsulation. Each method carries trade-offs in cost, time, and risk to the physical chip. Our standard practice is to attempt non-invasive methods first, escalating only with your approval.

Step 4 — Verification & Delivery

The raw binary is checksummed (CRC-32 at minimum) and, where a second sample chip is available, compared byte-for-byte against a parallel read to confirm integrity. We deliver the final file as a .hex (Intel HEX) or .bin, along with a brief report noting the flash size, read-protect state, and any configuration or option bytes recovered. Files are transferred via encrypted link or secure FTP.

Which Chip Families Can Be Reverse Engineered?

Our lab maintains tooling and documented success across a wide range of MCU and memory families. Below is a partial list—if your part isn’t listed, submit it for a free IC feasibility check and we’ll evaluate it.

Vendor Common Families Notes
Microchip / Atmel PIC10/12/16/18/24/dsPIC, ATmega, ATtiny, AT89 High success on most lock-bit configs. Atmel IC unlock details
STMicroelectronics STM8S, STM8L, STM32F0/F1/F2/F4 RDP Level 1 recoverable on many F-series; RDP2 is case-by-case. STM8 unlock specifics
NXP / Freescale LPC1xxx/2xxx, MC9S08, MC9S12, Kinetis CRP1 routinely bypassed; CRP3 is Tier 4. Freescale family coverage
Texas Instruments MSP430, CC2540/2640, TMS320 JTAG fuse on MSP430 is recoverable in most revisions.
Infineon / Cypress XMC1000/4000, PSoC 4/5/6 Varies by flash-protection level.
Others Nuvoton N76E/M0/M4, Holtek HT66/HT68, GigaDevice GD32, Espressif ESP8266/ESP32 Expanding coverage; submit for evaluation.

For standalone memory ICs—serial EEPROMs (24Cxx, 93Cxx), parallel flash, and OTP devices—success rates are generally above 95 % because these parts rarely implement code protection. See our dedicated EEPROM read service or OTP memory recovery page for specifics.

Deliverable Formats and What You Receive

  • Intel HEX (.hex) — standard for 8-bit and many 32-bit MCUs; compatible with most programmers.
  • Raw binary (.bin) — flat memory image; preferred for flash-based SoCs and direct memory mapping.
  • Motorola S-Record (.srec) — available on request for Freescale/NXP workflows.
  • Configuration / fuse bytes — reported separately so you can replicate the exact device state.
  • Extraction report — documents the part marking, die revision (if decapped), protection state, flash size, and CRC of the delivered file.

Authorization, Legality, and Ownership

Chip programmer and hex editor used during IC reverse engineering

IC reverse engineering for firmware recovery is legal in most jurisdictions when performed on hardware you own or are authorized to maintain. We require one of the following before starting work:

  • Proof of product ownership (purchase invoice, asset tag, or company letterhead confirmation).
  • Written authorization from the IP holder (e.g., an OEM authorizing a contract manufacturer to recover production firmware).
  • A signed NDA and service agreement outlining intended use.

We do not accept projects aimed at cloning third-party proprietary firmware for unauthorized reproduction. For a deeper look at how we handle IP concerns, visit our trust and compliance page.

What Can Go Wrong — Honest Constraints

No lab can guarantee 100 % success across every IC ever made. Here are the realistic failure modes our clients should understand:

  • Permanent lock fuses — some protection schemes (e.g., STM32 RDP Level 2, NXP CRP3) are designed to be irreversible. If the fuse is blown, current non-destructive techniques may fail.
  • Die damage during decapsulation — semi-invasive methods carry a small risk (typically < 5 % in our lab) of damaging bond wires or the die surface. We mitigate this by working under microscope guidance and using controlled acid-jet decapping.
  • Encrypted flash — even if raw bytes are read, AES-encrypted firmware may be useless without the key, which is often stored in a one-time-programmable key slot. We report this upfront.
  • Partial reads — on rare occasions, only a portion of flash is recoverable. We deliver what we extract and clearly document any gaps.

Typical Turnaround and Pricing Signals

Turnaround depends on protection tier and queue depth. Standard service runs 5–10 working days after feasibility confirmation. Rush service (2–3 days) is available for Tier 1–2 parts at a surcharge.

Pricing starts at approximately $150–$300 USD for unprotected EEPROMs and simple MCUs, scaling to $500–$2,000+ for protected 32-bit parts requiring glitch or semi-invasive techniques. Tier 4 projects are quoted individually. The initial feasibility assessment is free for most parts—you only pay if extraction succeeds.

How to Get Started

Submit your IC part number and a brief description of the recovery scenario. If you have the physical chip or board ready to ship, we can begin feasibility analysis within 24 hours of receipt. For firmware stored in standalone memory, our chip code extraction service covers the full workflow from desoldering through verified delivery.

Check feasibility for your project

Send the chip marking or board details and tell us what you need to recover. Add clear photos if available.

Request a feasibility review
Is IC reverse engineering the same as chip decapping?

Not necessarily. Decapping (removing the epoxy package to expose the silicon die) is one technique used in semi-invasive IC reverse engineering, but many extractions succeed through non-invasive debug-port or glitch-based methods without ever opening the package. Decapping is only used when lower-risk approaches have been exhausted.

Can you recover firmware from a chip that was damaged by overvoltage?

It depends on the extent of damage. If the flash memory array is intact—even if the I/O pads or voltage regulator are destroyed—we can often decap the device and micro-probe the memory bus directly. Success rates drop significantly if the die itself shows thermal discoloration or cracking. Ship the part for a free assessment; we’ll inspect under magnification before quoting.

Do I need to remove the IC from the PCB before sending it?

No. In most cases we prefer to receive the entire board. This lets us attempt non-invasive readout through on-board debug headers (JTAG, SWD, ISP) before desoldering. If desoldering is required, our rework station handles packages from SOIC-8 through BGA-256 without thermal damage to the die.

What if my chip’s protection level makes recovery impossible?

We will tell you during the free feasibility stage. If our assessment concludes that the protection is beyond current recovery methods, you pay nothing and we return your hardware. We never charge for an unsuccessful extraction.

How do you verify the extracted firmware is complete and correct?

We perform CRC-32 checksumming on every read and, when a second sample is available, run a byte-for-byte comparison between independent reads. For MCUs with known flash sizes, we verify the file length matches the expected memory map. The extraction report documents all verification steps taken.

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

Related reading

WhatsApp Send board details