Memory Reference Content and ROM - Mainkill1/SpiritBoot GitHub Wiki
Retained content, table evidence, and ROM mapping epochs
Scope
This is a second, bounded investigator pass over the already authorized Complex4627 reference artifacts. It builds on DEEP-CENSUS-ADDENDUM.md; it does not repeat the full disassembly or acquire another capture. No rig, running user session, target product source, firmware change, or new benchmark was involved.
Shared results contain original numeric metadata and anonymous region/candidate identifiers. The stored reference strings, array contents, instruction expressions, control-flow graph, and private names are not exported. Object interpretation and observed lifetime are reported separately from exact byte accounting. This records the research boundary, not legal certification.
1. What can now be classified exactly
The earlier addendum left 56,166 bytes semantically unclassified in retained executable-flag region_00. Its export directory advertised a 1,517-byte envelope, of which 1,504 bytes had been identified as the fixed directory and public function-address array.
The format-defined module-name pointer identifies a 13-byte terminated record wholly inside the remaining envelope. Its contents are withheld. This accounts for the last 13 bytes without guessing from a nearby symbol or publishing a private string.
The updated disjoint region accounting is:
Retained region_00 accounting |
Bytes |
|---|---|
| Prior recursive decoded-byte union | 94,726 |
| Fixed export directory | 40 |
| Public function-address array | 1,464 |
| Newly identified format-defined module-name record | 13 |
| Previously added trace-anchored decoded prefixes | 740 |
| Still semantically unclassified | 56,153 |
| Entire retained region | 153,136 |
Only the 13-byte format record moves into an exact data category in this pass. Static references and recognizable patterns improve the investigation map but do not establish complete object identity, original compiler boundaries, runtime use, or safe removal.
2. Exact exclusive evidence accounting for the remaining ranges
The new retained-content-evidence-ranges.csv retains all 246 range rows from the prior ledger and partitions each range without charging any byte twice. The table below includes the newly resolved 13 bytes so its total remains equal to the previous 56,166-byte set.
| Exclusive evidence bucket | Bytes | Interpretation |
|---|---|---|
| Format-proved module-name record | 13 | Exact data record and format boundary |
| Two locally bounded indexed-dispatch windows | 88 | Supported table-access candidates; exact objects and use remain unproved |
| Other literal memory-read operands | 469 | Statically referenced byte positions; not proof that these reads executed |
| Other aligned executable-address-shaped word runs | 908 | Table-like pattern; contents and targets withheld |
| Referenced terminated printable-byte shapes | 329 | Candidate string data whose starts appear as non-control address operands |
| Other terminated printable-byte shapes | 314 | Syntactic candidates without that reference evidence |
| Other terminated two-byte character shapes | 298 | Syntactic candidates, not recovered private string objects |
| Remaining repeated-zero shapes | 6,710 | Literal pattern; may be data, instruction fields, or padding |
| Remaining repeated trap-byte shapes | 223 | Literal pattern; padding versus intentional executable trap unresolved |
| Mixed or otherwise unclassified remainder | 46,814 | No stronger claim from this pass |
| Total | 56,166 | Disjoint evidence partition, not a certified code/data split |
The priority is exactly the row order. A byte that matches multiple kinds of evidence appears in the first applicable bucket. Consequently these exclusive values differ from the inclusive pattern totals below. Reordering the evidence would change which row receives an overlapping byte; it would not change the physical total or prove a different object layout.
For example, a plausible function-pointer array can also contain repeated zero bytes, and a terminated two-byte character sequence includes zero bytes. Adding the inclusive counts would be misleading. The CSV supplies both the range length and its exclusive charges, and every row's charges sum to that exact length.
Static memory references
The existing decoded instruction records contain 462 literal memory-read sites, addressing 111 distinct starts / 469 distinct byte positions in the old unknown set:
- 454 four-byte operands;
- one one-byte operand;
- seven eight-byte operands.
These sites encode reads, not writes. The audit does not assert that each site ran. Nor does a read establish that the bytes form a table: a routine can read scalars, constants, headers, or even executable bytes. Referenced byte positions are a useful test target; they are not a complete private structure boundary.
There are also 108 non-control literal-address candidates into the old unknown set. Eleven terminated printable-byte candidates begin at one of those addresses, covering 329 bytes. That raises the confidence of a data interpretation without revealing strings or claiming a particular consumer or service. No corresponding two-byte character candidate start has that evidence in the retained decoded set.
Inclusive pattern inventory
The following measurements describe byte shapes, not certified objects:
| Shape measured within old unknown ranges | Runs | Inclusive union bytes | Longest run |
|---|---|---|---|
| Terminated printable-byte sequence, at least four characters | 37 | 670 | 80 |
| Terminated two-byte printable-character sequence, at least four characters | 12 | 300 | 46 |
| At least three aligned words landing inside executable-section metadata | 24 | 996 | 152 |
| Repeated zero bytes, at least two | 2,071 | 6,886 | 48 |
| Repeated trap bytes, at least two | 44 | 229 | 15 |
No sequence contents or array targets are included in shared output. An executable-section flag alone does not prove a pointed-to byte is an instruction. Likewise, a printable sequence inside unknown bytes can arise in instruction operands. These facts keep semantic confidence below the confidence of the exact counts.
The zeros are especially unsuitable as a savings estimate: the longest contiguous run is only 48 bytes, and scattered zero values can be necessary constants, structure fields or encoding bytes. The audit has not identified thousands of safely disposable padding bytes.
Retained pointer-like patterns can reference discarded ranges
The 24 pointer-shaped runs contain 249 four-byte candidate slots. Of these, 202 point into retained region_00 and are RAM-backed at the captured checkpoint; 47 point to 29 distinct positions inside discardable region_04, all unmapped at that checkpoint. Twenty-one runs contain retained-section targets only, two contain discardable-section targets only, and one is mixed.
These are numeric target/backing relationships, not a recovered private callback layout. At the captured mapping, the 29 unmapped target virtual addresses cannot directly supply executable instructions. This does not prove that every stored word is actually a callable pointer, that its container is unused, or that the targets cannot be restored or invoked through another representation later.
The useful distinction is that reference retention is not identical to universal live reachability: some retained address-shaped data still names discarded positions. That observation should motivate an owned last-consumer audit, not automatic removal of a corresponding SpiritBoot table.
3. Two table candidates have stronger bounded-access evidence
The prior report correctly left ten retained candidate object sizes unknown. A bounded audit of the existing consumers finds two locally guarded access windows:
| Existing anonymous candidate | Locally bounded access window | Potential four-byte slots | Slots whose stored targets lie in executable-section metadata |
|---|---|---|---|
table_candidate_001 |
76 bytes | 19 | 19 |
table_candidate_002 |
12 bytes | 3 | 3 |
Each window follows a local unsigned bound check that directly guards one indexed access in the stored instruction evidence. This gives substantially stronger table evidence than simply finding address-looking words. Both windows are inside the previous unknown set and do not overlap each other.
These are access windows, not newly certified allocation sizes. The audit does not prove that all slots execute, that no other entry bypasses the guard, or that the surrounding object ends at the last slot. The second candidate also has another consumer whose full admitted domain is not established by this small local audit. Thus the previous exact_bytes = unknown status for the private table objects remains appropriate.
The other eight retained candidate object sizes remain unresolved. No neighboring address, pointer-looking prefix, or enclosing unknown span has been promoted to an object boundary. To strengthen those candidates, the next observation should associate executed consumer identity, access width, index range and mapping with the read, without extracting a reconstruction of the reference routine. Minimum observed accesses and maximum permitted accesses must remain distinct.
4. Snapshot stability is a lifetime clue, not a lifetime proof
All 56,166 bytes in the prior unknown set are RAM-backed at the later captured checkpoint and match their kernel-entry values exactly:
| Snapshot comparison | Bytes |
|---|---|
| Matching between kernel-entry image and later same-session RAM capture | 56,166 |
| Differing | 0 |
| Absent at later checkpoint | 0 |
This excludes a change detectable at those two endpoints. It does not show that the bytes were continuously unchanged, never read, never rewritten to the same value, or not needed by another title or reset path. Retention and stability are separate observations from liveness.
No additional globally unused function was proved. The previous 199 unobserved public entry walks remain unobserved in bounded workloads, not unreachable or removable. The same qualification applies to anonymous data: absent observed access is not a last-use proof.
5. The resident image's 460 non-content bytes are exactly located
The prior physical image partition included 460 backing bytes outside advertised content extents. These are four inter-section gaps, rather than an unexplained page-sized allocation:
| Anonymous gap | Bytes | Virtual interval, end excluded |
|---|---|---|
section_gap_00 |
16 | 0x800358f0–0x80035900 |
section_gap_01 |
20 | 0x8003aecc–0x8003aee0 |
section_gap_02 |
400 | 0x8003c870–0x8003ca00 |
section_gap_03 |
24 | 0x8003cb08–0x8003cb20 |
| Total | 460 | Already inside the same 45 physical image pages |
These gaps are exact consequences of advertised section placement. That does not prove a separate live object occupies them or that all are interchangeable alignment filler. Their small total also cannot explain a hundreds-of-KiB resident image difference. Eliminating a gap inside a page would not automatically release a physical page.
6. ROM mappings actually change between available checkpoints
The earlier addendum warned that a single post-startup map cannot establish every instruction's physical backing. The existing kernel-entry and later captures now demonstrate that concern concretely:
| Mapping epoch | Direct large mappings | Lower small aliases | Total mapping records |
|---|---|---|---|
| Kernel entry | One 4 MiB mapping | One 4 KiB alias | 2 |
| Later post-startup checkpoint | Three 4 MiB mappings | Three 4 KiB aliases | 6 |
At kernel entry, the direct mapping covers VA/PA 0xffc00000–0x100000000, with a lower alias at VA 0xc03ff000 to physical 0xffc00000.
At the later checkpoint, the direct mappings begin at 0xff000000, 0xff400000 and 0xff800000, each spanning 4 MiB. Their lower 4 KiB aliases begin at 0xc03fc000, 0xc03fd000 and 0xc03fe000, respectively. The old lower alias is absent in that captured later mapping.
These windows describe guest address translation into the physical ROM region. Their 4 MiB extents are not firmware file lengths, extra stored copies, or RAM allocations. They also do not establish a callable ROM service.
Recheck against both endpoint alias sets
The union has four distinct lower 4 KiB aliases. Neither of the two existing block-entry traces records execution inside any of those four lower alias intervals, during startup or runtime. The already known startup direct-ROM result remains 57 distinct PCs / 27,655 entries, all in the final virtual 4 KiB page. Runtime direct-ROM entries remain zero.
This closes the specific gap of omitting the known kernel-entry lower alias from the earlier frozen-map check. It does not close transient mapping uncertainty. There is no retained per-event physical instruction-fetch identity or complete map-change history. An alias installed and removed between the two captures could still be invisible to this method.
The available artifacts therefore support: startup direct-ROM execution observed; no runtime ROM execution observed in the two public-API traces or either endpoint's known lower aliases. They do not prove that all gameplay, storage errors, shutdown, debugger paths or warm reset execute solely from RAM.
The decisive ROM experiment
A useful follow-up should observe execution backing, rather than merely make a larger PC log:
- Correlate each executed block with the physical instruction-fetch range or an attributable active mapping epoch; include translation-cache reuse.
- Record direct high virtual ROM entries and lower aliases separately, and distinguish instruction execution from reading ROM as data.
- Preserve hardware/input identity so a hit can be attributed to the supplied MCPX/bootstrap or BIOS region instead of calling every ROM hit a BIOS function.
- Exercise title progress, an ordinary storage error, shutdown and warm reset, while preserving their authored inputs and outcomes.
- Retain bounded aggregate counts and first-hit records. Keep instrumented discovery separate from uninstrumented performance claims.
A hit would then prove actual ROM execution in the covered path and permit original numeric extent/lifetime notes. A zero result would remain scoped to the exercised paths. No reference function body needs to enter SpiritBoot to perform or use this observation.
7. What is genuinely attained, and what is still missing
This pass adds a complete format explanation for the export envelope, a reproducible exclusive evidence partition of every prior unknown range, stronger local table-access evidence, exact locations for resident section gaps, and a two-epoch ROM mapping check.
It does not supply an original linker map for the reference, exact private structure sizes, exhaustive dynamic table indices, a whole-game call graph, per-event physical fetches, or a complete allocator-owner census. The remaining 56,153 semantically unclassified retained bytes are an honest unresolved quantity, even though many now have useful investigation flags.
For implementation decisions, exact data type is not enough: a candidate also needs an independently established ownership and last-use contract. Conversely, an observed callable entry does not explain all of its shared helpers or physical storage. The owned-source audit should use these measurements to prioritize its own roots, tables and lifetimes without converting reference patterns into product code.
Artifacts and verification
retained-content-evidence.json: original aggregate counts, guarded-window evidence, snapshot comparisons, section gaps and two mapping epochs.retained-content-evidence-ranges.csv: 246 anonymous range rows with exact exclusive evidence charges.- Investigator-only audit code and reference contents remain under
private/.
Checks: exclusive bucket total and every CSV row reconcile to the previous 56,166-byte set; format record bounds reconcile to the 1,517-byte export envelope; the unchanged full region reconciles to 153,136 bytes; both local access windows are disjoint and inside the old unknown set; the 56,166-byte endpoint comparison has zero differences or missing backing; section gaps sum to 460; both old traces were checked against all four known lower aliases. No new performance or compatibility result is claimed.
Follow-up on table consumers and byte ownership
Memory-Reference-Table-and-Function-Ownership records six local access windows totaling 152 bytes, a disjoint public/anonymous walk-byte partition, and containing-block trace observations missed by exact-PC matching. Six window bytes overlap prior inferred decodes, so neither code-only classification nor exact table size is promoted from these observations. The 56,153-byte semantic remainder and 180 KiB physical image remain unchanged. No runtime ROM execution or safe-unused function is newly established.