IC unlock and IC crack are overlapping service terms, not standardized chip states. At PCB-Copy, both describe enquiries about authorized recovery of program or configuration data from protected devices. The useful distinction is the outcome: restoring programming access, preserving original firmware, recovering usable data and proving that a replacement works are different tasks.
This guide explains how chip security affects those outcomes. It separates read protection, debug restrictions, encryption and secure boot, then shows what evidence a feasibility review needs. For the commercial workflow and deliverables, visit our IC unlock and IC crack service page. No general comparison can establish recoverability for an unidentified chip.
1. IC unlock vs IC crack: define the requested recovery outcome
A programmer may report an “unlocked” device after an operation that erases its application. A repair team may use the same word to mean recovering that application without changing a byte. Unless both sides define success first, a technically successful operation can defeat the owner’s purpose.
Write the objective as a deliverable rather than a label. Examples include “preserve and assess the existing firmware,” “program an authorized replacement image,” or “identify whether configuration data is stored in the MCU or external memory.” State whether the original board must remain operational and whether it is the only working sample.
Also distinguish executable firmware from its development project. A recovered binary does not by itself supply the original source files, comments, build settings or third-party libraries. If editable source is required, discuss that separately from a BIN or HEX handover. Likewise, a readable memory image does not establish that every needed calibration or identity value has been captured.
Start by checking the owner’s existing assets: approved update packages, manufacturing images, programming logs, configuration exports and backups held by the design team. An available authorized image may change the project from data recovery to replacement programming. That is a different scope and should be described accurately.
2. Distinguish read protection, encryption and debug restrictions
Read protection controls access to stored data under specified conditions. Debug restrictions control what a debugging interface can do. Encryption changes the stored representation of selected data using cryptographic keys. Secure boot checks whether software is acceptable to execute. These mechanisms can coexist, but learning the state of one does not establish the others.
Read protection can preserve execution while restricting observation
ST’s PM0075 programming manual, Revision 2 describes read protection for its covered STM32F10xxx devices, including medium-density STM32F103 parts. Protected user code can still execute under the documented conditions, while external Flash access is restricted. The manual also specifies that changing from protected to unprotected forces a mass erase of main Flash. That documented transition is not a way to preserve the original application. Do not transfer its terminology or behavior to every STM32 family.
Flash encryption and secure boot answer different questions
Espressif’s ESP32 Flash Encryption guide explains that encryption protects contents of off-chip Flash, so a physical Flash read alone is insufficient to recover most contents. Coverage depends on the partition and configuration. The guide also distinguishes development and release configurations and describes associated debug restrictions. Therefore, “external memory readable” is not equivalent to “usable plaintext firmware recovered.”
The separate ESP32 Secure Boot v2 guide describes verification of signed bootloader and application images. For the original ESP32 target, it applies from chip revision v3.0 onward. Its purpose is controlling which software runs; it should not be described as a synonym for encrypting all stored data. These examples explain the distinction, not a universal recovery method for ESP32-family products.
Fuses and lock bits require the vendor’s definition
The ESP32 eFuse Manager documentation describes one-time-programmable bits that cannot be changed back after programming. Treat those irreversible fields differently from ordinary rewritable configuration. Conversely, a tool’s use of the word “fuse” or “lock” is insufficient to determine a different manufacturer’s storage technology, erase behavior or recovery options. Find the exact field definition before proposing a change.
3. Separate interface access from preserved program data
Assess access, data preservation and functional usefulness independently. A device identifier may be readable while application memory is protected. A memory read may return a file without establishing that its contents are complete or meaningful. An application may run on its original board but depend on configuration elsewhere.
Before connecting a tool, document the intended observation and any operation that would write, erase, update or change security settings. If original data must survive, stop before a command whose effects have not been established for that part. A general “repair,” “recover” or “unlock” button is not an adequate explanation of those effects.
The following are distinct acceptance outcomes. None automatically proves the next one.
| Requested outcome | Evidence to agree | Remaining limitation |
|---|---|---|
| Interface responds | Identified target, interface and recorded tool response | Does not establish application-memory access |
| Data image obtained | Documented regions, lengths, format and acquisition record | May be partial, encrypted or contain unknown areas |
| Original data preserved | Recorded initial condition and agreed evidence that relevant contents were retained | Must account for previous erases or updates |
| Replacement demonstrated | Agreed hardware, configuration and functional test results | Only the tested functions and conditions are established |
A file checksum is useful for tracking whether a delivered file changes. It does not prove that the source chip was read correctly, that all required regions were included or that the equipment will work. Keep file integrity evidence separate from completeness and functional validation.
4. Build a device-specific feasibility request
Supply the full package marking, manufacturer logo and clear photographs, including suffixes and secondary marking lines. Add the board revision and the chip’s role: main controller, external Flash, EEPROM, programmable logic or another function. A family name is a starting point; it does not establish the implemented security settings.
Where available, include the silicon revision from an existing trusted record, the programming tool and version, and the exact message from a previous attempt. Separate observed facts from assumptions. “Tool could not connect” is an observation. “Maximum protection enabled” is a diagnosis that requires additional evidence: power, wiring, target selection, reset state and device damage can also affect communication.
- Authority: identify the owner and the repair, maintenance or replacement purpose, with relevant authorization.
- Sample condition: record working, intermittent or failed behavior, available quantity and whether removal has occurred.
- Attempt history: disclose prior programming, erase, update or security-setting operations, including uncertain outcomes.
- Preservation boundary: specify what must remain unchanged and which sample, if any, may be altered.
- Deliverables: define required memory regions, file formats, configuration records and any programmed sample.
- Acceptance: identify the test equipment, required operating functions and who will verify the result.
Use the chip-family reference to organize an enquiry, then confirm the exact device and circumstances. A listing is not evidence that every revision or protection state is recoverable. For an initial assessment, state whether relevant keys or approved programming assets are held by the owner; do not put secret keys into a general enquiry message.
5. Protection and outcome terminology table
Use this comparison when reviewing a proposal or tool report. On a small screen, scroll the table horizontally. The definitions are a discussion aid; the applicable manufacturer documentation governs each device.
| Term | Meaning in this guide | Question to resolve |
|---|---|---|
| IC unlock / IC crack | Overlapping labels for an authorized recovery enquiry | Which actual deliverable counts as success? |
| Read protection | Restrictions on access to specified memory | Which regions and access paths are affected? |
| Debug restriction | Limits on debugging-interface capabilities | What is observable without changing the device? |
| Flash encryption | Cryptographic protection of configured stored contents | Would acquired bytes be plaintext or ciphertext? |
| Secure boot | Verification governing whether software may execute | What authorized image can the target accept? |
| OTP / eFuse | One-time-programmable storage or configuration, where documented | Which state changes are irreversible? |
| Firmware recovery | Obtaining the agreed program data with a documented scope | Is the result complete enough for the intended use? |
| Functional validation | Testing specified behavior on an agreed setup | Which functions passed, failed or remain untested? |
6. Questions to resolve before proceeding
Does IC crack mean a different service from IC unlock?
The wording alone does not establish a different method or result. Ask for the exact device, preservation requirements, proposed assessment scope and deliverables. Compare those details rather than choosing a service by its label.
Does a blocked debugger prove the firmware is encrypted?
No. An access restriction and encrypted storage are different mechanisms. A failed connection alone does not identify either mechanism reliably. Preserve the error report and establish the device and board condition before drawing conclusions.
Can the same firmware file be used on another chip?
Not automatically. Compatibility can depend on the exact device, memory map, configuration, calibration, identity checks and boot policy. A programmed sample must be assessed against the intended equipment requirements, not just a successful programmer message.
What if preserving the only working sample is essential?
State that before any assessment. Agree which observations are permitted and where work must stop for review. Keeping a package physically intact does not itself guarantee data preservation; a software operation can still alter contents.
For a broader PCB copy and replacement project, identify firmware and configuration dependencies alongside board files and components. Send the complete chip marking, board context, sample condition and preservation requirements so the feasibility discussion addresses the result you actually need.
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