Phase D.6.6-research-b iter-14 — UDID patch alone does not unblock CDS back-connect (H-HS narrowed slot #1 FALSIFIED)

Status: verified — 2026-04-24

Added env-gated UDID patching to the Handshake emitter (IOSMUX_HANDSHAKE_UDID=<25-char-UDID> at fixture offset 0x34BC), deployed, and ran the iter-12 wide-pcap trigger (devicectl device info details) with the patched UDID matching tunneld's advertisement. Across 4 runs: Handshake carries the correct UDID (backend verbose log confirms), devicectl reports pairingState: unpaired + Mercury warning (same as iter-12), 0 SYN to any advertised service port in a 30-second observation window. H-HS narrowed form slot #1 (UDID alone) is falsified. Full writeup: findings.md.

Signal worth remembering

Close-timing shifted from ~30 s (iter-12, zero UDID) to ~3 s (iter-14, patched UDID). The patched UDID is being consumed by CDS — it makes a faster adverse disposition, not a back-connect. Evidence the gate has multiple checks; UDID is one of them, but alone is not enough.

Methodology correction surfaced

tunneld-advertised UDID ≠ devicectl CoreDevice UUID. The first run used the wrong identifier and devicectl returned device not found. Runs 2–4 use the CoreDevice UUID (from devicectl list devices) as --device arg while the hardware UDID goes into the wire Handshake. iter-12's placeholder <devicectl-uuid> meant CoreDevice UUID.

Proposed next step

Combined patch: UDID + SerialNumber + ECID all set from tunneld / ioreg values in a single session. If still 0 back-connect SYNs, pivot from wire-state H-HS to host-side pair-state investigation (CoreDevice paired-devices DB).

Files

• findings.md — full methodology, 4-run table, hypothesis update, next steps, reproduce recipe
• index.md — this summary