Why the edited save state was rejected — Structure of checkpoint.dat

Source of grammar: re_probes/runtime_87400/module.bin (running, extracted NewColossus_x64vk.exe, file offset == RVA). Tool: tools/probe_save_structure.py. Corpus: re_probes/save_backups (5 real save states) and the three candidates, all read-only. Writing was done exclusively to re_probes/save_structure/.

Summary

1. The defect is a stale length prefix. Candidates v1 and v2 have extended the card name, but left the preceding u32 length unchanged. At checkpoint.dat offset 0xdf, there stands 17; it should stand 24. In checkpoint_mapstart.dat, this occurs six times (0x14, 0x8d, 0x106: 17 instead of 24; 0x44, 0xbd, 0x136: 14 instead of 21).
2. Second, independent defect in v1/v2: the checksum line in game.details remained at 2007466474; the correct value is 499283768.
3. v3 fixes both. A candidate reconstructed from scratch based on the grammar read from code is byte-identical to v3 in all 14 files. 33 of 33 checks pass green.
4. Not claimed: that v3 loads. "File Corrupt" is not observable offline. The reliable statement is: structurally consistent according to these tests, runtime unconfirmed.
5. Correction on the task: Branch (a) from saveverify.md (Read(rumpf) != length-4 at 0x8b47c4) is a pure short-read test on the file and cannot trigger here — the file delivers exactly Length-4 bytes. The consumption error lies one level deeper, in the component reader. See Section 5.

1. The Grammar — from code, not guessed

Three functions carry everything necessary:

The primitives (calls via serializer vtable):

[vtbl+0x28]  Read(puffer, n)      Raw bytes
[vtbl+0x30]  Write(puffer, n)
[vtbl+0xe8]  Serialize(idStr&)    u32-LE length, then characters, no NUL
[vtbl+0xf0]  SerializeCheck(tag, file, line)   writes/checks exactly such an idStr

Endianness: Integers and floats are big-endian — the reader rotates them after each manual Read(4) (0x11a57d4–0x11a57f1, pattern 0↔3, 1↔2). The length prefixes of idStr are little-endian, they are written without rotation (0x66ab58–0x66ab77). This exact mixture confuses the format at first glance.

checkpoint.dat, header (0x11b99e4–0x11b9e4e)

u32 LE   saveFormatVersion       must be <= 0x444D0005, otherwise FatalError
u32 LE   Subversion              here 0x26
u8       Flag                    must be 1 (0x11b9dee, otherwise FatalError)
u8       Flag
  if Subversion >= 0x26:  idStr, idStr        (Stand ID, SHA1-Hex)
  if Subversion > 0x21:  6 x u32
tag "idGameLocal_CheckpointInfo:10"
<idGameMapMemoryManager::ReadFromFile>
tag "idGameLocal_CheckpointInfo:11"
... from here, opaque component stream

idGameMapMemoryManager::ReadFromFile

tag "idGameMapMemoryManager:10"
u32 BE   Magic  == 0x0060FFCD     otherwise "Invalid Magic Number in idGameMapMemoryManager"
u32 BE   Version
u32 BE   Count of card entries
per entry:
    tag "idGameMapMemoryManager:20"
    idStr    Card name          <== the edited location
    u32 BE   Count of sub-entries
    ... sub-entries (0x30 bytes each; in backup always 0 — unmeasured)
    tag "idGameMapMemoryManager:30"

In the original from SLOT0, this fits perfectly: Tag at 0xb6… Magic 0xb6, Version 0xba, Count 0xbe = 1, Tag :20 at 0xc2, Card name at 0xdf (Length 17, characters 0xe3–0xf3), Sub-count 0xf4 = 0, Tag :30 at 0xf8.

checkpoint_mapstart.dat — complete

This file is tag-free and fully parseable:

4-Byte header, followed by k identical blocks:
  u32 BE  Magic 0x0060FFCD
  u32 BE  Version (3)
  u32 BE  u32 BE
  idStr   Card Name
  idStr   idStr   idStr   idStr        (empty in inventory)
  u32 BE  n   +  n x idStr             Layer
  u32 BE  m   +  m x idStr
  u32 BE  u32 BE  u32 BE  u32 BE
  float BE  float BE  float BE

Block size at SLOT0: 107 bytes, three blocks, 4 + 3*107 = 325 = file size. At SLOT2 it is 451 bytes, also exact. This is the branch where the parser can definitively state how many bytes the reader has consumed.

2. The Defect, Named

The build step replaced game/dlc/c02/c2v1 (17 bytes) with game/dlc/c02/c2v1_custom (24 bytes) and correctly grew the file by 7 bytes — only the u32 preceding it remained at the old value. The 4-byte MD5 folding header was then recalculated, so the file branch (b) of the load path parses without issue. A valid header over an inconsistent body.

What the Reader Does With It

idGameMapMemoryManager::ReadFromFile reads length 17 at 0xdf, takes game/dlc/c02/c2v1, and then becomes _cus…. The next read operation is the BE32 count of sub-entries — it reads the ASCII bytes 5f 63 75 73 as 1 600 353 651. The game subsequently attempts to reserve a list with 1.6 billion elements × 48 bytes (roughly 77 GB). The parser reports exactly this value when v2 is presented:

@0xf0: 1600353651 Sub-entries - Grammar unmeasured

In checkpoint_mapstart.dat it fails even earlier: there, the field behind the card name itself is again an idStr, and the reader retrieves the "length" 1 937 072 991 (_cus as u32 LE).

3. The Test Tool and Its Counter-tests

python tools/probe_save_structure.py parse <file.dat>
python tools/probe_save_structure.py check <folder> [--original <folder>]
python tools/probe_save_structure.py build --source … --target … \
       --alt-map … --new-map … --alt-layer … --new-layer …
python tools/probe_save_structure.py --selftest

The self-test is constructed so that it can fail:

• Positive: all 5 unchanged game states from re_probes/save_backups are accepted; checkpoint_mapstart.dat consumes exactly the file length there (325 or 4×451).
• Negative, real: v1 and v2 are rejected with the specific location in the message. This is the exact counter-test requested by the order — if the tester accepts both, it measures nothing.
• Negative, synthetic:
  1. Card name extended, prefix stale, header recalculated → header is valid (branch (b) notices nothing), structure parse fails.
  2. a flipped byte → header fails.
  3. an inserted null byte before the tag :30 → tag comparison fails.
  4. Identity renaming (same name) → byte-identical file.

Result: 0 errors, Exit code 0.

During renaming, the parser accesses the idStr fields at their parsed offsets and writes prefix and characters together. The defect of v1/v2 is thus constructively excluded, not just checked retroactively.

4. The Corrected Candidate

re_probes/save_structure/FC2-WOLF0-c2v1_custom_struct, built from re_probes/save_backups/SLOT0_before_c2custom. 33 tests, all green:

It is byte-for-byte identical to candidate v3 of the other Masters in all 14 files. This is an independent confirmation: v3 was created via framed text replacement, while this one was created via the grammar read from disassembly — two paths leading to the same result.

Regarding the Unparsed Remainder of checkpoint.dat

Of the 476,231 bytes parsed by the tool, 317 are consumed and 475,914 remain unparsed; the grammar of the component stream behind it (1,036 length-prefixed strings, 577 idQuickSaveStream tags with Magic 0x3832E21A, Havok Cloth blocks) is not measured. Instead of an excuse, there is a test: the remainder is byte-for-byte identical to that of the original, and the parser proves that the reader arrives at exactly the same position there (317 instead of 310, i.e., exactly +7). The original loads successfully. Therefore, the remainder does not need its own grammar.

5. What Has Been Refuted

• "Branch (a) at 0x8b47c4 is the trigger." No. That location only checks whether Read(rumpf) provides as many bytes as Length()-4 — a short read test on the file. The candidate provides exactly Length-4. That location cannot fire here. The consumption error sits one level deeper, in idGameMapMemoryManager::ReadFromFile, which can set its own error code at [stream+0x184] or via [vtbl+0xe0] — a path that the scan after mov dword [r15+0x270], 4 does not see. The direction of the instruction ("the deserializer consumes a different number of bytes than the file provides") was correct, only the specific code location was wrong.
• "Somewhere there is still an old total length / an offset table." No. In checkpoint.dat, no u32 and no u64 exist at any position, neither LE nor BE, holding the value of the file or buffer length (476,224 / 476,220, old or new) — 0 hits. The 52 values in the range 470,000–480,000 are, except for ten outliers, a monotonically increasing float series at 0x5d5c5, and the file end (last 256 bytes) consists of Havok floats, not a table. The block grammar of the map storage has no size field — the length of the name stands exactly once, in its own prefix.
• "The map name is additionally stored as a hash in the file." No. Checked against game/dlc/c02/c2v1: CRC32, Adler32, FNV-1a 32/64, idStr-Hash, MD5/SHA-1/SHA-256 (first 4 or 8 bytes respectively), each LE and BE. 0 hits in checkpoint.dat. For checkpoint_mapstart.dat, the question becomes moot: there every byte is covered by the grammar.
• "All map names in a savegame must be identical." No — measured at SLOT2: the map storage in checkpoint.dat regularly also carries the previous map (game/wolf/c01/c01p1 next to game/wolf/c02/c02p0), and GAME-TRANSITION even has three mapstart blocks with two different maps. Such a consistency check would be incorrect; instead, the tool compares against the original plus renaming.
• .verify remains untouched — confirmed by saveverify.md, here only rechecked to ensure the files were byte-identically copied over.

6. Open

• Runtime Proof. Whether the game FC2-WOLF0-c2v1_custom_struct (= v3) accepts is undecidable offline. To determine this, one would need to save the state in %USERPROFILE%\Saved Games and launch the game — both of which are excluded here. Before attempting such a test: the backups under re_probes/save_backups/ are the only copies of the real states.
• Sub-entries in the Card Storage. The branch with Anzahl > 0 (elements at 0x30 bytes) does not exist in the entire inventory; the parser explicitly rejects it rather than guessing.
• Component Stream from Byte ~0x2142. idQuickSaveStream with Magic 0x3832E21A before each day, non-fatal tag comparison (idQuickSaveStream::SerializeCheck: tag mismatch: is: %s, should be %s, 0x66aa60) and compressed heap sections. Excessive — whoever intends to modify munitions or upgrades there must start here.