fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the '504 unnamed keys' is 504 entries, not 504 names -- it is 42 keys

Browse Source 
Independently reproduced across all 33 paks: 7750 IDXD objects, 1485577 unnamed
field entries, 7094 distinct never-named keys splitting cleanly into 7052 in an
ordinal band (<=0x2198, 94.6% equal to their own field index) and 42 hash-shaped
(>=0x2677C), with ZERO keys in the gap between. The 42 carry exactly 504
entries -- six language copies of one object times two records.

So the preimage target was 42, not 504, and my earlier wording invited the
misreading. Cross-referenced to the idxd-unnamed-keys write-up, which shows the
42 belong to <lang>\script\ID.tbl and cannot be recovered from a 24-bit hash.
This commit is contained in:
Sylpheed RE agent
2026-08-26 03:40:55 +00:00
parent 165dbb4d81
commit 2498922e9a
2 changed files with 16 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/re/structures/idxd-container.md
View File

@@ -60,8 +60,18 @@ Disc-wide census of all **2,757,039** fields:
| unnamed, literal key (`< 0x10000`) | 1,485,073 |
| unnamed, hash-shaped key | 504 |
Those **504** are the entire remaining preimage problem on the disc. ❔ Their
names are unrecovered.
Those **504** are the entire remaining preimage problem on the disc — but the
count is easy to misread, so state it precisely: 504 is a count of **field
entries**, not of distinct names. They are **42 distinct keys**, each appearing
in 12 places (six byte-identical language copies of one object × two records).
The preimage target was never 504 names; it is 42.
❔ Their names are unrecovered, and
[idxd-unnamed-keys.md](idxd-unnamed-keys.md) shows why that is not a matter of
more compute: the 42 belong to `<lang>\script\ID.tbl`, and at 7 characters one
of them already has 1 176 preimages under a 24-bit modulus. 30 of the 42 have
their trailing digits pinned algebraically; the prefixes cannot be recovered
from the hash alone.
## Two corrections
@@ -144,7 +154,9 @@ of the four legacy magics), so that path is read-only knowledge, untestable here
## What this does *not* settle
* ❔ The names of the 504 unnamed hash-keyed fields.
* ❔ The names of the 42 unnamed hash-keyed fields (504 entries — see
[idxd-unnamed-keys.md](idxd-unnamed-keys.md); shown to be unrecoverable from
the hash alone).
* ❔ How much of the existing corpus the old string-pool reader got wrong. The
legacy `get_f32`/`get_raw` path infers a field's value from *pool adjacency*
(`<value>\0<key>\0`). That adjacency is a consequence of the field table, not a