Typed retained data and RAM backing

Scope

This bounded investigator pass revisits the remaining 56,153 semantically unclassified bytes using the existing authorized Complex4627 reference snapshots. It uses public PE metadata and the public Xbox ABI to identify required data footprints, then checks endpoint backing, protection and stability. It does not obtain another image, operate a rig, alter firmware, implement product code or publish reference expression.

The useful new result is 721 disjoint bytes with defensible data associations, leaving 55,432 bytes semantically unclassified. Public ABI footprints are distinguished from unknown larger internal allocation boundaries. Foreign strings, keys, private names, callback targets and contents remain private.

1. ROM file size is separate from resident RAM

The supplied artifact is labeled Complex4627. Its exact file size is 1,048,576 bytes / 1 MiB. Additional packaging or feature variants are not established.

The authorized reference investigator measured four byte-identical 262,144-byte / 256 KiB quarters in this supplied file. This is an exact repetition observation, not proof of how flash hardware selects a bank, how much unique executable code exists, or which portion is compressed. No byte contents or new hash calculation are needed to report it.

Quantity	Reference result	Meaning
Supplied ROM file/container	1,048,576 bytes / 1 MiB	Four identical 256 KiB quarters
One repeated quarter's byte sequence	262,144 bytes / 256 KiB	File-content repetition, not resident RAM
Kernel virtual image envelope	636,160 bytes	Includes retained and discardable virtual content
Unique retained physical kernel-image backing	184,320 bytes / 45 pages / 180 KiB	Actual backed image pages at the existing checkpoint
Original public-entry guest's unavailable memory	161 pages / 644 KiB	16,223 available of 16,384 total pages; includes workload and other owners
Frozen allocation/lifetime guest's unavailable memory	158 pages / 632 KiB	16,226 available of 16,384 total pages; includes workload and other owners

The last two checkpoints differ and must remain separate. Neither unavailable-memory total is a firmware-only subtotal. Neither the ROM file size nor its repeated quarter size can be substituted for the 45-page resident kernel measurement.

2. Two PE-format objects account for 109 bytes

The image advertises one 28-byte debug-directory entry. Its CodeView record occupies 81 bytes, comprising a format header of 16 bytes and one terminated private record of 65 bytes. The directory's advertised extent and record boundary agree; both lie wholly within the previously unknown retained set. The private record's contents are withheld.

Anonymous format object	Offset within retained region_00	Bytes	Boundary evidence
format_object_00	1,520	28	PE optional-header directory extent and one complete directory entry
format_object_01	10,488	81	Directory-specified record extent; fixed header and final terminator agree
Disjoint total		109

This establishes format-associated data rather than another printable-byte pattern. It does not prove that debugger or error paths never inspect the records, that they are safe to discard, or that omitting them would release a physical page. The directory can legally appear within a retained section; its location alone does not establish a boot-only lifetime. Microsoft PE format.

3. Fifteen public ABI data footprints account for 612 bytes

The public export table supplies each start. Public nxdk declarations supply the required 32-bit ABI footprint. This identifies the bytes exposed by the contract; it does not recover a proprietary structure implementation, infer a private adjacent object, or establish a larger enclosing allocation's size. The public contract is CC0-1.0; the retrieved header blob was 6cd126b9b447d56f10d9031d17e8cf1faf1c2cfd. Public nxdk Xbox kernel ABI.

Public data export	Public type association	Offset within region_00	ABI footprint bytes
ExEventObjectType	OBJECT_TYPE	1,548	28
ExMutantObjectType	OBJECT_TYPE	1,576	28
ExSemaphoreObjectType	OBJECT_TYPE	1,760	28
ExTimerObjectType	OBJECT_TYPE	1,804	28
XboxKrnlVersion	XBOX_KRNL_VERSION	1,872	8
IoCompletionObjectType	OBJECT_TYPE	1,896	28
IoDeviceObjectType	OBJECT_TYPE	1,924	28
IoFileObjectType	OBJECT_TYPE	1,952	28
KeTimeIncrement	Constant 32-bit unsigned value	2,544	4
MmGlobalData	MMGLOBALDATA	2,628	32
ObDirectoryObjectType	OBJECT_TYPE	2,680	28
ObSymbolicLinkObjectType	OBJECT_TYPE	2,708	28
PsThreadObjectType	OBJECT_TYPE	2,892	28
HalDiskCachePartitionCount	32-bit unsigned value	8,320	4
XePublicKeyData	Publicly declared byte array	9,184	284
Disjoint total			612

The ten object-type records contribute 280 bytes. The other five public footprints contribute 332 bytes. No public key or other payload contents are shared.

The footprint accounting is stronger than a pattern match because these are actual public data-export starts paired with published types. It remains narrower than an internal allocation census: an implementation could place extra private storage around a required public prefix.

4. Read-only at the later endpoint is not ROM residency

All seventeen newly typed ranges are RAM-backed at both existing snapshots. Their 721 bytes match exactly: zero differ and zero are absent. They occupy two unique physical image pages, which also contain 984 other previously decoded bytes outside these data ranges. This is co-tenancy, not 721 bytes of independent physical allocation.

Observation across all seventeen ranges	Kernel entry	Later post-startup snapshot
Backing	RAM	RAM
Export/data VA permits writes through captured page tables	Yes	No
At least one present writable alias for the same backing in the captured address space	Yes	No
CPU supervisor write protection enabled	Yes	Yes

The later page-table result supports calling this retained, protected data at that checkpoint. The earlier writable result shows that the initialization and settled states differ. Neither result proves the bytes were never temporarily rewritten, that another address space cannot map them writable, or that a device cannot modify physical RAM. The captures do not provide a complete mapping or write history.

The narrowly inspected decoded set contains no literal direct-memory operand wholly inside these new ranges. That does not prove no accesses: exported pointers, indexed accesses, table-relative loads and title code can reach them without embedding a literal address. In particular, lack of a direct literal reference is insufficient to remove a public ABI object.

5. Public callback records establish RAM dependencies

The public OBJECT_TYPE layout contains five callback slots and one default-object slot. Counting these fields across ten public records establishes the following aggregate backing relationships without publishing values, target lists or graph edges:

Public callback-slot relationship	Slots
Null callback slots	22
Non-null callback slots whose targets map to RAM at the later snapshot	28
Callback slots whose targets map to the physical ROM region	0
Five callback slots × ten records	50

The 28 non-null slots have ten distinct target addresses, all located in retained executable-section metadata and RAM-backed at the later endpoint. Five of these addresses appear as exact block entries during startup in the existing public-entry trace; two appear during its runtime phase. These counts need not be disjoint, and the trace does not establish that invocation occurred through these particular records. Only five targets match existing inferred walk entries; the others must not be promoted automatically to new functions or called unreachable.

The ten separate default-object fields contain five null values, four values mapping to RAM and one non-null value unmapped in the later capture. This is a numeric public-field/mapping relationship. It does not establish that the unmapped value is an invalid object reference: its permitted convention and consumer context remain unproved.

These observations support a specific conclusion: the public callback records studied here do not demonstrate direct-ROM callback execution as the explanation for the small resident image. Their known non-null callback dependencies point to retained RAM at the measured endpoint. The broader question of transient ROM aliases or other services remains open; the old traces still lack per-event physical instruction-fetch identity.

6. Exact reconciliation

All 721 newly typed bytes are inside the former unknown set, disjoint from each other and from the prior decoded/prefix/format classifications. The updated retained-section partition is:

Disjoint retained region_00 accounting	Bytes
Prior recursive decoded-byte union	94,726
Fixed export directory	40
Public function-address array	1,464
Previously identified format-defined module-name record	13
Previously added trace-anchored decoded prefixes	740
Newly typed PE debug metadata	109
Newly typed public ABI data footprints	612
Still semantically unclassified	55,432
Entire retained section	153,136

The earlier six table-access windows remain overlapping evidence sets, not additional allocations or exact object boundaries. No previous inferred decoded bytes are reclassified in this pass. The 45-page resident image total is unchanged.

7. Next useful owned-memory hypothesis

This evidence favors testing data lifetime and page packing before assuming wholesale execution from ROM. An owned-image audit should distinguish build-only metadata, data initialized once and subsequently protected, stable public ABI storage, and mutable pointed-to state. Public footprints must retain their address/contract; cold callbacks require their complete code/data dependencies to remain available.

The 109 bytes of reference debug metadata are too small to explain the resident-image gap, and sharing pages prevents turning a byte count directly into free-page savings. Likewise, these 612 public ABI bytes are required interface storage, not an obvious hundreds-of-KiB removal opportunity. The worthwhile hypothesis is whether the owned image's larger tables and cold service roots can be independently packed, specialized or lifetime-separated enough to release whole physical pages, without breaking post-link initialization, title exports, callback registration, media changes, errors or reset.

No unobserved function is declared unused. A ROM-placement experiment would still need owned relocation/write analysis, an actual physical-fetch observation, and ordinary behavior/performance validation. The existing evidence does not establish that such a change is necessary to match the reference's RAM footprint.

Publication scope

This page publishes original numerical results and public ABI footprint derivations. The private reference, scripts, memory contents, callback destinations and record strings remain in the authorized lab. No firmware change, new native title test or memory saving is claimed.

Public 32-bit ABI footprint derivations: OBJECT_TYPE has six four-byte pointers plus one four-byte unsigned integer, totaling 28 bytes; MMGLOBALDATA contains eight four-byte pointers, totaling 32 bytes; XBOX_KRNL_VERSION contains four two-byte unsigned integers, totaling eight bytes. See the public nxdk source linked above.

Main overview: Complex-BIOS-Size-and-Layout.