jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Classify acquisition transport and builder callers

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 22:51:57 -07:00
commit 39a97f173a
2 changed files with 81 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/rehost-queue.md
View file

@ -127,9 +127,17 @@ Working rule:
the data-driven loader callers `0x0046f073 / 0x004707ff` push tuple fields
`[+0x00/+0x04/+0x0c]` into `0x0040ef10`, and inside that helper arg3 becomes `ebx` and then
`[site+0x276]` at `0x0040f5d4`
- that tuple path is classified further now too:
the checked-in atlas ties `0x004707ff` to multiplayer transport selector-`0x13` body
`0x004706b0`, which attempts the placed-structure apply path through
`0x004197e0 / 0x004134d0 / 0x0040eba0 / 0x0052eb90 / 0x0040ef10`
- one surviving non-transport `0x004134d0` caller is bounded away from persisted restore too:
`0x00422bb4` pushes one live `0x0062b2fc` record plus local args and literal flags `1/0`
into `0x004134d0`, then returns the created row id through an out-param instead of feeding
the tuple-backed finalize path
- the remaining owner-company question is therefore narrower than “find any replay seam”:
identify which persisted source family feeds that tuple and which companion restore/finalize
calls are sufficient to repopulate `[site+0x276]` for shellless acquisition
identify which non-transport persisted source family feeds that tuple and which companion
restore/finalize calls are sufficient to repopulate `[site+0x276]` for shellless acquisition
- the second is narrower in the same way:
the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`