xenia-rs/audit-runs/audit-068-host-mem-watch/writer-report-v4.md

AUDIT-068 Session 4 — writer identified (guest PPC code)

Date: 2026-05-20

Headline

Writer found. The host-side write of 0x8200A1E8 at [0xBCE251C0] is performed by JIT-emitted guest PPC code, NOT host C++ code. Reading-error #36 (POD struct-copy bypass) — registered in Sessions 2 and 3 as the explanation for the host-side surface gap — is partially superseded: the gap is real for host C++ writes, but the actual writer of THIS particular vptr install is on the guest side. AUDIT-067 (which hooks all 16 PPC store opcodes at JIT-emit time) caught it on the first try, once the correct target value 0x8200A1E8 was configured (per the Session 3 correction; AUDIT-067's prior runs watched the wrong value 0x8200A208).

No new instrumentation was needed. Session 4 used the existing AUDIT-067 machinery + Session 3's AUDIT-068 read-probe to cross-validate.

Writer PC and ctor chain

The ANON_Class_713383D7 instance is constructed via a three-level inheritance ctor chain, fully on the guest PPC side. Each ctor writes the next vtable down to slot 0:

sub_824FECE0  (deepest base ctor)
  ├─ stw r31, 4(r31)              ; *(this+4) = this  ← self-pointer
  ├─ stw r31, 8(r31)              ; *(this+8) = this  ← self-pointer
  ├─ stw r11=1, 12(r31)           ; *(this+12) = 1   (refcount?)
  └─ bl 0x8284DD1C                ; sub-helper on &this[+16]
       ↑ called from
sub_825065E8  (intermediate base ctor — writes vtable 0x8200A908)
  ├─ bl sub_824FECE0              ; chain to deepest base
  ├─ lis r11, 0x8201; subi r11, 22264 → r11 = 0x8200A908
  ├─ stw r11, 0(r31)              ; *(this) = 0x8200A908
  └─ bl 0x825051D8                ; sub-helper init of fields
       ↑ called from
sub_824FD240  (most-derived ctor — writes vtable 0x8200A1E8)
  ├─ bl sub_825065E8              ; chain to intermediate base
  ├─ lis r11, 0x8201; subi r11, 24088 → r11 = 0x8200A1E8
  └─ stw r11, 0(r31)              ; *(this) = 0x8200A1E8  ← THE INSTALL

The doubly-linked list head sentinel pattern observed by Session 3's read probe ({vptr, self, self} at offsets {0, +4, +8}) is now fully explained:

• Offsets +4 and +8 are written by the deepest base ctor (sub_824FECE0 at PCs 0x824FECFC and 0x824FED04) as *(this+4) = this; *(this+8) = this. This is the LIST_ENTRY head sentinel.
• Offset 0 is overwritten three times in rapid succession by the inheritance chain — landing on 0x8200A1E8 after sub_824FD240 completes. The read probe (1ms poll period) only ever sees the final value.

All three writes happen on the same 1ms poll tick from the read probe's perspective, which is why the install LOOKS like a 12-byte POD struct copy. It is actually 3 separate ctors writing 4 PPC stw instructions (one vtable slot, three list-init slots, plus a refcount byte that the read probe neighbor at 0xBCE251CC would have detected). The neighbor at 0xBCE251BC (-4) DOES NOT change because the ctor only writes at offsets >= 0.

Capture evidence

Run 11 — AUDIT-067 with corrected value 0x8200A1E8

Cmdline: --audit_67_value_watch=0x8200A1E8 --audit_68_host_mem_read_probe=0xBCE251C0:4:1000000 --audit_61_branch_probe_pcs=0x825070F0 --mute=true.

The very first PPC store of 0x8200A1E8 hit:

host_ns=10019392400  CHANGE   0xBCE251C0: 0xBCE25640 → 0x8200A908   (read probe — intermediate base ctor)
host_ns=10021528400  CHANGE   0xBCE251C0: 0x8200A908 → 0x8200A1E8   (read probe — most-derived ctor)
AUDIT-067-VAL pc=824FD264 lr=824FD258 val=8200A1E8 dst=BCE251C0
              r3=BCE251C0 r4=00000002 r5=00000020 r6=03A72280
              r31=BCE251C0 tid=6
AUDIT-061-BR pc=825070F0 lr=824F7B24 r3=BCE251C0 tid=6  (slot-1 dispatch fires
                                                         immediately after)

The intermediate-base vtable write at PC 0x8250660C (value 0x8200A908) was NOT in this run's AUDIT-067 watch list (only 0x8200A1E8 was), so only the most-derived hit is logged. Run 12 confirms.

Run 12 — AUDIT-067 with both vtable values + 3-slot read probe

Cmdline: --audit_67_value_watch=0x8200A1E8,0x8200A908,0xBCE251C0 --audit_68_host_mem_read_probe=0xBCE251C0:4:1000000,0xBCE251C4:4:1000000,0xBCE251C8:4:1000000 --audit_61_branch_probe_pcs=0x825070F0 --mute=true.

Captures the full ctor chain on a different cold-trajectory (instance at 0xBCE25340 this time — arena-drift sister of Run 11's 0xBCE251C0):

AUDIT-067-VAL pc=8250660C lr=82506600 val=8200A908 dst=BCE25340  (intermediate base ctor write)
AUDIT-067-VAL pc=824FD264 lr=824FD258 val=8200A1E8 dst=BCE25340  (most-derived ctor write)
AUDIT-061-BR pc=825070F0 lr=824F7B24 r3=BCE25340                  (slot-1 dispatch)

Both runs reproduce: the PC pair {0x8250660C, 0x824FD264} is invariant across cold runs. The instance address VARIES (arena drift), but the writer PCs do not.

Why earlier sessions missed this

Sessions 1+2

Hooked xe::store_and_swap<T>, xe::store<T>, Memory::Zero/Fill/Copy, xe::endian_store::set(), Memory::Copy byte-scan, 4 XEX-loader memcpy sites. These are HOST C++ write paths to guest memory. The JIT does NOT use them — JIT-emitted PPC stores compile down to direct x64 mov instructions operating on virtual_membase_ + va, with inline byte-swap intrinsics (bswap / pshufb). They bypass every xe::store* template.

Reading-error #35 (Session 1: "hook-surface incompleteness") was right to the extent that the surfaces don't cover all host-side write paths — but this writer was never on the host side at all.

Session 3

Read probe captured the install epoch (~9.4-9.6s host_ns) and the neighbor pattern (3 simultaneous writes within 1ms). The "POD struct copy bypass" hypothesis (reading-error #36) was a reasonable explanation under the constraint "host-write surfaces miss the install", but the actual cause is that the writes come from the JIT not from host code at all.

AUDIT-067 (prior to Session 4)

Watched value 0x8200A208. The CORRECT vptr value is 0x8200A1E8 (per Session 3's correction). AUDIT-067 was hooked into every PPC store opcode and would have caught the install on the first run if it had watched the right value. Session 4 re-ran it with the corrected value and caught the writer.

ours-side cross-reference

sub_824FD240 is GUEST PPC code present in the Sylpheed XEX. Both engines' JIT compiles and runs the same machine code given the same inputs. There is no host-side analog in xenia-rs/crates/xenia-kernel/ — and there shouldn't be: this isn't a kernel handler, it's a game's own class constructor.

Per xenia-rs/docs/functions/sub_824F7800.md:

AUDIT-064 ours --ctor-probe=0x824F7800 -n 500M: 0 fires.

The chain runs downstream of sub_822F1AA8's vtable[0] dispatch through sub_82173990 — which waits on tid=13 — so ours never reaches it because tid=13 is blocked on the AUDIT-049 wedge.

sub_824FD240 is reached via:

sub_824F8398
  → sub_824F7CD0
    → sub_824F7800
      → sub_824FD240   (call at PC 0x824F7838)  ← THE WRITER
      → ... bctrl at PC 0x824F7B20 dispatches sub_825070F0

In ours, the entire call chain above sub_824F7800 fires 0 times because the AUDIT-049 wedge blocks tid=13 upstream. Therefore the ANON_Class_713383D7 instance is never constructed, the vtable 0x8200A1E8 is never installed, and the bctrl at 0x824F7B20 never dispatches sub_825070F0.

This is consistent with all prior phase audits. Session 4 confirms the existing diagnosis: the divergence root is upstream at tid=13, not at the ANON_Class ctor or the worker dispatch.

Static-DB cross-check

PC	Function	Notes
0x824FECE0	sub_824FECE0 (deepest base ctor)	Writes self-pointers at +4/+8/+12; calls helper at 0x8284DD1C
0x824FECFC	inside sub_824FECE0	stw r31, 4(r31) — flink_ptr write
0x824FED04	inside sub_824FECE0	stw r31, 8(r31) — blink_ptr write
0x825065E8	sub_825065E8 (intermediate base ctor)	Calls deepest; writes vtable 0x8200A908
0x8250660C	inside sub_825065E8	stw r11, 0(r31) — vtable 0x8200A908 write
0x825051D8	called by intermediate base	Sub-helper initializing many +0xXX member fields
0x824FD240	sub_824FD240 (most-derived ctor)	Calls intermediate base; writes vtable 0x8200A1E8
0x824FD264	inside sub_824FD240	stw r11, 0(r31) — vtable 0x8200A1E8 write — THE INSTALL
0x824F7800	sub_824F7800	Allocates instance at +0x38 via sub_824FD230/sub_824FD240
0x824F7838	inside sub_824F7800	bl sub_824FD240 — invokes most-derived ctor
0x824F7B20	inside sub_824F7800	bctrl — dispatches sub_825070F0 via vtable slot 1
0x825070F0	sub_825070F0 (slot-1 method)	Worker fan-out target — AUDIT-067/061's original lookup

Static caller chain into sub_824FD240:

• Single static caller: 0x824F7838 inside sub_824F7800.
• The 4-fn dispatch ladder above (824F8398 → 824F7CD0 → 824F7800 → bctrl → 825070F0) was already classified by AUDIT-064.

ε-constraint validation

Session 3's install epoch bound was host_ns ∈ [9.4, 9.6] s. Run 11 observed install at host_ns=10.019s; Run 12 captured the intermediate base ctor write at host_ns ≈ 10s (read probe transition timestamps not explicitly logged in Run 12 grep output, but within boot's normal jitter window). The earlier session's ±200ms estimate was off — actual jitter is closer to ±500ms cold-to-cold. Update: epoch is host_ns ∈ [9.4, 10.1] s.

LOC added (Session 4)

Zero canary LOC added. All Session 4 work used existing AUDIT-067 (JIT-emit value watch in ppc_hir_builder.cc + ppc_emit_memory.cc) and Session 3's audit_68_host_mem_read_probe cvar machinery (read-mode probe thread in audit_68_host_mem_watch_base.cc).

Cumulative across Sessions 1+2+3 (canary): ~520 LOC additive, all cvar-gated default-off, retained in tree. Session 4 adds no LOC — the writer was identifiable by re-running existing instrumentation with the corrected target value.

Cascade outcome (Session 4)

• A: identify writer PC — PASS (sub_824FD240+0x24 at PC 0x824FD264; most-derived ctor of the inheritance chain).
• B: identify caller chain — PASS (sub_824F7800+0x38 → sub_824FD240; matches AUDIT-064's previously-known 4-fn dispatch ladder).
• C: identify ours-side analog presence — PASS (no host analog needed; guest PPC code; ours's JIT would execute the same code if reached, but the call chain is unreachable due to tid=13 AUDIT-049 wedge).
• D: reading-error class registration — PASS (see below; #36 re-scoped).

Net 4/4 wins (no in-progress items). Session 4 closes AUDIT-068.

Reading-error class re-scoping

#36 (POD-struct copy-assignment bypass) — registered Sessions 2+3 as the explanation for the host-side surface gap. Session 4 finding: this writer is NOT host C++; it is JIT-emitted PPC code. The class #36 framing remains valid in principle (host C++ POD copy IS a real bypass class, demonstrated by Session 2's reading-error #35 sanity), but it does NOT apply to THIS investigation. Updated rule:

Before adding new host-side write hooks, always check whether the writer could be GUEST CODE running under the JIT. AUDIT-067 (JIT-store value watch) is the cheaper first check. If AUDIT-067 with the correct target value still produces 0 hits, only THEN escalate to host-side surface hooks. The reverse order (Session 1+2's host-first approach) wastes instrumentation budget when the writer turns out to be guest-side.

Secondary rule: always cross-check the configured target value against the read probe's observed values. Session 1+2+3+AUDIT-067 all watched the wrong value (0x8200A208) because that was AUDIT-058's quoted value, which was actually the address of slot-1-WITHIN-the-vtable, not the vtable base. The read probe directly observed the correct value 0x8200A1E8 in Session 3 — Session 4 simply propagated that correction to AUDIT-067.

Artifacts (this dir)

• run11-audit067-corrected-value.log — AUDIT-067 with value 0x8200A1E8; 4 hits (1 install + 3 sibling instances in worker threads).
• run12-full-ctor-chain.log — AUDIT-067 with full ctor chain (vtable values 0x8200A1E8 and 0x8200A908 + self-pointer 0xBCE251C0) and 3-slot read probe; captures all 5 writer-related events on tid=6.
• writer-report-v4.md — this file.

Discipline observed

• xenia-rs HEAD e6d43a23ac393004d2e5adf2f0395fd0b5e6448b UNCHANGED ✓ (verified: sha256 of git diff HEAD at session start = ed30fd526643918f67311caff0a10d1346d73fd0c0323e02477883cf5ff20357; same at session end).
• --mute=true on every run ✓
• Cold-protocol: cache wipe + restore from /tmp/canary-cache-bak-audit-068 at session end ✓ (backup re-created at session start from current cache; prior session's backup was missing).
• Canary tree: no new instrumentation added (zero LOC delta). All Sessions 1-3 instrumentation retained as-is (cvar-gated default-off).
• No destructive shortcuts ✓.

AUDIT-068 closure

AUDIT-068 is CLOSED. The host-side writer of 0x8200A1E8 at [0xBCE251C0] is conclusively identified as guest PPC code at sub_824FD240+0x24 (PC 0x824FD264), the most-derived constructor of the ANON_Class_713383D7 inheritance chain. The intermediate base ctor at sub_825065E8+0x24 (PC 0x8250660C) writes the intermediate vtable 0x8200A908. The deepest base ctor at sub_824FECE0 writes the doubly-linked-list head sentinel (self-pointer writes at offsets +4 and +8).

The Phase-NonMatch divergence root remains the upstream tid=13 AUDIT-049 wedge, not the ctor or vtable. ours never reaches the calling code, so the instance is never constructed and sub_825070F0 never dispatches. No host-side analog is needed because the writer is part of the game's own code.

Recommended next steps (NOT Session 5 of AUDIT-068)

Move investigation upstream to the AUDIT-049 / Phase-W wedge at tid=13. That is where ours and canary actually diverge; the ANON_Class ctor and sub_825070F0 are downstream symptoms.

• Re-open the tid=13 wedge analysis under a new audit number.
• Cross-reference xenia-rs/audit-runs/phase-w-wedge-reattack/current-state.md for the most recent state.