A fitness-equipment maker asked us to replicate the secured firmware of its console design, built on the PIC24FJ256GA108: 256 KB of program flash, 16 KB of SRAM, and the 80-pin package of the GA1 generation, running at up to 16 MIPS. Replication for this customer meant more than a byte copy: the console pairs with a handlebar assembly whose touch calibration lives in flash, and a replica that boots but miscalibrates the touch sensing is a warranty event, not a recovery.

Configuration words first, as always

The two-wire ICSP session opened with the configuration-word read. FBS showed boot segment security at the stronger mode: both boot and general segments would return zeros through ICSP. This is the strongest guard the family implements, and it moved the whole job into reconstruction territory, with one important exception: the console’s own self-programming infrastructure remained active, because the family supports reprogramming its flash under software control and the maker’s field-update path depended on it.

The update path as the honest channel

The field-update path accepted signed images over the service UART and wrote them row by row, 64 instruction words at a time. We exercised it with the maker’s authorisation, instrumenting the verification stage to learn what the boot code checked and how the touch-calibration block was laid down during factory provisioning. Controlled, logged experiments through a legitimate channel are the cleanest route a stronger-mode part allows, and the technique is the same one our boot-mode access on an RX24T note applies to boot-serial surfaces on Renesas silicon. The touch block’s write pattern fell out of the logs directly, which meant the calibration data could be preserved per unit rather than copied globally.

Preserving per-unit calibration

Touch calibration was the commercially decisive region: each console’s sensors had drifted individually over years of gym use, and a fleet-wide image would have overwritten every unit with one calibration set. The update-path instrumentation let us read each console’s calibration block through the firmware’s own routines before any rewrite, store it separately, and re-provision it after the replicated image was installed. The CTMU touch module’s behaviour confirmed the restored blocks: sensor baselines returned to their per-unit values rather than the factory averages. Per-unit state alongside code is a recurring theme in our reports, from the partial program-data recovery on an RX62T note to the an STM32F407ZET6 clone backup-domain discussion.

Verification and the replica decision

Acceptance ran on four consoles: replicated firmware, restored per-unit calibration, and the maker’s full console self-test including touch-linearity checks across the handlebar range. All four passed. The delivered package included the replicated image, the per-unit calibration archive, the reconstructed boot-verification logic with its evidence, and a recommendation to move the stronger security mode down to the standard one in future builds, since it had protected nothing the update path could not legitimately reach. For {x-p8} hardware the planning question is exactly that: what does the security mode actually guard, and what does the design’s own infrastructure expose? The the MCU reverse-engineering workflow and recovering data from a secured part pages describe how we scope that answer before quoting.

Signature verification in the boot region

The update path’s signature check, hidden in the blacked-out boot region, was the job’s central reconstruction target. The observation matrix over malformed images revealed its structure: a fixed-format header, a truncated hash over the payload, and a comparison table that turned out to hold public-key material the maker still possessed. With the key in hand, the verification was reproduced offline, and every behaviour the matrix had observed was explained by exactly one implementation candidate. Reconstruction that terminates in a mechanism the customer can re-derive independently is the standard we hold this class of work to, and the maker’s new update tooling now verifies signatures with the same rules the original boot enforced.

Touch-linearity acceptance in detail

The console’s touch acceptance test deserved its own rig: a mechanical carriage swept the handlebar’s sensor strip while the console reported raw CTMU readings, and linearity was computed per unit against the restored calibration. Four consoles passed on first run, which the calibration-preservation step deserved, and the rig stayed with the customer as a production test asset. Building acceptance equipment is not normally part of a recovery engagement, but replication work without a measurement instrument is assertion, and the maker’s quality team adopted the rig’s reporting format for their line tests. The marginal cost was a day of bench time; the alternative was shipping replicas on faith.