Linux consiguió usar Find My People de Apple: la clave estaba en los protocolos, no en el hardware

Eso no significa que cualquier ordenador Linux pudiera consultar Find My de forma anónima. El equipo tuvo que completar el proceso de autenticación y registro de Apple y demostrar que disponía de una identidad de dispositivo aceptada. El resultado fue una emulación de protocolo, no un certificado de Apple falsificado.

Cómo reprodujo Linux el flujo de Find My

El proyecto unió varias piezas que normalmente permanecen ocultas para el usuario:

1. Autenticación de la cuenta. Zerotistic utilizó GrandSlam, el protocolo de inicio de sesión de Apple. El proceso incluyó un intercambio Secure Remote Password (SRP) y autenticación de dos factores, tras lo cual obtuvo identificadores de la cuenta y un token temporal equivalente a una contraseña.

2. Registro del dispositivo. El cliente generó una solicitud de firma de certificado (CSR) en formato PKCS#10, con una clave RSA de 2048 bits y una firma SHA-1. Después envió la solicitud al antiguo endpoint de registro authenticateDS, que devolvió un certificado de Apple Identity Services (IDS).

3. Alta en IDS. Con el certificado y los materiales de identidad asociados, Linux pudo registrarse como un dispositivo compatible con IDS, declarar los tipos de cifrado que admitía, suscribirse a los subservicios de mensajería necesarios y obtener credenciales de entrega de Apple Push Notification Service (APNs).

4. Sincronización con Find My. El cliente reprodujo la secuencia de peticiones de Find My People, incluidas la inicialización, las operaciones de actualización y una solicitud SubscribeAndFetch con

   intent: distributeKeys

   y

   mode: proactive

   . Apple ordenó entonces al dispositivo de la persona que había dado su consentimiento que enviara el material de claves de ubicación a la nueva identidad registrada mediante IDS y APNs.

5. Descifrado local. El mensaje IDS cifrado contenía información de la relación y material de claves de SearchParty. La biblioteca de código abierto pypush gestionó la capa de notificaciones e IDS, mientras que FindMy.py consultó y descifró los informes de Find My para obtener coordenadas, marcas de tiempo y datos de precisión.

En otras palabras, el servidor siguió emitiendo las credenciales después de que se completara correctamente la autenticación de la cuenta y el registro del dispositivo. No fue un ataque para fabricar credenciales válidas desde cero.

Qué revela la distribución de claves de IDS

El comportamiento de SubscribeAndFetch sugiere que Apple puede entregar el material de claves de ubicación vigente a un dispositivo autorizado incorporado después de que ya exista una relación de uso compartido. Es una capacidad lógica para sincronizar una cuenta o sustituir un dispositivo: de lo contrario, cada vez que alguien añadiera un teléfono tendría que pedir a todos sus contactos que detuvieran y reiniciaran el uso compartido de su ubicación.

El mensaje analizado incluía un identificador de relación, un índice de clave, una clave de anuncio sometida a hash de 32 bytes y una representación de clave privada de 85 bytes. En conjunto, esos campos apuntan a que el descifrado de los informes de ubicación de Find My depende de material específico de cada relación y de cada versión de clave, que puede redistribuirse a través de IDS.

La investigación pública muestra cómo se sincroniza y rota el estado de las claves, pero no establece un intervalo universal de rotación. Esa distinción es importante: el trabajo explica cómo se entrega el estado actual de las claves, no ofrece una especificación pública completa del calendario de gestión de claves de Apple.

Lo que podía hacer —y lo que no— el cliente Linux

El cliente probado era deliberadamente limitado. Podía leer una ubicación ya compartida con la cuenta de Apple del investigador y procesar esos datos localmente. La lógica de geovallas también se ejecutaba en Linux, después del descifrado, y no como una función alojada en los servidores de Apple.

Según el análisis publicado, no incluía funciones para:

• enviar nuevas invitaciones para compartir ubicación;
• modificar permisos de uso compartido existentes;
• añadir familiares;
• crear geovallas alojadas por Apple; ni
• enviar órdenes a dispositivos.

Por eso, el resultado debe entenderse como un hallazgo de interoperabilidad y de frontera de confianza, no como un exploit para rastrear remotamente a cualquier persona. La preocupación de seguridad más realista sería el compromiso de una cuenta de Apple o de un dispositivo de confianza: si un atacante obtuviera el control de la cuenta o registrara en ella un dispositivo no autorizado, podría quedar expuesto el contenido que esa cuenta ya tenía permiso para consultar.

Diferencias con la investigación nRootTag de 2025

Zerotistic y nRootTag afectan a partes diferentes del ecosistema Find My y plantean modelos de amenaza distintos.

El trabajo de Zerotistic se centró en Find My People. Reprodujo el lado receptor de una relación de uso compartido ya autorizada. La cuenta y el dispositivo tenían que ser aceptados por Apple, y la persona debía haber compartido su ubicación con esa cuenta.

nRootTag apuntó a Find My Network y a la localización sin conexión. Sus investigadores informaron de que el servicio de Apple aceptaba tipos de direcciones Bluetooth que no eran los esperados. Esa debilidad podía permitir que un ordenador con Bluetooth se comportara como una baliza de rastreo similar a un AirTag y utilizara dispositivos Apple cercanos para retransmitir su ubicación sin conocimiento del propietario del equipo.

La diferencia, resumida, es clara: Zerotistic recibió datos que una cuenta ya estaba autorizada a ver; nRootTag buscaba crear una capacidad de rastreo no autorizada. Mezclar ambos trabajos haría que la demostración de Linux pareciera mucho más potente de lo que muestran las pruebas.

El objetivo original y el tiempo que llevó

El propósito declarado era una automatización basada en el consentimiento. Un amigo que ya compartía su ubicación aceptó que un sistema Linux mantuviera geovallas locales y enviara avisos a Discord cuando llegara a lugares concretos o saliera de ellos.

Zerotistic esperaba inicialmente que el trabajo consistiera en realizar una petición web autenticada y calculó que podría resolverlo en aproximadamente una tarde o una noche. Sin embargo, la ingeniería inversa terminó ampliándose mucho más de lo previsto. Las fuentes disponibles no permiten establecer cuánto duró exactamente el proyecto completo, por lo que cualquier cifra más precisa sería especulativa.

¿Cómo respondió Apple?

Las fuentes citadas confirman la demostración, pero no aportan una declaración pública verificada de Apple sobre esta implementación concreta de Find My People en Linux, ni una corrección confirmada o un resultado público de un programa de recompensas por errores.

La lección central permanece: limitar una función a dispositivos Apple no convierte automáticamente al hardware en la frontera de seguridad. Si la confianza del servidor depende sobre todo de credenciales, certificados, capacidades y comportamiento de protocolo, un cliente suficientemente compatible en otro sistema operativo puede atravesar la frontera del producto, aunque siga limitado por los permisos de la cuenta y las claves criptográficas que obtiene legítimamente.