volume modem chatroom · e2e encrypted · no network · index
derives a 256-bit AES-GCM key via PBKDF2-SHA256 (600k iterations) from the passphrase + the literal string "zebra-report-v1" as salt. Anyone with the same phrase joins the same room.
your public key (click to copy):
add one peer at a time. each add derives a 1-to-1 shared key and lets you exchange messages with that peer.
a silent stereo carrier is published to PulseAudio. Each frame modulates the GainNode between MARK (80%) and SPACE (20%) per bit. A local introspector (see “receive” below) polls PA sink-input state and decodes.
OFFER and READY frames travel at fixed ZEBRA_BAUD_HANDSHAKE=50.
Each peer measures its own scheduling jitter, broadcasts its max baud, and
the room settles on min(all peers).
expects zebrad at ws://127.0.0.1:7777. The bridge
polls PulseAudio sink-input volumes via PA IPC and pushes decoded frames here.
Without it the page transmits but cannot receive. The
recovered rx.c handles
decoding; zebrad is the WebSocket wrapper around it.
peers in room:
log:
This page is the “production” zebra-report protocol:
a covert peer-to-peer chatroom whose data path is PulseAudio sink-input
state. Chat content never enters an IP packet — Wireshark sees only the
websocket between this browser tab and the local zebrad bridge,
and even that traffic is post-encryption ciphertext + frame metadata.
Protects against: a network-level observer (Wireshark, IDS, DPI middlebox, ISP) seeing chat content. None of it crosses the network.
Does not protect against: (1) other same-UID processes that can poll PulseAudio — this is the entire attack surface zebra-report demonstrates; (2) an endpoint compromise of either peer's machine; (3) traffic analysis against the encrypted ciphertext over many sessions; (4) anyone able to run a microphone in earshot of the speakers (n/a here — this protocol's bytes don't ride on speaker audio energy).
Mitigation for defenders: require PulseAudio clients to hold a capability before reading peer sink-input volumes. The current design grants any same-UID process unrestricted read access — that's the published defect this whole project documents. See foxhop.net/linux-audio-ipc-attack-surface for the full whitepaper.