Memory readout is the process of extracting the stored contents—firmware, calibration tables, configuration data—from a microcontroller, EEPROM, or flash IC and delivering those contents as a usable binary file. Our engineers perform memory readout on devices ranging from 8-pin serial EEPROMs to 144-pin ARM Cortex MCUs, returning verified .hex or .bin files typically within 5–15 working days. Authorization and proof of ownership are required for every project.
What Exactly Is a Memory Readout?
A memory readout captures every addressable byte inside an integrated circuit’s non-volatile storage. The result is a bit-accurate image of the chip’s flash, OTP, or EEPROM region at the moment of extraction. This image is saved in Intel HEX (.hex), Motorola S-record (.srec), or raw binary (.bin) format—whichever your toolchain requires.
Memory readout differs from a simple “chip read” with a desktop programmer because many modern ICs ship with readout protection mechanisms such as RDP levels, lock bits, and fuses that block standard programming tools. Bypassing those protections requires specialized equipment and techniques that go well beyond plugging a chip into a socket adapter.
Why Clients Request Memory Readout

- Legacy equipment repair — The original firmware source code is lost, the OEM is defunct, and a replacement MCU needs an identical image.
- Production backup — Creating a golden master of your own firmware before a chip goes end-of-life.
- Failure analysis — Comparing a faulty unit’s memory contents against a known-good image to isolate data corruption.
- Re-manufacturing — Scaling production of your own design when the original programming files are unavailable.
- Reverse engineering your own product — Recovering IP from a prototype or first-run board when development files have been lost.
Which Memory Types Can Be Read Out?
| Memory Type | Typical Packages | Common Sizes | Readout Difficulty |
|---|---|---|---|
| Serial EEPROM (I²C / SPI) | SOIC-8, TSSOP-8, DFN-8 | 1 Kbit – 2 Mbit | Low — usually unprotected |
| Parallel NOR Flash | TSOP-48, BGA-48/63 | 512 Kbit – 256 Mbit | Low to moderate |
| SPI NOR Flash | SOIC-8, WSON-8 | 4 Mbit – 1 Gbit | Low — standard SPI read |
| NAND Flash | TSOP-48, BGA-63/132 | 1 Gbit – 32 Gbit | Moderate — ECC & bad-block handling needed |
| MCU Internal Flash (unprotected) | QFP, QFN, BGA | 4 KB – 2 MB | Low — JTAG / SWD / ISP read |
| MCU Internal Flash (protected) | QFP, QFN, BGA | 4 KB – 2 MB | High — requires protection bypass |
| OTP ROM / Mask ROM | DIP, QFP, die-level | 1 KB – 64 KB | High — may require decapping & optical read |
For protected MCUs, the readout procedure overlaps with what the industry calls extracting code from microcontrollers—our engineers use fault injection, glitching, UV exposure, or micro-probing depending on the protection scheme and silicon revision.
How Our Memory Readout Process Works
Step 1 — Feasibility Assessment
You send us the chip part number, package photo, and a brief description of what you need. We identify the memory architecture, protection level, and known bypass routes. Within 1–2 working days we return a feasibility verdict, estimated cost range, and turnaround.
Step 2 — Chip Preparation
If the IC is soldered to a PCB, we desolder it under controlled thermal profiles (peak 260 °C for lead-free, 235 °C for SnPb) to avoid thermal damage to the die. For BGA parts we use a reballing jig or direct socket adapter. Devices requiring decapping go through chemical or laser lid removal in a clean environment.
Step 3 — Memory Extraction
Depending on the device, we use one or more of these approaches:
- Standard interface read — JTAG, SWD, ISP, I²C, SPI, or parallel bus via a calibrated programmer.
- Glitch / fault injection — Voltage or clock glitching to bypass readout protection during the boot sequence. Timing windows are often under 50 ns.
- UV / laser attack — Targeted photon injection to reset lock bits on older CMOS processes (≥ 180 nm).
- Micro-probing — Direct contact with internal bus lines after decapping, used on high-security parts when other methods fail.
Step 4 — Verification
Every readout is performed at least twice. We compare the two dumps byte-by-byte; a mismatch triggers a third read and a root-cause check (marginal bit cells, ECC corrections, or extraction artifact). The final file includes a CRC-32 and SHA-256 checksum.
Step 5 — Delivery
We deliver the verified file via encrypted transfer. Standard formats are Intel HEX and raw .bin; we also provide .srec or segmented region files on request. A brief extraction report accompanies every delivery, noting the protection level encountered and the method used.
Deliverable File Formats Explained
| Format | Extension | Best For | Notes |
|---|---|---|---|
| Intel HEX | .hex | MCU programming tools, Keil, IAR | ASCII; includes address offsets & checksums per line |
| Raw Binary | .bin | Flash programmers, dd-based workflows | Exact byte image; no metadata |
| Motorola S-record | .srec / .s19 | Freescale / NXP legacy tools | ASCII; similar to HEX with different record structure |
| Segmented Dump | .bin (multiple) | Devices with separate flash + EEPROM + fuse regions | One file per memory region |
Vendor-Specific Considerations

Protection schemes vary dramatically across silicon vendors, which directly affects memory readout feasibility and turnaround. A few examples from our lab:
- Samsung microcontrollers — Older S3C/S3F families often use single-level lock bits that respond well to glitching. Newer Exynos-class parts are significantly harder. See our notes on Samsung IC readout capabilities.
- Zilog Z8 / eZ80 families — OTP variants require optical ROM read after decapping; flash variants with OCD disabled can sometimes be re-enabled via pin forcing. Details on Zilog IC recovery.
- Maxim (now Analog Devices) MAXQ / MAX32 — These parts use multi-level security with permanent lock options. If the permanent lock fuse is blown, memory readout may not be possible. We document this clearly during feasibility. More on Maxim IC extraction.
For WCH CH32, APM32, Dialog, and other less common vendors, our lab maintains current bypass research—contact us with the exact part number for a feasibility check.
What Can Go Wrong — Honest Limitations
We do not guarantee 100 % success on every chip. Here are the realistic constraints:
- Permanent protection fuses — Some MCUs (e.g., STM32 RDP Level 2, certain Renesas RH850 configs) have irreversible protection. Once blown, no known technique recovers the flash contents.
- Die damage during decapping — Chemical decapping carries a small risk (roughly 2–5 % on fine-pitch BGA devices) of bond-wire or passivation damage. We mitigate this with laser decapping when the geometry allows.
- Bit-rot on aged OTP/EPROM — Devices older than 20 years may have marginal charge retention, producing inconsistent reads. We flag affected addresses in the report.
- Encrypted firmware — Reading out an AES-encrypted blob is technically a successful memory readout, but the resulting file is useless without the decryption key. We clarify this distinction before starting work.
Turnaround and Pricing Signals
| Category | Typical Turnaround | Starting Price Range |
|---|---|---|
| Unprotected EEPROM / Flash | 3–5 working days | USD 150 – 400 |
| Protected MCU (single-level lock) | 5–10 working days | USD 500 – 1,500 |
| High-security MCU (multi-level) | 10–20 working days | USD 1,500 – 5,000+ |
| OTP / Mask ROM (optical read) | 15–25 working days | USD 2,000 – 6,000 |
Final pricing depends on the exact part number, protection configuration, package type, and quantity of devices. We provide a binding quote after the feasibility assessment—no surprise charges.
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 reviewFrequently Asked Questions About Memory Readout
What file do I receive after a memory readout?
You receive the chip’s full memory image as an Intel HEX (.hex) or raw binary (.bin) file, along with CRC-32 and SHA-256 checksums. We can also provide Motorola S-record format or segmented region files if your toolchain requires them. A short extraction report is included with every delivery.
Is memory readout legal?
Memory readout for firmware you own—or are authorized to access—is legal in most jurisdictions. Common lawful scenarios include recovering your own lost source code, backing up production firmware, and repairing legacy equipment. We require proof of ownership or written authorization before starting any project, and every engagement is covered by NDA. See our readout protection overview for more on how security mechanisms work.
Can you read a chip that’s still soldered to the board?
In some cases, yes—SPI and I²C EEPROMs can often be read in-circuit using test clips or pogo-pin fixtures. For MCUs requiring JTAG/SWD access, we may read in-circuit if the debug port is accessible and not disabled. When in-circuit reading isn’t possible, we desolder the IC under controlled thermal profiles to preserve the die.
What if the readout protection cannot be bypassed?
We tell you during the feasibility assessment. If our analysis shows the protection is irreversible (e.g., STM32 RDP Level 2 or a blown permanent lock fuse), we report that finding at no charge beyond the initial evaluation fee. You are never billed for an unsuccessful extraction attempt.
How do I verify the dump is correct?
We perform at least two independent reads and deliver only when the byte-by-byte comparison matches. The checksums in our report let you verify file integrity on your end. For MCU firmware, you can flash the image onto an identical blank chip and perform a functional test against the original hardware.
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 reviewWorking 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