Bao'An Shenzhen China

Firmware Cloning | Get Your Code Back as .hex or .bin

Sep 8, 2026  /  PCB COPY

firmware cloning: Technician probing a microcontroller on a PCB during firmware extraction in an electronics lab

What Is Firmware Cloning and When Do You Need It?

Firmware cloning is the process of reading the executable program from a microcontroller’s internal flash or EEPROM and producing a bit-accurate copy—typically delivered as a .hex (Intel HEX) or .bin (raw binary) file. It is the fastest way to recover code you own when the original source has been lost, a development partner has disappeared, or a legacy product needs continued production without a redesign. Our engineers perform firmware cloning under NDA with proof of ownership required before work begins.

How Firmware Cloning Actually Works

firmware cloning: Technician probing a microcontroller on a PCB during firmware extraction in an electronics lab

The method we use depends entirely on the target MCU’s architecture, protection level, and package type. Below is the general workflow from the moment your board arrives in our lab to the moment you receive a verified binary.

Step 1 — Device Identification and Protection Assessment

We desolder or probe the MCU in-circuit, identify the exact part number and silicon revision, then determine which read-protection bits (RDP, CRP, code-protect fuses, etc.) are set. This triage takes 1–2 working days and is where most of the feasibility risk lives. Some protection schemes—like STM32 RDP Level 2—permanently disable JTAG/SWD readout at the hardware level, making non-invasive extraction impossible.

Step 2 — Extraction

Depending on the protection level, extraction follows one of three paths:

  • Non-invasive (debug interface): JTAG, SWD, ICSP, or UART bootloader readout when protection is absent or has been authorized for removal. Fastest method; takes hours.
  • Semi-invasive (glitching / side-channel): Voltage or clock glitch attacks on the boot sequence to bypass read-protection. Applicable to many Cortex-M0/M3 parts. Typical success window: 60–85 % depending on silicon revision.
  • Invasive (decap + micro-probing): Chemical or laser decapsulation followed by FIB (focused ion beam) editing or direct ROM/flash probing. Reserved for high-value recoveries; adds 5–10 working days and significant cost. Learn more about chip-level reverse engineering and decap techniques.

Step 3 — Verification

Every cloned binary is verified against a CRC or checksum of the original flash contents when available. If a second identical device exists, we read both and compare. Bit-for-bit match confirms integrity. We also confirm the file programs correctly onto a blank device of the same part number before shipping.

Step 4 — Delivery

You receive the firmware file in your preferred format (.hex, .bin, or .s19), plus a brief extraction report noting the MCU model, flash size, protection state encountered, and verification method used. Typical end-to-end turnaround: 5–15 working days.

Deliverable Formats at a Glance

Format Extension Typical Use Address Info
Intel HEX .hex Most programmer tools (J-Link, ST-Link, PICkit) Embedded in record
Raw Binary .bin Direct flash write, bootloader upload Assumed from base address
Motorola S-Record .s19 / .srec Freescale/NXP legacy toolchains Embedded in record
ELF (on request) .elf Debug / disassembly workflows Full section headers

If you need the firmware loaded onto replacement ICs rather than delivered as a file, we can program blank chips in-house and ship them ready to solder. Minimum order: 1 unit.

Which MCU Families Can Be Cloned?

Firmware cloning feasibility is chip-specific. The table below summarizes common families and realistic success expectations. Protection levels vary by silicon revision, so treat these as guidelines—submit your part number for a definitive answer.

MCU Family Common Protection Cloning Feasibility Typical Lead Time
STM32F0 (Cortex-M0) RDP Level 0–2 High at RDP 1; not possible at RDP 2 5–8 days
STM32F1 (Cortex-M3) RDP Level 0–1 High 5–8 days
STM32F4 (Cortex-M4) RDP Level 0–2 Moderate at RDP 1; case-by-case at RDP 2 7–15 days
PIC16 / PIC18 CP / CPD fuse bits High for most revisions 3–7 days
ATmega / ATtiny (AVR) Lock bits LB1/LB2 High 3–5 days
Renesas RX / RL78 ID code, OCD disable Moderate 7–12 days
NXP LPC series CRP Levels 1–3 High at CRP 1; limited at CRP 3 5–10 days
GD32 / APM32 clones SWD lock High 5–8 days

For STM32 sub-families, we maintain dedicated workflows: see our pages on STM32F0 unlock feasibility and STM32F4 unlock lead times and cost for part-specific detail.

When Firmware Cloning Fails — Honest Constraints

Not every extraction succeeds. Transparency here saves you time and money:

  • Permanent read-protect (STM32 RDP 2, NXP CRP 3): These fuses are one-time-programmable. Once set, the debug interface is physically severed. Invasive methods may recover partial data, but full verified cloning is not guaranteed.
  • Encrypted flash (e.g., Infineon AURIX HSM, TI C2000 DCSM): Even if flash contents are read, the output is ciphertext without the key. Firmware cloning delivers the raw data; decryption is a separate, often infeasible, challenge.
  • Anti-tamper / secure-boot chains: Parts with TrustZone-M or similar will run only signed binaries. A cloned .bin may not execute on a different device without the signing key.
  • Damaged flash cells: If the die has been exposed to excessive heat, ESD, or radiation, some flash sectors may return corrupted data. We flag bad sectors in the extraction report.

If your MCU falls into a gray area, our free feasibility assessment tells you the realistic probability before any cost is incurred. For chips requiring authorized copy-protection bypass, we document the legal basis and proceed only with signed authorization.

Firmware Cloning vs. Full PCB Cloning — What’s the Difference?

Two identical PCBs on an anti-static mat with a programmer connected for firmware verification

Firmware cloning addresses only the software side: the binary running on the MCU. Full PCB cloning reproduces the entire board—schematic capture, Gerber generation, BOM extraction, and firmware recovery combined. If you need the hardware replicated as well, firmware cloning is one step inside the larger reverse-engineering scope.

Quick Comparison

Scope Deliverables Turnaround Starting Cost
Firmware cloning only .hex / .bin file, extraction report 5–15 days $300–$1,500 depending on protection
Full PCB clone (incl. firmware) Schematic, Gerber, BOM, firmware 15–30 days $2,000+ depending on complexity

Authorization and Legal Framework

We perform firmware cloning exclusively for authorized parties: the original IP owner, a licensee with documented rights, or a company maintaining its own legacy equipment. Before extraction begins, we require a signed declaration of ownership or authorization. All work is performed under NDA. This protects you, protects us, and ensures the recovered firmware is used lawfully. For less common chip families—such as Actel / Microsemi FPGA readback—the same authorization framework applies.

How to Submit a Firmware Cloning Request

  1. Identify the MCU: Read the part number from the chip marking. Include package type (QFP-48, LQFP-64, BGA, etc.) and any known silicon revision.
  2. State the protection level if known: If you previously programmed the device, note which protection options you enabled (RDP level, lock bits, CRP level).
  3. Ship the board or loose chip: We accept whole PCBs or desoldered ICs. If you have two identical units, send both—it accelerates verification.
  4. Receive feasibility report: Within 1–2 days of receipt, we confirm whether extraction is viable and quote a fixed price.
  5. Approve and receive files: After your go-ahead, extraction and verification proceed on the quoted timeline.

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

Frequently Asked Questions

Can firmware cloning recover source code, not just a binary?

No. Firmware cloning extracts the compiled machine code (.hex or .bin), not the original C/C++ or assembly source. Decompilation or disassembly can produce a rough approximation, but the result lacks variable names, comments, and high-level structure. If you need source-level understanding, a full chip reverse-engineering engagement with disassembly annotation is the next step.

Will the cloned firmware work on a different MCU revision?

Usually yes, if the replacement is the same part number and silicon revision. Peripheral register maps occasionally change between revisions (e.g., STM32F103C8 Rev X vs. Rev Y), which can cause subtle runtime failures. We recommend programming a test unit and verifying critical I/O behavior before committing to production.

How do you handle EEPROM data alongside flash firmware?

If the MCU has on-chip EEPROM (common in PIC and AVR families), we read it as a separate binary segment and deliver it alongside the flash image. External EEPROM or SPI flash on the same board can also be read—flag it in your request and we include it in the scope.

Is firmware cloning the same as chip decryption?

They overlap but are not identical. Firmware cloning is the end goal—a usable binary copy. Chip decryption (or IC unlock) is a method used when read-protection must be bypassed to reach that goal. Not all firmware cloning jobs require decryption; unprotected chips are read directly via standard debug interfaces.

What if my chip is from an obscure vendor like ELAN or APM32?

We maintain extraction toolchains for a wide range of lesser-known MCU vendors. See our dedicated pages for families like APM32 firmware readout for part-specific feasibility details. Submit your part number and we will confirm coverage within one business day.

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