fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: refute the "counter sits at page offset 0x9668" prediction

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-26 23:57:25 +00:00
parent c2b7c93792
commit 2add603485
1 changed files with 31 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/re/structures/mission-objective-counter.md
View File

@@ -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`.