Code Reading Service | What Determines Feasibility

What Is a Code Reading Service?

A code reading service recovers the binary firmware, configuration bitstream, or stored data from a programmable integrated circuit—microcontrollers (MCUs), EEPROMs, CPLDs, FPGAs, and flash memory ICs. The extracted file is typically delivered as an Intel HEX or raw BIN image that can be reprogrammed into a blank replacement part. Whether the readout succeeds depends on the chip’s protection architecture, die process node, package condition, and the extraction method available. Success rates vary from near-certain on unprotected serial EEPROMs to genuinely impossible on certain high-security MCU families.

Why Engineers Need Code Reading

The request almost always traces back to one of four scenarios:

• Legacy equipment repair — the original firmware source was lost or the developer is unreachable, and a failed IC must be replaced to keep a production line running.
• Authorized duplication — you own the design and need to program replacement units without rebuilding the toolchain.
• Reverse engineering for interoperability — understanding a peripheral’s register map or boot sequence for a new hardware revision you control.
• Quality verification — confirming that a contract manufacturer programmed the correct firmware revision before shipping.

In every case, proof of ownership or written authorization is required before work begins. Our engineers operate under NDA, and we decline requests that lack clear legal standing.

What Determines Whether Code Reading Is Possible?

Seven variables control feasibility. Understanding them before you submit a chip saves time and sets realistic expectations.

1. Protection Fuse / Lock-Bit State

Most MCUs ship with configurable read-protection bits. An STM32 in Read-Out Protection Level 1 (RDP1) can often be reset—at the cost of erasing flash—while RDP2 is permanent and blocks JTAG/SWD entirely. Atmel AVR lock bits, PIC code-protect bits, and Renesas ID-code locks each behave differently. The first step in any code reading service engagement is identifying the exact protection state.

2. Die Process Node and Architecture

Older devices fabricated at 350 nm or above are generally more accessible to physical-layer techniques (micro-probing, UV erasure of EPROM-style fuses, FIB circuit editing). Modern 40 nm and below nodes pack features too dense for reliable probe contact, and multi-layer metal stacks obscure the memory array. A chip made in 2005 on a 180 nm process is a fundamentally different challenge than one taped out in 2022 at 28 nm.

3. Memory Type

The storage technology inside the IC matters as much as the protection scheme around it:

4. Package Condition

Physical-layer code reading requires decapsulation—chemically or mechanically removing the package to expose the die. If the IC has been damaged by heat, moisture, or corrosion, the die surface may already be compromised. Chips desoldered with excessive heat (>300 °C sustained) sometimes suffer bond-wire lift or passivation cracks that destroy memory cells before extraction begins. Ship the chip on its original board whenever possible; our engineers handle desoldering under controlled conditions.

5. Vendor-Specific Countermeasures

Some silicon vendors implement active tamper detection: voltage and clock glitch sensors, light sensors under the passivation layer, encrypted flash with per-device keys, or mesh routing that scrambles the memory bus layout. These features are common in automotive-grade and payment-terminal MCUs (e.g., Infineon AURIX, NXP SE050). A code reading service must evaluate these countermeasures on a per-part-number basis—blanket success claims are a red flag.

6. Firmware Size and Verification

Even after extraction, the binary must be verified. For MCUs with 256 KB or less of flash, a CRC or checksum comparison against a known-good unit (if available) confirms integrity. Larger devices—1 MB+ ARM Cortex-M7 parts, for instance—require more extensive validation, sometimes including functional testing on a target board. Turnaround for small MCUs (≤64 KB) is typically 5–10 working days; complex or high-protection parts may take 15–25 days.

7. Legal and Authorization Requirements

We require documented proof that you own the IP or have authorization from the IP holder before starting any code reading service job. This is not optional. Typical documentation includes a purchase order for the original design, a letter of authorization from the rights holder, or a statutory declaration. We maintain an NDA framework and can provide a mutual NDA before you ship hardware.

Our Code Reading Service Process

1. Feasibility inquiry — You submit the IC part number, package photo, and a brief description of the use case. We respond within 1–2 business days with a feasibility assessment and quote.
2. Authorization check — We verify ownership documentation before proceeding.
3. Chip receipt and inspection — Visual and electrical inspection under microscope; we confirm the part number matches the marking and assess package condition.
4. Protection-level analysis — We probe the debug interface (JTAG, SWD, UART, ISP) to determine the lock-bit state and decide on the extraction method.
5. Extraction — Non-invasive (debug port), semi-invasive (glitching, UV), or invasive (decap + micro-probing) depending on the protection level.
6. Verification — CRC check, hex comparison against a second sample if supplied, or functional test on a reference board.
7. Delivery — HEX/BIN file delivered via encrypted transfer. Optionally, we can program the firmware into blank replacement ICs.

Which Chip Families Are Commonly Submitted?

Our lab handles parts from dozens of vendors. The table below lists families we see most often, with general feasibility notes. Every part number is assessed individually—these are guidelines, not guarantees.

For MCUs with blown fuses or high-security protection, our engineers evaluate whether a microcontroller crack approach is viable on a case-by-case basis. When the original silicon cannot be read, an alternative path is replicating chip functionality through black-box analysis.

What Can Go Wrong — Honest Failure Modes

Not every code reading service attempt succeeds. Transparency about failure modes is part of responsible engineering:

• Permanent read-protect — Some fuses are OTP; once blown, no non-destructive path exists, and invasive methods may not be viable on fine-geometry nodes.
• Die damage during decapsulation — Acid concentration, exposure time, and temperature must be tightly controlled. Even with experienced operators, roughly 3–5% of decaps result in partial die damage.
• Encrypted flash — If the key is stored in a secure enclave or derived from a PUF (physically unclonable function), the raw flash contents are ciphertext without the key.
• Incomplete readout — Glitch attacks sometimes yield partial data. We only deliver verified, complete images; partial dumps are flagged and discussed with the client.

We charge a non-refundable evaluation fee (typically $50–$150 depending on the part) that covers the feasibility analysis. If extraction fails, you pay only the evaluation fee, not the full service price.

Turnaround and Pricing Signals

Prices depend on the specific part number, protection state, and quantity. The ranges above cover single-unit extractions; volume programming of recovered firmware into blank parts is quoted separately.

Related reading

• Oct 2026ATSAMD21 Crack | Protection Levels & Recovery Guide
• Oct 2026Silicon Labs IC Unlock | Families We Can Read
• Oct 2026ATSAMD21 Unlock | Feasibility, Cost & Lead Time