Claude (auto-RE)
882dbc2ae2
Made a second save in-game (READY ROOM -> SYSTEM -> SAVE GAME -> empty slot) so the format had a differential to read against. nav_probe.sh drives it: boot to the READY ROOM, walk a scripted step list, screenshot after every step and stamp every save file's md5, so the trail says which keypress wrote a save. That stamp is what caught the first attempt failing -- the save confirm starts on YES, unlike the load confirm which starts on NO, so the load flow's extra up-press selected NO and wrote nothing. Result 1: saving the same loaded state into a new slot produces a BYTE-IDENTICAL 545-byte payload. Only the GDHA header moves, and every byte that moves is either the container FILETIME or one of the guest-pointer words -- which empirically confirms those words are uninitialised padding rather than data. So the payload holds no timestamp, no slot number and no name; a save's identity is entirely in its content header. Result 2: the LOAD/SAVE screen's Details panel prints Points 4101 P, Flight Time 000:05:24 and Clear Ratio 5 % for exactly this state, which names GHAD +24 (Points), +4 (flight time in ms -- 324773 ms = 5m24.773s) and +8 (clear ratio %). Difficulty EASY and STAGE 02 both being 2, and three fields holding 2, is left undecided on purpose: one save cannot separate them. Result 3: the 16 SHAB records are not the UI's save slots. The UI has 20, slots are separate gameNN files, and record 0's FILETIME stayed at 2026-07-23 in a save written on 2026-08-11 -- so the table is part of the game state, most likely a per-stage result record (one stage finished, one record filled), which the next cleared stage will falsify or confirm. The original save was backed up first and is untouched; the new save went to an empty slot.
2.9 KiB
Executable File
2.9 KiB
Executable File