From a22ef5f96f5a5be5d700764d3dd37c33ed0dfa8b Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Thu, 27 Aug 2026 00:23:22 +0000 Subject: [PATCH] re: LOCATE REMAINING OB at 0xbdb69668, and refine the ...9668 pattern Ran this file's own transition filter on a guarded Stage 02 run (stage asserted), reading the HUD from a crop taken at the same instant as each memory sample: scan at HUD 004 -> 41537 candidates; filter at HUD 008 -> 8; verify across the 008 -> 012 transition, which was NOT selected on -> exactly ONE survivor. That survivor, 0xbdb69668, tracked 4 -> 8 -> 12 against the HUD's 004 -> 008 -> 012. The other seven collapsed into noise at the first unselected transition, which is precisely what that rule exists to catch. The file's "try 0xbdb59668 first, re-scan when it reads 0" rule worked verbatim: it read a hard 0 here, and the re-scan cost about the predicted five minutes. The ...9668 page-offset pattern is REFINED, not reinstated: the three located addresses (0xbdb49668, 0xbdb59668, 0xbdb69668) are three ADJACENT 64 KB pages at one offset, and in this run exactly one of 8192 probed pages held 12 -- the counter -- making it a one-step lookup. But the 2026-08-26 refutation stands as measured (zero ...9668 VAs held the HUD value in that run), so this is a fast heuristic to be HUD-checked, not a law. --- .../structures/mission-objective-counter.md | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/re/structures/mission-objective-counter.md b/docs/re/structures/mission-objective-counter.md index 109de4c8..631a3fc9 100644 --- a/docs/re/structures/mission-objective-counter.md +++ b/docs/re/structures/mission-objective-counter.md @@ -163,6 +163,49 @@ HUD was confirmed at `012`. | filter | `012` (confirmed) | **17** | | later sample | — (see caveat) | 7 still 12 | +> ## ✅ 2026-08-27 — the counter LOCATED again, at `0xbdb69668`, and the `…9668` pattern is *refined* +> +> A sixth located run, by this file's own transition filter, on a guarded Stage 02 +> run (stage asserted). Every step's HUD value was read from a crop taken at the +> same instant as the memory sample. +> +> | step | HUD | candidates | +> |---|---|---| +> | scan | `004` | 41 537 | +> | filter | `008` | **8** | +> | verify (not selected on) | `008 → 012` | **1** | +> +> The single survivor is **`0xbdb69668`**, which tracked `4 → 8 → 12` against the +> HUD's `004 → 008 → 012` ([capture](../captures/ob-012-located.png)). The other +> seven collapsed into noise (`1040511`, `3211282537`, …) at the first transition +> they were not selected on — which is exactly why that rule is in this file. +> +> ### ✅ The "try it first, re-scan when it reads 0" rule worked verbatim +> +> `0xbdb59668` read a **hard 0** here — the documented failure mode, not garbage — +> so the re-scan was the right move and cost the five minutes the file predicts. +> +> ### 🟡 The `…9668` page offset: a fast HEURISTIC, not a law +> +> The three located addresses are **three adjacent 64 KB pages at one offset**: +> +> | run | address | +> |---|---| +> | run 1 | `0xbdb5``9668` | +> | run 2 | `0xbdb4``9668` | +> | this run | `0xbdb6``9668` | +> +> And in this run the offset probe is *decisive on its own*: of 8192 pages, exactly +> **one** VA at offset `0x9668` held `12`, and it was the counter. That is a +> one-step lookup where the full scan costs five minutes. +> +> ⚠️ This **refines rather than reverses** the refutation immediately below. That +> refutation stands as measured: in that run, zero `…9668` VAs held the HUD value. +> So the pattern recurs but is not universal — the same shape as the address +> itself. **Practical order:** try `0xbdb59668`; if it is 0 or garbage, probe the +> `…9668` pages (seconds); only then run the full scan. Check every candidate +> against the HUD before believing it. + > ## ❌ 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