# Phase C — ground-truth reference

## Third reference: the pre-extracted `.pe`

- Path: `/home/fabi/RE - Project Sylpheed/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).pe`
- SHA-256: `9be5f5621c517c78a451245eca25d54388af741ed20e669b2f78438aaa429e72`
- Size: 9568256 bytes == `xex_image_size`
- `file(1)`: `PE32 executable (XBOX) PowerPC (big-endian), for MS Windows, 14 sections`

## Provenance

Generated by `tools/xex-extract/` (Rust tool in this workspace). The tool:

1. Parses the XEX2 header from the ISO's `default.xex`
2. Decrypts the encrypted body using XEX2 retail AES-128 key
3. Decompresses (LZX for normal-compressed XEXs)
4. Verifies `MZ` PE signature
5. Writes the resulting raw PE image to `<stem>.pe`

The tool is **completely independent of both canary and ours** — it is
an offline XEX2 decoder with its own AES + LZX implementations. This
makes the `.pe` file a true third reference for the post-decode XEX
content.

## Layout

The `.pe` file is a **flat virtual image**: byte offset N in the file
corresponds to guest VA `image_base + N` = `0x82000000 + N`. Verified
by sampling:

- offset 0x000000: `4d 5a 90 00 ...` → MZ DOS header at image_base ✓
- offset 0x150000 (= `.text` virtual_address): `7d 88 02 a6 ...` → PPC
  `mflr r12` function prologue ✓
- offset 0x910800 (= `.reloc` virtual_address): `0c aa 8f f6 ...` → PE
  base-relocation block records ✓
- offset 0x144C00 (= `.text` raw_offset, but ≠ virtual_address):
  `00 00 ... 00` → padding gap (zero), confirming raw-offset is NOT
  the layout key in this file ✓

This means the engines' loaded image at `[0x82000000, 0x82920000)`
should match `.pe` byte-for-byte **modulo** runtime patches (import
slots, relocations).

## What `.pe` represents

The `.pe` is the **post-decode pre-patch** XEX content. It contains:

- PE headers (DOS+NT+section table)
- Each section's raw bytes laid out at its virtual address
- XEX import-record markers at the slot addresses listed in the XEX
  import table (record_type=0 → 4-byte u32 BE ordinal; record_type=1 →
  16-byte thunk template `01 00 ord_hi ord_lo / 02 00 ord_hi ord_lo /
  mtspr ctr,r11 / bctr`)
- Base relocations in `.reloc` (not applied)

It does NOT contain:

- Runtime import-slot patches (variable addresses, thunk shim bytes)
- Applied base relocations
- Any per-engine runtime state

## Verification this session

Computed `image_canonical_sha256` (XEX import slots masked to 0xCD) over
all three:

| source | canonical sha256 |
|---|---|
| canary loaded image | `62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96` |
| ours loaded image | `62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96` |
| .pe pre-patch | `62c51908e2df705583fe81a084f39bd399196f9000cfa7bffd56127b41a4ab96` |

All three match. This is the strongest possible evidence that:

1. Both engines decode the XEX2 file to the same canonical content.
2. The .pe reference is correctly aligned to engine-loaded virtual VA.
3. There is no XEX-decode bug in either engine at this layer.

## Conclusion

`.pe` is **validated as ground truth** for the post-decode XEX image
content at `[image_base, image_base + image_size)`, modulo runtime
patches.