alex/sots-re
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

BQ: cross-reference lane BP's probe 2 - both lanes landed on the AI fleet layer

Browse source 
BP has a per-PROCESS input (two pinned processes disagree); this lane has a
per-HISTORY input (two load processes agree with each other and disagree
with the continuation). One datum against the ASLR reading as stated: the
exe base was identical in all five VM145 processes (0x00f40000, delta
+11796480), so any image-base hypothesis has to name which allocation it
means. Probe 3's ledger taken twice on ar-oracle-A-pre - once by
continuation, once by load - now speaks to both.
This commit is contained in:
alex 2026-09-09 02:13:22 -04:00
parent a264529b88
commit c43f638bc0
1 changed files with 28 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
findings/control-flow/seed-exposure-forward-test.md
View file

@ -440,6 +440,34 @@ off a single run — and the *sub-tree* discipline lane AD used is what saves th
measuring the trade half on this turn has a valid sub-tree, and a lane measuring anything downstream
of Venkman does not.
### 4.6 Read next to lane BP's probe 2 — two lanes, one afternoon, the same layer
Lane BP's `pinned-seed-rich-turn.md` landed on VM146 while these runs were in flight, and its result
and this one point at the **same layer of the AI from opposite directions**. Neither lane knew the
other's answer when it committed its prediction.
| | lane BP (probe 2) | lane BQ (probe 1b) |
|---|---|---|
| what was held constant | the per-client **seed** (pinned), same process shape | the **save** (identical input, identical `hooks=off` config) |
| what varied | the process | the **route to the state** — continuation from turn 37 vs load of turn 38 |
| residue | newly allocated **fleet ids** paired differently with newly formed fleets | a fleet's **move order** issued in one route and not the other |
| BP's reading | a per-process input that is not the seed; *inferred* to be a pointer-keyed container under ASLR | — |
**One datum this lane can hand BP for free, and it is against the ASLR hypothesis as stated.**
`shim.log` records the image base on every launch, and on VM145 it was **identical in every one of
the five processes**: `exe base=0x00f40000 (link-time image base 0x00400000, ASLR delta
+11796480)`. Different pids, different sessions, same base. That does not touch heap addresses —
BP's residue could still be a heap-pointer-ordered container — but it does mean *exe* ASLR is not
varying on these guests, so any hypothesis that reaches for image-base randomisation needs to say
which allocation it means.
And the two results are not the same phenomenon: BP's two processes **disagreed** with each other,
while this lane's two load processes **agreed** with each other and disagreed with the continuation.
So BP has a per-process input and this lane has a **per-history** input. Both live in the fleet
layer, and both are open. Probe 3's per-client draw ledger, taken on `ar-oracle-A-pre → 39`
**twice — once by continuation from turn 37 and once from a load** — is now the single measurement
that would speak to both.
---
## 5. Verdicts on the committed predictions