Delta Firmware Updates: Prove the Installed Base Before Applying a Patch

Authorize a delta only after verifying the exact base bytes that its patch algorithm expects. A matching release label is insufficient if the device’s image was modified, personalized or rebuilt. After reconstruction, verify the expected output identity before treating the result as an installable candidate.

This article uses librsync/rdiff 2.3.4 as a concrete patch-mechanism example and RFC 9124 for the precursor-digest concept. It defines an original updater qualification procedure. No patching, library execution, flash write or boot test was performed.

1. Name all three byte objects

A delta workflow has a basis, a delta artifact and a reconstructed result. Give each a precise identity and byte scope. “Version 4 to version 5” leaves unanswered whether the inputs are compressed files, raw partition images, extracted contents or normalized application data.

Object	Required contract	Common mistake
Expected basis.	Component, exact length, representation and digest.	Accepting a displayed version string.
Delta artifact.	Authorized format, algorithm, length and digest.	Assuming any file called a patch is compatible.
Expected result.	Complete reconstructed length and digest, plus normal image policy.	Treating decoder completion as image acceptance.

Keep the trusted relationship among these objects in the product’s authenticated update metadata. A digest supplied by the same untrusted source as an arbitrary patch is not sufficient authorization.

RFC 9124 section 3.5 describes a precursor image digest condition for content that must already be present, including differential updates. It is an optional information-model element, not evidence that every deployed updater checks a base automatically.

2. Inspect the selected patch implementation

The rdiff 2.3.4 documentation describes deltas as insert/copy instructions over a basis byte stream. It explicitly warns that applying a delta to the wrong basis is not checked by rdiff and can produce incorrect output. Its block-checksum “signature” is a delta-generation structure, not a publisher’s digital signature.

The pinned librsync v2.3.4 whole-file patch API takes basis, delta and output streams and uses the basis through a copy callback. The updater must supply the surrounding identity and authorization checks. Do not infer them from a successful library return.

This example does not establish the behavior of another delta engine, a vendor fork or a future librsync release. Record the exact decoder version, format options, supported size limits and error paths chosen for the product.

3. Verify the bytes that will actually be read

Determine the basis source from the authoritative component map. The running root filesystem, inactive slot and cached package can contain different bytes even when a dashboard labels them with the same software version. Hash the source the decoder will use, not a convenient neighboring file.

Define how padding and mutable regions are handled. If the delta was generated from a file of a particular length, do not hash an entire larger partition and compare it with that file’s digest. Conversely, do not omit meaningful trailing bytes merely to obtain a match.

Personalized settings inside an image can make each deployed basis differ. Either the product has a specified canonical basis representation or it needs an update method that does not assume the shared bytes. Do not strip fields or reconstruct a guessed “factory image” during admission.

Keep the verified basis stable throughout reconstruction. Use an approved immutable image or snapshot mechanism, and ensure no other writer can change its contents after the digest check. A correct precheck followed by reading changed bytes defeats the applicability gate.

4. Choose delta, full image or hold

Preflight result	Permitted next decision
Exact basis matches; delta and output contract supported.	Eligible for reconstruction under resource limits.
Basis differs, but an authorized full image is available.	Evaluate the full-image path independently.
Basis differs and no approved fallback exists.	Hold; do not try the patch optimistically.
Basis read fails or cannot be held stable.	Hold applicability as unproven.
Decoder reports failure or output identity differs.	Reject the candidate and preserve a diagnosable result.

A full image removes the delta’s exact-basis dependency, but not hardware compatibility, trust, downgrade, persistent-data or recovery requirements. It may also require a different storage and network budget. Select that path through the campaign’s approved policy rather than silently downloading a larger artifact.

Keep base mismatch distinct from corrupt delta, read failure and insufficient capacity. Those reasons imply different corrective actions. Repeating the same delta cannot repair an unchanged wrong basis.

5. Bound reconstruction and verify the result

Reserve a separate disposable output destination with an explicit size bound. The rdiff patch contract requires output separate from the basis and a random-access basis. Do not adapt the example into an in-place overwrite of the only known-good firmware.

Monitor decoder completion, bytes produced and storage errors. Verify the full result against its authenticated expected length and digest, then apply the product’s normal candidate validation. None of these steps alone authorizes boot selection.

Preserve the current working image and irreplaceable data while qualifying the update path. Any target-writing test requires a recoverable development device, approved disposable destinations and verified backups. No destructive formatting or patch commands are provided here.

6. Build the wrong-basis fixture first

1. Create synthetic basis A and target B, then generate the delta through the selected, pinned toolchain.
2. Prove the approved A-to-B case reconstructs the exact target bytes.
3. Modify one basis byte while retaining its release label and length; require rejection before reconstruction.
4. Test a different-length basis, an unreadable basis and a change attempted after verification.
5. Corrupt or truncate the delta and exercise bounded decoder failure.
6. Force output-size or digest mismatch and verify the result never becomes an accepted candidate.
7. Exercise the separately approved full-image fallback without weakening its normal policy.

These are proposed tests. Preserve fixture identities, tool revisions, expected gate outcomes and observations from the actual implementation. Host reconstruction and target installation remain separate evidence stages.

Hypothetical locally modified image

A service patch changes one file inside a supposedly read-only image but leaves its version label unchanged. The next delta targets the original image. The version comparison passes, while the precise basis digest fails.

The updater holds that delta and evaluates an authorized full-image route. It does not accept a decoder’s eventual completion as proof of correctness. The useful release contract ties exact basis, delta and output identities together and states which failures permit fallback.