Bound infrastructure payload string fallbacks
This commit is contained in:
parent
ae67719ac6
commit
1873db0b08
3 changed files with 51 additions and 33 deletions
|
|
@ -69,9 +69,12 @@ Working rule:
|
|||
disassembly now also shows the shared child payload callback `0x00455fc0` opening
|
||||
`0x55f1 -> 0x55f2 -> 0x55f3`, parsing three `0x55f1` strings through `0x00531380`, seeding the
|
||||
child through `0x00455b70`, and then dispatching slot `+0x48`; the widened save-side probe
|
||||
currently sees `0` third `0x55f1` strings on grounded `q.gms`, so the next pass should ask
|
||||
whether that third string is genuinely absent on ordinary saves or stored under different
|
||||
framing than the current embedded-row scan.
|
||||
currently sees `0` third `0x55f1` strings on grounded `q.gms`. That now looks less like a probe
|
||||
failure and more like an ordinary fallback path, because direct disassembly of `0x00455b70`
|
||||
stores the three payload strings into `[this+0x206/+0x20a/+0x20e]`, defaulting the second lane
|
||||
through a fixed literal when absent and defaulting the third lane back to the first string when
|
||||
absent. So the next pass should stay focused on payload-stream grouping and tagged value roles,
|
||||
not on rediscovering a missing third-string encoding.
|
||||
- The child loader identity is closed now too: local `.rdata` at `0x005cfd00` proves the
|
||||
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
|
||||
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue