A water-quality analyser maker asked us to crack the protected flash binary of its discontinued instrument, built on the PIC24FJ256GA106: 256 KB of program flash, 16 KB of SRAM, 64-pin package, up to 16 MIPS. At a quarter of a megabyte, the array spans three logical regions in any serious instrument: a bootloader, an application, and a parameter block the factory writes during calibration. The recovery story at this size is as much about mapping those regions as about defeating any protection.

The configuration-word read and what it decided

The two-wire ICSP entry is possible at every security level this family implements, and the configuration words are readable first in all of them. FBS reported boot segment security at the standard mode, so the boot segment would read as zeros while the general segment stayed open. FGS carried general write protection only, which as ever in this family blocks writes and not reads. The practical consequence: roughly 252 KB of the array was directly readable, and the protected region was the small bootloader at the bottom. Our flash-content extraction service description covers this class of fully-verifiable readout.

Mapping a 256 KB instrument image

The readable region disassembled into the analyser’s measurement engine, the reagent-sequencing logic and a communication stack for the lab interface. The parameter block, written during factory calibration, sat near the top and held sensor coefficients the customer most needed, because recalibration fixtures were long gone. Locating it was a data-region exercise: access patterns in the disassembly marked the boundary, and the recovered coefficients matched the instrument’s measured response curves within tolerance, which is the empirical test that turns a guess into a finding. The same data-region method organises the a 128 KB RL78/G13 case and the an STM32F413VHT6 classification work.

Row-level integrity across a large image

The family programs flash in rows of 64 instruction words, and at 256 KB the image spans over a thousand of them. Our verification checked contiguity row by row rather than trusting a single end-of-image checksum, because interrupted field updates leave damage at exactly those boundaries. Two units showed such scars from a failed update years back; the damaged rows were rebuilt from a sister unit’s image, and the provenance table recorded the substitution. Endurance figures of 10,000 cycles per location framed how much rewriting the calibration block could safely accept going forward.

The boot segment reconstruction

The protected bootloader verified application images before handover. Its logic was re-derived through the observation-matrix method, feeding varied images and logging accept and reject decisions until the checksum rules were pinned down, then validated by crafting a synthetic image the original boot accepted and executed. Two bench sessions sufficed. The same standard of evidence is described in the reverse engineering a chip workflow, and comparable boot reconstructions appear in the an STM32F407ZET6 clone and an RL78 locked behind its serial ID notes.

Delivery

The package contained the verified general-segment binary, the decoded calibration block with field-level annotations, the reconstructed boot logic, and a provenance statement separating read bytes from re-derived behaviour and substituted rows. A reflashed analyser passed the manufacturer’s full verification sequence. For a {x-p7} design in this security mode, the honest sequence is fixed and short: configuration words, full readout, data-region mapping, then the boot decision, and the binary recovery service page explains how each stage is quoted separately.

The reagent sequencer’s timing evidence

The analyser’s reagent-sequencing logic carried hard timing parameters the customer had lost with their source: pump pre-run delays, valve settle times, and a photometer integration window. The recovered disassembly stated them as constants, and the bench validated them by running the analyser’s own calibration routine against a reference photometer, where the measured settle behaviour matched the constant within measurement error. Constants read from flash and confirmed by physics are the strongest form of recovery evidence there is, and the validated parameter set went into the delivery as a configuration file rather than as annotated code, because the customer’s next iteration would retune them directly.

Calibration block wear and the rewrite plan

The parameter block’s wear map showed why the vendor’s calibration tools behaved the way they did: every factory recalibration rewrote the whole block, and heavily serviced analysers approached the endurance rating at those locations. The delivered plan relocated the block to fresh rows and halved the rewrite frequency by making the firmware patch single fields instead of erasing the region. Neither change would have been justified without the wear evidence, and both extend the fleet’s life materially. Endurance arithmetic is unglamorous, but on self-programming families it is the difference between a recovery that restores operation and one that schedules the next failure.