Skip to content

Phase D.6.6-research-c iter-16 — host-side pair-state survey; Ed25519 CUPairedPeer store matched via Bonjour advert

Status: verified — 2026-04-24

Read-only survey of havoc's pair-state surface. The authoritative store is /var/db/lockdown/RemotePairing/user_{UID}/peers/<CoreDevice-UUID>.plist — an NSKeyedArchiver CUPairedPeer record with an Ed25519 public key. Peer records for our iPhone exist; devicectl still reports pairingState: unpaired because remotepairingd matches peers via live Bonjour _remotepairing._tcp.local adverts, and neither tunneld nor SPIKE backend publishes that mDNS service. CoreDevice's on-disk SQLite is a cache (0 data rows). System keychain has zero iPhone entries (Ed25519 keys live inline in plists). Full writeup: findings.md.

The gate, precisely

  1. iPhone advertises _remotepairing._tcp.local with an ident TXT (or similar) over BT LE / USB tunnel / Wi-Fi.
  2. remotepairingd resolves the advert, extracts ident, matches it against its in-memory peer-records (loaded at daemon start from RemotePairing/user_{UID}/peers/*.plist).
  3. On match, remotepairingd runs an Ed25519 challenge-response between host sk (in identity.plist) + peer pk (in peer file); the device's side uses its secure-enclave-held private key.
  4. Only on successful handshake does CoreDevice escalate to pairingState: paired / tunnelState: available and permit the back-connect to advertised service ports.

Wire-level Handshake patching (iter-12/14/15) cannot move this needle — the gate is a layer below RSD that requires both the correct mDNS advert AND a cryptographic challenge-response the device must sign with its own private key.

Plantability

UNKNOWN, leaning unfeasible without device private key. Structurally the peer file format is plantable, and we could advertise a fake _remotepairing._tcp.local service with matching ident. But the device-side Ed25519 verification uses the iPhone's secure-enclave-held private key — we can't forge that.

What iter-17 CAN decide cheaply: whether a planted peer + fake advert flips pairingState reported by devicectl before any actual cryptographic command runs (e.g. for a pure metadata query). If yes, we unblock at least info-query-level access to the device's back-connect flow.

Next step

iter-17 write-side, brief + reversible: plant a throwaway peer plist with our own Ed25519 keypair, advertise matching mDNS, kickstart remotepairingd, observe pairingState. Restore from backup at end. Backup-first discipline mandatory.

Files

  • findings.md — full survey, schema dumps, interpretation, iter-17 plan
  • index.md — this summary