xenia-rs/audit-runs/phase-c-first-divergence/classification.md

Phase C — first-divergence classification

The raw first byte-diff

Guest VA	0x82000600
File offset	0x00000600
Section	.rdata (start of section, virtual_address = 0x600)
canary byte	0xde (start of de ad c0 de poison pattern)
ours byte	0x00
.pe byte	0x00

The diff is the xam.xex variable-import slot table

xex.json lists 52 record_type=0 imports for xam.xex, each at a sequential 4-byte slot starting at address = 0x82000600:

xam.xex ord=652 rt=0 addr=0x82000600
xam.xex ord=700 rt=0 addr=0x82000604
xam.xex ord=705 rt=0 addr=0x82000608
xam.xex ord=725 rt=0 addr=0x8200060c
...

The next 204−52 = 152 record_type=0 slots are for xboxkrnl.exe, continuing at 0x820006D0..0x82000934.

What each engine writes at these slots

	record_type=0 (var slot, 4 bytes)	record_type=1 (thunk, 16 bytes)
canary	de ad c0 de (poison sentinel)	host-shim bytes: 44 00 00 42 / 4e 80 00 20 / 60 00 00 00 / 60 00 00 00 (sc; blr; nop; nop)
ours	00 00 00 00 (zero)	leaves .pe bytes in place (01 00 ord_hi ord_lo / 02 00 ord_hi ord_lo / mtspr ctr,r11 / bctr)
.pe	XEX import-record tag: 00 00 ord_hi ord_lo	template thunk: 01 00 ord_hi ord_lo / 02 00 ord_hi ord_lo / mtspr ctr,r11 / bctr

Classification: import-thunk / ε-class allocator drift

This matches tripstone #2 of the Phase C brief verbatim:

Import thunks are legitimately engine-specific. If first byte-diff is in a thunk, canonicalize and re-find first diff.

The two engines implement different HLE dispatch strategies:

• canary: in-place thunk patching. Overwrites the guest XEX bytes with host-shim instructions; record_type=0 slots get 0xDEADC0DE poison (canary panics if a guest dereferences an unimplemented import variable).
• ours: HLE dispatch happens at the JIT translation layer, not by patching the thunk. Record_type=1 thunks keep their original .pe bytes; record_type=0 slots get zeroed (still distinguishable from the .pe ordinal-tag content if guest code reads them).

Both are valid engine implementation choices.

After canonicalization — the real check

Mask all import-slot bytes (record_type=0 = 4 bytes per slot, record_type=1 = 16 bytes per slot, total 3920 bytes across 398 slots) to 0xCD in canary, ours, AND .pe. Then compare:

canary canonical sha256: 62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96
ours   canonical sha256: 62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96
pe     canonical sha256: 62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96

All three match. Bytes differing canonical: 0.

Conclusion

There is NO real engine divergence at the image-load layer.

• Both engines decode the XEX2 file correctly.
• Both load it into guest memory at the correct virtual addresses.
• Both produce byte-identical content outside the import-patch region.
• Even .pe (an independent third-party offline XEX2 decoder) produces the exact same canonical content.

The Phase B image_loaded_sha256 δ-content-STOP was a false positive caused by an overly strict invariant: hashing engine-specific runtime patches as if they were XEX content.

What the fix is

The fix is in the comparison framework, not the engines:

1. diff_state.py: relaxed STOP invariant — when --xex-json is provided AND both snapshots contain image.bin, compute and check image_canonical_sha256 (engine-mask agnostic) as the real STOP key. The raw image_loaded_sha256 is still reported but is informational.
2. phase_b_snapshot.{rs,cc}: when phase_b_dump_section_content is set, emit image.bin (raw bytes of the XEX image region) so the diff tool can perform canonicalization. Default-off; cvar-OFF binary digest is byte-identical to pre-Phase-C baseline.

What this implies for downstream divergences

The Phase B catalog's 57 remaining divergences (post-image-load) are still meaningful — they describe real differences in stack/PCR/TLS allocation strategy, heap layout, kernel-object population, and exports-table state. These are now interpretable on a verified canonically-equivalent image baseline.

The Phase A diff's first runtime divergence at tid_event_idx=113 (KeQuerySystemTime return_value) is the next Phase C+1 target. It is not a downstream symptom of the image-load mismatch; it is the next genuine engine divergence in the kernel-call sequence.