If you have an ATmega or ATtiny with its lock bits set and no hex file left in your archives, AVR Unlock is the service that reads the flash and EEPROM contents back out and hands you a usable binary. Feasibility depends on the exact part number, the die revision, and how the security fuses were configured — not on the AVR name alone. Send us the chip marking and we’ll tell you where your specific device sits before you commit to anything.
What lock bits actually block, and why that matters to you
Classic AVR parts protect code with a small set of lock bits (LB1/LB2) plus boot lock bits (BLB0x/BLB1x). Set them to the protected state and the serial or parallel programming interface refuses to return flash contents. The chip still runs fine — it just won’t talk about what’s inside.
That’s a different mechanism from a password or an encrypted image. There is no key to guess. The device is simply configured to deny the read command, which is why AVR code recovery is an engineering problem about the silicon and its programming logic rather than a cryptographic one.
Two practical consequences follow. First, a locked AVR still gives up useful information — fuse states, signature bytes, sometimes partial regions depending on how boot lock bits were set. Second, the newer AVR generations with UPDI and unified program-and-debug interfaces behave differently from a 2005-era ATmega16 in a DIP package, and they need to be assessed separately.
Which AVR families come across our bench most
- ATmega classic — ATmega8/16/32/64/128, ATmega48/88/168/328 and the 328P. Enormous installed base in industrial controllers, gate openers, HVAC boards, and consumer appliances.
- ATtiny — ATtiny13, 25/45/85, 2313, 24/44/84. Small pin counts, often doing one job in a power supply or a sensor node.
- ATmega with USB or CAN — ATmega16U/32U4, AT90CAN parts, common in test fixtures and automotive accessories.
- Newer AVR-Dx / tinyAVR 1-series and 2-series — UPDI-based, different lock architecture, assessed case by case.
- AT90S legacy — AT90S1200/2313/8515 and similar, usually attached to equipment that is thirty years old and still earning money.
How an AVR Unlock job actually runs in the lab
The order matters, because every step either narrows the problem or rules out a cheaper path before we spend effort on a harder one.
- Identify the part properly. Top marking, date code, package, and the visible revision letter. An ATmega128 rev C and a much later rev do not always respond identically. If the marking is sanded off or the part is remarked, we say so.
- Read what’s readable. Signature bytes, fuse bytes, lock byte state, calibration. This confirms the die matches the marking and tells us exactly which protection configuration we’re facing rather than which one we assumed.
- Attempt the least invasive route first. Non-invasive and electrically non-destructive approaches are always tried before anything that touches the package. If the code comes out this way, the chip usually survives and can go back in your board.
- Escalate only if needed. Some parts require die-level access. That path is destructive to the sample, which is why we ask about spare units early.
- Verify the dump against the hardware. A hex file is worthless if it doesn’t run. We check vector table sanity, reset vector, and code/data boundaries, then program a blank device of the same part number and confirm it behaves like the original board.
- Package the deliverables. Flash image, EEPROM image, and the original fuse settings — because a correct flash dump programmed into a chip with the wrong fuse configuration will look broken for reasons that have nothing to do with the firmware.
That last point trips up more people than anything else. Clock source selection, brown-out level, watchdog, and the boot reset vector all live in fuses. We record them and hand them over with the binary.
What to send us, and what comes back
Getting a real answer instead of a vague “yes we can” takes about five minutes of your time.
Send this
- The full chip marking, all lines, photographed straight on. “ATMEGA328P-AU 1523” tells us far more than “an ATmega”.
- A clear photo of the chip in place and, if the board is involved, both sides of the board on a dark background with the whole board in frame.
- Board dimensions and a note on whether the chip can be desoldered or must stay attached.
- Quantity of samples available — one only, or spares. This directly changes which methods we can consider.
- One line on the deliverable you need: flash binary only, flash plus EEPROM, fuse settings, or programmed working chips returned to you.
Get this back
A feasibility assessment specific to your part and revision, a lead time, and a price. Where we’re genuinely unsure, we say “needs a sample evaluation” instead of guessing. Simple older ATmega and ATtiny parts are typically quick; unusual revisions, unclear markings, and newer UPDI silicon take longer to assess and longer to execute.
What drives cost and turnaround on AVR code recovery
| Factor | Effect on effort and price |
|---|---|
| Common older part (ATmega8/16/32, ATtiny13/85) | Well-characterized, usually the fastest and least expensive route |
| Late die revision of a familiar part | May need re-characterization; adds time before work starts |
| Newer UPDI-based AVR | Assessed individually; feasibility is not assumed |
| Single sample, no spares | Limits method choice, raises risk, may reduce feasibility |
| Chip must stay soldered to the board | Adds desolder/resolder or in-situ handling steps |
| EEPROM contents also required | Extra readout and verification pass |
| Damaged, cracked, or previously reworked package | Higher risk, sometimes not feasible at all |
We don’t publish a flat rate for AVR work because the spread between an ATtiny13 in a socket and a remarked ATmega of unknown revision on a potted board is enormous. Ask for a quote with the details above and you get a real number instead of a range that means nothing.
The honest limits on AVR Unlock
This is where most service pages go quiet. Here’s the straight version.
- No guarantees per device. AVR spans two decades of silicon. We can tell you our confidence level for your exact part and revision; we won’t claim a success rate for “AVR” as a category, because that number would be meaningless.
- Physically damaged dies may be unrecoverable. If the part died from overvoltage, ESD, or long-term thermal stress, the flash cells may no longer read reliably no matter what access we obtain. Sometimes we recover a partial image; sometimes nothing.
- One sample is a real constraint. Approaches that risk the die are much harder to justify when there is no second unit. Two or three identical chips meaningfully improve your odds.
- Remarked or counterfeit parts change the problem. If the signature bytes don’t match the printed marking, we’re working on a different chip than you think, and we’ll tell you before proceeding.
- Newer AVR generations are not the same job. Treating an AVR-Dx like an ATmega32 is exactly the mistake that produces confident quotes and failed deliveries.
- A recovered binary is machine code, not source. You get a working, programmable image. Turning that into readable C is a separate reverse engineering effort with its own scope and cost.
Why engineers ask for this work
Almost every AVR job that reaches us is maintenance, not competition. A machine builder went out of business and the ATmega firmware exists only inside the last three working boards. An engineer retired and the hex file lived on a drive that got wiped. A part hit end-of-life and the design has to move to a current device, which means the existing behavior needs to be captured first.
Failure analysis is another common one: reading the EEPROM out of a controller that misbehaves in the field often shows exactly which stored parameter drifted. Authorized security review of your own product is legitimate too.
You need to hold the rights to the design, and complying with applicable IP law is your responsibility as the customer. Every project runs under NDA, and we decline jobs where ownership looks unclear. If you’re weighing an AVR against another architecture on your next board, our notes on PIC18F code recovery cover a family that shows up in exactly the same industrial roles, and the 8051-derived STC89 parts sit at a very different point on the protection spectrum.
FAQ
Can you unlock an ATmega328P that has the lock bits set?
Often yes, and it’s one of the most frequently requested AVR jobs we see. Feasibility still depends on the die revision and package, so we confirm against the actual chip marking and signature bytes before quoting. Send a straight-on photo of the top marking and tell us how many samples you have — that’s enough for a real answer rather than a maybe.
Will my chip survive AVR firmware extraction?
Sometimes. Non-invasive approaches are tried first and normally leave the device fully functional and reusable. Methods that require die access destroy the sample. We tell you which category your part falls into before starting, so if the original chip must go back into a one-of-a-kind board, that constraint shapes the plan from the beginning.
Do I get C source code back?
No. You
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