Whitepaper zu RoamSwitch-Architektur und -Sicherheit

§1

RoamSwitch ist eine Menüleisten-App für den Mac. Je nachdem, wie sehr Sie dem Netzwerk vertrauen, dem Sie vertrauen aktuell verbunden, schaltet es automatisch die macOS-Firewall, die Freigabedienste, AirDrop usw. um. und DNS. Es überwacht auch ARP-Spoofing, nach außen offene Ports, USB-Speicher usw Ransomware-ähnliche Verschlüsselungsaktivitäten, und wenn etwas Gefährliches entdeckt wird, geht es so weit Unterbrechen des Datenverkehrs mit dem Paketfilter (pf) – ein Notfall-Air-Gap.

Mit anderen Worten: RoamSwitch installiert einen Root-privilegierten Daemon und könnte, wenn er wollte, alle stoppen Netzwerkverkehr auf dem Mac. Es wird von einer Person gebaut und „Bitte vertrau mir“ reicht nicht aus rechtfertigen Sie dieses Privileg. Stattdessen erklärt dieses Dokument das Design in einer Form, die Sie überprüfen können.

Für wen das ist

• Ingenieure entscheiden über die Installation
• Sicherheitsforscher und Journalisten, die vor einer Rezension oder einem Artikel die Interna verstehen wollen
• Sicherheitspersonal bei Partnerunternehmen evaluiert einen internen Rollout oder eine OEM-Bündelung

Was dieses Dokument nicht abdeckt

Es geht nicht um die Optimierung der Erkennungsschwelle, falsch-positive Statistiken oder exemplarische Vorgehensweisen für die Benutzeroberfläche. Es erklärt vier Dinge: Privilegien, Prozessgrenzen, Datenfluss und Kryptographie. Die Funktionsspezifikationen selbst befinden sich in der gebündelten MCP-Ressource roamswitch://docs/features und in der In-App-Hilfe.

Was wird offengelegt und wie weit (Offenlegungsrichtlinie)

Dieses Dokument basiert auf der Annahme, dass ein Angreifer bereits über die verteilte Binärdatei verfügt. Alle Endpunkt-URLs, Kennungen, Dateipfade, XPC-Protokolle und eingebetteten öffentlichen Schlüssel, die hier angezeigt werden kann in wenigen Minuten aus dem Versand RoamSwitch.app gezogen werden strings, codesign -d oder ein Verkehrsproxy. Schreiben Sie sie daher hier auf gibt einem Angreifer nichts Neues. Der einzige Fortschritt ist das Verständnis des Rezensenten.

Andererseits ist die serverseitige Implementierung nicht aus der Binärdatei ersichtlich – Rate-Limit Schwellenwerte, Schlüssel, Admin-Endpunkte, das DB-Schema, das Firebase-Projektlayout – sind nicht enthalten. Das OEM- und Partner-Integrationsdesign liegt hier ebenfalls nicht im Rahmen und wird separat behandelt internes Dokument. „Was man durch die Beobachtung des Klienten lernen kann“ lautet die Offenlegungszeile hierfür Dokument.

§2

RoamSwitch.app besteht aus drei ausführbaren Dateien. Nur einer von ihnen ist privilegiert; die Die anderen beiden werden mit Login-Benutzerrechten ausgeführt. Alle drei werden mit aktivierter Hardened Runtime und Entwickler-ID ausgeliefert unterzeichnet und notariell beglaubigt.

Berechtigungen und Unterzeichnung

• Alle drei Ziele haben ENABLE_HARDENED_RUNTIME = true.
• App Sandbox ist deaktiviert (com.apple.security.app-sandbox = false). Die Berechtigungen des Helfers und des MCPServers sind leere Wörterbücher.
• Distributions-Builds werden vom Entwickler-ID-Antrag unterzeichnet, von Apple notariell beglaubigt und geheftet (§10).

§3

Wie es registriert wird

Der Helfer wird mit SMAppService.daemon(plistName:) als LaunchDaemon registriert. Die plist in die App eingebettet (Contents/Library/LaunchDaemons/com.tetsuharu.RoamSwitch.Helper.plist) deklariert nur Label, BundleProgram, ein einzelner MachServices-Eintrag und AssociatedBundleIdentifiers. Aufgrund der Funktionsweise von SMAppService Eine Registrierung ist nicht einmal möglich, es sei denn, die App ist in /Applications. Am ersten Nach der Registrierung wird der Helfer erst dann aktiv, wenn der Benutzer ihn im System manuell genehmigt Einstellungen.

Wessen Verbindungen es akzeptiert (ClientValidator)

Der Helfer überprüft den Verbindungsvorgang in NSXPCListeners shouldAcceptNewConnection und verteilt HelperProtocol nur an diejenigen, die passieren. Die Inspektion verwendet den audit_token anstelle der PID Vermeiden Sie die Wiederverwendung von PIDs und TOCTOU.

# Code-Signing-Anforderungen, die der Release-Build an verbindende Clients stellt
identifier "com.tetsuharu.RoamSwitch"
  and anchor apple generic
  and certificate leaf[subject.OU] = "GV76B6G4YU"

Diese Anforderung wird mit SecCodeCopyGuestWithAttributes und überprüft SecStaticCodeCheckValidity, und die Verbindung wird getrennt, wenn sie nicht erfolgreich ist. Nur DEBUG-Builds verzichten aus Gründen der Entwicklungsfreundlichkeit auf die Team-ID-PIN. Was tatsächlich versendet wird, ist immer ein Release-Build.

Was der Helfer tun kann (die vollständige Liste)

Die in Shared/HelperProtocol.swift definierten privilegierten Operationen sind alle davon. Es gibt keine privilegierte API, die hier nicht aufgeführt ist.

Zustand im Helfer

• HelperTool.shared ist eine einzelne Instanz, die von allen Verbindungen gemeinsam genutzt wird. Früher war es eine separate Instanz pro Verbindung, sodass eine Notfalleindämmung, die eine neue Verbindung öffnete, zu einem Rennen führen konnte, bei dem der Überblick darüber verloren ging, „welche Dienste wiederhergestellt werden sollten“.
• Der Sharing-Service und die DNS-Backups werden nur in einer seriellen Warteschlange (stateQueue) mutiert.

§4

Vier Funktionen berühren Pf: den Notfall-Air-Gap, den Dev-Server-Port-Guard und die VPN-Tunnel WireGuard-Kill-Switch (§5, 1.7.6+) und sein Tailscale-Kill-Switch (§5, 1.8.0+ – nur die ausgewählten Backends). Alle gehen immer über einen einzelnen Einstiegspunkt, PFRulesetCoordinator, und wird niemals ausgeführt pfctl -f selbst.

Warum es einen einzigen Einstiegspunkt gibt

Zuvor luden die beiden Funktionen jeweils unabhängig voneinander Regeln mit pfctl -f und konkurrierten über den einzigen Hauptregelsatz von pf. Wenn die enge Regel des Hafenwächters block ... port {…} war Nachdem der Luftspalt block drop all geladen wurde, könnte es zu einem Zustand kommen, in dem der Bildschirm nicht mehr funktioniert sagte „isoliert“, aber der Mac war immer noch erreichbar. Dieser Fehler wurde durch einen tatsächlichen Angriff auf gefunden Maschine von einem anderen Host und wurde in 1.4.3 behoben (die Geschichte ist geschrieben in docs/marketing/zenn/03_lan_side_attack_test.md).

Wie es jetzt funktioniert

• Jedes Mal vollständig neu erstellt. Der gesamte erforderliche Regelsatz wird ausgehend vom aktuellen Status neu erstellt und auf einmal angewendet. Es wird niemals als Diff angewendet.
• Eine serielle Warteschlange. Jede PF-Änderung wird auf demselben DispatchQueue ausgeführt. Unabhängig davon, ob sie von einer XPC-Verbindung, dem Start des Hilfsprogramms oder dem Failsafe-Timer stammt, werden Änderungen der Reihe nach verarbeitet.
• Die Prioritätsreihenfolge ist wie folgt (weiter oben stehende Einträge haben Vorrang).
  1. Notluftspalt → set skip on lo0 und block drop all (nichts anderes wird berücksichtigt)
  2. VPN-Kill-Switch → block drop all plus pass quick nur für: lo, die Tunnelschnittstelle (utunN), den UDP-Handshake zu den angepinnten Endpunkt-IP(s), DHCP und ICMP
  3. Dev-Server-Wächter → block drop in quick proto tcp ... port { … }
  4. Keine → /etc/pf.conf neu laden und pf in seinen ursprünglichen Zustand zurückversetzen
• Nach der Anwendung zurücklesen. pfctl -sr liest die Regeln zurück, um zu bestätigen, dass block drop all oder die Regel jedes Ports tatsächlich geladen ist. Ein Fall, in dem pfctl -f stillschweigend ignoriert wurde, wird nicht als Erfolg gewertet.
• Die temporäre Datei wird in einen Pfad geschrieben, der einen UUID enthält, und nach der Anwendung gelöscht. (v1.4.5 hat den festen Pfad zugunsten eines schwer zu erratenden Pfads gelöscht). Das Statusverzeichnis ist /Library/Application Support/RoamSwitch.

§5

Die Arten von Blöcken sind jeweils unterschiedlich

Wie verhindert wird, dass der Luftspalt bestehen bleibt

• Sie wird nach spätestens 10 Minuten aufgehoben. Der Helfer selbst führt weiterhin unmittelbar nach dem Start und über einen 60-Sekunden-Timer releaseAirGapIfExpired() aus, aber als vollständig unabhängiges Sicherheitsnetz erwacht ein dedizierter LaunchDaemon (AirGapFailsafe) ohne jegliches KeepAlive selbstständig alle 3 Minuten und führt dieselbe Prüfung und Aufhebung durch. Stürzt der Helfer selbst ab und reißt seinen eigenen Selbstaufhebungs-Timer mit sich, bleibt dieses Sicherheitsnetz davon unberührt (ab 1.8.6).
• Dieser dedizierte Daemon rührt niemals die eigene Startkonfiguration des interaktiven Helfers an. Ein früherer Ansatz (1.8.5) nutzte für diese Wiederherstellung das eigene KeepAlive.PathState des Helfers, das jedoch gelegentlich mit einem normalen Beenden der App kollidierte und einen unbeabsichtigten Neustart auslöste, weshalb er zugunsten des jetzigen, vollständig unabhängigen Daemons zurückgenommen wurde.
• Die Zeitstempelprüfung verwendet eine Hybridlösung aus monotoner Systemlaufzeit (ProcessInfo.systemUptime) und der Uhrzeit. Bevorzugt wird normalerweise die monotone Systemlaufzeit, sodass NTP-Korrekturen und manuelle Uhrzeitänderungen keine Auswirkung haben. Nur wenn die Systemlaufzeit nicht vertrauenswürdig ist – unmittelbar nach einem Neustart, erkannt daran, dass der aktuelle Wert kleiner ist als der gespeicherte – wird auf die Uhrzeit zurückgegriffen.
• Es wird nach einem Neustart oder einem Daemon-Respawn erneut angewendet. Beim Start liest der Helfer den Zustand auf der Festplatte mit reapplyFromDisk() und stellt ihn selbst wieder her, in der Reihenfolge Air Gap, Port Guard, Systemstandard (auch hier gilt die 10-Minuten-Regel).
• ___ Auf dem Bildschirm wird nie fälschlicherweise „angehoben“ angezeigt.
• Sie können jederzeit die Kontrolle zurückerlangen – mit der Lift-Taste im Modal oder einfach durch Ausschalten des WLANs.

Wie ein Port-Guard-Falsch-Positiv-Ergebnis wiederhergestellt wird

Die automatische Blockierung unbekannter Ports (Pro, standardmäßig aktiviert, sobald Pro aktiviert ist) kann einen legitimen Port stoppen LAN-Empfänger – LocalSend, Syncthing, alles, was nach der Aktivierung des Wächters gestartet wurde. Wenn das passiert, erlauben Sie es über die Schaltfläche „Zulassen“ im Benachrichtigungsbanner oder in der entsprechenden Zeile den Bildschirm „Freigelegte Anschlüsse“. Eine einmal zulässige ausführbare Datei wird als bekannt aufgezeichnet und nicht blockiert wieder (PortAnomalyGuard.allowPort(_:)). Beachten Sie, dass generische Skriptinterpreter (Python, Node.js, Netcat usw.) haben einen strengen Gültigkeitsbereich von path:port und nicht von Binärdateien allein, um Angriffe von Landbewohnern zu verhindern. Apple-System-Daemons, die zufriedenstellend sind anchor apple (rapportd, das Handoff unterstützt und dergleichen) sind es nicht als erstes gesehen.

Selbstheilender Ransomware-Kanarienköder und Eindämmungsunterdrückung

Wenn Canary-Decoy-Dateien manipuliert oder umbenannt werden und den Notfall-Luftspalt auslösen, erfolgt die Freigabe Nach der Sicherheitsüberprüfung werden fehlende oder beschädigte Canary-Dateien automatisch neu generiert kehren zu ihrem authentischen Basis-Hash zurück, der aus eingebetteten Vorlagen generiert wurde, wodurch die ununterbrochene Überwachung der K-Warteschlange sofort wiederhergestellt wird (wodurch eine Kontamination der Basislinie durch den Gegner verhindert wird). Darüber hinaus werden während der aktiven Eindämmung (während das Notfallmodal angezeigt wird) redundante Benachrichtigungen und erneut auslösende Ereignisse aus regelmäßigen Hintergrund-Integritätsabfragen automatisch unterdrückt, um eine Ablenkung des Benutzers während der Reaktion auf den Vorfall zu vermeiden.

Mehrschichtige Erkennung heruntergeladener Dateien (statische Signaturen + ClamAV) – statische Signaturschicht ab 1.8.7

Neu im Downloads-, Schreibtisch- oder Dokumente-Ordner abgelegte Dateien durchlaufen zunächst eine leichtgewichtige statische Signaturprüfung durch StaticSignatureScanner (nur die ersten 4 MB, einfacher AND/OR-Bytemuster-Abgleich – keine regulären Ausdrücke oder Entropieberechnungen). Sie benötigt kein EndpointSecurity-Entitlement und funktioniert auch dort weiter, wo ClamAV nicht installiert ist. Die Erkennung ist bewusst auf das beschränkt, was ohne einen echten Malware-Korpus als Tatsache belegt werden kann: die branchenübliche EICAR-Testsignatur sowie fünf in öffentlichen Offensive-Security-Referenzen (z. B. PayloadsAllTheThings) dokumentierte Lehrbuch-Reverse-Shell-Einzeiler – /dev/tcp/ von bash/sh, -e von netcat, pty.spawn von Python, Socket von Perl und fsockopen von PHP. Wir schreiben keine bytegenauen „Signaturen“ für namentlich bekannte Malware-Familien, ohne eine echte Probe zu besitzen, aus der sie extrahiert werden könnten – das wäre nur ein trügerisches Sicherheitsgefühl. Die Muster selbst werden XOR-0x5A-verschleiert gespeichert, damit RoamSwitchs eigene Binärdatei niemals eine wörtliche EICAR-Zeichenfolge oder einen Reverse-Shell-Einzeiler enthält, wegen der ClamAV selbst sie melden könnte.

Nur Dateien, die die statische Signaturschicht als „sauber“ einstuft, gehen weiter in den ClamAV-Scan. Neu im Downloads-, Schreibtisch- oder Dokumente-Ordner abgelegte Dateien werden unabhängig von einer .tmp-Erweiterung oder einem com.apple.quarantine-Attribut (etwa bei einer über das Terminal erstellten Kopie) sofort von ClamAV gescannt. EICAR und andere branchenübliche Testsignaturen gelten als harmlos: Es wird keine Benachrichtigung angezeigt, sondern nur ein Eintrag im Benachrichtigungsverlauf angelegt – und sie werden nie unter Quarantäne gestellt oder blockiert (nur echte Malware-Proben werden unter Quarantäne gestellt). Und war bereits zuvor eine Datei gleichen Namens unter Quarantäne gestellt worden, wird die neue trotzdem unter einem eindeutigen, zeitgestempelten Namen in den Quarantäne-Ordner verschoben, sodass eine Bedrohung wegen einer Namenskollision nie an ihrem ursprünglichen Ort verbleiben kann.

Überwachung neuer Autostart-Persistenz (LaunchAgent/LaunchDaemon) – 1.8.7

Neue .plist-Dateien unter ~/Library/LaunchAgents, /Library/LaunchAgents oder /Library/LaunchDaemons werden per FSEvents in Echtzeit erkannt (PersistenceMonitorGuard). Ohne ES_EVENT_TYPE_AUTH_CREATE von EndpointSecurity lässt sich der Schreibvorgang selbst nicht blockieren. Möglich ist jedoch, ihn innerhalb von Sekunden zu bemerken und den Inhalt zu bewerten.

Die Bewertung stützt sich darauf, was direkt gestartet wird, nicht auf die Signatur der ausführbaren Datei selbst. Reale Techniken aus dem Jahr 2026 – ein als Google Update getarnter LaunchAgent, der ein Base64-dekodiertes Bash-Skript verbirgt, oder ein LaunchDaemon mit Root-Rechten, der bei jedem Neustart eine Base64-dekodierte AppleScript-Payload erneut ausführt – verstecken den bösartigen Code beide Male im Skript selbst, während sie ein gültig signiertes /bin/bash oder /usr/bin/osascript unverändert aufrufen. Eine Prüfung, die nur die Signatur der ausführbaren Datei betrachtet, würde beides ungehindert durchlassen. Deshalb wird jeder neu registrierte LaunchAgent/LaunchDaemon, der einen rohen Skriptinterpreter (bash, sh, zsh, osascript, python3, perl, ruby, php und Ähnliches) direkt aufruft, unabhängig von dessen gültiger eigener Signatur, ausnahmslos gemeldet. Die dabei übergebenen Argumente werden zudem durch StaticSignatureScanner geprüft, und jedes gefundene bekannte bösartige Muster wird in die Benachrichtigung aufgenommen. Einträge, die über BundleProgram (verweist auf eine signierte, kompilierte Binärdatei innerhalb eines App-Bundles – einschließlich RoamSwitchs eigenem Helfer) registriert wurden, werden ganz normal per codesign --verify --strict verifiziert.

ClickFix-Erkennung und Notfall-Abriegelung – 1.8.7, standardmäßig deaktiviert

„ClickFix“ ist eine Social-Engineering-Technik, bei der ein gefälschtes CAPTCHA oder eine Fehlermeldung dazu auffordert, das Terminal zu öffnen und einen Befehl „zur Verifizierung“ einzufügen. Die Erkennungen stiegen von 2024 bis 2025 um über 500 %, und bis 2026 gilt sie als einer der am weitesten verbreiteten macOS-Angriffsvektoren. Da es sich um die eigene, legitime Shell handelt, die genau das ausführt, was eingegeben wurde, umgeht sie Gatekeepers Signaturprüfung vollständig.

Menüleiste → Malware-Schutz → ClickFix-Abwehr (Pro, standardmäßig deaktiviert). Überwacht per FSEvents neu angehängte Zeilen in ~/.zsh_history/~/.bash_history (nur Zeilen, die nach dem Start der Wache hinzugefügt werden – der bestehende Verlauf wird nie durchsucht) und gleicht ausschließlich die Reverse-Shell-Einzeiler ab, die sie mit StaticSignatureScanner teilt, sowie die spezifische Kombination aus Base64-Dekodierung direkt in eine Shell oder in osascript. Ein bloßes curl | bash – bei legitimen Installationsprogrammen äußerst verbreitet – ist bewusst ausgeschlossen, da es sich nicht von den offiziellen Installationsanleitungen für Homebrew, rustup, nvm und Ähnliches unterscheiden lässt. Sobald eine Übereinstimmung gefunden wird, löst sie denselben oben beschriebenen Notfall-Air-Gap aus. Da der Befehl bereits ausgeführt wurde, geschieht dies zwangsläufig im Nachhinein, kann aber dennoch einen laufenden zweiten Download oder eine Zugangsdaten-Exfiltration unterbrechen. Wie jeder andere Air-Gap-Auslöser hebt sie sich von selbst nach spätestens 10 Minuten auf (siehe Beginn dieses Abschnitts).

Eine bekannte Einschränkung. Da die Erkennung von einem Schreibvorgang in den Shell-Verlauf abhängt, kann sie die dateilose Variante nicht erfassen, die das Terminal vollständig umgeht, indem sie den Skripteditor direkt über das applescript://-URL-Schema aufruft und nichts auf die Festplatte schreibt. Apple hat hierfür eine gewisse Abschwächung eingeführt (ein Bestätigungsdialog für nicht identifizierte Skripte), doch es wurden Varianten gemeldet, die diese umgehen. Wir haben diesen Pfad auf echter Hardware gegen das einheitliche macOS-Protokoll (log show/log stream) getestet und kein charakteristisches Protokollsignal gefunden, an dem eine Erkennung ansetzen könnte. Wir stellen diese Einschränkung lieber offen dar, als eine Abdeckung zu behaupten, die wir nicht haben.

Docker-Risikoerkennung — 1.8.9, Pro, standardmäßig deaktiviert

Menüleiste → „Malware-Schutz“ → „Privilegierte Docker-Container & docker.sock-Mounts erkennen“ (DockerEventGuard). Da es in dieser Codebasis keinen Präzedenzfall für eine dauerhafte Streaming-Verbindung wie docker events gibt, wird derselbe Timer-Polling-Ansatz wie bei PortAnomalyGuard verwendet. Alle 20 Sekunden wird mit einem leichten docker ps -q die Menge der Container-IDs abgerufen, und nur die Differenz zum vorherigen Stand (neu gestartete Container) wird mit docker inspect --format im Detail geprüft. Der zur Erkennung verwendete Format-String ist absichtlich identisch mit dem der Linux-Edition (roamswitch_core::health::LinuxHealthChecker::DOCKER_INSPECT_RISK_FORMAT), sodass beide Plattformen exakt dieselben Bedingungen erkennen (Start im --privileged-Modus oder ein /var/run/docker.sock-Bind-Mount).

Bei der Erkennung wird keine automatische Aktion ausgelöst. Ein privilegierter Container oder ein docker.sock-Mount ist eine riskante „Konfiguration“, die einen Container-Escape ermöglichen könnte, aber keine bestätigte Kompromittierung – es gibt auch legitime Anwendungsfälle, etwa den bewussten Betrieb eines Überwachungs-Agents als privilegiert. Da die meisten Nutzer überhaupt kein Docker verwenden, bleibt diese Funktion auch mit Pro-Lizenz standardmäßig deaktiviert. Sie verwendet nicht das EndpointSecurity-Entitlement; die docker-CLI wird zunächst am Standard-Installationspfad von Docker Desktop, dann über Homebrew und schließlich über which gesucht. Verifiziert an einer echten Docker-Desktop-Installation (29.7.2) anhand von drei Szenarien – ein privilegierter Container, ein Container mit docker.sock-Mount und ein normaler Container – ohne Fehlalarme oder verpasste Erkennungen.

Geheimnis-/API-Schlüssel-Leck-Audit — hinzugefügt in 1.8.4, Ordner-Scan hinzugefügt in 1.8.9

Menüleiste → „Malware-Schutz“ → „Geheimnis-/API-Schlüssel-Leck-Audit“. Text einfügen, und er wird sofort auf durchgesickerte API-Schlüssel und Tokens geprüft, mit Zeilennummer, maskiertem String und einer Handlungsempfehlung je Fund (SecretLeakAuditor, vollständig auf dem Gerät). In 1.8.9 kam die Option „Ordner zum Scannen auswählen“ hinzu, mit der dieselbe Erkennungs-Engine ein Verzeichnis – etwa einen Quellcode-Checkout – rekursiv über auditDirectory(at:) prüfen kann. .git, node_modules, target, vendor, dist, build, __pycache__ und venv werden automatisch ausgeschlossen, ebenso Dateien über 2 MB oder als Binärdatei erkannte Dateien. Die Verarbeitung läuft außerhalb des Hauptthreads, um die Oberfläche nicht zu blockieren, und es wird niemals etwas nach außen gesendet.

Link Guard (blockiert Phishing-Verbindungen) – 1.7.2 und höher, verstärkt in 1.8.0

Menüleiste → „Malware-Schutz“ → „Link Guard“ (Pro). Blockiert Verbindungen zu Phishing-/Betrugsseiten auf dem Gerät, in jedem Browser und in jeder App. Es gibt zwei Durchsetzungspunkte, die zusammen in der Reihenfolge ihrer Priorität verwendet werden.

• ① Content-Filter-Systemerweiterung (RoamSwitchLinkFilter, 1.8.0+, nach Genehmigung bevorzugt). Eine NEFilterDataProvider-Systemerweiterung – keine Apple-Überprüfung (Content-Filter-Anbieter sind Selbstbedienungsanbieter, keine Genehmigungswarteschlange). Es überprüft den tatsächlichen ausgehenden TCP-Fluss after Namensauflösung. Der Zielname stammt aus dem vom Betriebssystem aufgelösten Hostnamen oder, falls dies nicht der Fall ist, wurde der TLS SNI aus den ersten Bytes des Flusses geparst – ein Browser, der sein eigenes DoH/DoT ausführt und eine Verbindung zu einer nackten IP herstellt, wird also immer noch blockiert. Es schreibt /etc/hosts nie neu und ordnet jeden Fluss einem Prozess zu. QUIC (UDP/443) hat kein lesbares SNI, daher wird es im block-Modus gelöscht, wodurch der Browser gezwungen wird, auf HTTP/2 über TCP zurückzugreifen. Erfordert eine einmalige Genehmigung in den Systemeinstellungen.
• ② /etc/hosts Sinkhole (Fallback, während die Erweiterung nicht genehmigt/abgelehnt ist). Der privilegierte Helfer schreibt die Zieldomänen in einen durch Trennzeichen getrennten verwalteten Abschnitt von /etc/hosts als 0.0.0.0 und leert den Cache. Maximal 60.000. Sobald die Erweiterung aktiv ist, wird dieser Abschnitt entfernt.
• Drei Modi. „Aus“ deaktiviert es. „Nur warnen“ pausiert die passende Verbindung und fragt den Benutzer (siehe Real warn unten). „Offensichtliche Betrugsseiten automatisch blockieren (empfohlen)“ wird sofort entfernt. Der Standardwert ist Block ab 1.7.2.
• ___ Sobald das Tippen des Benutzers allowlist.txt / extra.txt erreicht – die Erweiterung fragt alle 1,5 s die kleinen Statusdateien ab – werden die angehaltenen Flows fortgesetzt (zulassen) oder gelöscht (blockieren). Keine Antwort innerhalb von 25 s schlägt open fehl (eine Warnung ist beratend). Die Entscheidung wird pro Host zwischengespeichert (5 Minuten zulassen/1 Stunde blockieren), sodass die anderen Flüsse der Seite und spätere Besuche sofort erfolgen und erzwungen werden. Die block-Benachrichtigung ist unverändert: „Blockiert …“ mit der Schaltfläche „Einmal zulassen (5 Min.)“.
• Nur eindeutige Fälle werden blockiert. Eine Auflistung im Bedrohungs-Feed oder ein Marken-Unicode-Homograph – alles andere (Hochrisiko-TLDs, Subdomain-Nachahmung usw.) ist eine Warnung. Die Urteils-Engine wird mit der Linux-Edition geteilt und sendet URLs nirgendwohin.
• Wiederherstellung nach einer falschen Blockierung. Eine Domain über die Benachrichtigung oder das Menü zulassen (5 Minuten oder dauerhaft). Die Zulassungsliste wird abgezogen, wenn der Abschnitt neu generiert wird.
• Pro-gated. Die Durchsetzung (applyMode()) erfolgt nur bei einer gültigen Pro-Lizenz. Ohne Pro wird der Modus gespeichert, aber /etc/hosts wird nie berührt. Die Aktivierung oder das Erlöschen einer Lizenz wird mitten in der Sitzung wirksam.
• Feed und gebündelter Seed. Die Blockliste stammt aus dem signierten Bedrohungs-Feed (§7, verifiziert mit einem Feed-spezifischen Schlüssel). Es funktioniert bereits vor dem ersten Abruf mit dem gebündelten Seed der App (ca. 60.000 Einträge) und die Deaktivierung von „Auto-Update“ bedeutet, dass kein ausgehender Datenverkehr stattfindet.

Präventive Gateway-ARP/NDP-Sperre – 1.7.5 und höher

Menüleiste → „Port- und Gerätemonitor“ → „ARP/NDP des Gateways an nicht vertrauenswürdige Netzwerke anheften (präventiv)“ (Pro, standardmäßig deaktiviert).

• Wie es funktioniert. Beim Beitritt zu einem nicht vertrauenswürdigen Netzwerk wird der aktuelle MAC des IPv4-Gateways, des IPv6-Standardrouters und der On-Link-DNS-Resolver von route / scutil --dns / arp -n / ndp -an erfasst, und der Helfer pinnt jeden als permanent-Eintrag mit arp -s / ndp -s (Vertrauen bei der ersten Verwendung – der erste beobachtete MAC ist vertrauenswürdig). Gefälschte ARP/NDP-Antworten für diese IPs werden dann ignoriert, sodass kein Man-in-the-Middle-Angriff durchgeführt werden kann.
• Scope. Nur diese drei Arten von Einträgen werden angeheftet. Vertrauenswürdige (offene) Netzwerke werden niemals gepinnt. Bei jedem Netzwerkwechsel wird es einmal entsperrt und erneut angepinnt. Öffentliche Off-Link-Resolver (8.8.8.8, …) haben keinen On-Link-ARP-Eintrag und werden automatisch ausgeschlossen.
• arp -s ist präventiv; der Luftspalt ist nachträglich. Dieser Pin existiert, daher kann eine Parodie nicht erfolgreich sein; Die ARP-Spoofing-Erkennung (ARPSpoofContainmentManager) und der Notfall-Luftspalt dienen dazu, „schneller als ein Mensch zu schneiden“, sobald einer erkannt wird. Sie laufen unabhängig.
• Persistence. Der Pin-Satz wird unter /Library/Application Support/RoamSwitch/gateway_arp_lock.json gespeichert, sodass er bei einer erneuten XPC-Verbindung oder einem Neustart des Hilfsprogramms entsperrt werden kann.

Der VPN-Tunnel (WireGuard / Tailscale) und sein Kill-Switch – 1.7.6 und höher, auswählbares Backend in 1.8.0

Menüleiste → „Port- und Gerätemonitor“ → „VPN-Tunnel“ (Pro, standardmäßig deaktiviert). Dies ist die primäre Anti-MITM-Abwehr – sie hängt nicht von der Integrität von L2 (ARP/NDP) ab. Das Backend ist wählbar (Untermenü → „Backend“) zwischen „WireGuard (config file)“ und „Tailscale (Exit Node)“. RoamSwitch implementiert selbst keine Kryptografie; Nur das ausgewählte Backend ist scharfgeschaltet.

• (A) WireGuard-Backend. Steuert Homebrews wireguard-tools (keine Berechtigung zur Apple Network Extension). Importieren Sie Ihr eigenes .conf; Der Helfer speichert es bei 0600. Kill-Switch: pf block drop all plus ein pass quick nur für lo, die Tunnelschnittstelle, den UDP-Handshake zu den angehefteten Endpunkt-IP(s), DHCP und ICMP. Ein nicht vollständiger Tunnel AllowedIPs löst eine Split-Tunnel-Warnung aus.
• (B) Tailscale-Backend (1.8.0+). Für Benutzer, die Tailscale bereits ausführen. RoamSwitch führt nicht aus, führt tailscale up aus / meldet sich an / installiert es – es liest tailscale status --json und führt tailscale set --exit-node=<node> aus. Die eigenständige CLI (brew install tailscale) wird empfohlen – der App Store (GUI)-Build kann nicht von außerhalb der App (Sandbox) gesteuert werden; Damit wählen Sie den Ausgangsknoten in der Tailscale-App aus und RoamSwitch zeigt nur den Status an. Ein Ausgangsknoten ist erforderlich (leitet den gesamten Datenverkehr durch den Tunnel); Es wird automatisch deaktiviert, wenn es offline geht oder nicht erreichbar ist.
• ___ Der Datenverkehr sinkt für ca. 5–10 s und die Schutzstufe wird in diesem Fenster nicht herabgestuft.
• Der Tailscale-Kill-Switch ist standardmäßig deaktiviert (Opt-in). Der Exit-Knoten tunnelt bereits alles; der pf block drop all (erlaubt nur CGNAT/MagicDNS/STUN/DERP/DHCP/ICMP/DNS) ist für fortgeschrittene Benutzer und ist „lecksicher, nicht lecksicher“ (DNS ist erlaubt, daher bleibt tailscaled bestehen).
• Automatisch / bei Lizenzverlust. Kommt bei nicht vertrauenswürdigen Netzwerken hoch, bei vertrauenswürdigen herunter; wird aufgehoben, wenn die Pro-Lizenz erlischt.

§6

Wenn Sie eine Verbindung zu einem Netzwerk herstellen, das Sie nicht registriert haben, wird der Schalter „Schutzstufe“ nicht verwendet pf. Es ändert lediglich die Standardeinstellungen des Betriebssystems auf eine Weise, die später rückgängig gemacht werden kann.

Dabei handelt es sich nicht um einen neuen Blockierungsmechanismus, den RoamSwitch hinzufügt – es handelt sich lediglich um das Umschalten der Betriebssystemeinstellungen. Wenn löscht man die App, stoppt nur noch die netzwerkabhängige Umschaltung; das letzte Betriebssystem Die angewendeten Einstellungen bleiben unverändert. Nichts bleibt gesperrt, aber wenn Sie sich irren möchten Stellen Sie es auf der sicheren Seite in einem vertrauenswürdigen Netzwerk wieder auf „Offen“, bevor Sie es deinstallieren.

§7

Was bleibt auf dem Mac

Verkehr, der die Maschine verlässt (die vollständige Liste)

Es gibt nirgendwo einen Code, der Diagnoseergebnisse, Portinformationen, URLs usw. sammelt und sendet Protokolle. Es sind kein Analyse-SDK und kein Crash-Reporter-SDK enthalten. Die einzige externe Bibliothek ist Sparkle (Updates). Was an das Netzwerk gesendet wird, sind diese acht, und das ist alles (die sechste nur, wenn der Benutzer ein VPN konfiguriert, die siebte nur, wenn die RoamSwitch Sensor-Kopplung aktiviert ist).

# Developer-ID-Signatur und Team-ID
codesign -dvvv /Applications/RoamSwitch.app 2>&1 | grep -E 'Authority|TeamIdentifier|flags'

# Ob das Notarization-Ticket gestapelt (staple) ist
stapler validate /Applications/RoamSwitch.app
spctl -a -t exec -vvv /Applications/RoamSwitch.app

# Signatur des mitgelieferten Helpers / MCP-Servers
codesign -dvvv /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchHelper
codesign -dvvv /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer

codesign -d --entitlements :- /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchHelper
codesign -d --entitlements :- /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer
# → Ein leeres Entitlements-Dictionary. Keine app-sandbox-/network-client-Schlüssel.

# tcpdump parallel mitlaufen lassen, um zu bestätigen, dass bei normaler Nutzung kein Traffic entsteht
sudo tcpdump -i any -n 'host not 127.0.0.1' and 'not port 53'
# Kein Traffic außer Lizenzaktivierung, Update-Prüfungen und ClamAV-Definitionsupdates

Eine strengere, automatisierte Prüfung mit Zuordnung pro Prozess finden Sie unter rs-zerotel-audit.sh in roamswitch-support/audit/

# Verifiziert automatisch in einem Durchgang: XPC-Autorisierungsgrenze, pf-Air-Gap-Priorität, Port-Expositionserkennung, MCP-Nur-Lesen, ARP-Überwachung
git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Live-Penetrationstests und mehrschichtiges Verteidigungsaudit von einer macOS-VM: RESULTS-DEFENSE-2026-08-30

# Abfrage der offiziellen Quad9-Testdomain zur Verifikation der Bedrohungsblockierung
nslookup test.dns9.quad9.net
# → Sollte ** server can't find test.dns9.quad9.net: NXDOMAIN liefern, d. h. die Namensauflösung ist blockiert

# Die harmlose branchenübliche Antiviren-Teststring (EICAR) in Downloads erstellen
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/Downloads/eicar_test.com
# → Die FSEvents-Erkennung löst einen sofortigen ClamAV-Scan aus; es erscheint keine Benachrichtigung, "EICAR-Testsignatur erkannt (harmlos)"
#   wird nur im Benachrichtigungsverlauf erfasst. Da EICAR eine branchenübliche Testdatei und keine echte Bedrohung ist,
#   wird sie weder unter Quarantäne gestellt noch blockiert, und die Datei bleibt unverändert (nur eine echte Malware-Probe wird in den Quarantäne-Manager verschoben).

## Ein Lehrbuch-Reverse-Shell-Einzeiler aus öffentlichen Offensive-Security-Referenzen (harmlos, wird nie ausgeführt)
echo 'bash -i >& /dev/tcp/127.0.0.1/4444 0>&1' > ~/Downloads/rs_test.sh
## → Auch ohne installiertes ClamAV erscheint eine Benachrichtigung „Gefährliche Download-Datei unter Quarantäne gestellt“, und die Datei wird
##   sofort in den Quarantäne-Ordner verschoben (unabhängig von ClamAVs Signaturdatenbank)

# Einen harmlosen LaunchAgent anlegen, der einen rohen Skriptinterpreter direkt aufruft (wird nie tatsächlich ausgeführt)
cat > ~/Library/LaunchAgents/com.example.selfcheck.plist <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>com.example.selfcheck</string>
  <key>ProgramArguments</key><array><string>/bin/bash</string><string>-c</string><string>echo hi</string></array>
</dict></plist>
EOF
# → Innerhalb weniger Sekunden sollte eine Benachrichtigung „Neue Autostart-Registrierung erkannt“ erscheinen. Danach entfernen:
rm ~/Library/LaunchAgents/com.example.selfcheck.plist

# Ob der verwaltete Abschnitt vorhanden ist (2 BEGIN/END-Zeilen bei Pro + Standardmodus)
sudo grep -c 'RoamSwitch link guard' /etc/hosts

# Inhalt des Abschnitts und Anzahl der Sinkholes
sudo sed -n '/BEGIN RoamSwitch link guard/,/END RoamSwitch link guard/p' /etc/hosts | head -4
sudo sed -n '/BEGIN RoamSwitch link guard/,/END RoamSwitch link guard/p' /etc/hosts | grep -c '^0\.0\.0\.0'

# Ob es tatsächlich blockiert wird (mit einem Eintrag aus dem Abschnitt geprüft; harmlos)
D=$(sudo sed -n '/BEGIN RoamSwitch/,/END RoamSwitch/p' /etc/hosts | awk '/^0\.0\.0\.0/{print $2; exit}')
dscacheutil -q host -a name "$D"   # → ip_address: 0.0.0.0 (Namensauflösung ist blockiert)

# Auch bestätigen, dass der obige Abschnitt über Menü → „Linkschutz" → „Aus" verschwindet

# Öffentlicher Feed und Manifest (von jedem abrufbar und überprüfbar)
curl -s https://lafine.net/updates/v1/manifest        # version/generated/threatfeed{...}
curl -sI https://lafine.net/updates/v1/manifest.sig   # → text/plain
# Es wird nur ein GET ohne Query-String, Cookies oder Identifikatoren gesendet. Mit parallel laufendem tcpdump überprüfbar.

# Mit aktivierter präventiver Sperre mit einem nicht vertrauenswürdigen Netzwerk verbinden → auf permanent-Einträge prüfen
arp -an | grep -i permanent          # Gateway und andere IPs werden als (permanent) aufgeführt
ndp -an | grep -i 'P '               # IPv6-Seite (P = permanent)
sudo cat "/Library/Application Support/RoamSwitch/gateway_arp_lock.json"  # Die Menge der aktuell fixierten IP→MAC-Zuordnungen
# Sperre über das Menü aufheben → das Obige sollte verschwinden

# Setzt wireguard-tools voraus (über Homebrew)
brew list wireguard-tools >/dev/null && echo "wireguard-tools: OK"

# VPN in einem nicht vertrauenswürdigen Netzwerk aktivieren → bevor der Tunnel steht, befindet sich pf im Kill-Switch-Zustand
sudo pfctl -sr | grep -E 'block drop all|pass .*(utun|udp)'   # block drop all + eine begrenzte Menge an pass-quick-Regeln

# Nachdem der Tunnel steht (wg-quick up bereits ausgeführt)
wg show                              # handshake / transfer läuft
route -n get default | grep interface  # → utunN (die Standardroute ist der Tunnel)
# VPN deaktivieren → Kill-Switch wird aufgehoben, pf kehrt in den vorherigen Zustand zurück

# Der registrierte LaunchDaemon
sudo launchctl print system/com.tetsuharu.RoamSwitch.Helper

# Die aktuell geladenen pf-Regeln (tatsächlicher Zustand von Air-Gap / Port-Guard)
sudo pfctl -sr

# Das Zustandsverzeichnis des Helpers
ls -la "/Library/Application Support/RoamSwitch/"

BIN=/Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
              '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | "$BIN"
# Liefert serverInfo und die Definitionen der 5 Tools zurück. Es entsteht keine Netzwerkverbindung.

git clone https://github.com/lafine1211/roamswitch-mcp
cd roamswitch-mcp
swift build -c release        # Derselbe Quellcode wie in der ausgelieferten Binärdatei
swift test                    # Unit-, Adversarial-Input-, stdio- und Mutations-Fuzzing-Tests
# Testinhalte und gefundene Probleme siehe SECURITY_TESTING.md

# Der Rohwert, der an das Token gebunden ist (gesendet wird nur ein gesalzener SHA-256)
ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'