Secured MCU Breaker Experts!

Posts Tagged ‘ic locked eeprom breaking’

The first question after a read is almost never “what does the code do”. It is “which one is this”. A customer with twelve units in the field, three hardware revisions and four firmware releases needs to know which combination is in their hand before anything else in the delivery matters, because the answer decides whether they are looking at a known defect or an unknown one.

That answer is usually sitting in the image as plain text. Products embed version strings for their own support reasons — a boot banner, a service-menu display, a diagnostic response — and those strings survive compilation intact. Extracting one takes minutes and it changes the value of the whole engagement.

The part is R5F562T7ADFF#V1: RX62T group, thirty-two-bit core with an FPU, two twelve-bit converter units and the motor-control timer set. Note that the version suffix on the order code identifies a shipping configuration and has nothing to do with the firmware revision. Confusing the two is a common and expensive mistake at the quotation stage.

Four places a version hides

The first two are the ones worth searching for first, because a text search needs no addresses, no endianness and no architecture knowledge.

Searching a binary for text

A flat binary has no structure, and that is an advantage here: scan for runs of printable ASCII of length six or more, and read what comes out.

Three patterns repay the effort. A version string in the form word-major-minor, often preceded by a product name. A date in one of the compiler’s formats, which is frequently the build date and is the most decisive single identifier because it orders revisions absolutely. And a compiler identification string, which is less useful for the customer and extremely useful for the rebuild work that may follow.

The scan finds noise as well: error message text, unit names, protocol keywords. Sorting the candidates by whether they contain a digit and a separator character, and by their position near the start of the image, reduces a few hundred hits to a handful.

When there is no string

Four fallbacks, in order of effort.

The reset path. Some designs compare a stored value against a computed one at startup and branch to a fault handler; the constant used in that comparison is often a build identifier, and the comparison itself is a strong enough landmark to find.

The table layout. Different revisions place constant tables at slightly different addresses, because tables grow. The base address of the largest table is therefore a rough revision indicator, useful for distinguishing two known revisions and useless in general.

The code structure. A revision that fixed a bug has one function that is slightly larger or slightly different from its predecessor. Comparing two recovered images function by function localises the difference and identifies both.

And the customer’s own records. A serial number in the option area or in an ID location, matched against a production database, identifies the revision without any analysis at all — which is why asking for the serial number early is worth the email.

Why this matters more than the part number

The part number identifies the silicon. The customer already knows the silicon; they have the board. What they do not know is which firmware build is on it, because the label on the enclosure refers to the product, not to the code, and the code has been updated in the field more often than the label has.

A delivery that states the revision up front is a delivery the customer can act on immediately. One that states only the model and the array length forces them to compare images themselves, which is exactly the work they were trying to avoid.

Putting it in the report

One line, at the top, before any technical content: the product revision identified, the evidence used, and the confidence. Where the identification rests on a string, say so and quote it. Where it rests on a comparison against a reference image the customer supplied, say that instead, because the confidence is different.

Then the second line: what the image does not tell you. A version string identifies a build, not a configuration; the same build can run with different parameter sets, and the parameters live in the data region rather than in the code.

For where the data region sits, R5F562T7ADFF EEPROM covers the location markers. For the flat-file properties that make this search necessary, R5F562T6BDFF binary deals with base and length. And for the order-code suffix that is so often mistaken for a firmware revision, R5F562T7DDFF code sets the record straight.

FAQ

Is the version string always in plain text? No. Designs that compress their strings or strip them for size have none, and then the identification is a comparison exercise.

Can a version string be wrong? It can be stale, if somebody updated the code without updating the constant. That is rare and it is detectable when the string disagrees with the code structure.

Does the order code tell you the firmware revision? No. It identifies the device and its shipping configuration. The firmware revision is a property of what was programmed into it.

The short version

Before analysing what the code does, establish which code it is. Scan for printable strings, keep the ones with digits and separators, and look for a build date — that single line answers the customer’s real question and it is the cheapest useful output of a whole recovery. Then say what the string does not cover, so nobody assumes a build identifier is a configuration identifier.