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

re: REMAINING OB's address is run-dependent -- cross-run stability refuted

Browse Source 
The doc carried a 🟡 saying cross-run stability was untested.  Tested now on a
fresh guarded Stage 02 run (stage asserted): the HUD reads "Remaining OB : 004"
while RAM at the documented 0xbdb59668 reads 95748078, constant over four samples
12s apart.  Not 4, not near 4, not moving.  So the address belongs to that run's
heap, as the corpus's own heap-reallocation warning predicts.

No constant-shift shortcut either: a BE u32 equal to 4 occurs 1654 times within
+-1 MB of the old address and 11202 times within +-16 MB, far too many to isolate
without the transition filter.  The durable result is the METHOD (ob_scan.py:
scan at one value, filter against live memory at a DIFFERENT value), not the
number.

Also fixes a contradiction in INDEX.md, which said in one row that the address is
"still ❔" while another row linked the doc that had already CONFIRMED it.
This commit is contained in:
Sylpheed RE agent
2026-08-26 23:34:36 +00:00
parent c7d7df0ead
commit 45a46fadea
2 changed files with 28 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -2,8 +2,33 @@
**Status:** ✅ `CONFIRMED` for one Stage 02 run: a **big-endian u32** whose value
is exactly the HUD's `REMAINING OB`, verified across two transitions it was not
selected by. 🟡 the address itself is from one run — **cross-run stability is
untested**. ❔ what it counts, and whether objective-marked entities carry a flag.
selected by. ❌ **the ADDRESS is run-dependent — measured 2026-08-26, see below.**
❔ what it counts, and whether objective-marked entities carry a flag.
> ## ❌ Cross-run stability: REFUTED (2026-08-26)
>
> The 🟡 above said cross-run stability was untested. It is now tested, and the
> address does **not** carry over. A fresh Stage 02 run (guarded route, stage
> asserted via `assert_stage.py UN_f101_TCAF_Acropolis`):
>
> | | |
> |---|---|
> | HUD | `Remaining OB : 004` ([capture](../captures/remaining-ob-004-crossrun.png)) |
> | RAM `0xbdb59668` | **95748078**, constant over four samples 12 s apart |
>
> Not 4, not near 4, and not moving while the mission ran. So `0xbdb59668` is a
> property of *that* run's heap, exactly as the corpus's own warning about the
> heap re-allocating between runs predicts.
>
> ❔ **No cheap constant shift either.** Looking for a BE u32 equal to the HUD's
> `4` near the old address gives **1654** candidates within ±1 MB and **11202**
> within ±16 MB — far too many to isolate without the transition filter. So there
> is no "old address + delta" shortcut to be had.
>
> **Practical consequence:** treat the address as *derived per run*, never as a
> constant. The method below (`ob_scan.py`: scan at one value, filter against
> live memory at a **different** value) is the durable result here — the number
> `0xbdb59668` is not.
## Why it matters