Ford vs ChunkInfo: forcing the plan, then learning to wait
With an IKM in hand, 10 July 2026 was about reading the AuthorizeGet / FileGroup plan the way backupd does: some edge hosts are Ford material (key blobs), others are ChunkInfo-addressed data slices (offset/length + checksum21). Refs in the group say which chunk belongs to which logical file. Confuse the two and you decrypt the wrong species of bytes with perfect confidence.
The first instinct was to force the obstacle—guess windows, re-slice
hosts, plant every lead-0x04 candidate into the map, try geometric demux when
Auth offsets lied. Those paths burned weeks. They sometimes opened a file; they also
poisoned caches with Ford-shaped prefixes sitting where data should be, so later
retries failed even worse.
The structural fix was humbler: treat MMCS like a store that can deliver
chunk data after you already saw the Ford gate. We introduced
caching keyed by checksum21 (on-disk .chunks/ style maps) so a
FillChunks pass can bind Ford keys first, then attach data when the matching body finally
lands—exactly the order live captures showed, and the opposite of “one GET must
finish the file.”
By midsummer the pipeline shape was clear (Pipe A Ford inject, Pipe B data fill, optional Pipe C chunkEncryptionKey). Completeness was still not. That fight continues into August, when a single lead byte finally explained the stubborn tail.
← All notes