VisualDev
DEEN
Imprint Privacy Licenses

Hiatus Remote

Remote support where the relay sees nothing. Screen, files, shell and audio, end-to-end encrypted.

Version 1.0.0-rc1 · Release candidate
Download Manual

Windows · Linux (X11) · macOS · Android debugging

Hiatus Remote main window: own ID, one-time password and connecting to a partner

Threat model

Hiatus Remote is designed against these attackers. Outside the model remains an attacker with administrator or root rights on one of the two endpoints: they can read everything anyway.

Attacker Goal Countermeasure
Relay operator (compromised or curious) Decrypt the session, guess the password, impersonate the partner SPAKE2+ per RFC 9383: the password never leaves the endpoints; channel binding to the TLS exporter; end-to-end encryption; device key pinning
Passive eavesdropper (Wi-Fi, ISP) Read screen, files, input TLS 1.3 to the relay with SPKI pin, QUIC/TLS 1.3 between the devices, plus payload encryption with AES-256-GCM or ChaCha20-Poly1305 on top
Active man-in-the-middle Get between supporter and target Keys are bound to the password; a differing fingerprint shows up during comparison; device key pinning for known devices
Password guesser Try one-time or permanent passwords One attempt per handshake; lockout with exponential backoff on the target; new one-time password after three failures; Argon2id verifier for the permanent password
Malicious partner Attack the supporter's computer through manipulated video data, file names or terminal output Decoder in its own process under AppContainer or seccomp; fuzzed parsers; validated names and limits for folder downloads; libvterm without OSC 52
Local user without rights on the target Abuse service or agent for privilege escalation Hardened IPC with peer verification; agent pipe only for SYSTEM with a start token; settings only with administrator rights
Scammer ("support scam") Talk the victim into granting access Clear warning in the request dialog, fine-grained permissions (everything except the screen off by default), always visible notice bar with abort

Cryptography

Key exchange

SPAKE2+ per RFC 9383, cipher suite P256-SHA256-HKDF-SHA256-HMAC-SHA256, over the signalling channel. The server never knows the password. Own module on OpenSSL primitives, verified against the RFC test vectors and Wycheproof. K_shared

Channel binding

Right after the QUIC handshake each side sends HMAC(K_bind, TLS exporter). If the value does not match, the connection ends immediately. The QUIC connection is thus bound to the PAKE; self-signed certificates suffice. K_bind

End-to-end

AES-256-GCM, ChaCha20-Poly1305 on devices without AES acceleration; the choice is part of the transcript. 96-bit nonce from stream ID and strictly monotonic counter, rekeying after 2³² records or 60 minutes. AEAD

Key derivation

HKDF-SHA256 from K_shared with fixed labels: direction keys, binding, fingerprint, resumption token, device authentication; a separate subkey per QUIC stream. HKDF-SHA256

Fingerprint

Four words from a fixed list of 256 German words (32 bits), alternatively six digits or a QR code, visible on both sides. Comparing them exposes an attack even if the password travelled over an eavesdropped channel. falke · ahorn · kupfer · welle

Unattended access

Permanent password (at least 12 characters) stored only as an Argon2id verifier, device key (Ed25519) pinned, allowlist of permitted supporters, service without UI, lock after the session. Argon2id · Ed25519

What the relay sees

Sees

  • IDs of both sides and timestamps
  • IP addresses and ports for hole punching
  • Packet sizes and data volume in the fallback case
  • The SPAKE2+ transcript, from which nothing can be derived without the password

Does not see

  • The password, neither one-time nor permanent
  • Screen contents, keystrokes, files, audio
  • The fingerprint or the session keys
  • Whether a direct connection was established (no payload)

Traffic analysis (who talks to whom, for how long) is deliberately out of scope. Anyone who wants to avoid it runs the relay themselves; the Docker image is meant for exactly that.

Process hardening

  • All programs are built with warnings as errors and hardening flags; BinSkim checks Dynamic Base, High Entropy VA, NX, Control Flow Guard, CET and /Qspectre in every full check.
  • Key material lives in SecretBytes (non-copyable, fixed size) and is wiped with OPENSSL_cleanse on release.
  • The decoder runs in an AppContainer on Windows and under seccomp on Linux; shared memory to the agent is read-only.
  • Tunnels only reach localhost and approved ports; Android debugging by address is restricted to private networks and recorded in the history.

Security review M8

In October 2026 the release candidate was reviewed in a structured way: threat model checked against today's feature set, code review in five areas (handshake and crypto; identity, allowlist, relay; local IPC; privileged paths and installer; files, shell, tunnels, adb), an overnight fuzzing run over 26 targets with mutation testing, clang-tidy and MSVC /analyze, BinSkim, CVE matching of the 22 dependencies against the NVD. The findings that needed fixing have been addressed; a few notes were accepted as residual risk and documented. An external penetration test was not part of the review.

Limits

  • The fingerprint only protects if users actually compare it. The UI prompts for it but does not enforce it.
  • The relay sees metadata. Only your own relay protects against traffic analysis.
  • Code signing (Authenticode, minisign) follows with publication; until then the SHA-256 checksum per file applies.
  • An attacker with administrator rights on an endpoint is outside the model.