From 2add603485f44cb7f1d612146da802404cc32cb8 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 23:57:25 +0000 Subject: [PATCH] re: refute the "counter sits at page offset 0x9668" prediction The file proposed that the counter lives at a fixed offset inside an allocation whose base moves by whole 64 KB pages, and stated the test itself: "a third scan should again land on ...9668". Ran it on a fresh guarded Stage 02 run. Probing all 8192 pages of the form 0x????9668 across 0xa0000000-0xbfffffff: with the HUD at 004, exactly two VAs held 4 (0xbc3f9668, 0xbe3f9668); with the HUD at 012, ZERO held 12. Both candidates also failed the file's own transition rule -- over 252 s 0xbc3f9668 held a flat 4 and 0xbe3f9668 flickered 4/0 while the HUD went 004 -> 012. Both arms were sampled at the same instant (cropped HUD digits beside each memory read), after a stale-screenshot comparison earlier in this session produced a spurious 13-vs-004 mismatch. Scope kept narrow: this refutes the page-offset prediction, not the confirmed finding that 0xbdb59668 carries the counter in some runs. The counter's address in THIS run remains unknown -- no transition filter was run. --- .../structures/mission-objective-counter.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/re/structures/mission-objective-counter.md b/docs/re/structures/mission-objective-counter.md index 073b1f24..109de4c8 100644 --- a/docs/re/structures/mission-objective-counter.md +++ b/docs/re/structures/mission-objective-counter.md @@ -163,6 +163,37 @@ HUD was confirmed at `012`. | filter | `012` (confirmed) | **17** | | later sample | — (see caveat) | 7 still 12 | +> ## ❌ REFUTED 2026-08-26 — the page-offset `…9668` prediction does not hold +> +> The reading below — *"the counter lives at a fixed offset inside an allocation +> whose base moves by whole 64 KB pages"* — came with its own test: **"a third +> scan should again land on `…9668`."** That test has now been run, on a fresh +> guarded Stage 02 run (stage asserted), and it fails. +> +> Probing **8192** pages, every VA of the form `0x????9668` across +> `0xa0000000`–`0xbfffffff`: +> +> | HUD | VAs at offset `0x9668` holding that value | +> |---|---| +> | `004` | **2** — `0xbc3f9668`, `0xbe3f9668` | +> | `012` | **0** | +> +> Both candidates then failed the file's own transition rule. Watched for 252 s: +> `0xbc3f9668` held a flat **4** and `0xbe3f9668` flickered 4/0, while the HUD +> went **004 → 012** ([capture](../captures/remaining-ob-012-crop.png)). A value +> that does not move when the counter moves is not the counter, and at `012` +> nothing at that page offset holds `12` at all. +> +> Both arms were read at the same instant (cropped HUD digits beside each memory +> sample), because comparing a stale screenshot against a later memory read is +> exactly how the earlier `13`-vs-`004` confusion in this session arose. +> +> ⚠️ **Scope, stated so this is not over-read:** this refutes the page-offset +> prediction *for this run*. It does not touch the confirmed finding that +> `0xbdb59668` carries the counter in some runs — that address is simply not at a +> reachable `…9668` page here. Nor was the counter located in this run: no +> transition filter was run, so where it actually lives this time is ❔. + **The survivor of interest is `0xbdb49668`** — the run-1 address `0xbdb59668` **minus exactly `0x10000`**, at the identical page offset `0x9668`.