Livre blanc sur l'architecture et la sécurité de RoamSwitch

§1

RoamSwitch est une application de barre de menus pour Mac. En fonction de votre confiance dans le réseau que vous faites actuellement connecté, il bascule automatiquement le pare-feu macOS, les services de partage, AirDrop, et DNS. It also watches for ARP spoofing, ports open to the outside, USB storage, and ransomware-like encryption activity, and when it detects something dangerous it will go as far as cutting off traffic with the packet filter (pf) — an emergency air-gap.

En d'autres termes, RoamSwitch installe un démon bénéficiant des privilèges root et, s'il le voulait, il pourrait tout arrêter. trafic réseau sur Mac. It is built by one person, and "please trust me" is not enough to justifier ce privilège. Au lieu de cela, ce document explique la conception sous une forme que vous pouvez vérifier.

Pour qui c'est

• Les ingénieurs décident de l'installer ou non
• Security researchers and journalists who want to understand the internals before a review or an article
• Personnel de sécurité des entreprises partenaires évaluant un déploiement interne ou un regroupement OEM

Ce que ce document ne couvre pas

It does not go into detection-threshold tuning, false-positive statistics, or UI walkthroughs. Ce qu'il explique, ce sont quatre choses : les privilèges , les limites des processus, le flux de données et cryptographie. Les spécifications des fonctionnalités elles-mêmes se trouvent dans la ressource MCP fournie roamswitch://docs/features et dans l'aide intégrée à l'application.

Ce qui est divulgué et dans quelle mesure (politique de divulgation)

This document is written on the assumption that an attacker already has the distributed binary. Every endpoint URL, identifier, file path, XPC protocol, and embedded public key that appears here peut être retiré du colis d'expédition RoamSwitch.app en quelques minutes avec strings, codesign -d ou un proxy de trafic. Les écrire ici donc ne donne rien de nouveau à un attaquant. La seule chose qu'il fait progresser est la compréhension du critique.

On the other hand, server-side implementation that cannot be seen from the binary — rate-limit thresholds, keys, admin endpoints, the DB schema, the Firebase project layout — is not included. La conception de l'intégration des OEM et des partenaires est également hors de portée ici et est couverte dans un document distinct. document interne. « Ce que vous pouvez apprendre en observant le client » est la ligne de divulgation pour cela. documenter.

§2

RoamSwitch.app est composé de trois exécutables. Un seul d’entre eux est privilégié ; le deux autres fonctionnent avec des droits d'utilisateur de connexion. All three ship with Hardened Runtime enabled, Developer ID signé et notarié.

Droits et signature

• Les trois cibles ont ENABLE_HARDENED_RUNTIME = true.
• L'application Sandbox est désactivée (com.apple.security.app-sandbox = false). Les droits de l'assistant et de MCPServer sont des dictionnaires vides.
• Les versions de distribution sont des applications d'ID de développeur signées, notariées par Apple et agrafées (§10).

§3

Comment il est enregistré

L'assistant est enregistré en tant que LaunchDaemon en utilisant SMAppService.daemon(plistName:). Le plist intégré à l'application (Contents/Library/LaunchDaemons/com.tetsuharu.RoamSwitch.Helper.plist) déclare uniquement Label, BundleProgram, une seule entrée MachServices, et AssociatedBundleIdentifiers. En raison du fonctionnement de SMAppService, l'inscription n'est même pas possible à moins que l'application soit en /Applications. Au premier l'enregistrement, l'assistant ne devient actif que lorsque l'utilisateur l'approuve manuellement dans le système Paramètres.

Dont les connexions sont acceptées (ClientValidator)

L'assistant inspecte le processus de connexion dans les NSXPCListener shouldAcceptNewConnection et distribue HelperProtocol uniquement à ceux qui passer. L'inspection utilise le audit_token plutôt que le PID, pour éviter la réutilisation du PID et du TOCTOU.

# Exigences de signature de code imposées par le build Release aux clients qui se connectent
identifier "com.tetsuharu.RoamSwitch"
  and anchor apple generic
  and certificate leaf[subject.OU] = "GV76B6G4YU"

Cette exigence est vérifiée avec SecCodeCopyGuestWithAttributes et SecStaticCodeCheckValidity, et la connexion est interrompue si elle échoue. Seulement Les versions DEBUG suppriment le code PIN d'identification de l'équipe, pour faciliter le développement. Ce qui est réellement expédié est toujours un Version de publication.

Ce que l'assistant peut faire (la liste complète)

Les opérations privilégiées définies dans Shared/HelperProtocol.swift le sont toutes. Il n’existe aucune API privilégiée qui ne soit répertoriée ici.

État à l'intérieur de l'assistant

• HelperTool.shared est une instance unique partagée entre les connexions. Auparavant, il s'agissait d'une instance distincte par connexion, donc un confinement d'urgence qui ouvrait une nouvelle connexion pouvait frapper une course qui perdait la trace des « services à ramener ».
• Les sauvegardes du service de partage et DNS sont uniquement mutées sur une file d'attente série (stateQueue).

Séparation des privilèges dans l'assistant et exception pour la lecture du journal SSH

Juste après son démarrage, l'assistant s'impose à lui-même un plafond appliqué par le noyau (un bac à sable d'exécution, distinct de l'entitlement App Sandbox mentionné plus haut), que les processus enfants qu'il lance héritent. Ce plafond empêche de remplacer des programmes système, d'enregistrer un LaunchDaemon ou un LaunchAgent, de réécrire la configuration de sudoers, PAM ou sshd, d'écrire directement dans le magasin de répertoires local et d'exécuter des programmes situés dans des emplacements où les utilisateurs, les volumes externes ou les dossiers temporaires peuvent écrire. Il n'empêche pas les modifications de comptes faites via Open Directory (dscl) et ne restreint pas le trafic réseau (ce n'est pas son rôle).

Sous ce plafond, /usr/bin/log ne s'exécute pas. Sous macOS 26, log refuse de s'exécuter dans un bac à sable (log: Cannot run while sandboxed) et aussi en tant que nobody (Must be admin). Ni l'app de l'utilisateur connecté ni l'assistant root dans son bac à sable ne peuvent donc lire le journal de sshd (le journal unifié). La détection de la force brute SSH doit lire ce journal ; la séparation des privilèges comporte donc une exception.

L'exception est un petit processus root : avant d'entrer dans son bac à sable, l'assistant lance le même binaire avec --ssh-log-reader. Ce processus n'accepte qu'une commande d'un octet (démarrer ou arrêter) et ne fait rien d'autre que lancer /usr/bin/log avec des arguments fixes (log stream --style ndjson --level info et un filtre fixe qui ne garde que les lignes de sshd). Il ne transmet aucune variable d'environnement, et l'appelant n'a aucun moyen de choisir des arguments ou une commande. Il ne lit ni n'interprète le journal ; la sortie va dans un tube que l'assistant lui a remis.

Les lignes du journal contiennent des chaînes qu'un attaquant peut écrire, comme le nom d'utilisateur ; l'assistant root ne les interprète donc pas. Il confie chaque ligne à un processus d'analyse qui s'exécute en tant que nobody dans un bac à sable interdisant l'accès au réseau, l'écriture de fichiers et le lancement ou la duplication de processus, et l'adresse source est prise à la fin de la ligne (IP port N), que le nom d'utilisateur ne peut pas influencer. Sur un Mac dont la session à distance est désactivée, ce processus ne lance pas log et ne lit rien. Cinq opérations SSH peuvent être appelées par le XPC de l'assistant : appliquer les réglages, récupérer l'état, les enregistrements et les connexions, et lever un blocage. Aucune n'accepte de commande.

§4

Quatre fonctionnalités touchent pf : l'entrefer d'urgence, la protection du port du serveur de développement, le tunnel VPN Le kill-switch WireGuard (§5, 1.7.6+) et son kill-switch Tailscale (§5, 1.8.0+ — uniquement le backend sélectionné). Tous y vont toujours via un point d'entrée unique, PFRulesetCoordinator, et ne jamais exécuter pfctl -f eux-mêmes.

Pourquoi il y a un point d'entrée unique

Auparavant, les deux fonctionnalités chargeaient chacune des règles avec pfctl -f indépendamment, en concurrence sur l'ensemble de règles principal unique de pf. Si la règle étroite block ... port {…} du garde portuaire était chargé après le block drop all de l'entrefer, vous pourriez vous retrouver dans un état où l'écran dit "isolé" mais le Mac était toujours accessible. Ce bug a été trouvé en attaquant réellement le machine d'un autre hôte, et a été corrigé dans la version 1.4.3 (l'histoire est écrite dans docs/marketing/zenn/03_lan_side_attack_test.md).

Comment ça marche maintenant

• Reconstruit entièrement à chaque fois. L'ensemble des règles requises est reconstruit à partir de l'état actuel et appliqué en une seule fois. Il n’est jamais appliqué comme différence.
• Une file d'attente série. Chaque modification de pf s'exécute sur le même DispatchQueue, donc qu'elle provienne d'une connexion XPC, du démarrage de l'assistant ou de la minuterie de sécurité, les modifications sont traitées dans l'ordre.
• L'ordre de priorité est le suivant (les éléments les plus haut priment).
  1. Entrefer de secours → set skip on lo0 et block drop all (rien d'autre n'est pris en compte)
  2. Kill-switch VPN → block drop all plus pass quick pour uniquement : lo, l'interface du tunnel (utunN), la prise de contact UDP avec les IP du point de terminaison épinglé, DHCP et ICMP
  3. Garde du serveur de développement → block drop in quick proto tcp ... port { … }
  4. Aucun → rechargez /etc/pf.conf et remettez pf à son état d'origine
• Relisez après l'application. pfctl -sr lit les règles pour confirmer que block drop all, ou la règle de chaque port, est réellement chargée. Un cas où pfctl -f a été silencieusement ignoré n'est pas traité comme un succès.
• Le fichier temporaire est écrit dans un chemin contenant un UUID et supprimé une fois appliqué (la v1.4.5 a abandonné le chemin fixe au profit d'un chemin difficile à deviner). Le répertoire d'état est /Library/Application Support/RoamSwitch.

§5

Les types de blocs sont différents

Comment l'Air-Gap ne s'éternise pas et ne peut pas être attendu

• La façon dont il se termine dépend de ce qui l'a déclenché (à partir de 1.9.52). Un leurre anti-rançongiciel altéré, une détection XProtect confirmée et un isolement manuel choisi depuis un avertissement ARP sont de « confiance élevée » ; ClickFix, les anomalies de port et similaires sont de « confiance faible ». Un isolement de confiance faible se lève toujours de lui-même au bout de 10 minutes au plus. Un isolement de confiance élevée ne se lève pas à 10 minutes : une levée complète fondée sur le seul temps permettrait à un attaquant de simplement attendre.
• Un isolement de confiance élevée reste totalement fermé jusqu'à une limite (1 heure par défaut, de 5 minutes à 24 heures dans les réglages) et vérifie alors la cause. Pour un rançongiciel, la cause n'est jugée disparue que si le processus suspect a été identifié et a pris fin, et que les leurres n'ont pas changé depuis la détection. Si cela ne peut être confirmé, il passe en « mode dégradé » : les nouvelles connexions restent bloquées (sauf boucle locale et DHCP) tandis que seule la radio Wi-Fi est rétablie, pour que vous puissiez voir ce qui se passe. Il ne s'ouvre jamais du seul fait du temps écoulé. Il ne s'ouvre que si vous le levez ou si la cause est confirmée disparue.
• Au début d'un isolement, les connexions déjà ouvertes vers l'extérieur sont aussi coupées. La table d'états de pf est vidée (pfctl -F states), ce qui arrête le trafic antérieur à l'isolement. Il en va de même au passage en mode dégradé.
• Un isolement causé par une usurpation ARP n'est levé automatiquement que lorsque la disparition de la cause est confirmée sans aucun trafic. La vérification ne fait que lire le cache ARP (elle n'envoie aucun paquet) et juge la cause disparue lorsque la MAC de confiance de la passerelle est vue lors de 3 vérifications consécutives couvrant au moins 60 secondes. Pendant l'isolement, cependant, l'entrée ARP de la passerelle peut disparaître de la table de voisinage (confirmé sur un vrai Mac) ; la cause ne peut alors pas être confirmée. Dans ce cas, l'isolement reste en mode dégradé jusqu'à ce que vous le leviez.
• Même si l'assistant plante, la vérification de levée ne s'arrête pas. Un LaunchDaemon dédié sans aucun KeepAlive (AirGapFailsafe) démarre seul toutes les 3 minutes et prend la même décision que l'assistant (confiance faible : levée à 10 minutes ; confiance élevée : vérification de la cause à la limite, puis mode dégradé). Si l'assistant plante lui-même et perd son propre minuteur de levée, ce filet de sécurité n'est pas affecté (depuis 1.8.6 ; la décision selon la confiance depuis 1.9.52).
• Ce démon dédié ne touche jamais à la configuration de démarrage propre de l'assistant interactif. Une tentative antérieure (1.8.5) utilisait le KeepAlive.PathState propre à l'assistant pour cette récupération, mais cela interférait parfois avec une fermeture normale de l'application et provoquait un redémarrage non désiré ; elle a donc été annulée au profit du démon actuel, totalement indépendant.
• La vérification de l'horodatage utilise une combinaison hybride du temps de fonctionnement monotone (ProcessInfo.systemUptime) et de l'heure murale. Elle privilégie normalement le temps de fonctionnement monotone, de sorte que les corrections NTP et les changements manuels d'horloge n'ont pas d'effet. Elle ne revient à l'heure murale que lorsque le temps de fonctionnement ne peut pas être fiable — juste après un redémarrage, détecté lorsque la valeur actuelle est inférieure à celle stockée.
• Il est réappliqué après un redémarrage ou la recréation du démon. Au lancement, l'assistant lit l'état sur le disque avec reapplyFromDisk() et restaure lui-même l'Air-Gap, la garde des ports et les réglages système par défaut, dans cet ordre. Il reprend aussi l'état de l'isolement (confiance, complet ou dégradé) et le temps écoulé ; le décompte continue depuis le premier déclenchement (confirmé sur un vrai Mac en redémarrant l'assistant).
• Un ascenseur échoué est traité comme un échec. Si block drop all n'a pas pu être supprimé, l'horodatage est réécrit afin que le minuteur de sécurité et la nouvelle tentative aient quelque chose sur lequel converger. L'écran n'affiche jamais faussement "levé".
• Vous pouvez reprendre la main à tout moment : avec « Lever l'isolement Air-Gap » dans la barre des menus, avec le bouton de levée de la fenêtre modale, ou simplement en coupant le Wi-Fi. La levée ne demande pas Pro (elle fonctionne même si Pro expire en plein isolement).

Comment récupérer un faux positif de port-guard

Le blocage automatique des ports inconnus (Pro, activé par défaut une fois Pro activé) peut arrêter un Récepteur LAN — LocalSend, Syncthing, tout a démarré après l'activation de la garde. Quand ça se produit, autorisez-le à partir du bouton "Autoriser" sur la bannière de notification ou de la ligne correspondante dans l'écran "Ports exposés". Un exécutable autorisé une fois est enregistré comme connu et n'est pas bloqué encore une fois (PortAnomalyGuard.allowPort(_:)). Notez que les interpréteurs de script génériques (Python, Node.js, Netcat, etc.) sont strictement limités par path:port plutôt que par binaire seuls pour empêcher les attaques visant à vivre de la terre. Démons du système Apple qui satisfont anchor apple (rapportd, qui soutient Handoff, etc.) ne sont pas regardé en premier lieu.

Appât pour canaris et suppression du confinement par ransomware auto-réparateur

Si les fichiers du leurre Canary sont falsifiés ou renommés et déclenchent l'entrefer d'urgence, libérant le confinement après vérification de la sécurité régénère automatiquement les fichiers Canary manquants ou corrompus revenir à leur hachage de base authentique généré à partir de modèles intégrés, rétablissant immédiatement la surveillance ininterrompue de kqueue (empêchant la contamination de base de l'adversaire). De plus, pendant le confinement actif (lorsque le mode d'urgence est affiché), les alertes de notification redondantes et les événements de redéclenchement issus d'interrogations périodiques d'intégrité en arrière-plan sont automatiquement supprimés pour éviter de distraire l'utilisateur lors de la réponse à un incident.

Détection générique des rançongiciels par entropie — 1.10.0, Pro, activée par défaut

Surveille les dossiers Documents, Bureau, Téléchargements et Photos via FSEvents, et se déclenche lorsque des écritures dont l'entropie de Shannon dépasse le seuil (7,92) arrivent en rafale de 20 fichiers ou plus en 5 secondes. Contrairement à l'approche canari (fichier leurre), elle ne dépend pas de l'altération d'un fichier appât, et détecte donc aussi le chiffrement dans des emplacements sans fichier canari. Ce n'est qu'une fois le seuil atteint qu'elle utilise lsof pour identifier le processus et le comparer à une liste d'autorisation (cp, mv, ditto, tar, ffmpeg, Xcode, Time Machine, principaux navigateurs, etc.). En cas de détection, elle déclenche le même blocage réseau automatique, via RansomwareContainmentManager, que la garde canari.

L'édition Linux peut suivre les rafales par processus, car fanotify associe un PID à chaque événement d'écriture. macOS ne dispose ni de fanotify ni (par choix) d'EndpointSecurity ; cette implémentation ne lit donc que le chemin via FSEvents et compte la rafale globalement, indépendamment du processus. Limite : lorsque plusieurs processus légitimes écrivent simultanément un grand nombre de fichiers à haute entropie (des travaux de compression ou de chiffrement concurrents, par exemple), un faux positif est plus probable ici que sur l'édition Linux.

Instantanés d'avant les dégâts pour la récupération après rançongiciel (Mac)

Un instantané pris au moment de la détection contient déjà les fichiers chiffrés avant celle-ci, il ne permet donc pas de revenir en arrière. RoamSwitch crée donc des instantanés locaux APFS à intervalle régulier, indépendamment de toute détection (toutes les 6 heures par défaut ; désactivé, 1, 3, 6, 12 ou 24 heures). Quand une détection survient, les nouveaux instantanés d'avant les dégâts et le nettoyage sont suspendus jusqu'à 7 jours (mode de conservation), afin que l'état chiffré ne chasse pas la dernière génération d'avant le chiffrement. La récupération est toujours manuelle : seuls les fichiers choisis sont copiés vers ~/RoamSwitch-Recovered/. Les fichiers actuels ne sont jamais écrasés et aucune restauration de tout le volume n'est proposée. La copie exige de monter l'instantané, donc l'assistant privilégié a besoin de l'accès complet au disque (les instantanés sont quand même créés sans lui). macOS peut supprimer seul les instantanés locaux, par exemple quand l'espace libre baisse, et rien ne garantit leur conservation au-delà d'environ 24 heures. La fenêtre de récupération est une fonction Pro (la création des instantanés fonctionne aussi sans Pro).

Bundle de preuves forensiques — 1.10.0

Lorsqu'un Air-Gap d'urgence démarre — déclenché par la garde canari, la garde ransomware par entropie ou une garde similaire — une file d'attente en arrière-plan qui ne bloque pas le confinement lui-même enregistre un instantané de la liste des processus (ps), des connexions réseau (lsof -i), des fichiers modifiés au cours des cinq dernières minutes, et des fichiers ouverts par le processus suspect, dans ~/Library/Application Support/RoamSwitch/incident-evidence/<horodatage>/manifest.json. Le manifeste consigne le SHA-256 de chaque artefact afin qu'une falsification ultérieure puisse être détectée. La liste des bundles est disponible via l'outil MCP get_forensic_evidence_bundles. Limite : conçu sans droit EndpointSecurity, il ne capture ni trace de paquets ni instantané mémoire/descripteurs de fichiers du processus.

Enregistrement des exécutions de processus (Mac, Pro, désactivé par défaut)

L'assistant privilégié lance le /usr/bin/eslogger fourni par macOS (exec, fork, exit) comme processus enfant et enregistre les lancements de processus sur ce seul Mac. Il ne demande pas l'entitlement EndpointSecurity (il n'appelle jamais es_new_client) ; RoamSwitch doit être autorisé dans Accès complet au disque (Réglages Système ; s'il n'apparaît pas, ajoutez /Applications/RoamSwitch.app avec « + »). Tant que l'autorisation manque, il affiche l'état « indisponible », attend et revérifie toutes les 60 secondes (il ne passe pas à un sondage coûteux). Il ne fait que notifier. Il ne bloque ni l'exécution ni la communication et n'isole pas.

Notifie ces dix comportements : un navigateur, une application Office ou de messagerie lançant directement un shell ; l'exécution d'un binaire non signé depuis un dossier temporaire ou un emplacement mis en quarantaine ; une commande sur une ligne qui télécharge puis transmet à un shell (combinée à une URL en IP brute, base64, eval ou une vérification TLS désactivée) ; osascript utilisant base64 ou eval ; l'exécution d'un fichier juste après le retrait de son attribut de quarantaine ; le lancement d'un binaire non signé depuis un enregistrement de démarrage automatique tout juste écrit (LaunchAgent ou LaunchDaemon) ; un parent non signé par Apple lisant un secret du trousseau (comme security find-generic-password -w) ; une commande sur une ligne python3, perl, ruby, php ou pwsh avec -c/-e/-Command, où un décodage base64/eval et un appel à curl, wget, exec ou system apparaissent tous deux sur la même ligne (à partir de 1.10.0 — base64 ou eval seuls ne déclenchent pas cette détection) ; et le lancement d'un processus avec la variable d'environnement DYLD_INSERT_LIBRARIES définie (à partir de 1.10.0 — pour éviter toute fuite, seule la valeur de cette unique variable est lue ; les processus signés par Apple en sont exclus) ; et une ligne de commande qui désigne directement un faux fichier d'identifiants posé par RoamSwitch (comme ~/.aws/credentials ou ~/.env.backup, reconnu par le marqueur qu'il contient), par exemple cat, tar ou curl -F ; les vrais fichiers ne correspondent jamais, et les lectures via une bibliothèque relèvent de la surveillance des honeytokens. Chaque détection porte un identifiant de technique MITRE ATT&CK.

Seules les détections de gravité élevée deviennent des bannières, et celles du même type sont regroupées à une par 10 minutes (chaque événement reste dans l'enregistrement). Les outils de développement comme Claude Code et la CLI GitHub qui lisent leurs propres identifiants ne sont pas notifiés par défaut. Si un autre programme les lit, l'action « Autoriser ce programme » de la notification autorise seulement cet élément (par Team ID s'il est signé, sinon par nom d'exécutable, associé au nom de l'élément).

L'enregistrement est stocké lisible par root seul (dossier 0700, fichiers 0600) et conserve 200 Mo et 14 jours par défaut. Les variables d'environnement ne sont pas stockées, mais les arguments de ligne de commande peuvent contenir des secrets. Chaque segment est scellé dans une chaîne de hachage reliée au hachage du segment précédent, et « Vérifier la chaîne » détecte les modifications, les segments manquants et les scellés supprimés (chacun confirmé sur un vrai Mac). Cela détecte l'altération, sans l'empêcher. La suppression ou le retour en arrière du segment le plus récent ne peut pas être détecté. La lecture passe par le XPC de l'assistant, et MCP passe par l'app (avec une revérification de Pro).

Limites : les exécutions avant le démarrage de l'assistant ou avant l'activation de l'enregistrement ne sont pas enregistrées. eslogger observe après coup et ne peut pas bloquer. Sous une charge telle que des milliers de lancements de processus par seconde, des événements sont perdus (le nombre s'affiche à l'écran et le fonctionnement continue). Cet enregistrement ne remplace pas un EDR (détection et réponse sur les terminaux).

Honeytokens d'identifiants — 1.10.0, Pro, activés par défaut

Place un fichier d'identification leurre, marqué d'une valeur sentinelle, à chacun de ces trois emplacements : ~/.aws/credentials, ~/.ssh/id_rsa_backup et ~/.docker/config.json. Il n'écrase jamais un fichier réel déjà présent à cet emplacement. La détection d'accès combine le même mécanisme kqueue (DispatchSource.makeFileSystemObjectSource) que la garde canari avec un sondage de la date d'accès toutes les 30 secondes, car sans EndpointSecurity un événement open() ne peut pas être capté de manière fiable. La détection ne fait que notifier ; elle ne bloque jamais rien et ne déclenche aucune isolation. Le leurre ssh utilise un nom que ssh ne cherche pas par défaut (et non id_rsa), de sorte qu'une exécution normale de ssh n'est ni perturbée ni signalée à tort. Le leurre AWS utilise un nom de profil distinct au lieu de [default], le leurre Docker pointe vers un registre interne inexistant, et tous sont créés avec le mode 0600 (depuis la 1.10.3). En plus de ces trois emplacements, ~/.pypirc et ~/.env.backup reçoivent aussi un leurre (pour les recherches de jetons PyPI, de fichiers .env et de clés d'API d'IA). ~/.npmrc n'est pas utilisé, car npm le lit à chaque exécution, et les identifiants GCP non plus, car un faux fichier casserait l'authentification réelle. Lorsqu'un leurre est réellement consulté, exactement un leurre associé (~/.aws/config, ~/.ssh/config ou ~/.kube/config) est posé en plus et surveillé lui aussi ; la chaîne s'arrête après une étape, et aucun fichier existant n'est écrasé.

Surveillance de l'accès aux identifiants du navigateur — 1.10.0, opt-in même dans Pro, désactivée par défaut

Surveille, via FSEvents, les écritures dans les bases de données de mots de passe/cookies enregistrés de Chrome, Brave, Edge, Vivaldi, Chromium et Firefox. En cas de rafale, lsof identifie le processus ; tout ce qui n'est pas le navigateur lui-même, un indexeur comme Spotlight, ou un démon de sauvegarde, compte comme une détection. Contrairement aux autres nouvelles gardes, l'activation de Pro ne l'active pas automatiquement — une extension de navigateur ou la fonction d'importation d'un gestionnaire de mots de passe peut la déclencher, si bien que le risque de faux positif est suffisamment inhérent pour qu'elle soit livrée en opt-in.

Communication avec le Sensor (TLS et signatures)

L'appairage, les demandes d'audit et la récupération des résultats avec un RoamSwitch Sensor (un produit distinct) sur le même réseau local utilisent TLS 1.3 avec l'empreinte du certificat (SHA-256) épinglée (Sensor 0.3.9 et ultérieur). L'empreinte n'est pas récupérée par le réseau ; l'utilisateur saisit la valeur affichée sur l'écran du Sensor. L'autorité de certification, le nom d'hôte et l'expiration ne sont pas vérifiés, seule la valeur épinglée est crue. Si TLS échoue, il ne bascule pas en clair (ce repli permettrait à un homme du milieu de rétrograder la connexion). Les signatures des requêtes incluent un horodatage et un nonce (v2) pour empêcher le rejeu. Seul un ancien appairage sans empreinte se connecte encore en clair comme avant, avec un avertissement.

Si le certificat change, la connexion est refusée. La mise à jour de l'épinglage n'est jamais automatique : elle n'est enregistrée que si l'utilisateur saisit et confirme la nouvelle valeur et qu'une sonde signée réussit réellement en TLS. Limite : cette sonde ne vérifie pas par clé que ce Sensor est le même que celui appairé auparavant. Elle suppose que l'utilisateur saisit la valeur qu'il a confirmée sur l'écran du Sensor.

Détection multicouche des téléchargements (signatures statiques + ClamAV) — couche de signatures statiques ajoutée en 1.8.7

Les fichiers nouvellement placés dans les dossiers Téléchargements, Bureau ou Documents passent d'abord par une vérification légère de signatures statiques via StaticSignatureScanner (seulement les 4 premiers Mo, simple correspondance de motifs d'octets AND/OR — aucune expression régulière ni calcul d'entropie). Elle ne nécessite pas l'entitlement EndpointSecurity et continue de fonctionner même là où ClamAV n'est pas installé. La détection est délibérément limitée à ce qui peut être affirmé comme un fait sans corpus de malware réel : la signature de test EICAR, norme du secteur, et cinq reverse shells classiques documentés dans des références publiques d'offensive security (par exemple PayloadsAllTheThings) — /dev/tcp/ de bash/sh, -e de netcat, pty.spawn de Python, Socket de Perl, et fsockopen de PHP. Nous n'écrivons pas de « signatures » au niveau des octets pour des familles de malwares nommées sans disposer d'un échantillon réel dont les extraire — ce ne serait qu'un faux sentiment de sécurité. Les motifs eux-mêmes sont stockés obfusqués par XOR 0x5A, afin que le binaire de RoamSwitch n'intègre jamais littéralement une chaîne EICAR ou un reverse shell que ClamAV pourrait lui-même signaler.

Seuls les fichiers que la couche de signatures statiques juge « propres » passent ensuite à l'analyse ClamAV. Les fichiers nouvellement placés dans les dossiers Téléchargements, Bureau ou Documents sont analysés immédiatement par ClamAV, qu'ils portent ou non une extension .tmp ou un attribut com.apple.quarantine (par exemple une copie faite via le Terminal). EICAR et les autres signatures de test standard du secteur sont traités comme inoffensifs : aucune notification n'est affichée, seule une entrée est ajoutée à l'historique des notifications — et ils ne sont jamais mis en quarantaine ni bloqués (seuls les échantillons de malware réels sont mis en quarantaine). Et si un fichier du même nom avait déjà été mis en quarantaine auparavant, la nouvelle menace est tout de même déplacée vers le dossier de quarantaine sous un nom unique horodaté, afin qu'une menace ne puisse jamais rester à son emplacement d'origine à cause d'une collision de noms.

Détection de web shells dans les dossiers web de développement (Web Rules)

Les fichiers du développement web local (~/Sites, MAMP, Herd, Local, /Library/WebServer/Documents et les dossiers de projet enregistrés pour le rapprochement des CVE de paquets) sont analysés avec les mêmes 18 règles de détection que l'édition Linux : PHP, JavaScript, JSP et ASP. Les règles décrivent uniquement des techniques publiquement documentées et ne contiennent aucune signature tirée d'un échantillon réel. Il y a trois couches : intégrées à l'app, une mise à jour signée en réception seule une fois par jour (incluse dans la récupération unique existante) et vos propres règles dans ~/Library/Application Support/RoamSwitch/rules.d (seuls sont lus les fichiers appartenant à root ou à vous et non modifiables par le groupe ou les autres). Les dossiers déjà surveillés, comme Téléchargements, sont analysés juste après une écriture ; les dossiers web de développement une fois par jour et à la demande (l'analyse quotidienne n'entre pas dans node_modules ni .git ; l'analyse d'un dossier choisi entre dans node_modules). EndpointSecurity n'étant pas utilisé, rien ne peut être arrêté avant son exécution : toute détection est faite après coup.

Par défaut, seul critical est mis en quarantaine automatiquement. Un résultat high laisse le fichier intact et apparaît comme notification et dans une liste des réglages, où vous pouvez choisir « ne plus détecter » (le niveau de quarantaine se règle dans les réglages). Le hook post-détection (~/Library/Application Support/RoamSwitch/hooks/post-detection) ne s'exécute que s'il appartient à root ou à vous et que personne d'autre ne peut l'écrire, et il est arrêté après 30 secondes. La réponse sur les comptes (désactivée par défaut ; l'activer demande le mot de passe administrateur) révoque le shell de connexion du propriétaire d'un fichier mis en quarantaine, mais ne touche ni root, ni les UID inférieurs à 501, ni les utilisateurs connectés (vous compris, qui utilisez ce Mac). Exécuté en root sous le propre bac à sable de l'assistant dans une machine virtuelle macOS 26, le vrai changement de shell par dscl et sa restauration ont été vérifiés (le bac à sable bloque les écritures directes dans dslocal, mais pas les changements faits via dscl). La confirmation par mot de passe administrateur et le chemin d'appel de l'app vers l'assistant n'ont pas encore été vérifiés sur une machine réelle. Il y a eu 0 résultat sur 114 501 fichiers d'un dossier de développement.

Surveillance des nouvelles persistances de démarrage (LaunchAgent/LaunchDaemon) — 1.8.7

Les nouveaux fichiers .plist placés dans ~/Library/LaunchAgents, /Library/LaunchAgents ou /Library/LaunchDaemons sont détectés en temps réel via FSEvents (PersistenceMonitorGuard). Sans ES_EVENT_TYPE_AUTH_CREATE d'EndpointSecurity, l'écriture elle-même ne peut pas être bloquée. Ce qui est possible, c'est de la remarquer en quelques secondes et d'en évaluer le contenu.

L'évaluation porte sur ce qui est directement lancé, et non sur la signature de l'exécutable lui-même. Des techniques réelles observées en 2026 — un LaunchAgent déguisé en Google Update dissimulant un script bash décodé en base64, ou un LaunchDaemon root réexécutant à chaque démarrage une charge utile AppleScript décodée en base64 — cachent toutes deux le code malveillant dans le script lui-même tout en appelant un /bin/bash ou /usr/bin/osascript signé et inchangé. Une vérification ne regardant que la signature de l'exécutable laisserait passer les deux. C'est pourquoi tout LaunchAgent/LaunchDaemon nouvellement enregistré qui invoque directement un interpréteur de script brut (bash, sh, zsh, osascript, python3, perl, ruby, php et similaires) est signalé sans condition, indépendamment de la validité de la signature de cet interpréteur. Les arguments qui lui sont passés sont également soumis à StaticSignatureScanner, et tout motif connu comme malveillant est inclus dans la notification. Les entrées enregistrées via BundleProgram (pointant vers un binaire compilé et signé à l'intérieur d'un bundle d'application — y compris l'assistant propre de RoamSwitch) sont simplement vérifiées de manière habituelle, avec codesign --verify --strict.

Détection de ClickFix et confinement d'urgence — 1.8.7, désactivé par défaut

« ClickFix » est une technique d'ingénierie sociale où un faux CAPTCHA ou écran d'erreur vous demande d'ouvrir le Terminal et d'y coller une commande « pour vérification ». Les détections ont augmenté de plus de 500 % entre 2024 et 2025, et d'ici 2026, cette technique est considérée comme l'un des vecteurs d'attaque macOS les plus répandus. Comme il s'agit de votre propre shell légitime exécutant exactement ce que vous avez saisi, elle échappe entièrement à la vérification de signature de Gatekeeper.

Barre de menu → Protection contre les malwares → Défense ClickFix (Pro, désactivée par défaut). Surveille via FSEvents les nouvelles lignes ajoutées à ~/.zsh_history/~/.bash_history (uniquement les lignes ajoutées après le démarrage de la surveillance — elle ne remonte jamais dans l'historique existant), et ne fait correspondre que les reverse shells classiques qu'elle partage avec StaticSignatureScanner, ainsi que la combinaison spécifique du décodage base64 directement vers un shell ou vers osascript. Un simple curl | bash — extrêmement courant dans les installateurs légitimes — est délibérément exclu, car il est indiscernable des instructions d'installation officielles de Homebrew, rustup, nvm et similaires. Dès qu'une correspondance est trouvée, elle déclenche le même Air-Gap d'urgence décrit plus haut. Comme la commande a déjà été exécutée, il s'agit nécessairement d'une réaction a posteriori, mais elle peut néanmoins interrompre un téléchargement de second stade ou une exfiltration d'identifiants en cours. Comme tout autre déclencheur d'Air-Gap, il se lève de lui-même après 10 minutes au maximum (voir le début de cette section).

Une limite connue. Comme la détection repose sur une écriture dans l'historique du shell, elle ne peut pas détecter la variante sans fichier qui contourne entièrement le Terminal en invoquant directement l'Éditeur de script via le schéma d'URL applescript://, sans rien écrire sur le disque. Apple a mis en place une certaine atténuation pour cela (une boîte de dialogue de confirmation pour les scripts non identifiés), mais des variantes la contournant ont été signalées. Nous avons testé ce chemin sur du matériel réel via le journal unifié de macOS (log show/log stream) et n'avons trouvé aucun signal de journal distinctif sur lequel baser une détection. Nous préférons énoncer clairement cette limite plutôt que revendiquer une couverture que nous n'avons pas.

Détection des risques Docker — 1.8.9, Pro, désactivée par défaut

Barre de menus → « Protection contre les logiciels malveillants » → « Détecter les conteneurs Docker privilégiés et les montages docker.sock » (DockerEventGuard). Comme cette base de code n'a aucun précédent de connexion de streaming persistante telle que docker events, elle utilise la même approche d'interrogation par minuteur que PortAnomalyGuard. Toutes les 20 secondes, elle récupère l'ensemble des identifiants de conteneurs via un léger docker ps -q, puis exécute docker inspect --format uniquement sur la différence (conteneurs nouvellement démarrés) pour une inspection détaillée. La chaîne de format utilisée pour la détection est délibérément identique à celle de l'édition Linux (roamswitch_core::health::LinuxHealthChecker::DOCKER_INSPECT_RISK_FORMAT), de sorte que les deux plateformes signalent exactement les mêmes conditions (démarrage en mode --privileged, ou montage lié /var/run/docker.sock).

Aucune action automatique n'est entreprise lors de la détection. Un conteneur privilégié ou un montage docker.sock est une « configuration » risquée pouvant permettre une évasion de conteneur, mais ce n'est pas une compromission confirmée — il existe aussi des usages légitimes, comme l'exécution délibérée d'un agent de surveillance en mode privilégié. Comme la plupart des utilisateurs n'utilisent pas du tout Docker, cette fonction reste désactivée par défaut même avec une licence Pro. Elle n'utilise pas l'entitlement EndpointSecurity ; la CLI docker est recherchée dans l'emplacement d'installation par défaut de Docker Desktop, puis via Homebrew, puis via which, dans cet ordre. Vérifiée sur une installation réelle de Docker Desktop (29.7.2) selon trois scénarios — un conteneur privilégié, un conteneur avec montage docker.sock et un conteneur normal — sans faux positifs ni détections manquées.

Audit des fuites de secrets et clés API — ajouté en 1.8.4, analyse de dossier ajoutée en 1.8.9

Barre de menus → « Protection contre les logiciels malveillants » → « Audit des fuites de secrets/clés API ». Collez du texte et il est instantanément vérifié à la recherche de clés API et de jetons divulgués, affichant le numéro de ligne, une chaîne masquée et une recommandation par résultat (SecretLeakAuditor, entièrement sur l'appareil). La version 1.8.9 a ajouté une option « Choisir un dossier à analyser », permettant au même moteur de détection d'auditer récursivement un répertoire — comme un dépôt de code source — via auditDirectory(at:). .git, node_modules, target, vendor, dist, build, __pycache__ et venv sont automatiquement exclus, tout comme les fichiers de plus de 2 Mo ou détectés comme binaires. Le traitement s'exécute hors du thread principal pour ne pas bloquer l'interface, et rien n'est jamais envoyé à l'extérieur.

Link Guard (blocage des connexions de phishing) — 1.7.2 et versions ultérieures, renforcé dans la version 1.8.0

Barre de menu → « Protection contre les logiciels malveillants » → « Link Guard » (Pro). Bloque les connexions aux sites de phishing/arnaques sur l'appareil, dans tous les navigateurs et applications. Il existe deux points d'application, utilisés ensemble par ordre de priorité.

• ① Extension du système de filtrage de contenu (RoamSwitchLinkFilter, 1.8.0+, préférée une fois approuvée). Une extension du système NEFilterDataProvider — pas d'examen Apple (les fournisseurs de filtres de contenu sont en libre-service, pas de file d'attente d'approbation). Il inspecte la résolution réelle du nom du flux TCP sortant après. Le nom de destination provient du nom d'hôte résolu par le système d'exploitation ou, à défaut, du TLS SNI analysé à partir des premiers octets du flux. Ainsi, un navigateur effectuant son propre DoH/DoT et se connectant à une adresse IP nue est toujours bloqué. Il ne réécrit jamais /etc/hosts et attribue chaque flux à un processus. QUIC (UDP/443) n'a pas de SNI lisible, donc en mode block, il est supprimé, forçant le navigateur à revenir à HTTP/2 sur TCP. Nécessite une approbation unique dans les paramètres système.
• ② Gouffre /etc/hosts (repli, tandis que l'extension n'est pas approuvée/refusée). L'assistant privilégié écrit les domaines cibles dans une section gérée délimitée de /etc/hosts en tant que 0.0.0.0 et vide le cache. Plafonné à 60 000. Une fois l'extension active, cette section est supprimée.
• Trois modes. "Off" le désactive. "Avertir uniquement" met en pause la connexion correspondante et demande à l'utilisateur (voir Real warn ci-dessous). "Bloquer automatiquement les sites frauduleux évidents (recommandé)" disparaît immédiatement. La valeur par défaut est bloquée à partir de la version 1.7.2.
• Real warn (1.8.0+, extension uniquement). Sur un warn, appuyez sur l'extension système contient le flux (à la fois le nom du système d'exploitation et le chemin SNI) avec .pause() et l'application génère une notification « Autoriser / Bloquer ». Dès que l'utilisateur atteint allowlist.txt / extra.txt (l'extension interroge les petits fichiers d'état toutes les 1,5 s), les flux suspendus reprennent (autorisent) ou s'arrêtent (bloquent). Aucune réponse dans les 25 s échoue open (un avertissement est consultatif). La décision est mise en cache par hôte (comptez 5 min/bloc 1 h), de sorte que les autres flux de la page et les visites ultérieures sont instantanés et appliqués. La notification block est inchangée : « Bloqué… » avec un bouton « Autoriser une fois (5 min) ».
• Seuls les cas clairs sont bloqués. Une liste sur le fil de menaces ou un homographe Unicode de marque - tout le reste (TLD à haut risque, usurpation d'identité de sous-domaine, …) est un avertissement. Le moteur de verdict est partagé avec l'édition Linux et n'envoie d'URL nulle part.
• Récupération d'un mauvais blocage. Autoriser un domaine depuis la notification ou le menu (5 minutes ou permanent). La liste verte est soustraite lorsque la section est régénérée.
• Pro-gated. L'application (applyMode()) n'a lieu que sur une licence Pro valide. Sans Pro, le mode est stocké mais /etc/hosts n'est jamais touché. L’activation ou l’expiration d’une licence prend effet en milieu de session.
• Flux et graines groupées. La liste de blocage provient du flux de menaces signé (§7, vérifié avec une clé dédiée au flux). Il fonctionne sur la graine groupée de l'application (~ 60 000 entrées) avant même la première récupération, et la désactivation de la « mise à jour automatique » signifie aucun trafic sortant.

Verrouillage préventif ARP/NDP de la passerelle — 1.7.5 et versions ultérieures

Barre de menu → "Port & Device Monitor" → "Épingler l'ARP/NDP de la passerelle sur des réseaux non fiables (préventif)" (Pro, désactivé par défaut).

• Comment ça marche. Lors de la connexion à un réseau non fiable, le MAC actuel de la passerelle IPv4, du routeur IPv6 par défaut et des résolveurs DNS en liaison est collecté à partir de route / scutil --dns / arp -n / ndp -an, et l'assistant épingle chacun comme une entrée permanent avec arp -s / ndp -s (confiance à la première utilisation - le premier MAC observé est fiable). Les réponses ARP/NDP usurpées pour ces adresses IP sont ensuite ignorées, de sorte qu'une attaque de l'homme du milieu ne peut pas être mise en place.
• Scope. Seuls ces trois types d'entrée sont épinglés. Les réseaux de confiance (ouverts) ne sont jamais épinglés. À chaque changement de réseau, il se déverrouille une fois et se réépingle. Les résolveurs publics hors liaison (8.8.8.8, …) n'ont pas d'entrée ARP en liaison et sont automatiquement exclus.
• arp -s est préventif ; l'entrefer est après coup. Cette broche existe donc une usurpation d'identité ne peut pas réussir ; La détection d'usurpation d'identité ARP (ARPSpoofContainmentManager) et l'entrefer d'urgence existent pour "couper plus vite qu'un humain" une fois que l'on en voit un. Ils fonctionnent de manière indépendante.
• Persistance. Le jeu de broches est enregistré dans /Library/Application Support/RoamSwitch/gateway_arp_lock.json afin qu'il puisse être déverrouillé lors d'une reconnexion XPC ou d'un redémarrage d'assistance.

Le tunnel VPN (WireGuard / Tailscale) et son kill-switch — 1.7.6 et versions ultérieures, backend sélectionnable en 1.8.0

Barre de menu → "Moniteur de ports et de périphériques" → "Tunnel VPN" (Pro, désactivé par défaut). Il s'agit de la défense anti-MITM primary — elle ne dépend pas de l'intégrité de L2 (ARP/NDP). Le backend est sélectionnable (sous-menu → "Backend") entre "WireGuard (fichier de configuration)" et "Tailscale (Exit Node)". RoamSwitch n'implémente aucune cryptographie elle-même ; seul le backend choisi est armé.

• (A) Backend WireGuard. Pilote le wireguard-tools de Homebrew (pas de droit à l'extension réseau Apple). Importez votre propre .conf ; l'assistant l'enregistre à 0600. Kill-switch : pf block drop all plus un pass quick uniquement pour lo, l'interface du tunnel, la prise de contact UDP avec les IP du point de terminaison épinglé, DHCP et ICMP. Un AllowedIPs de tunnel non plein déclenche un avertissement de tunnel divisé.
• (B) Backend Tailscale (1.8.0+). Pour les utilisateurs qui exécutent déjà Tailscale. RoamSwitch not exécute tailscale up / se connecte / installe - il lit tailscale status --json et exécute tailscale set --exit-node=<node>. La version Standalone (téléchargement direct depuis tailscale.com) avec l’intégration CLI activée (Réglages → « CLI integration » → « Install Now », qui ajoute /usr/local/bin/tailscale) est recommandée — la version de l'App Store (GUI) ne peut pas être pilotée depuis l'extérieur de l'application (bac à sable) ; avec lui, vous choisissez le nœud de sortie dans l'application Tailscale et RoamSwitch affiche uniquement l'état. Un nœud de sortie est requis (achemine tout le trafic à travers le tunnel) ; il est automatiquement désarmé s'il est hors ligne ou inaccessible.
• ⚠️ La version Homebrew (brew install tailscale) n’est pas recommandée. Le tailscaled distribué par Homebrew présente un bug macOS connu qui peut l’empêcher de réécrire correctement la table de routage (tailscale/tailscale#21395, #21216) — un nœud de sortie peut s’afficher comme « connecté » alors que le trafic continue de fuir, ou sa désactivation peut couper entièrement la connexion Internet du Mac. RoamSwitch vérifie la table de routage réelle du système et avertit dans ce cas, mais utiliser la version Standalone ci-dessus évite ce problème dès le départ.
• Reconfiguration du réseau à la déconnexion. Le macOS autonome tailscaled ne restaure pas proprement le routage + DNS lorsqu'un nœud de sortie est effacé, donc RoamSwitch fait rebondir le(s) service(s) réseau actif (la même chose que basculer le Wi-Fi à la main ; uniquement les services avec une adresse IPv4, sans danger pour les multi-NIC et les IP statiques). Le trafic diminue pendant environ 5 à 10 s et le niveau de protection n'est pas dégradé pendant cette fenêtre.
• Le kill-switch Tailscale est désactivé par défaut (opt-in). Le nœud de sortie tunnelise déjà tout ; le pf block drop all (autorise uniquement CGNAT/MagicDNS/STUN/DERP/DHCP/ICMP/DNS) est destiné aux utilisateurs avancés et est "résistant aux fuites, pas étanche" (le DNS est autorisé donc tailscaled survit).
• Automatique / en cas de perte de licence. Apparaît sur les réseaux non fiables, en panne sur les réseaux fiables ; levée à l'expiration de la licence Pro.

§6

Lorsque vous vous connectez à un réseau que vous n'avez pas enregistré, le commutateur « niveau de protection » n'utilise pas pf. Il modifie simplement les paramètres standard du système d'exploitation d'une manière qui peut être inversée ultérieurement.

Rien de tout cela n’est un nouveau mécanisme de blocage ajouté par RoamSwitch – il s’agit simplement de basculer les paramètres du système d’exploitation. Si vous supprimez l'application, la seule chose qui s'arrête est la commutation dépendante du réseau ; le dernier système d'exploitation les paramètres appliqués restent tels quels. Rien n'est laissé verrouillé, mais si vous voulez vous tromper Côté sécurité, remettez-le sur « Ouvrir » sur un réseau de confiance avant de le désinstaller.

§7

Ce qui reste sur Mac

Trafic qui quitte la machine (la liste complète)

Il n'existe aucun code qui collecte et envoie des résultats de diagnostic, des informations sur les ports, des URL ou des journaux. Aucun SDK d'analyse ni de rapport de crash n'est inclus. La seule bibliothèque externe est Sparkle (mises à jour). Ce qui sort sur le réseau, ce sont les huit flux suivants, auxquels s'ajoutent les fonctions déclenchées par l'utilisateur, les fonctions désactivées par défaut et la protection DNS contre les menaces décrites sous le tableau, et c'est tout (le sixième uniquement si l'utilisateur configure un VPN, le septième uniquement si l'appairage RoamSwitch Sensor est activé).

# Signature Developer ID et identifiant d'équipe (Team ID)
codesign -dvvv /Applications/RoamSwitch.app 2>&1 | grep -E 'Authority|TeamIdentifier|flags'

# Si le ticket de notarisation est agrafé (staple)
stapler validate /Applications/RoamSwitch.app
spctl -a -t exec -vvv /Applications/RoamSwitch.app

# Signature du helper embarqué / serveur 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 dictionnaire d'entitlements vide. Aucune clé app-sandbox / network client.

# Exécuter tcpdump en parallèle pour confirmer qu'en usage normal aucun trafic ne sort des flux du tableau
sudo tcpdump -i any -n 'host not 127.0.0.1' and 'not port 53'
# Aucun trafic hormis les flux du tableau (activation de licence, vérifications de mise à jour, données de mise à jour signées, mises à jour ClamAV, etc.)

Pour une vérification plus stricte et automatisée avec attribution par processus, voir rs-zerotel-audit.sh dans roamswitch-support/audit/

# Vérifie automatiquement en une fois la frontière d'autorisation XPC, la priorité Air-Gap de pf, la détection d'exposition de port, le mode lecture seule MCP et la surveillance ARP
git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Tests d'intrusion en direct et audit de défense multicouche à partir d'une VM macOS : RESULTS-DEFENSE-2026-08-30

# Interroger le domaine de test officiel de Quad9 pour vérifier le blocage des menaces
nslookup test.dns9.quad9.net
# → Doit renvoyer ** server can't find test.dns9.quad9.net: NXDOMAIN, c'est-à-dire que la résolution de noms est bloquée

# Créer la chaîne de test antivirus standard et inoffensive (EICAR) dans Downloads
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/Downloads/eicar_test.com
# → La détection FSEvents déclenche une analyse ClamAV immédiate ; aucune notification n'est affichée, et « signature de test EICAR détectée (inoffensive) »
#   est enregistrée dans l'historique des notifications. EICAR étant un fichier de test standard de l'industrie et non une menace réelle,
#   il n'est ni mis en quarantaine ni bloqué et le fichier reste en place (seul un véritable échantillon de malware est déplacé vers le gestionnaire de quarantaine).

## Un reverse shell classique tiré de références publiques d'offensive security (inoffensif, jamais exécuté)
echo 'bash -i >& /dev/tcp/127.0.0.1/4444 0>&1' > ~/Downloads/rs_test.sh
## → Même sans ClamAV installé, une notification « Fichier téléchargé dangereux mis en quarantaine » apparaît, et le fichier est
##   déplacé immédiatement vers le dossier Quarantine (indépendamment de la base de signatures de ClamAV)

# Créer un LaunchAgent inoffensif qui invoque directement un interpréteur de script brut (jamais réellement exécuté)
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
# → En quelques secondes, une notification « Nouvel enregistrement de démarrage automatique détecté » devrait apparaître. Retirez-le ensuite :
rm ~/Library/LaunchAgents/com.example.selfcheck.plist

# Si la section gérée est présente (2 lignes BEGIN/END en mode Pro + par défaut)
sudo grep -c 'RoamSwitch link guard' /etc/hosts

# Le contenu de la section et le nombre de 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'

# Si le blocage est effectif (vérifié avec une entrée de la section ; inoffensif)
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 (résolution de noms bloquée)

# Confirmer également que la section ci-dessus disparaît via Menu → « Protection des liens » → « Désactivé »

# Flux public et manifeste (n'importe qui peut les récupérer et les vérifier)
curl -s https://lafine.net/updates/v1/manifest        # version/generated/threatfeed{...}
curl -sI https://lafine.net/updates/v1/manifest.sig   # → text/plain
# Seule une requête GET sans chaîne de requête, cookies ni identifiant propre à l'appareil est envoyée (User-Agent standard uniquement). Vérifiable avec tcpdump en parallèle.

# Se connecter à un réseau non fiable avec le verrouillage préventif activé → vérifier les entrées permanent
arp -an | grep -i permanent          # La passerelle et les autres IP sont listées comme (permanent)
ndp -an | grep -i 'P '               # Côté IPv6 (P = permanent)
sudo cat "/Library/Application Support/RoamSwitch/gateway_arp_lock.json"  # L'ensemble des correspondances IP→MAC actuellement fixées
# Libérer le verrou via le menu → ce qui précède doit disparaître

# Suppose que wireguard-tools est installé (via Homebrew)
brew list wireguard-tools >/dev/null && echo "wireguard-tools: OK"

# Activer le VPN sur un réseau non fiable → avant l'établissement du tunnel, pf est en état de coupe-circuit
sudo pfctl -sr | grep -E 'block drop all|pass .*(utun|udp)'   # block drop all + un ensemble limité de règles pass quick

# Une fois le tunnel établi (wg-quick up déjà exécuté)
wg show                              # handshake / transfer est actif
route -n get default | grep interface  # → utunN (la route par défaut est le tunnel)
# Désactiver le VPN → le coupe-circuit est levé et pf revient à son état antérieur

# Le LaunchDaemon enregistré
sudo launchctl print system/com.tetsuharu.RoamSwitch.Helper

# Les règles pf actuellement chargées (état réel de l'Air-Gap / de la garde de port)
sudo pfctl -sr

# Le répertoire d'état du 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"
# Renvoie serverInfo et les définitions des outils. Aucune connexion réseau ne se produit.

git clone https://github.com/lafine1211/roamswitch-mcp
cd roamswitch-mcp
swift build -c release        # La même source que le binaire livré
swift test                    # Tests unitaires, entrées adverses, stdio et fuzzing par mutation
# Voir SECURITY_TESTING.md pour le contenu des tests et les problèmes trouvés

# La valeur brute liée au jeton (seul un SHA-256 salé est jamais envoyé)
ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'