Secured MCU Breaker Experts!

Posts Tagged ‘chip source program recovery’

A disassembly is a description of bytes. A project is a set of inputs that produces those bytes. The gap between them is where most software-level recoveries quietly fail, because a listing can be delivered in a week and a project can take a month, and the customer cannot tell which one they received until they try to change something.

The proof that a project is real is simple and unforgiving: rebuild it and compare the output against the original image. If the bytes match, the reconstruction is not an approximation, it is an equivalent. If they do not, the difference tells you exactly what is still missing.

R5F562T6BDFF#V1 is an RX62T group part — thirty-two-bit core with a single-precision FPU, two twelve-bit converter units, motor-control timer set. The version suffix after the hash identifies a shipping configuration, so nothing about the software work depends on it.

Four things a project needs

Every row is the same shape: the image answers what, and the project needs how.

The startup code is the most tractable. On this architecture it runs from the reset vector, sets up the stack pointer, initialises memory, configures the clock, and branches to main. Because it is the first code executed, it is also the best-preserved region of any image — nothing has overwritten it and nothing has optimised it away.

The linker script is the most informative. It describes the memory map the design assumed: where code goes, where constants go, where the stack lives, how large the heap is if there is one. On a recovered design it is reconstructed from the section boundaries in the image, and those boundaries are visible as abrupt changes in content.

Reconstructing the startup path

Start at the reset vector at the top of the map, follow the branch, and read forward until the first branch to an address that is called from nowhere else. That region is the startup code, and its structure is highly stereotyped.

Four stages appear in order on almost every design: stack and memory setup, clock configuration, peripheral configuration that must precede main, and the call to main. The clock configuration is the one that reveals the most, because it names the oscillator source the board provides and the frequency the PLL produces. On a part with two on-chip oscillators, an external crystal input and a sub-clock input, there are several legal combinations and the code states which one it expects.

That single sequence is worth extracting carefully, because it is the only place in the image where the design’s clock is written down.

The linker script is a description of the design

Section boundaries are visible in a recovered image as changes in the character of the bytes: code disassembles and has structure, constant tables look like regular data, strings are readable, and erased space is uniform.

Mapping those boundaries back into a linker script is mechanical once they are identified, and the result is genuinely useful to a customer, because it documents how the original project was organised. A design with a large constant table at a fixed address had a reason for putting it there, and the reason is usually a bootloader, a second-stage loader or a shared-memory protocol with another processor on the board.

That last case is worth flagging: a design with a shared memory region is a design where the recovered image is not the whole system.

The rebuild test

The test that turns an opinion into a fact has three steps.

Compile the reconstruction with a toolchain that can target this core, using an optimisation level that the code’s structure suggests. Link against the reconstructed script. Then compare the output against the original image, not by eye but by diff, and localise every mismatch.

Three outcomes are possible and each is informative. An exact match proves equivalence and ends the argument. A match with a handful of differences localises to specific constructs — usually an inline assembly block, a library routine the compiler generated differently, or a literal pool the linker placed at a different address. And a mismatch everywhere means the toolchain or the optimisation level is wrong, which is a setting problem rather than a reconstruction problem.

That third outcome is the most common first result and it is the reason this work is quoted by the week rather than by the file.

Where the process stalls

Four things stop a faithful rebuild, and they are worth naming because they are what makes an honest quotation possible.

The compiler version. Different versions of the same compiler emit different code for the same source, especially around loop optimisation and floating-point sequences. Without the original version, an exact match may be impossible and the deliverable becomes behaviourally equivalent rather than byte-identical.

The optimisation level. Related and equally invisible. The structure of the code usually reveals it — heavily unrolled loops and aggressive scheduling suggest a high level, straightforward code suggests none.

Inline assembly. A hand-written block has no source-level equivalent, and it has to be reproduced as-is. It is identifiable because it does not look like compiler output.

And library routines. A called routine that appears in many recovered images is usually a library, and it should be linked rather than reconstructed. Reconstructing it is wasted effort and it will not match anyway.

For the disassembly that precedes all of this, R5F562T7BDFF code covers boundaries and literal pools. For the clock statement the project has to carry, R5F562T6DDFF program recovery deals with timing. And for what a software-level engagement contains at the other end of the size range, R5F562T6ADFK software sets out the scope question.

FAQ

How can a rebuild be byte-identical without the original source? Because the compiler is a deterministic function of source, flags and version. Reproduce the inputs and the output follows, provided the source is behaviourally identical in the places the compiler can observe.

Does a byte-identical rebuild prove the source is the original? No. It proves the reconstruction produces the same machine code, which for maintenance purposes is the property that matters.

Is a behavioural match good enough? Usually, if it is stated. The difference matters when the customer needs to compare against a known-good image for regulatory or diagnostic reasons.

The short version

Four artefacts separate a listing from a project: startup code, linker script, section placement and vector definitions. Reconstruct them, then prove the reconstruction by rebuilding and diffing. Say in advance which outcome you can guarantee — byte-identical or behaviourally equivalent — because the difference is a week of work and the customer cannot see it from the outside.