Secured MCU Breaker Experts!

Posts Tagged ‘open locked microcontroller firmware’

Ask for a device to be “opened” and you will get one of two answers depending on who is listening. Someone who works with older microcontrollers will assume you mean “make the contents readable”. Someone who works with ARM parts will assume you mean “remove the protection”, which on this silicon is a different thing entirely.

The difference is not pedantic. One operation returns data. The other returns a blank chip, by design, and the design is deliberate: the protection is removed by removing what it protected.

The sequence, and the erase hidden inside it

Removing level one protection is done by writing the option byte that encodes the protection level back to the unprotected value, then triggering a reload of the option bytes so the new value takes effect.

The reload is the moment everything happens. When the device reloads a protection change from protected to unprotected, it first performs a mass erase of the main flash. Then it applies the new option value and resets.

So the answer to “can you open it without losing the program” is no, and it is not a limitation of tools or skill. It is the mechanism doing its job.

What is actually lost

The mass erase covers the main flash array. It does not touch everything:

• The unique identifier survives, which is why the part can still be identified afterwards.
• The factory calibration values survive.
• The option bytes are, obviously, changed.
• External components are untouched.

What is lost is the program and anything stored in flash — including an emulated non-volatile store, which is usually where the production data lived. On a device that has been in service, the configurational data is frequently more valuable than the code, and it goes with everything else.

The interruption risk

The regression involves an erase that takes time, and a supply that fails partway through leaves the device in a state nobody designed for. Three outcomes are possible and only one is convenient:

The erase completed and the option byte was written. The device is open and blank, which is what was asked for.

The option byte was written but the erase did not complete. Rare, and the worst case: the device reports a protection state that does not match its contents, and recovering from it may require repeating the procedure.

Nothing happened. The safest failure. The device is still protected, still holds its program, and the procedure can be repeated.

The practical defence is boring: a supply that will not sag, a tool that waits for the operation to finish rather than timing out, and no other activity on the board during the sequence.

Level two is a different category

At the highest protection level the debug interface is disabled at the silicon level and the option bytes cannot be modified. There is no regression, no erase, no documented recovery. The part still runs; it simply cannot be investigated through any standard interface.

This matters for quoting work, because a level two device is not a harder version of a level one device. It is a device for which the software route does not exist, and any plan that assumes otherwise will fail at the first step.

When opening is the right call

Four situations justify it, and each has the same shape: the contents have no value.

The program is already captured. The array has been read, the read verified, the file delivered. Opening the device afterwards is housekeeping, and it may be required if the part is being handed back and the customer wants a known protection state.

The device is being repurposed. A part recovered from a failed board, being prepared for a legitimate new image.

The firmware is available from another source. A second unit of the same product, or the customer’s own archive, means the contents are not unique.

The customer asked, in writing, knowing the consequence. Not “the customer wants it unlocked” as an assumption, but an explicit instruction with the erasure stated.

Everything else calls for reading first, and for the non-destructive options — including the physical ones — before any destructive one.

The conversation that prevents an argument

The single most useful sentence in this work is short: “opening it will erase it”. Said before the operation, it produces a decision. Said after, it produces a dispute.

Along with it, three facts the owner needs:

• What is on the device, as far as can be determined without reading it.
• What will be lost, in terms of their product rather than in terms of bytes.
• What the alternatives are, and what each costs.

That is a two-minute conversation and it converts a technical operation into an informed decision, which is the only kind that should be executed.

Recording the outcome

Whatever the device’s state after the work, write it down: the protection level before, the operations performed, the level after, and whether the array retains its contents.

A part returned in a different protection state than it arrived in is a change to the customer’s product. Recording it is not bureaucracy; it is the difference between a delivery and a surprise.

Related reading

• STM32G030F6 and what the security bits actually are — the map behind this operation.
• STM32G030K8 and the non-destructive read path — what to do first.
• STM32F030R8 locked bits — the same mechanism on the predecessor family.

FAQ

Can read protection be removed without erasing? No. The erasure is part of the mechanism, not a side effect of a particular tool.

Does the erase clear the unique identifier? No. It survives, which is how the part can be identified after being opened.

Is level two ever reversible? Not by any documented method.

What if the device is already level zero? Then there is nothing to open, and the array can simply be read.

Conclusion

Opening and destroying are the same operation on this part, and the documentation says so plainly. Read first, keep the file somewhere durable, have the consequence agreed before the command is issued, and record the protection state the device was left in.