Libro bianco sull'architettura e la sicurezza di RoamSwitch

§1

RoamSwitch è un'app della barra dei menu per Mac. A seconda di quanto ti fidi della rete che sei attualmente connesso, cambia automaticamente il firewall macOS, i servizi di condivisione, AirDrop, e DNS. Controlla anche lo spoofing ARP, le porte aperte verso l'esterno, l'archiviazione USB e attività di crittografia simile a un ransomware e quando rileva qualcosa di pericoloso arriverà fino al punto tagliare il traffico con il filtro dei pacchetti (pf) — un air-gap di emergenza.

In altre parole, RoamSwitch installa un demone con privilegi di root e, se lo volesse, potrebbe bloccare tutto traffico di rete sul Mac. È stato costruito da una sola persona e "per favore fidati di me" non è sufficiente giustificare quel privilegio. Quindi, invece, questo documento spiega il progetto in un formato che puoi verificare.

Per chi è questo

• Gli ingegneri decidono se installarlo
• Ricercatori e giornalisti di sicurezza che vogliono comprendere i dettagli prima di una recensione o di un articolo
• Il personale addetto alla sicurezza presso le aziende partner sta valutando un'implementazione interna o un raggruppamento OEM

Cosa non copre questo documento

Non riguarda l'ottimizzazione della soglia di rilevamento, le statistiche sui falsi positivi o le procedure dettagliate dell'interfaccia utente. Ciò che spiega sono quattro cose: privilegi, limiti del processo, flusso di dati e crittografia. Le specifiche delle funzionalità stesse si trovano nella risorsa MCP in bundle roamswitch://docs/features e nella guida in-app.

Cosa viene divulgato e in che misura (politica di divulgazione)

Questo documento è scritto partendo dal presupposto che un utente malintenzionato abbia già il file binario distribuito. Ogni URL, identificatore, percorso file, protocollo XPC e chiave pubblica incorporata dell'endpoint visualizzato qui può essere estratto dalla spedizione RoamSwitch.app in pochi minuti con strings, codesign -d o un proxy di traffico. Scriveteli qui dunque non dà nulla di nuovo all'attaccante. L'unica cosa che avanza è la comprensione del revisore.

D'altra parte, l'implementazione lato server che non può essere vista dal binario è un limite di velocità soglie, chiavi, endpoint di amministrazione, schema DB, layout del progetto Firebase non sono inclusi. Anche la progettazione dell'integrazione OEM e partner non rientra nell'ambito di questo contesto ed è trattata in un documento separato documento interno. "Cosa puoi imparare osservando il cliente" è la riga di divulgazione per questo documento.

§2

RoamSwitch.app è composto da tre eseguibili. Solo uno di essi è privilegiato; il gli altri due vengono eseguiti con diritti di utente di accesso. Tutti e tre vengono forniti con Hardened Runtime abilitato, ID sviluppatore firmato e autenticato.

Diritti e firma

• Tutti e tre gli obiettivi hanno ENABLE_HARDENED_RUNTIME = true.
• La sandbox dell'app è disabilitata (com.apple.security.app-sandbox = false). I diritti dell'helper e di MCPServer sono dizionari vuoti.
• Le build di distribuzione sono firmate dall'applicazione ID sviluppatore, autenticate da Apple e pinzate (§10).

§3

Come viene registrato

L'helper è registrato come LaunchDaemon utilizzando SMAppService.daemon(plistName:). Il plist incorporato nell'app (Contents/Library/LaunchDaemons/com.tetsuharu.RoamSwitch.Helper.plist) dichiara solo Label, BundleProgram, una singola voce MachServices e AssociatedBundleIdentifiers. A causa di come funziona SMAppService, la registrazione non è nemmeno possibile a meno che l'app non sia in /Applications. Sul primo registrazione, l'helper non diventa attivo finché l'utente non lo approva manualmente nel sistema Impostazioni.

Di quali connessioni accetta (ClientValidator)

L'aiutante controlla il processo di connessione in NSXPCListener shouldAcceptNewConnection e distribuisce HelperProtocol solo a quelli che passare. L'ispezione utilizza audit_token anziché il PID evitare il riutilizzo del PID e il TOCTOU.

# Requisiti di firma del codice richiesti dalla build Release ai client che si connettono
identifier "com.tetsuharu.RoamSwitch"
  and anchor apple generic
  and certificate leaf[subject.OU] = "GV76B6G4YU"

Questo requisito viene verificato con SecCodeCopyGuestWithAttributes e SecStaticCodeCheckValidity e la connessione viene interrotta se non passa. Solo Le build DEBUG rilasciano il pin ID squadra, per comodità di sviluppo. Ciò che effettivamente viene spedito è sempre a Rilascia la build.

Cosa può fare l'aiutante (l'elenco completo)

Le operazioni privilegiate definite in Shared/HelperProtocol.swift sono tutte. Non esiste alcuna API privilegiata che non sia elencata qui.

Stato all'interno dell'aiutante

• HelperTool.shared è una singola istanza condivisa tra connessioni. In passato si trattava di un'istanza separata per connessione, quindi un contenimento di emergenza che apriva una nuova connessione poteva colpire una gara che aveva perso traccia di "quali servizi ripristinare".
• Il servizio di condivisione e i backup DNS vengono modificati solo su una coda seriale (stateQueue).

§4

Quattro funzionalità toccano pf: l'air-gap di emergenza, la protezione della porta del server di sviluppo, il tunnel VPN Kill-switch WireGuard (§5, 1.7.6+) e il suo kill-switch Tailscale (§5, 1.8.0+ — solo il backend selezionato). Vanno sempre tutti attraverso un unico punto di ingresso, PFRulesetCoordinator, e non eseguire mai pfctl -f stessi.

Perché esiste un unico punto di ingresso

In precedenza, le due funzionalità caricavano ciascuna regole con pfctl -f in modo indipendente, competendo sull'unico set di regole principali di pf. Se la regola ristretta della guardia del porto fosse block ... port {…} caricato dopo block drop all dell'air-gap, potresti ritrovarti in uno stato in cui screen ha detto "isolato" ma il Mac era ancora raggiungibile. Questo bug è stato trovato attaccando effettivamente il file macchina da un altro host ed è stato corretto nella versione 1.4.3 (la storia è scritta in docs/marketing/zenn/03_lan_side_attack_test.md).

Come funziona adesso

• Ricostruito completamente ogni volta. L'intero set di regole richiesto viene ricostruito dallo stato corrente e applicato in un colpo solo. Non viene mai applicato come diff.
• Una coda seriale. Ogni modifica pf viene eseguita sullo stesso DispatchQueue, quindi, indipendentemente dal fatto che provenga da una connessione XPC, dall'avvio dell'helper o dal timer di failsafe, le modifiche vengono elaborate in ordine.
• L'ordine di priorità è il seguente (gli elementi più in alto hanno la precedenza).
  1. Air-gap di emergenza → set skip on lo0 e block drop all (nient'altro viene considerato)
  2. Kill-switch VPN → block drop all più pass quick solo per: lo, l'interfaccia tunnel (utunN), l'handshake UDP agli IP dell'endpoint bloccato, DHCP e ICMP
  3. Guardia del server di sviluppo → block drop in quick proto tcp ... port { … }
  4. Nessuno → ricarica /etc/pf.conf e riporta pf al suo stato originale
• Rileggi dopo l'applicazione. pfctl -sr rilegge le regole per confermare che block drop all, o la regola di ciascuna porta, è effettivamente caricata. Un caso in cui pfctl -f è stato silenziosamente ignorato non viene considerato un successo.
• Il file temporaneo viene scritto in un percorso contenente UUID ed eliminato una volta applicato (la versione 1.4.5 ha abbandonato il percorso fisso a favore di uno difficile da indovinare). La directory dello stato è /Library/Application Support/RoamSwitch.

§5

I tipi di blocco sono diversi

Come si impedisce al traferro di persistere

• Si disattiva dopo al massimo 10 minuti. L'helper stesso continua a eseguire releaseAirGapIfExpired() subito dopo l'avvio e su un timer di 60 secondi, ma come rete di sicurezza completamente indipendente, un LaunchDaemon dedicato (AirGapFailsafe) privo di qualsiasi KeepAlive si risveglia da solo ogni 3 minuti ed esegue lo stesso controllo e rilascio. Se l'helper stesso va in crash trascinando con sé il proprio timer di autorilascio, questa rete di sicurezza non ne risente (dalla 1.8.6).
• Questo daemon dedicato non tocca mai la configurazione di avvio dell'helper interattivo stesso. Un tentativo precedente (1.8.5) usava il KeepAlive.PathState proprio dell'helper per questo ripristino, ma a volte interferiva con una normale chiusura dell'app causando un riavvio indesiderato, per cui è stato annullato a favore dell'attuale daemon completamente indipendente.
• Il controllo del timestamp utilizza una combinazione ibrida di tempo di attività monotono (ProcessInfo.systemUptime) e ora dell'orologio. Normalmente privilegia il tempo di attività monotono, così le correzioni NTP e i cambi manuali dell'ora non hanno effetto. Ricorre all'ora dell'orologio solo quando il tempo di attività non è affidabile — subito dopo un riavvio, rilevato quando il valore attuale è inferiore a quello memorizzato.
• Viene riapplicato dopo un riavvio o una rigenerazione del daemon. All'avvio, l'helper legge lo stato su disco con reapplyFromDisk() e lo ripristina da solo, nell'ordine air-gap, protezione delle porte, impostazione predefinita di sistema (anche qui si applica la regola dei 10 minuti).
• Un sollevamento fallito viene trattato come un fallimento. Se block drop all non può essere effettivamente rimosso, il timestamp viene riscritto in modo che il timer di failsafe e il nuovo tentativo abbiano qualcosa su cui convergere. Lo schermo non mostra mai erroneamente "sollevato".
• Puoi riprendere il controllo in qualsiasi momento, con il pulsante dell'ascensore in modalità o semplicemente disattivando il Wi-Fi.

Come viene recuperato un falso positivo Port-Guard

Il blocco automatico delle porte sconosciute (Pro, attivo per impostazione predefinita una volta attivato Pro) può interrompere un traffico legittimo Ricevitore LAN: LocalSend, Syncthing, qualsiasi cosa avviata dopo l'attivazione della guardia. Quando quello accade, consentilo dal pulsante "Consenti" sul banner di notifica o sulla riga corrispondente la schermata "Porte esposte". Un eseguibile consentito una volta viene registrato come noto e non viene bloccato ancora (PortAnomalyGuard.allowPort(_:)). Tieni presente che gli interpreti di script generici (Python, Node.js, Netcat, ecc.) hanno un ambito rigorosamente path:port anziché binario da solo per prevenire gli attacchi di chi vive fuori terra. Demoni di sistema Apple che soddisfano anchor apple (rapportd, che sostiene Handoff e simili) non lo sono guardato in primo luogo.

Esca canary ransomware autoriparante e soppressione del contenimento

Se i file esca canary vengono manomessi o rinominati e attivano l'air-gap di emergenza, rilasciando il contenimento dopo aver verificato la sicurezza rigenera automaticamente i file Canary mancanti o danneggiati al loro hash di base autentico generato da modelli incorporati, ripristinando immediatamente la sorveglianza ininterrotta della coda (prevenendo la contaminazione della linea di base avversaria). Inoltre, durante il contenimento attivo (mentre è visualizzata la modalità di emergenza), gli avvisi di notifica ridondanti e gli eventi di riattivazione dal polling periodico dell'integrità in background vengono automaticamente soppressi per evitare di distrarre l'utente durante la risposta agli incidenti.

Rilevamento multilivello dei download (firme statiche + ClamAV) — livello di firme statiche aggiunto nella 1.8.7

I file appena inseriti nelle cartelle Download, Scrivania o Documenti passano prima per un leggero controllo di firme statiche tramite StaticSignatureScanner (solo i primi 4 MB, semplice corrispondenza di pattern di byte AND/OR, senza espressioni regolari né calcoli di entropia). Non richiede l'entitlement EndpointSecurity e continua a funzionare anche dove ClamAV non è installato. Il rilevamento è deliberatamente limitato a ciò che può essere affermato come un fatto senza un corpus reale di malware: la firma di test EICAR, standard del settore, e cinque reverse shell da manuale documentate in riferimenti pubblici di offensive security (ad esempio PayloadsAllTheThings) — /dev/tcp/ di bash/sh, -e di netcat, pty.spawn di Python, Socket di Perl e fsockopen di PHP. Non scriviamo «firme» a livello di byte per famiglie di malware specifiche senza disporre di un campione reale da cui estrarle: sarebbe solo un falso senso di sicurezza. I pattern stessi sono memorizzati offuscati con XOR 0x5A, in modo che il binario di RoamSwitch non contenga mai letteralmente una stringa EICAR o una reverse shell per cui ClamAV stesso potrebbe segnalarlo.

Solo i file che il livello di firme statiche giudica «puliti» passano poi alla scansione ClamAV. I file appena inseriti nelle cartelle Download, Scrivania o Documenti vengono scansionati immediatamente da ClamAV, indipendentemente da un'estensione .tmp o da un attributo com.apple.quarantine (ad esempio una copia fatta da Terminale). EICAR e altre firme di test standard del settore sono considerate innocue: non viene mostrata alcuna notifica, ma solo registrata una voce nella cronologia delle notifiche, e non vengono mai messe in quarantena o bloccate (solo i campioni di malware autentici vengono messi in quarantena). E se un file con lo stesso nome era già stato messo in quarantena in precedenza, la nuova minaccia viene comunque spostata nella cartella di quarantena con un nome univoco e con timestamp, così una minaccia non può mai restare nella sua posizione originale a causa di una collisione di nomi.

Monitoraggio di nuova persistenza di avvio (LaunchAgent/LaunchDaemon) — 1.8.7

I nuovi file .plist collocati in ~/Library/LaunchAgents, /Library/LaunchAgents o /Library/LaunchDaemons vengono rilevati in tempo reale tramite FSEvents (PersistenceMonitorGuard). Senza ES_EVENT_TYPE_AUTH_CREATE di EndpointSecurity, la scrittura stessa non può essere bloccata. Ciò che si può fare è accorgersene entro pochi secondi e valutarne il contenuto.

La valutazione si basa su cosa viene avviato direttamente, non sulla firma dell'eseguibile stesso. Tecniche reali osservate nel 2026 — un LaunchAgent camuffato da Google Update che nasconde uno script bash decodificato in base64, oppure un LaunchDaemon con privilegi root che riesegue a ogni avvio un payload AppleScript decodificato in base64 — nascondono entrambe il codice malevolo nello script stesso, mentre richiamano semplicemente un /bin/bash o /usr/bin/osascript firmato validamente. Un controllo che guardasse solo la firma dell'eseguibile lascerebbe passare entrambi i casi. Per questo, qualsiasi LaunchAgent/LaunchDaemon appena registrato che invochi direttamente un interprete di script grezzo (bash, sh, zsh, osascript, python3, perl, ruby, php e simili) viene segnalato incondizionatamente, indipendentemente dalla validità della firma dell'interprete stesso. Gli argomenti passati vengono inoltre sottoposti a StaticSignatureScanner, e ogni pattern noto come malevolo viene incluso nella notifica. Le voci registrate tramite BundleProgram (che puntano a un binario compilato e firmato all'interno di un bundle applicativo, incluso l'Helper stesso di RoamSwitch) vengono semplicemente verificate nel modo consueto, con codesign --verify --strict.

Rilevamento di ClickFix e blocco di emergenza — 1.8.7, disattivato di default

«ClickFix» è una tecnica di ingegneria sociale in cui una falsa schermata CAPTCHA o di errore invita ad aprire il Terminale e a incollare un comando «per la verifica». Le rilevazioni sono aumentate di oltre il 500% dal 2024 al 2025, e entro il 2026 è considerata uno dei vettori di attacco macOS più diffusi. Poiché è la shell legittima dell'utente stesso a eseguire esattamente ciò che è stato digitato, elude completamente la verifica della firma di Gatekeeper.

Barra dei menu → Protezione da malware → Difesa ClickFix (Pro, disattivata di default). Monitora tramite FSEvents le nuove righe aggiunte a ~/.zsh_history/~/.bash_history (solo le righe aggiunte dopo l'avvio della protezione — non esamina mai la cronologia già esistente), e verifica la corrispondenza solo con le reverse shell da manuale condivise con StaticSignatureScanner, oltre alla specifica combinazione di decodifica base64 direttamente verso una shell o verso osascript. Un semplice curl | bash — estremamente comune negli installer legittimi — è deliberatamente escluso, poiché è indistinguibile dalle istruzioni ufficiali di installazione di Homebrew, rustup, nvm e simili. Non appena viene trovata una corrispondenza, si attiva lo stesso air-gap di emergenza descritto sopra. Poiché il comando è già stato eseguito, si tratta necessariamente di una reazione successiva, ma può comunque interrompere un download di seconda fase o un'esfiltrazione di credenziali in corso. Come qualsiasi altro trigger dell'air-gap, si disattiva da solo dopo al massimo 10 minuti (vedi l'inizio di questa sezione).

Un limite noto. Poiché il rilevamento dipende da una scrittura nella cronologia della shell, non può individuare la variante fileless che elude completamente il Terminale invocando direttamente l'Editor di script tramite lo schema URL applescript://, senza scrivere nulla su disco. Apple ha introdotto una certa mitigazione per questo (una finestra di conferma per gli script non identificati), ma sono state segnalate varianti che la aggirano. Abbiamo testato questo percorso su hardware reale usando il log unificato di macOS (log show/log stream) e non abbiamo trovato alcun segnale di log distintivo su cui basare il rilevamento. Preferiamo dichiarare apertamente questo limite piuttosto che rivendicare una copertura che non abbiamo.

Rilevamento rischi Docker — 1.8.9, Pro, disattivato per impostazione predefinita

Barra dei menu → "Protezione da malware" → "Rileva container Docker privilegiati e mount docker.sock" (DockerEventGuard). Poiché questa codebase non ha precedenti di connessioni di streaming persistenti come docker events, utilizza lo stesso approccio di polling a timer di PortAnomalyGuard. Ogni 20 secondi recupera l'insieme degli ID dei container con un leggero docker ps -q, quindi esegue docker inspect --format solo sulla differenza (container appena avviati) per un'ispezione dettagliata. La stringa di formato usata per il rilevamento è deliberatamente identica a quella dell'edizione Linux (roamswitch_core::health::LinuxHealthChecker::DOCKER_INSPECT_RISK_FORMAT), quindi entrambe le piattaforme segnalano esattamente le stesse condizioni (avvio in modalità --privileged, o un mount collegato di /var/run/docker.sock).

Nessuna azione automatica viene intrapresa al rilevamento. Un container privilegiato o un mount docker.sock è una "configurazione" rischiosa che potrebbe consentire l'escape dal container, ma non è una compromissione confermata: esistono anche usi legittimi, come l'esecuzione deliberata di un agente di monitoraggio in modalità privilegiata. Poiché la maggior parte degli utenti non utilizza affatto Docker, questa funzione resta disattivata per impostazione predefinita anche con una licenza Pro. Non utilizza l'entitlement EndpointSecurity; la CLI docker viene individuata controllando prima il percorso di installazione predefinito di Docker Desktop, poi Homebrew, poi which. Verificata su un'installazione reale di Docker Desktop (29.7.2) in tre scenari — un container privilegiato, un container con mount docker.sock e un container normale — senza falsi positivi né rilevamenti mancati.

Controllo fughe di segreti/chiavi API — aggiunto in 1.8.4, scansione cartelle aggiunta in 1.8.9

Barra dei menu → "Protezione da malware" → "Controllo fughe di segreti/chiavi API". Incolla del testo e viene verificato all'istante alla ricerca di chiavi API e token trapelati, mostrando il numero di riga, una stringa mascherata e un consiglio per ogni risultato (SecretLeakAuditor, interamente sul dispositivo). La versione 1.8.9 ha aggiunto l'opzione "Scegli cartella da scansionare", che consente allo stesso motore di rilevamento di controllare ricorsivamente una directory — come un checkout del codice sorgente — tramite auditDirectory(at:). .git, node_modules, target, vendor, dist, build, __pycache__ e venv vengono esclusi automaticamente, così come i file superiori a 2 MB o rilevati come binari. L'elaborazione viene eseguita fuori dal thread principale per non bloccare l'interfaccia, e non viene mai inviato nulla all'esterno.

Link Guard (blocco delle connessioni di phishing) — 1.7.2 e versioni successive, rafforzato in 1.8.0

Barra dei menu → "Protezione malware" → "Link Guard" (Pro). Blocca le connessioni a siti di phishing/truffa sul dispositivo, su ogni browser e app. Esistono due punti di applicazione, utilizzati insieme in ordine di priorità.

• ① Estensione del sistema di filtro dei contenuti (RoamSwitchLinkFilter, 1.8.0+, preferibile una volta approvata). Un'estensione del sistema NEFilterDataProvider: nessuna revisione da parte di Apple (i fornitori di filtri dei contenuti sono self-service, nessuna coda di approvazione). Esamina l'effettivo flusso TCP in uscita dopo risoluzione dei nomi. Il nome di destinazione deriva dal nome host risolto dal sistema operativo o, in caso contrario, TLS SNI viene analizzato dai primi byte del flusso, quindi un browser che esegue il proprio DoH/DoT e si connette a un IP nudo è ancora bloccato. Non riscrive mai /etc/hosts e attribuisce ogni flusso a un processo. QUIC (UDP/443) non ha SNI leggibile, quindi in modalità block viene eliminato, costringendo il browser a ricorrere a HTTP/2 su TCP. Richiede un'approvazione una tantum nelle Impostazioni di sistema.
• ② /etc/hosts sinkhole (fallback, mentre l'estensione non è approvata/rifiutata). L'helper privilegiato scrive i domini di destinazione in una sezione gestita delimitata di /etc/hosts come 0.0.0.0 e svuota la cache. Limite massimo a 60.000. Una volta attiva l'estensione, questa sezione verrà rimossa.
• Tre modalità. "Off" lo disabilita. "Solo avviso" mette in pausa la connessione corrispondente e chiede all'utente (vedi Real warn di seguito). "Blocco automatico dei siti truffa evidenti (consigliato)" viene eliminato immediatamente. L'impostazione predefinita è blocco a partire dalla versione 1.7.2.
• Real warn (1.8.0+, solo estensione). Su warn premi l'estensione di sistema holds il flusso (sia il nome del sistema operativo che il percorso SNI) con .pause() e l'app genera una notifica "Consenti/Blocca". Nel momento in cui il tocco dell'utente raggiunge allowlist.txt / extra.txt (l'estensione esegue il polling dei piccoli file di stato ogni 1,5 s) i flussi sospesi riprendono (consenti) o interrompono (bloccano). Nessuna risposta entro 25 s fallisce open (un avviso è consultivo). La decisione viene memorizzata nella cache per host (consenti 5 minuti/blocco 1 ora), quindi gli altri flussi della pagina e le visite successive sono istantanei e applicati. La notifica block è invariata: "Bloccato..." con un pulsante "Consenti una volta (5 min)".
• Solo i casi chiari vengono bloccati. Un elenco nel feed delle minacce o un omografo Unicode di un marchio: tutto il resto (TLD ad alto rischio, impersonificazione di sottodomini, ...) è un avvertimento. Il motore del verdetto è condiviso con l'edizione Linux e non invia URL da nessuna parte.
• Recupero da un blocco sbagliato. Consenti un dominio dalla notifica o dal menu (5 minuti o permanente). L'elenco consentito viene sottratto quando la sezione viene rigenerata.
• Pro-gate. L'applicazione (applyMode()) avviene solo su una licenza Pro valida. Senza Pro la modalità viene memorizzata ma /etc/hosts non viene mai toccata. L'attivazione o la decadenza di una licenza ha effetto a metà sessione.
• Feed e seed in bundle. L'elenco dei blocchi proviene dal feed delle minacce firmato (§7, verificato con una chiave dedicata al feed). Funziona sul seed in bundle dell'app (~ 60.000 voci) anche prima del primo recupero e la disattivazione dell'"Aggiornamento automatico" significa assenza di traffico in uscita.

Blocco preventivo ARP/NDP del gateway: 1.7.5 e versioni successive

Barra dei menu → "Monitoraggio porta e dispositivo" → "Aggiungi ARP/NDP del gateway su reti non attendibili (preventivo)" (Pro, disattivato per impostazione predefinita).

• Come funziona. Quando si accede a una rete non attendibile, il MAC corrente del gateway IPv4, del router predefinito IPv6 e dei risolutori DNS sul collegamento viene raccolto da route / scutil --dns / arp -n / ndp -an e l'helper blocca ciascuno come voce permanent con arp -s / ndp -s (attendibilità al primo utilizzo — il primo MAC osservato è attendibile). Le risposte ARP/NDP contraffatte per tali IP vengono quindi ignorate, quindi non è possibile impostare un attacco man-in-the-middle.
• Scope. Vengono bloccati solo questi tre tipi di voce. Le reti affidabili (aperte) non vengono mai bloccate. Ad ogni modifica della rete si sblocca una volta e si ricollega. I risolutori pubblici off-link (8.8.8.8, …) non hanno alcuna voce ARP on-link e sono automaticamente esclusi.
• arp -s è preventivo; l'air-gap è successivo al fatto. Questo pin esiste quindi uno spoofing non può avere successo; Il rilevamento dello spoofing ARP (ARPSpoofContainmentManager) e l'air-gap di emergenza esistono per "tagliare più velocemente di un essere umano" una volta che ne viene visto uno. Corrono in modo indipendente.
• Persistenza. Il set di pin viene salvato in /Library/Application Support/RoamSwitch/gateway_arp_lock.json in modo che possa essere sbloccato tramite una riconnessione XPC o un riavvio dell'assistente.

Il tunnel VPN (WireGuard/Tailscale) e il suo kill switch — 1.7.6 e versioni successive, backend selezionabile nella 1.8.0

Barra dei menu → "Monitor porta e dispositivo" → "Tunnel VPN" (Pro, disattivato per impostazione predefinita). Questa è la difesa primary anti-MITM: non dipende dall'integrità di L2 (ARP/NDP). Il backend è selezionabile (sottomenu → "Backend") tra "WireGuard (file di configurazione)" e "Tailscale (Nodo di uscita)". RoamSwitch non implementa alcuna crittografia stessa; solo il backend scelto è armato.

• (A) Backend WireGuard. Guida wireguard-tools di Homebrew (nessun diritto all'estensione di rete Apple). Importa il tuo .conf; l'aiutante lo salva in 0600. Kill-switch: pf block drop all più un pass quick solo per lo, l'interfaccia del tunnel, l'handshake UDP agli IP dell'endpoint bloccato, DHCP e ICMP. Un tunnel AllowedIPs non pieno genera un avviso di tunnel diviso.
• (B) Backend Tailscale (1.8.0+). Per gli utenti che già eseguono Tailscale. RoamSwitch non esegue tailscale up / accede / lo installa: legge tailscale status --json ed esegue tailscale set --exit-node=<node>. Si consiglia la CLI autonoma (brew install tailscale): la build dell'App Store (GUI) non può essere gestita dall'esterno dell'app (sandbox); con esso scegli il nodo di uscita nell'app Tailscale e RoamSwitch mostra solo lo stato. È richiesto un nodo di uscita (indirizza tutto il traffico attraverso il tunnel); viene disattivato automaticamente se va offline o non è raggiungibile.
• Riconfigurazione della rete alla disconnessione. Il macOS autonomo tailscaled non ripristina in modo pulito il routing + DNS quando un nodo di uscita viene cancellato, quindi RoamSwitch rimbalza i servizi di rete attivi (lo stesso che attivare manualmente il Wi-Fi; solo servizi con un indirizzo IPv4, sicuro per multi-NIC e IP statico). Il traffico diminuisce per circa 5-10 secondi e il livello di protezione non viene abbassato durante tale periodo.
• Il kill switch di Tailscale è disattivato per impostazione predefinita (opt-in). Il nodo di uscita esegue già il tunneling di tutto; il pf block drop all (consente solo CGNAT/MagicDNS/STUN/DERP/DHCP/ICMP/DNS) è per utenti avanzati ed è "resistente alle perdite, non a prova di perdite" (il DNS è consentito, quindi tailscaled sopravvive).
• Automatico / in caso di perdita della licenza. Si attiva su reti non attendibili, diminuisce su quelle attendibili; revocato alla scadenza della licenza Pro.

§6

Quando ti connetti a una rete che non hai registrato, l'interruttore del "livello di protezione" non viene utilizzato pf. Modifica semplicemente le impostazioni standard del sistema operativo in un modo che può essere invertito in seguito.

Niente di tutto questo è un nuovo meccanismo di blocco aggiunto da RoamSwitch: si tratta semplicemente di attivare/disattivare le impostazioni del sistema operativo. Se elimini l'app, l'unica cosa che si ferma è la commutazione dipendente dalla rete; l'ultimo sistema operativo le impostazioni applicate rimangono invariate. Niente viene lasciato bloccato, ma se vuoi sbagliare sul per sicurezza, reimpostarlo su "Aperto" su una rete attendibile prima di disinstallarlo.

§7

Cosa rimane sul Mac

Traffico in uscita dalla macchina (l'elenco completo)

Non esiste alcun codice che raccolga e invii risultati diagnostici, informazioni sulla porta, URL o registri. Non sono inclusi alcun SDK di analisi e alcun SDK di crash reporter. L'unica libreria esterna è Sparkle (aggiornamenti). Ciò che esce in rete sono questi otto e basta (il sesto solo se l'utente configura una VPN, il settimo solo se è attivata l'associazione RoamSwitch Sensor).

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

# Se il ticket di notarizzazione è stato allegato (staple)
stapler validate /Applications/RoamSwitch.app
spctl -a -t exec -vvv /Applications/RoamSwitch.app

# Firma dell'helper incluso / server MCP
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
# → Un dizionario di entitlements vuoto. Nessuna chiave app-sandbox / network client.

# Esegui tcpdump in parallelo per confermare che non ci sia traffico durante l'uso normale
sudo tcpdump -i any -n 'host not 127.0.0.1' and 'not port 53'
# Nessun traffico se non l'attivazione della licenza, i controlli di aggiornamento e gli aggiornamenti di ClamAV

Per un controllo più rigoroso e automatizzato con attribuzione per processo, vedere rs-zerotel-audit.sh in roamswitch-support/audit/

# Verifica automaticamente in un unico passaggio il confine di autorizzazione XPC, la priorità Air-Gap di pf, il rilevamento dell'esposizione delle porte, la modalità di sola lettura di MCP e il monitoraggio ARP
git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Test di penetrazione in tempo reale e audit di difesa multilivello da una VM macOS: RESULTS-DEFENSE-2026-08-30

# Interroga il dominio di test ufficiale di Quad9 per verificare il blocco delle minacce
nslookup test.dns9.quad9.net
# → Deve restituire ** server can't find test.dns9.quad9.net: NXDOMAIN, cioè la risoluzione dei nomi è bloccata

# Crea la stringa di test antivirus standard e innocua (EICAR) in Downloads
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/Downloads/eicar_test.com
# → Il rilevamento FSEvents attiva una scansione immediata di ClamAV; non viene mostrata alcuna notifica e "firma di test EICAR rilevata (innocua)"
#   viene registrata nella cronologia delle notifiche. Poiché EICAR è un file di test standard del settore e non una minaccia reale,
#   non viene messo in quarantena né bloccato e il file resta al suo posto (solo un vero campione di malware viene spostato nel gestore della quarantena).

## Una reverse shell da manuale tratta da riferimenti pubblici di offensive security (innocua, non viene mai eseguita)
echo 'bash -i >& /dev/tcp/127.0.0.1/4444 0>&1' > ~/Downloads/rs_test.sh
## → Anche senza ClamAV installato, appare una notifica «File scaricato pericoloso messo in quarantena» e il file viene
##   spostato immediatamente nella cartella Quarantine (indipendentemente dal database delle firme di ClamAV)

# Creare un LaunchAgent innocuo che invoca direttamente un interprete di script grezzo (non viene mai realmente eseguito)
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
# → Entro pochi secondi dovrebbe apparire una notifica «Rilevata nuova registrazione di avvio automatico». Rimuoverlo in seguito:
rm ~/Library/LaunchAgents/com.example.selfcheck.plist

# Se la sezione gestita è presente (2 righe BEGIN/END in modalità Pro + predefinita)
sudo grep -c 'RoamSwitch link guard' /etc/hosts

# Il contenuto della sezione e il numero di sinkhole
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'

# Se viene effettivamente bloccato (verificato con una voce della sezione; innocuo)
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 (risoluzione dei nomi bloccata)

# Verifica anche che la sezione precedente scompaia tramite Menu → "Protezione link" → "Off"

# Feed e manifest pubblici (chiunque può recuperarli e verificarli)
curl -s https://lafine.net/updates/v1/manifest        # version/generated/threatfeed{...}
curl -sI https://lafine.net/updates/v1/manifest.sig   # → text/plain
# Viene inviata solo una GET senza query string, cookie o identificatori. Verificabile eseguendo tcpdump in parallelo.

# Connettersi a una rete non attendibile con il blocco preventivo attivo → verificare le voci permanent
arp -an | grep -i permanent          # Il gateway e le altre IP sono elencati come (permanent)
ndp -an | grep -i 'P '               # Lato IPv6 (P = permanent)
sudo cat "/Library/Application Support/RoamSwitch/gateway_arp_lock.json"  # L'insieme delle mappature IP→MAC attualmente fissate
# Rilascia il blocco dal menu → quanto sopra dovrebbe scomparire

# Presuppone wireguard-tools (tramite Homebrew)
brew list wireguard-tools >/dev/null && echo "wireguard-tools: OK"

# Attiva la VPN su una rete non attendibile → prima che il tunnel sia attivo, pf è in stato di kill-switch
sudo pfctl -sr | grep -E 'block drop all|pass .*(utun|udp)'   # block drop all + un insieme limitato di regole pass quick

# Dopo che il tunnel è attivo (wg-quick up già eseguito)
wg show                              # handshake / transfer è attivo
route -n get default | grep interface  # → utunN (la route predefinita è il tunnel)
# Disattiva la VPN → il kill-switch viene rilasciato e pf torna allo stato precedente

# Il LaunchDaemon registrato
sudo launchctl print system/com.tetsuharu.RoamSwitch.Helper

# Le regole pf attualmente caricate (stato reale di Air-Gap / guardia porte)
sudo pfctl -sr

# La directory di stato dell'helper
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"
# Restituisce serverInfo e le definizioni dei 5 strumenti. Non si verifica alcuna connessione di rete.

git clone https://github.com/lafine1211/roamswitch-mcp
cd roamswitch-mcp
swift build -c release        # Lo stesso codice sorgente del binario distribuito
swift test                    # Test unitari, input avversari, stdio e fuzzing a mutazione
# Consulta SECURITY_TESTING.md per il contenuto dei test e i problemi riscontrati

# Il valore grezzo associato al token (viene inviato solo uno SHA-256 con salt)
ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'