From bcdd70123e29406240b5cbd1d0630d8f8bf7b468 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Mon, 31 Aug 2026 03:43:25 +0000 Subject: [PATCH] re: correct the dialog record alignment, and close the static route to the id-entry join Two things, both from reading the image. The record layout is {id, name_ptr, handler}, not {handler, id, name_ptr} as first published -- the same three fields shifted by one word, so every record was credited with the previous record's handler. Caught by a control dump: under the old alignment record 0 had a 'handler' of 0x10000000, not a code address. ids and names are unaffected and DLG_SELECT_DIFFICULTY is still id 2000; only the attribution moved. Corrected histogram over 70 records: 0x821D0808 x43, 0x821D05D8 x24, 0x821CFD80 x3. And the id-to-pak-entry join is not reachable this way. All three handlers load the same global at 0x828E2B14 and two take addresses at 0x828E45E0/4640/467C, and every one of those sits inside a 364 601-byte contiguous zero run -- BSS, populated only at runtime. Controlled: the dialog table itself reads non-zero through the same arithmetic, so the addressing is right and the data is genuinely absent. Reach stated: this closes one route, not the question. 'Not in the image' is not established -- 'not reachable from the dialog handlers' is. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/data/difficulty-is-a-dialog.txt | 42 ++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/docs/re/data/difficulty-is-a-dialog.txt b/docs/re/data/difficulty-is-a-dialog.txt index 85adc71c..609706a5 100644 --- a/docs/re/data/difficulty-is-a-dialog.txt +++ b/docs/re/data/difficulty-is-a-dialog.txt @@ -75,7 +75,16 @@ # one. Every DLG_ string in the image is pointed at by exactly one aligned word, # at a regular 12-byte stride. The table is: # -# struct { u32 handler; u32 id; u32 name_ptr; } // 12 bytes, big-endian +# struct { u32 id; u32 name_ptr; u32 handler; } // 12 bytes, big-endian +# +# 🔴 CORRECTED 2026-08-31: this first read as `{handler, id, name_ptr}`, which is +# the same three fields SHIFTED BY ONE WORD, so every record was credited with the +# PREVIOUS record's handler. Caught by a control dump: under the old alignment +# record 0 (DLG_LET_SIGNIN) had a "handler" of 0x10000000, which is not a code +# address. ids and names are unaffected -- they are the same fields either way, +# and DLG_SELECT_DIFFICULTY is still id 2000. Only the handler attribution moved. +# Under the corrected alignment its handler is 0x821D0808, and the histogram over +# all 70 records is 0x821D0808 x43, 0x821D05D8 x24, 0x821CFD80 x3. # # spanning 0x820A0A2C .. 0x820A0D68, three distinct handler values # (0x821CFD80, 0x821D05D8, 0x821D0808). @@ -243,3 +252,34 @@ # It cost two scans and went AGAINST the reading I had offered. A bound nobody is # incentivised to test is exactly where a convenient claim survives -- and the # next reader cannot tell whether a bound was respected or merely never revisited. + + +################################################################################ +# ❌ THE id -> PAK-ENTRY BINDING IS NOT IN THE IMAGE BY THIS ROUTE. 2026-08-31. +# +# Positional ordering was already ruled out. The next route was the dialog +# table's own handlers: if anything joins a dialog id to an archive entry, the +# code that builds a dialog should touch it. +# +# All three handlers were disassembled from the image. All three begin by loading +# the SAME global -- `lis r11,0x828E` then `lwz r3,0x2B14(r11)` -> 0x828E2B14 -- +# and two take addresses at 0x828E45E0 / 0x828E4640 / 0x828E467C. +# +# ❌ EVERY ONE OF THOSE IS BSS. They sit inside a single contiguous ZERO RUN of +# 364 601 bytes (0x828A28C7 .. 0x828FB900) -- uninitialised data, zero in the +# image, populated only at runtime. +# +# ✅ CONTROL, because an all-zero read is also what a bad address gives: the +# dialog table itself at 0x820A0A2C reads non-zero through the same arithmetic +# (10000000 00000000 820a4598 821cfd80). The addressing is right; the data is +# genuinely absent. +# +# => The handlers operate on RUNTIME state. If the id -> entry join exists there, +# it is visible only in a running game, not in the image. That is a route +# closed rather than a question answered, and it says where the next attempt +# has to look: guest memory at 0x828E2B14 with the game up. +# +# ⚠️ REACH: one route (the table's own handlers). Not looked at: the archive +# loader, the GamePart that opens GP_DIALOG, or any table keyed by id elsewhere +# in the image. "Not in the image" is NOT established -- what is established is +# "not reachable from the dialog handlers, because they read BSS".