93Cxx EEPROM Crack | Firmware Readout & Code Recovery

A 93Cxx EEPROM crack is almost never a code-breaking job — it’s a data readout job. The 93C46/56/66/76/86 family is a small serial EEPROM on a 3-wire Microwire bus, with no lock bits and no read protection in the way an MCU has them. So if the die is intact, the contents can usually be read out and returned to you as a binary dump. The real questions are whether the part is electrically alive, whether the stored data is encrypted or checksummed by the host system, and how the chip has to be accessed.

What people actually mean when they ask for a 93Cxx crack

In our inbox, “93Cxx crack” arrives in three flavors, and they need different answers.

The first is recovery: an instrument, ECU, meter, or industrial controller stores its calibration, serial number, or configuration in a 93C56, the board is dead or the EEPROM is corrupted, and you need the last known-good contents. The second is duplication: you’re building spare boards or a service replacement and need the same EEPROM image programmed into fresh parts. The third is analysis: you have a dump but no idea what the bytes mean, and you want help mapping fields.

All three are legitimate engineering work. What none of them are is a way around a protection scheme — 93Cxx parts don’t have one worth defeating. The interesting security, when it exists, lives in the host MCU or in how the host obfuscates what it writes.

Which parts are in the family

Note the ×8 / ×16 ambiguity. Many of these parts select word width with an ORG pin, and a surprising number of failed DIY dumps are simply the wrong organization — the data is there, it’s just byte-swapped or address-shifted into nonsense. That’s the single most common thing we fix on customer-supplied dumps.

How the readout actually works, step by step

Here’s what happens on the bench, in order, for a typical 93Cxx job.

1. Identify the exact part. We read the top marking under a stereo microscope and confirm the manufacturer prefix — Atmel AT93C, Microchip 93AA/93LC/93C, ST M93C, ONsemi CAT93C. The letter suffix matters: 93LC parts are low-voltage, and driving a 3.3 V part at 5 V during readout is how you turn a recoverable chip into scrap.
2. Decide in-circuit or removal. If the host MCU can be held in reset and the CS/CLK/DI lines aren’t loaded by other drivers, we read it in place. If not, the part comes off with hot air (SOIC-8) or is desoldered by hand (DIP-8), pads photographed first so it goes back exactly where it was.
3. Bring it up on a socket. Correct Vcc, ORG state set both ways, CS/CLK/DI/DO on a programmer or a bench adapter. We check the DO line actually toggles before trusting anything.
4. Read the whole array, then read it again. A minimum of three full passes. If any pass differs from the others, we treat the part as marginal and slow the clock, adjust Vcc within the datasheet window, and repeat until we get stable, repeatable data — or we document that we can’t.
5. Sanity-check the image. Does the dump contain plausible ASCII, a recognizable checksum at the tail of each record, repeated structure at a regular stride? A 93C46 that reads back all FF or all 00 is usually erased, not misread — and we say so rather than shipping you a file full of padding.
6. Verify by writing back. Where the customer wants working replacement parts, we program a fresh 93Cxx from the image, read it back, and compare byte for byte against the source. If a board is available, we prefer to confirm the host boots and behaves.

The part nobody talks about: making sense of the bytes

A raw dump of 128 words is easy. Knowing that words 0x10–0x17 are a scaled ADC offset and word 0x7F is a two’s-complement checksum is the work. We do this by comparing multiple units, by changing one setting on a live board and re-reading to see which bytes moved, and by correlating against the host firmware where you also need code recovery from the PIC16C controller or whatever MCU sits next to the EEPROM. Field mapping is a separate line item on a quote because it’s genuinely open-ended analysis, not a fixed procedure.

What to send us for a quote

Short list. Getting these right saves a full day of back-and-forth.

• Clear photos of both sides of the board on a dark, non-reflective background, whole board in frame, in focus. Then one close-up of the 93Cxx itself where the top marking is legible.
• The exact chip marking, typed out including the suffix and package (e.g. AT93C56A-10SU-2.7, SOIC-8).
• Board dimensions and, if the EEPROM is under a shield, potting, or a heatsink, a note saying so.
• Quantity: one chip, one board, or a batch of units you need matched.
• One line on what you need back — raw binary only, binary plus programmed replacement chips, or binary plus field analysis.
• Any dump you already have, even a bad one. It tells us the organization and often the record structure immediately.

What comes back from us: a feasibility answer with the reason behind it, a lead time, and a price. Simple readout of a healthy, accessible 93Cxx is one of the faster jobs we do; the schedule stretches when the chip has to come off a potted assembly or when field mapping is in scope. Projects run under NDA, and you’re responsible for holding the rights to the data and design you’re asking us to recover.

Where a 93Cxx job gets hard, and where it stops

Honest constraints, because they change the answer more than anything on our capability list.

Physical damage. Overvoltage on Vcc, a lightning event, or a burned trace that took the die with it. If bond wires are open or the die has a visible crater, the data is gone. Decapsulation and probing can sometimes confirm the failure mode for a failure-analysis report, but it does not resurrect erased or destroyed floating gates.

Wear-out. These parts are rated in the hundreds of thousands of write cycles per cell. A 93C46 in a machine that logs a counter every few seconds for fifteen years will have cells that no longer hold charge reliably. Symptom: bits that read differently pass to pass, usually clustered in the same few words. We can sometimes stabilize the read with slower clocking and Vcc trimming, and we’ll report exactly which words we couldn’t trust rather than quietly guessing.

Host-side encryption or binding. The EEPROM hands over whatever it was given. If the host MCU wrote AES-wrapped or XOR-scrambled data, or if a record includes a hash tied to a unique MCU serial, a clean dump still won’t let you drop it into another unit. That’s a firmware problem, not an EEPROM problem, and solving it means going after the host — which is a different and much harder job than reading the 93Cxx.

Access. Epoxy potting, conformal coat over fine-pitch pads, or a 93Cxx buried under a soldered RF shield all add removal risk. We’ll say up front if we think the removal risk to your only unit is high, and we’d rather you send a spare.

Counterfeit or relabeled parts. Occasionally a “93C66” turns out to be a remarked 93C46 with only a quarter of the address space real. Addresses above the true density alias back onto lower ones. Reading the full array and looking for that mirror pattern catches it.

How this compares to cracking the MCU next to it

Customers often assume the EEPROM and the microcontroller are the same class of problem. They’re not, and knowing the difference will save you money.

If your goal is to rebuild a whole board, you usually need both halves: the EEPROM image for the unit-specific data, and the program memory from the controller. We handle the second half separately for families like AVR ATmega code readout, STC15 firmware recovery, and older 16-bit parts such

Related reading

• Oct 2026NXP LPC18 Unlock | Feasibility, Cost & Lead Time
• Oct 2026Analog Devices IC Unlock | Families We Can Read
• Oct 2026NXP LPC17 Crack | Protection Levels & Recovery