Short answer: most legacy ELAN 8-bit microcontrollers — the EM78 series and its EM85/EM86 relatives — are candidates for ELAN IC unlock, and a lot of them are OTP (one-time programmable) rather than flash, which changes the whole approach. Feasibility is decided part number by part number, not brand by brand. Send us the exact top marking and we’ll tell you whether the code can be read out before you commit to anything.
This page is written for the person who already has a dead or undocumented board on the bench: an ELAN chip in the middle of it, no hex file, no source, and either a customer waiting or a production line stopped.
Why ELAN parts show up in this kind of work
ELAN Microelectronics built its reputation on cheap, small, high-volume 8-bit controllers. You’ll find them in remote controls, calculators, keyboards and touchpads, battery chargers, small appliances, LED drivers, scales, toys, thermometers, and thousands of Taiwanese and mainland OEM designs from roughly the late 1990s onward.
Two things follow from that. First, the firmware was often written by a contract house that no longer exists or no longer answers email, so the customer holds the product rights but not the code. Second, a large slice of the catalog is OTP. There is no in-system reprogramming path, no bootloader, and frequently no formal archive of the burned image — the programming file lived on one engineer’s PC.
That combination is why ELAN work lands in our lab: the part is still soldered into a working product, the design is still selling, and nobody can rebuild the binary.
Which ELAN families we see and how they behave
ELAN’s numbering is not always obvious, and the same die can appear under several package suffixes. What matters for feasibility is the memory type and the protection scheme on that specific die revision.
| Family | Typical memory | What we’re looking at | General difficulty |
|---|---|---|---|
| EM78P series (EM78P153, P156, P157, P447, P451, P458 and relatives) | OTP program memory | Protection bit state, package type, die accessibility | Commonly workable; varies by die revision |
| EM78 mask-ROM versions | Mask ROM | ROM content read at die level | Feasible but invasive and slower |
| EM85/EM86 series | ROM or OTP, application-specific | Whether a test/debug path exists | Case by case |
| eKT / eKTF keyboard and touch controllers | Embedded flash or ROM | Firmware image plus configuration data | Harder; often needs die-level work |
| Custom / house-marked ELAN dies | Unknown until identified | Die identification first, then feasibility | Unknown until we see the part |
The last row is not a cop-out. A meaningful fraction of ELAN parts in the field carry a customer house number instead of an ELAN part number. In those cases the first job is identification, not extraction — and identification sometimes means decapsulating one sacrificial sample to read the die markings under a microscope.
OTP is a different animal from flash
On a flash MCU the security story is usually a documented mechanism — read protection levels, a lock bit, a JTAG fuse, a bootloader password. On classic OTP parts like the EM78P family, the protection is a fuse or a small set of protection bits that gate the programmer’s verify path. There is no elaborate cryptographic layer, but there’s also no clean debug port to lean on.
Practically, that means ELAN OTP work leans harder on physical and semi-invasive techniques than, say, a modern ARM part does. It also means we can rarely promise a fast software-only result. If someone quotes you an ELAN OTP part with same-day turnaround and no sample, be skeptical.
What actually happens to your chip
Here’s the sequence, in order, so you know what you’re buying.
- Identification. We read the top marking and confirm the die family. If the marking is a house code, we compare pinout, package, and — when necessary — the die itself against known ELAN silicon.
- Non-destructive attempts first. We try to talk to the part through its normal programming interface and read the memory. Sometimes the protection bit was never actually set at production, and that happens more often than you’d expect on low-cost consumer builds. This step costs nothing to try and occasionally ends the job in an hour.
- Sample sacrifice, if required. If the part is genuinely locked, we plan a route on one sample. That may involve decapsulation and optical inspection of the die to locate the protection structure and confirm the memory array layout. This sample does not come back.
- Extraction. The code is read out and captured as a binary or hex image matching the original program memory map, including configuration/option registers where they exist.
- Verification. This is the part cheap vendors skip. We program a blank part of the same type with the extracted image and run it — either on your original board or on a fixture — and compare behavior against your reference unit. If the display comes up, the keys respond, the timing matches and the outputs switch the way they should, the dump is good. If it doesn’t, the dump is wrong and we go back.
Verification against a known-good reference is the only meaningful proof of a firmware extraction. A checksum tells you the file is internally consistent; it tells you nothing about whether you got the whole array or the right bank. This is the same discipline we apply across all of our Texas Instruments unlock work and other legacy MCU families.
What we need from you
A feasibility answer is fast when you send the right things. Send these and you’ll normally get a straight yes, no, or “we need a sample to say”:
- The exact top marking — every character and line, including the date code and any suffix letters. Photograph it straight on, well lit, dark background. Blurry markings are the single most common cause of a slow reply.
- Package and pin count — DIP, SOP, SSOP, QFN, or die-on-board.
- Quantity available. Tell us how many samples you have. If you can spare two or three identical units, feasibility improves substantially, because we can attempt an invasive route without risking your only good part.
- A working reference unit if one exists. Even a partly working board helps us verify the result.
- What you actually need back — just the binary? Programmed replacement chips? A path to a different MCU because the ELAN part is obsolete?
- Photos of both sides of the board if you also want the hardware documented. Whole board in frame, dark background, no flash glare.
What comes back from us is a feasibility statement, a lead time, and a price. If we don’t think we can do it, we say so instead of taking a deposit and stalling.
Where the board matters too
Firmware alone rarely solves an obsolescence problem. If the ELAN part is discontinued, you need somewhere to put the code — which usually means documenting the hardware as well. Customers frequently pair chip work with Sinowealth-style legacy controller recovery on sister products, or with board-level schematic and Gerber recovery so a replacement design can be laid out around a current-production MCU.
Honest limits: when ELAN IC unlock gets hard or stops
These are the cases where we slow down or decline:
- One and only one sample, physically irreplaceable. If an invasive route is needed and you have exactly one board, we will tell you the risk plainly. Sometimes the right answer is not to try.
- Die-on-board / chip-on-board assemblies. An epoxy-blobbed ELAN die glued to the PCB is much harder to work with than a packaged part, and the blob compound varies wildly between assembly houses.
- Newer eKT touch and keyboard controllers. These are more integrated, better protected, and frequently paired with external configuration data. Feasibility here is genuinely uncertain until we look.
- Physically damaged dies. A part that’s been overvoltaged, reverse-biased, or cooked may have lost array contents. No technique recovers bits that aren’t there anymore.
- Unidentifiable house-marked parts where the die also carries no useful markings. Rare, but it happens.
Two things change the answer more than anything else: how many samples you have, and whether the specific die revision is one we’ve handled before. A part we’ve seen is quick. A part we haven’t may need an evaluation stage first.
Legitimate use, and confidentiality
We take ELAN work for firmware you own but have lost, for maintaining out-of-production equipment, for migrating a design off a discontinued part, and for failure analysis. You need to hold the rights to the design or have authorization from whoever does — that’s your call to make, and we ask about it. Every project runs under NDA, samples and files stay in the lab, and nothing gets reused. We don’t publish or resell customer firmware.
Frequently asked questions
Can you unlock an EM78P153 or EM78P447?
Usually, yes — these EM78P OTP parts are among the most common ELAN requests and we’ve handled the family repeatedly. The caveat is die revision: parts with the same printed number made years apart aren’t always identical inside. Send the full marking including date code and we’ll confirm against what we’ve actually done rather than guessing from the part number alone.
How much does ELAN IC unlock cost?
It depends on the part and the route. A part where the protection bit turns out to be unset and a straight read works is the cheapest possible outcome. A locked OTP die needing decapsulation, optical work, and sacrificial samples costs meaningfully more. Sample quantity, package type, and whether you want programmed replacement chips all move the number. Send the details for a quote.
Will I get source code back?
No. You get the binary or hex image of the program memory, which is what the chip actually contains. Source code doesn’t ex
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