One nibble: when 0xC4 stopped looking like broken Ford
4 August 2026 is the day a complete, clean backup download stopped being a
fantasy. For months we treated lead byte 0x04 as the sacred
marker of “this host is Ford / this slice is decryptable.” Force paths scanned for
0x04; anything else was discarded or forced through Ford open checks that
could not succeed.
The fulcrum was absurdly small: many data ChunkInfo bodies do not start with
0x04 at all. They start with values such as 0xC4
(yes—a C where we insisted on a 0). Those slices are still
valid ciphertext for the chunk pipeline; they are simply not Ford CT. Once the
classifier stopped requiring lead-0x04 for data gates—and kept
0x04 as the typical Ford CT marker—the remaining thousands of files fell
into place. Side-by-side with commercial tools, reconstructions covered nearly the whole
inventory; the gap had been a nibble, not a missing Apple API.
Completeness still has honest ceilings. Some small files are removed from CloudKit by Apple or third-party developers: the backup inventory may still name them, but there is no longer an MMCS record / authorizeGet asset to fetch—you cannot invent edge bytes that the account no longer holds. Separately, a few payloads (notably some Mozilla translation / on-device AI model style files we hit in testing) are encrypted under schemes that are not the Apple Ford/MMCS path we reverse-engineered. Those remain opaque without a different oracle; calling that a “failed MMCS decrypt” would be a lie.
So August unlocked a protocol-complete Apple backup download for the material that still lives on MMCS—not a claim that every historical filename on earth is recoverable.
← All notes