fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: LOCATE REMAINING OB at 0xbdb69668, and refine the ...9668 pattern

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-27 00:23:22 +00:00
parent 7e89249f46
commit e3098f7316
2 changed files with 43 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/re/captures/ob-012-located.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

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

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