VisualDev
DEEN
Impressum Datenschutz Lizenzen

Hiatus Remote

Remote-Support, bei dem der Relay nichts sieht. Bildschirm, Dateien, Shell und Ton, Ende-zu-Ende verschlüsselt.

Version 1.0.0-rc1 · Release-Kandidat
Download Handbuch

Windows · Linux (X11) · macOS · Android-Debugging

Hauptfenster von Hiatus Remote: eigene ID, Einmal-Passwort und Verbindung zu einem Partner

Architektur

Hiatus Remote besteht aus sechs klar getrennten Prozessen. Der Supporter arbeitet im Client, auf dem Target laufen Dienst und Agent, und der Relay-Server sieht in beiden Richtungen nur verschlüsselte Pakete. Die Videodekodierung läuft in einem eigenen, eingesperrten Prozess.

hiatus-relay Docker · 443 TCP/UDP, 444 UDP sieht nur verschlüsselte Pakete SUPPORTER-RECHNER hiatus-client Qt Quick · Sitzung, Dateien, Shell hiatus-decoder Sandbox: AppContainer / seccomp Android-Gerät adb · Logcat, Fernsteuerung TARGET-RECHNER hiatus-service Systemdienst · unbeaufsichtigt hiatus-agent Benutzersitzung · Bildschirm, Eingabe hiatus-pty-host Remote Shell Relay-Fallback · TLS 1.3 Relay-Fallback · TLS 1.3 Direkt · UDP Hole Punching · QUIC · E2EE IPC adb IPC, gehärtet Terminal als Benutzer Ende-zu-Ende verschlüsselt sieht nur Metadaten / verschlüsselte Pakete Sandbox-Prozess
Komponenten und Verbindungen · UML-VerteilungsdiagrammIn voller Größe öffnen

Komponenten

Prozess Läuft auf Aufgabe
hiatus-client Supporter und Target Oberfläche (Qt Quick): Sitzungen, Dateibrowser, Shell, Android-Debugging; die Logik liegt in Qt-freien Bibliotheken
hiatus-decoder Supporter Videodekodierung, Ton und Bilder der Zwischenablage von der Gegenseite in eigenem Prozess; AppContainer (Windows) bzw. seccomp (Linux)
hiatus-service Target Systemdienst für unbeaufsichtigten Zugriff; nimmt Verbindungen auch ohne angemeldeten Benutzer an und startet den Agent in der Benutzersitzung
hiatus-agent Target Bildschirmaufnahme, Eingabe, Dateien und Audio in der jeweiligen Benutzer- oder Anmeldesitzung
hiatus-pty-host Target (Windows) Hält Terminal und Shell für die Remote Shell als angemeldeter Benutzer, nicht als SYSTEM
hiatus-relay Server (Docker, Windows-Dienst) Vergibt IDs, vermittelt Verbindungen, begrenzt Verbindungsversuche und leitet Pakete weiter, wenn kein Direktweg zustande kommt

Verbindungsaufbau

Von der ID-Anfrage bis zum ersten Bild: Das Passwort wird nie übertragen, der Relay bekommt es nie zu sehen.

ID-Anfrage. Beide Seiten melden sich am Relay über TLS 1.3 an, dessen Schlüssel per SPKI-Pin im Zugangscode hinterlegt ist, und erhalten ihre ID. Der Supporter fragt die Partner-ID an.

SPAKE2+-Handshake. Über den Signalisierungskanal wird aus dem Einmal-Passwort ein gemeinsamer Schlüssel K_shared abgeleitet, ohne das Passwort zu senden. Beide Geräteschlüssel, die IDs und die Protokollversion fließen in den Transcript ein.

Hole Punching. Beide Seiten tauschen Adresskandidaten aus und versuchen eine direkte UDP-Verbindung, bei symmetrischer NAT mit gezielter Portsuche. Scheitert das, bleibt der Relay-Pfad; bei gesperrtem UDP per TCP.

QUIC und Channel Binding. QUIC-Handshake (ngtcp2, TLS 1.3); der TLS-Exporter wird an K_shared gebunden, Richtungsschlüssel werden per HKDF abgeleitet. Beginnt eine Sitzung über das Relay, wechselt sie ohne Unterbrechung auf den Direktweg, sobald einer gefunden ist.

Verbindungsaufbau: von der ID bis zum ersten BildSupporterRelay-ServerTargetAnmeldung, TLS 1.3 mit SPKI-PinAnmeldung, eigene IDVerbindungswunsch an ID 482 917 305Anfrage des SupportersSPAKE2+ (RFC 9383) über den Signalisierungskanal:beide beweisen das Passwort, ohne es zu senden.Ergebnis: gemeinsames Geheimnis K_sharedSPAKE2+ Nachricht (pA)weitergeleitetSPAKE2+ Nachricht (pB, confirmV)weitergeleitetconfirmPZustimmungsdialog, Fingerprint, BerechtigungenAdresskandidatenAdresskandidatenUDP Hole Punching, QUIC-Handshake (TLS 1.3)Channel Binding: HMAC(K_bind, TLS-Exporter)Channel Binding bestätigtAb hier Ende-zu-Ende: AES-256-GCM je Stream.Scheitert der Direktweg, laufen dieselben Pakete über das Relay.Bild, Eingabe, Dateien, Shell
Verbindungsaufbau · UML-SequenzdiagrammIn voller Größe öffnen

Unbeaufsichtigter Zugriff

Mit dem Hiatus-Dienst ist ein Rechner erreichbar, ohne dass jemand davor sitzt, auch am Anmeldebildschirm. Der Dienst prüft das permanente Passwort gegen einen gespeicherten Argon2id-Verifier, gleicht den Geräteschlüssel des Supporters mit der Allowlist ab und startet den Agent in der aktiven Sitzung. Einstellungen ändert nur ein Administrator; unter Linux über eine polkit-Aktion.

Unbeaufsichtigter Zugriff: Dienst und AgentSupporterhiatus-service (SYSTEM)hiatus-agent (Sitzung)Verbindungswunsch mit permanentem PasswortSPAKE2+ gegen den gespeicherten Argon2id-Verifier;das Passwort selbst liegt nirgends auf der Platte.Geräteschlüssel des Supporters prüfen (Allowlist, Pinning)Optional: angemeldeten Benutzer fragen (30 s)Agent in der aktiven Sitzung starten (Start-Token)Bereit, Shared Memory nur lesendEnde-zu-Ende verschlüsselte SitzungBildschirm, Eingabe, Dateien mit BenutzerrechtenBilddatenBild, Statusleiste zeigt Route und RTTSitzung beendenRechner sperren (Voreinstellung)Verlauf: wann, wer, wie lange, welche Berechtigungen
Unbeaufsichtigter Zugriff · UML-SequenzdiagrammIn voller Größe öffnen

Schichtenmodell

Die Logik liegt in Qt-freien Bibliotheken, die Qt-Quick-Schicht ist dünn. Eine CMake-Regel (hiatus_forbid_qt()) bricht die Konfiguration ab, wenn eine Logikbibliothek gegen Qt linkt.

  • Qt Quick · Fenster, Dialoge, Bindungen, ViewModels: keine Logik
  • support · adb · Sitzungslogik, Dateitransfer, Shell, Audit-Log, Android-Werkzeuge (Dateisystem, ADB-Shell, Logcat)
  • session · connect · remote · Sitzungsprotokoll, Verbindungsaufbau, Hole Punching, Relay-Fallback, Host- und Viewer-Seite
  • protocol · net · Nachrichtenformat (Protobuf), Framing, QUIC (ngtcp2), TLS-Adapter mit SPKI-Pinning
  • crypto · common · SPAKE2+, HKDF, AEAD, Argon2id, Ed25519; Grundtypen, Fehler, Protokollierung

Netzwerk und Relay

  • Ports am Relay: derselbe Port für TCP (TLS 1.3, Signalisierung) und UDP (Hole Punching, Weiterleitung), Standard 443, dazu UDP 444 für Adressabfragen zur Erkennung symmetrischer NATs.
  • Direktverbindungen ohne Relay, etwa im VPN: Adresse statt ID, Standardport 47443, Zertifikat beim ersten Kontakt bestätigt und danach gepinnt.
  • Relay-Datei oder Zugangscode hiatus://relay.example.org:443?pin=sha256:… zur Verteilung an Clients; das Docker-Image erzeugt Zertifikat und Zugangscode beim ersten Start selbst.
  • Qualitätssteuerung: adaptive Bitrate bis 16 Mbit/s und 60 Bilder/s, Modi Automatisch, Qualität, Geschwindigkeit, Manuell.

Teststrategie

Unit

Jede Logikbibliothek ohne Qt und ohne Netz; CTest-Label unit.

Integration

Client, Dienst und Relay als echte Prozesse im Verbund; NAT-Szenarien (Cone, symmetrisch, UDP gesperrt, IPv6, VPN) in Docker.

Fuzzing · Sanitizer

Protokollparser mit libFuzzer, ASan und UBSan; Nachtläufe über 26 Ziele, Mutantentests gegen eingebaute Fehler.

BinSkim · clang-tidy

Härtungs-Flags der Binärdateien (CFG, CET, ASLR, NX), statische Analyse mit clang-tidy und MSVC /analyze, SBOM mit CVE-Abgleich.

Technologie-Stack

C++23 mit CMake und vcpkg; Qt 6 für den Client (LGPLv3, dynamisch gelinkt); OpenSSL für TLS und Kryptografie-Primitive; ngtcp2 für QUIC; Protobuf für Nachrichten; OpenH264 und libyuv für Video, Opus für Ton, libvterm für das Terminal; SQLite für die Geräte-Datenbank des Relays; asio für Netzwerk-I/O. Pakete: MSI (WiX) für Windows, systemd-Units und polkit-Richtlinie für Linux, Docker-Image für das Relay.