Complex BIOS Size and Layout - Mainkill1/SpiritBoot GitHub Wiki
Complex BIOS size and memory layout
This is the dedicated layout reference for the supplied Complex4627 image. It explains the complete measured image, the parts of runtime RAM we can account for, function and table measurements, and the remaining gaps. Additional feature options of the supplied variant are unknown. Do not apply its numbers to every BIOS called Complex.
The investigation is based on authorized private inspection and bounded public-API guests in xemu. Published material is original numeric and behavioral research. Proprietary firmware contents, private strings, recovered instructions, table destinations and reconstructed control-flow graphs are not included.
For our implementation, see SpiritBoot-BIOS-Size-and-Layout. For matched differences, see Resident-Memory-Comparison. Measurements use 4,096-byte pages; KiB means 1,024 bytes. All address intervals exclude their final address.
1. Four different meanings of BIOS size
| Quantity | Measured size | Meaning |
|---|---|---|
| Supplied ROM file | 1,048,576 bytes / 1 MiB | Complete file container used in this investigation. |
| Distinct repeated quarter | 262,144 bytes / 256 KiB | The authorized reference investigator measured four byte-identical quarters of this supplied file. This establishes repetition, not four separate kernels. |
| Kernel virtual image envelope | 636,160 bytes | 0x80010000–0x800ab500, including initialization content and alignment. It is not the settled RAM charge. |
| Resident kernel image backing | 184,320 bytes / 180 KiB / 45 physical pages | Unique RAM pages still backing the image at the measured title checkpoint. |
| Total unavailable RAM, allocation/lifetime guest | 647,168 bytes / 632 KiB / 158 pages | 16,226 available out of 16,384 pages. Includes firmware, title and hardware allocations. |
| Total unavailable RAM, original public-entry guest | 659,456 bytes / 644 KiB / 161 pages | A different checkpoint, with 16,223 available pages. Do not average it with the allocation guest. |
A 4 MiB ROM mapping is an address window, not a 4 MiB firmware file or RAM allocation. The repeated file size does not establish the individual sizes of its bootstrap, compressed payload, settings or other components; that internal container partition remains unmeasured in the public ledger.
2. Complete resident image accounting
Every physical image byte is charged once:
| Resident content owner | Bytes |
|---|---|
| Image header | 704 |
Retained executable-flag region region_00 |
153,136 |
Retained writable regions region_01–03 |
28,772 |
| Surviving discardable content sharing a live page | 1,248 |
| Four gaps outside advertised content extents | 460 |
| Total unique resident backing | 184,320 |
The writable subtotal is 21,964 + 6,544 + 264 bytes. An executable section can contain constants and tables; its 153,136 bytes are not all proved instructions. The surviving discardable content is already within the 45 pages.
Virtual and physical layout
| Region | Virtual content interval | Content bytes | Intersected pages | Resident pages | Physical backing at checkpoint |
|---|---|---|---|---|---|
| Header | 0x80010000–0x800102c0 |
704 | 1 | 1 | 0x00010000–0x00011000 |
region_00: executable flag |
0x800102c0–0x800358f0 |
153,136 | 38 | 38 | 0x00010000–0x00036000 |
region_01: writable |
0x80035900–0x8003aecc |
21,964 | 6 | 6 | 0x00035000–0x0003b000 |
region_02: writable |
0x8003aee0–0x8003c870 |
6,544 | 3 | 3 | 0x0003a000–0x0003d000 |
region_03: writable |
0x8003ca00–0x8003cb08 |
264 | 1 | 1 | 0x0003c000–0x0003d000 |
region_04: discardable |
0x8003cb20–0x800ab4fa |
453,082 | 112 | 1 | First page survives at 0x0003c000–0x0003d000; 111 later intersected pages are unmapped. |
The unique retained physical interval is 0x00010000–0x0003d000. Row page counts are not additive: header/code, code/writable, adjacent writable regions and the beginning of discardable content share pages. See Memory-Reference-Deep-Census for the complete sharing explanation.
The four non-content gaps are 16, 20, 400 and 24 bytes at 0x800358f0, 0x8003aecc, 0x8003c870 and 0x8003cb08, respectively. Their 460-byte total cannot explain the hundreds-of-KiB difference from SpiritBoot. Deleting an interior gap would not necessarily free a page.
3. What the function measurements cover
The ledger contains 1,361 inferred entry walks: 329 distinct public callable entries, 929 anonymous direct-entry candidates and 103 anonymous indirect-entry candidates. The export interface has 330 callable slots with one address alias. These are recovered measurement roots, not an original compiler/linker function count.
Recursive decoding covers a 220,530-byte instruction union across retained and discardable regions. Adding each walk's length would produce 221,954 bytes and double-count 1,424 bytes. Within the retained region, the 94,726-byte union consists of 40,286 public-only bytes, 54,323 anonymous-only bytes and 117 bytes shared by public and anonymous walks. These are coverage categories, not independent allocations.
The retained decoded union includes 94,661 bytes owned by retained-entry walks and 65 shared with discardable-entry walks. Some walks cross lifetime boundaries. Therefore neither an inferred entry envelope nor a boot-only entry label proves its entire reachable code can be discarded.
Complete row-level references:
- Memory-Reference-Entry-Walk-Ledger — all 1,361 roots, anonymous/public identity, measured union/extent information and overlap caveats.
- Memory-Reference-Census — all 330 public entry comparisons with SpiritBoot. Entry/thunk sizes omit helper costs; the owned side of this older comparison is explicitly versioned.
- Memory-Reference-Table-and-Function-Ownership — disjoint function ownership, shared tails and bounded table consumers.
There are 199 public entries unobserved in bounded traces. None is proved globally unused. Interrupts, rare storage errors, reset, debugger and title-specific paths can retain apparently cold functions.
4. Retained code, metadata, tables and unresolved bytes
The current disjoint classification of the 153,136-byte retained executable-flag region is:
| Classification | Bytes | Evidence |
|---|---|---|
| Prior recursive instruction-byte union | 94,726 | Decode coverage; not a compiler-function partition. |
| Fixed export directory | 40 | PE format-defined extent. |
| Function-address array | 1,464 | 366 four-byte export slots. |
| Format-proved module-name storage | 13 | Extent only; contents withheld. |
| Additional trace-anchored decoded prefixes | 740 | Bounded prefixes from recorded PCs; not complete functions. |
| PE debug metadata | 109 | 28-byte directory plus 81-byte CodeView record. |
| Public ABI data footprints | 612 | 15 independently bounded interface objects. |
| Semantically unclassified | 55,432 | Exact remainder; not assumed unused code or padding. |
| Total | 153,136 | Disjoint byte accounting. |
The debug record's footprint is proved from its format, but contents are not published. The public ABI measurements establish the interface body, not a larger private allocation's end. All newly typed 721 bytes match between the two retained captures, with no absent bytes or overlap with previous decode classifications. Endpoint stability does not establish continuous immutability or last use.
Newly bounded data objects
| Public object / format | Interface or format | Offset within region_00 |
Proved bytes |
|---|---|---|---|
| PE debug directory | PE debug directory | 1,520 | 28 |
| legacy CodeView metadata record | legacy CodeView metadata record | 10,488 | 81 |
ExEventObjectType |
OBJECT_TYPE | 1,548 | 28 |
ExMutantObjectType |
OBJECT_TYPE | 1,576 | 28 |
ExSemaphoreObjectType |
OBJECT_TYPE | 1,760 | 28 |
ExTimerObjectType |
OBJECT_TYPE | 1,804 | 28 |
HalDiskCachePartitionCount |
ULONG | 8,320 | 4 |
IoCompletionObjectType |
OBJECT_TYPE | 1,896 | 28 |
IoDeviceObjectType |
OBJECT_TYPE | 1,924 | 28 |
IoFileObjectType |
OBJECT_TYPE | 1,952 | 28 |
MmGlobalData |
MMGLOBALDATA | 2,628 | 32 |
KeTimeIncrement |
CONST ULONG | 2,544 | 4 |
ObDirectoryObjectType |
OBJECT_TYPE | 2,680 | 28 |
ObSymbolicLinkObjectType |
OBJECT_TYPE | 2,708 | 28 |
PsThreadObjectType |
OBJECT_TYPE | 2,892 | 28 |
XboxKrnlVersion |
XBOX_KRNL_VERSION | 1,872 | 8 |
XePublicKeyData |
UCHAR[284] | 9,184 | 284 |
Indirect tables and page ownership
Ten retained-executable-region indirect-table candidates remain under investigation. Six local access windows support 152 bytes / 38 four-byte positions. They are bounded windows, not all ten objects' complete sizes. Of those 152 bytes, 146 belonged to earlier unknown content and six overlap previously inferred decode. This is an orthogonal access-evidence layer and must not be added again to the disjoint classification above.
Three pages containing those windows also contain 6,278 other decoded bytes. Even a table's complete last-use proof would not by itself make those pages reclaimable. Callback-bearing public objects likewise share backing with code and other data. The ten public object-type bodies contain 50 callback positions: 28 are RAM-backed non-null positions and 22 are null at the later capture. Their ten distinct non-null destinations are RAM-backed retained executable content; destination values and instruction bodies are withheld. This does not establish all future callbacks or their last use.
See Memory-Reference-Typed-Data-and-Backing, Memory-Reference-Table-and-Function-Ownership, Memory-Reference-Unclassified-Ranges and Memory-Reference-Content-and-ROM. The earlier unknown-range atlas describes its explicitly frozen earlier classification; the 55,432-byte total above includes the newer typed-object refinement.
5. Runtime allocations outside the image
The 180 KiB kernel image is only one part of the 632 KiB unavailable total. Public scalar counters at the frozen allocation checkpoint report five pool pages, 19 stack pages and 16 ordinary cache pages. Their definitions and overlap are not a complete private physical-owner census. In particular, the public image counter is not the measured resident kernel image; adding it to 180 KiB would mix categories.
The independent public guest performs 576 allocations across 18 request sizes and 40 thread lifetimes. Available pages return to 16,226 at its final checkpoint. The measured query capacity for a 512-byte pool request is 536 bytes and for a 1,024-byte request is 1,048 bytes. Those are reported capacities, not private allocator-header proofs. The default stack requirement observed through 12,288-byte requests remains three physical pages; this evidence does not justify shrinking SpiritBoot's 12 KiB live-stack minimum.
A complete reference heap/PFN/driver/cache owner census remains missing. The ledger deliberately does not invent those owners by subtracting public counters. Exact hidden cache reserves, private structure sizes, per-thread stack depth and complete allocator metadata are unresolved.
6. Does Complex run functions directly from ROM?
Startup ROM execution is observed; post-title ROM execution is not observed in the two retained public-API workloads. That is the result, not a universal no-ROM assertion.
| Observation | Result |
|---|---|
| Direct-ROM startup execution | 57 distinct block-entry PCs; 27,655 recorded entries in the final virtual 4 KiB page. |
| Runtime direct-ROM execution | Zero observed entries in the two covered workloads. |
| Known lower ROM aliases | Four distinct aliases across two mapping epochs; no observed entries in those intervals. |
| Sampled kernel/API entries | RAM-backed at the captured checkpoints. |
| Per-event physical instruction-fetch history | Unavailable; transient aliases or translation reuse cannot be fully attributed. |
At kernel entry, one 4 MiB window maps VA/PA 0xffc00000–0x100000000, with a lower 4 KiB alias at 0xc03ff000. Later captures show three 4 MiB windows beginning at 0xff000000, 0xff400000 and 0xff800000, with lower aliases 0xc03fc000, 0xc03fd000 and 0xc03fe000. These are mappings into the ROM region, not resident RAM owners.
The startup page may involve both the supplied MCPX input and BIOS bootstrap. Current traces do not assign every ROM entry to a Complex service. Nor does a mapped ROM address prove a callable function exists there. Gameplay, shutdown, storage-error and warm-reset paths need attributable instruction-fetch evidence before asserting direct-ROM services explain Complex's low RAM use.
7. What explains its smaller footprint, and what remains unknown
Measured advantages are smaller retained image content, boot-content retirement, different reported pool capacities, and prompt allocation retirement in the covered guest. The evidence does not establish a magic ROM-call mechanism or that the difference is merely alignment.
The research priorities are to finish readonly/callback-object lifetime accounting, identify remaining resident data with bounded access evidence, and measure the missing dynamic physical owners. An unobserved function is not a deletion candidate until its ABI, callback, interrupt, error and reset consumers are addressed.
Evidence and maintenance
This page combines the frozen Complex4627 layout census, two retained block-entry traces, the function-walk/unknown-range ledgers, table/function ownership addendum and the newer typed-retained-data audit. It does not announce a new firmware patch or game-performance measurement. The public ABI footprint study records its retrieved XboxDev/nxdk header blob; proprietary inputs remain private. Update this page only with a named artifact/checkpoint and a disjoint accounting reconciliation.
Current plain-main comparison and third reference
The new Retail-5838-BIOS-Size-and-Layout keeps the supplied retail kernel separate from Complex. SpiritBoot-Main-Emitted-Extent-Ledger records every exact emitted extent in the source/artifact bound to the plain-main capture at f60f8de605cb, excluding ROM/pool experiments. SpiritBoot-Main-Physical-Ownership accounts for all 332 unavailable pages at its completed guest checkpoint. Memory-Reduction-Targets compares those results, preserves historical revision boundaries, and links the updated reduction issues. The historical figures on this page are not silently replaced or upgraded.
Three BIOS comparison guide
Memory-Comparison-and-Removal-Guide reconciles the initial and post-activity gaps, distinguishes image from runtime backing, and lists the owner/lifetime proof needed for each saving. Memory-Three-BIOS-Public-API-Comparison places all 366 reference ordinals in one table, keeping inferred reference walks separate from exact owned compiler extents.