There are two different identifiers on this part and they are routinely confused. One is a protection mechanism that gates a debug session. The other is a factory-burned value that identifies the individual device. Neither is secret, and one of them has consequences that survive long after a recovery succeeds.

The second one is the subject here, because it is the reason a perfectly good image can fail on a perfectly good replacement part.

Two identifiers, two purposes

The first is a door policy. The second is a serial number. Confusing them leads to a specific and expensive mistake: assuming that a part whose identifier reads back normally has no protection, or that a part whose protection is clear has no identifier.

How firmware uses the unique value

Three patterns account for almost all uses, and they have very different consequences.

Binding. A key or a licence is encrypted using the identifier, so that the encrypted blob only decrypts on that device. The product cannot be cloned by copying the flash.

Derivation. A per-device key is computed from the identifier and a fixed secret in the code, and then used to encrypt the device’s own data. Nothing is stored that could be copied usefully.

Audit. The identifier is reported over a serial port or stored alongside production records, so that a unit can be traced. This is the harmless case and by far the most common.

The second row is the one that surprises people. Nothing in the image looks bound to anything, the code runs, and the data it reads back is nonsense — because the key it derived from its own identifier is not the key the data was written with.

The AES block, and what its presence implies

The part has hardware for block cipher operations, which is why designs of this class can afford encryption at all: a software implementation on a core without a floating-point unit would dominate the cycle budget.

Two things about its use are visible in an image. The first is the key schedule: a sequence of table lookups and byte manipulations that runs once per key and produces a round-key array in RAM. That array is large enough to be obvious, and its size states whether the design uses 128-bit or 256-bit keys.

The second is what happens immediately before the cipher is invoked. Where the key is a constant from flash, the code loads it and calls the block. Where the key is derived, the code reads the identifier first, mixes it with something, and then schedules. That read-modify-schedule sequence is the fingerprint of a bound design.

The random number generator is a third case

A hardware generator for random values is present as well, and its use is usually easier to spot than encryption because the pattern is smaller: a request, a wait for a valid result, a read.

What makes it worth mentioning in a recovery context is a failure mode. A design that seeds something from the generator and then relies on the seed being unpredictable is only as good as the generator’s health. Where the health check bits are being polled, the code that handles a failure is visible, and it is frequently a loop with no timeout — which means a device with a failing generator hangs in initialisation, and looks dead.

What happens when an image moves

This is the practical core. An image recovered from a bound device and written to a replacement produces one of three outcomes:

1. It runs and reports an authentication failure, because the blob it holds does not decrypt under the new identifier.
2. It runs and produces garbage data, because it derived a key that does not match the one used when the data was written.
3. It runs normally, because the identifier was only ever used for audit.

Only the third case is a successful migration, and it cannot be distinguished from the other two without reading the code. That is what makes this worth a section in a recovery report rather than a footnote.

Reading the identity path

1. Find reads from the fixed address range where the identifier lives. They are plain loads and they cluster.
2. Follow what happens to the loaded value: mixed into a key, stored for reporting, or compared against something.
3. Look for a block cipher key schedule nearby. Its presence confirms binding or derivation.
4. Find the random generator access and check whether its failure path has a timeout.
5. Note in the report which of the three patterns applies.

Steps one and two take an hour and they answer the only question that matters before a replacement is attempted.

What the deliverable contains

The return set is the code flash image, the data flash separately, the configuration words, both identifiers as read, a disassembly with the identifier access annotated, and a statement of whether the firmware binds itself to the device.

That statement is the item that prevents a customer from spending money on a replacement that cannot work without a companion procedure.

The protection identifier, which is a different mechanism with a different failure, is covered in R7FA2L1AB2DFN locked program recovery. The clock configuration that the crypto blocks depend on is in R7FA2L1A93CNE binary recovery, and the supply range that constrains operation at the extremes in R7FA2L1A92DFM program recovery.

FAQ

Is the unique identifier a security feature? It is a serial number. Security comes from what the firmware does with it.

Can the identifier be changed? No. It is burned at test and is read-only.

Will a recovered image always work on a new part? Only where the identifier was used for reporting. Where it feeds a key, the image is device-specific by construction.

Conclusion

A 128-bit value burned at test turns a generic microcontroller into a specific one, and firmware is free to depend on that. Where it does, the image is not portable and no amount of correct reading changes that. Establishing which of the three patterns applies is a half-hour job that decides whether a replacement is a repair or a redesign.

Comments are closed.