fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: "follow the name pointer" is structurally dead for pak strings

Browse Source 
Locating DeltaSaber at mission time works: 53 occurrences, all in the heap
(0xBC66..-0xBC6C..), none in the XEX image -- DeltaSaber_T.xpr, _Special,
_NoseGun, _Missile, _TwinGun.

But searching all of guest memory for a big-endian pointer to those addresses
returns ZERO references for every one tried.  That is the format, not a search
bug: those strings live in the mission pak's IDXD string pool, and this corpus
decoded that container long ago -- records reference names by OFFSET into the
pool, never by absolute pointer.  So there are no pointers to find, and "find the
name, follow what points at it" cannot work on pak data by construction.

This also narrows what the string counts proved.  The title-vs-mission control
stands (DeltaSaber 0 -> 81), so mission-specific DATA is loaded, which is more
than "the tables load at boot".  But these are asset-table strings, not live
entity objects, so they do not show entities have been spawned.  Honest split:
the mission's pak data is loaded; whether entity objects exist is still
unmeasured, because both probes tried -- gworld's vtable constants and
name-pointer following -- are respectively stale and structurally inapplicable.

Remaining routes, untried: derive the entity vtable from CODE via sylpheed.db's
vptr_writes table, which exists for exactly this; or find the entity list from
the mission update function rather than from data.
This commit is contained in:
Sylpheed RE agent
2026-08-26 20:06:10 +00:00
parent 432cc43885
commit b56a4ab9f9
1 changed files with 34 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/re/mission-freeze-signin-dialog.md
View File

@@ -253,3 +253,37 @@ attachment names living in the **XEX image** (`0x820A…`), not runtime definiti
records — so the route in is a name that only exists at mission time.
**`DeltaSaber` is exactly that name**: find its occurrences in the heap, find what
points at them, and read the vtable pointer of the referencing object.
## 🔴 The "follow the name pointer" route is structurally dead for pak strings
Locating `DeltaSaber` at mission time works: **53 occurrences, every one in the
heap** (`0xBC66…`–`0xBC6C…`), none in the XEX image —
`DeltaSaber_T.xpr`, `_Special`, `_NoseGun`, `_Missile`, `_TwinGun`.
But searching all of guest memory for a 32-bit big-endian pointer to those
addresses returns **0 references** for every one tried.
That is not a search bug, it is the format. Those strings live in the mission
pak's **IDXD string pool**, and this corpus decoded that container long ago:
records reference names by **offset into the pool**, never by absolute pointer
([`structures/idxd-container.md`](structures/idxd-container.md)). So there are no
pointers to find, and "find the name, follow what points at it" cannot work on
pak data by construction.
## 🟡 Which narrows what the string counts actually proved
The title-vs-mission control stands — `DeltaSaber` really is 0 at the title and 81
after take-off, so **mission-specific data is loaded**, which is more than "the
unit tables load at boot". But these are **asset-table strings**, not live entity
objects, so they do **not** show that entities have been *spawned*. The honest
statement is:
* ✅ the mission's pak data is loaded;
* ❔ whether entity objects exist is still unmeasured, because the only two
probes tried — `gworld`'s vtable constants, and name-pointer following — are
respectively stale and structurally inapplicable.
❔ Remaining routes, none tried: derive the entity vtable from the **code** (find
the constructor that writes a vtable pointer, via `sylpheed.db`'s `vptr_writes`
table, which exists precisely for this); or find the entity list from the mission
update function rather than from data.