4142438ae8
Ported onto the shared harness, the HUD changed from 4 to 8 and the intersection collapsed in a single step: one u32be survivor at 0xbdb59668, with the u16be and u8 hits at 0xbdb5966a and 0xbdb5966b being the low half and low byte of that same word. Verified live rather than asserted. Reading screenshot and memory together three times, the one legible HUD frame showed 012 against mem@0xbdb59668 = 12; the other two frames were unreadable rather than mismatched. This independently rediscovers the address the earliest sessions found by digit-transition hunting, by a completely different method. It also corrects an earlier conclusion. A previous run intersected HUD readings of 4 and then 11, got zero survivors in every encoding, and that was written up as eliminating big-endian u32 for the whole region. This run shows u32be holds the counter, so the refutation was wrong. The likely cause is the input: ob_digits.png has templates for 0 1 2 4 8 only, so values containing other digits are misread rather than rejected, and "11" was probably one of those. A single bad reading poisons an intersection permanently, because it removes the true address and nothing later can restore it. The lesson is that an intersection method needs individually verifiable inputs -- the reader's confidence scores were printed but never gated on. One observation reopens the arrival question in a useful way: the counter increases, 4 then 8 then 12 across about five minutes, measured in memory so not a digit misread. A count of remaining marked targets that rises means targets are being added during the mission. That does not contradict the deployment finding, since the roster is fixed at load, but it does mean the game marks new objective targets as the mission proceeds. Watching this one address across a whole mission is now the obvious next experiment and costs almost nothing.
850 B
Executable File
850 B
Executable File