From a79a1da183bbc625dc661901fd1494cf185ba553 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Thu, 13 Aug 2026 21:21:49 +0000 Subject: [PATCH] re(challenge): withdraw the kind-field constructor attribution -- snapshot refutes it Section 4 claimed the mission-kind field at obj+144 "is initialised to 0 in the constructor sub_821783D8, alongside +148 = 0, +132 = 2, +136/+140 = -1". That linked two code regions on nothing more than both touching +144/+148, and an in-flight snapshot refutes it: sub_821783D8 initialises the STATIC at 0x828F3EC0 -- its first act is InitializeCriticalSection(obj, 256) -- and in the snapshot that object holds 0x000B1C8B at +144 and a float at +592. Not a kind, not flags. So the object that owns the kind field is UNIDENTIFIED. Scanning the snapshot for it (kind in {0,3,5,6} at +144, stage 10 at +148, pointers at +0/+52/+604) returns only matches inside the executable's own static data; the value 10 at +148 is far too common to discriminate. The switch itself stands -- it is direct disassembly at two independent sites (0x82184df0, 0x82185ed0) plus two grouping tests. Only the attribution was wrong, and the wrong half is the half I inferred rather than read. Confirmed on screen instead: launching a story stage from MISSION SELECT reaches a READY ROOM carrying an "EXTRA" watermark -- the EXTRA config section, kind 3, visible in the UI. Independent evidence the field means what section 4 says even though its owning object is not pinned. --- docs/re/challenge-mission-gate.md | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/docs/re/challenge-mission-gate.md b/docs/re/challenge-mission-gate.md index fbc943e..263a1ae 100644 --- a/docs/re/challenge-mission-gate.md +++ b/docs/re/challenge-mission-gate.md @@ -95,12 +95,29 @@ bgt file ; otherwise -> "FILE" (0x820A2168) Two further sites (`0x82186a60`, `0x82186cb8`) classify the same field as `{3, 5, 6}` versus everything else — i.e. **EXTRA and CHALLENGE together are "not an -ordinary story load"**. The field is initialised to **0** in the constructor -(`sub_821783D8`, `0x8217851c`, alongside `+148 = 0` — the stage index — and -`+132 = 2`, `+136/+140 = -1`), and every write to it inside this class -(`0x82184b10`, `0x82185d48`, `0x82186ab4`) only *clears* it. Nothing in the image -stores an immediate 3/5/6 into it, so the kind is **supplied from outside the class** -— by whichever GamePart launches the mission — not derived from the stage number. +ordinary story load"**. Every write to `+144` inside this class (`0x82184b10`, +`0x82185d48`, `0x82186ab4`) only *clears* it, and nothing in the image stores an +immediate 3/5/6 into it, so the kind is **supplied from outside the class** — by +whichever GamePart launches the mission — not derived from the stage number. + +> ⚠️ **Withdrawn:** this section used to add "the field is initialised to 0 in the +> constructor `sub_821783D8`, alongside `+148 = 0`, `+132 = 2`, `+136/+140 = -1`". +> That linked two code regions on nothing more than both touching `+144`/`+148`, and +> a snapshot **refutes it**: `sub_821783D8` initialises the **static** at +> `0x828F3EC0` (its first act is `InitializeCriticalSection(obj, 256)`), and in an +> in-flight snapshot that object's `+144` holds `0x000B1C8B` and `+592` a float — +> not a kind and not flags. So **the object owning the kind field is unidentified**. +> Scanning the snapshot for it (kind ∈ {0,3,5,6} at `+144`, stage at `+148`, +> pointers at `+0`/`+52`/`+604`) returns only matches inside the executable's own +> static data — `10` at `+148` is far too common to discriminate. The **switch +> itself stands**: it is direct disassembly at two sites. Only the constructor +> attribution was wrong. + +**Confirmed on screen instead:** launching a story stage from MISSION SELECT reaches +a READY ROOM carrying an **"EXTRA" watermark** +([capture](captures/ready-room-extra-mode.png)) — the `EXTRA` config section, i.e. +kind **3**, visible in the UI. That is independent evidence the kind field means what +§4 says, even though its owning object is not pinned. ### 4.1 Why the stage-field probe crashes 🟡