Linux został zaakceptowany przez Apple Find My People. Nie trzeba było łamać szyfrowania

To istotne rozróżnienie. Eksperyment nie pokazał, że każdy może anonimowo odpytywać Find My z dowolnego komputera z Linuksem. Wykazał natomiast, że system operacyjny spoza ekosystemu Apple może odtworzyć zachowanie właściwego klienta po przejściu procesu uwierzytelniania i rejestracji.

Jak Linux odtworzył przepływ Find My

Projekt połączył kilka zwykle niewidocznych elementów infrastruktury Apple:

1. Uwierzytelnianie konta. Zerotistic wykorzystał protokół logowania Apple GrandSlam. Opisany przebieg obejmował wymianę Secure Remote Password (SRP) oraz uwierzytelnianie dwuskładnikowe. W rezultacie klient otrzymał identyfikatory konta i krótkotrwały token będący odpowiednikiem hasła.

2. Rejestracja urządzenia. Klient wygenerował żądanie podpisania certyfikatu PKCS#10 z 2048-bitowym kluczem RSA i podpisem SHA-1. Następnie przesłał je do starszego punktu końcowego rejestracji profilu authenticateDS, który zwrócił certyfikat Apple Identity Services.

3. Rejestracja w IDS. Dzięki certyfikatowi i powiązanym danym urządzenia Linux mógł zarejestrować się jako urządzenie obsługujące Identity Services, zadeklarować typy obsługiwanego szyfrowania, zasubskrybować wymagane podusługi komunikacyjne i uzyskać dane dostępowe do dostarczania powiadomień przez Apple Push Notification Service (APNs).

4. Synchronizacja Find My. Klient odtworzył natywną sekwencję żądań Find My People: inicjalizację, odświeżanie oraz żądanie SubscribeAndFetch z parametrami

   intent: distributeKeys

   i

   mode: proactive

   . Apple poleciło wtedy urządzeniu kontaktu, który wyraził zgodę na udostępnianie, przekazać aktualny materiał kluczowy nowo zarejestrowanej tożsamości przez IDS i APNs.

5. Lokalne odszyfrowanie. Zaszyfrowany komunikat IDS zawierał informacje o relacji oraz klucze SearchParty. Biblioteka open source pypush obsługiwała warstwę powiadomień i IDS, natomiast FindMy.py pobierała i odszyfrowywała raporty Find My, zamieniając je na współrzędne, znaczniki czasu i dane o dokładności.

Była to emulacja protokołu, a nie podrobienie certyfikatu Apple. Serwer nadal wydawał poświadczenia dopiero po pomyślnym przejściu uwierzytelniania konta i procesu rejestracji.

Co IDS ujawnił o dystrybucji kluczy

Opisane działanie SubscribeAndFetch sugeruje, że Apple może przekazać aktualny materiał kluczowy dotyczący lokalizacji nowemu, autoryzowanemu urządzeniu, jeśli relacja udostępniania już istnieje. Jest to praktyczne rozwiązanie przy wymianie urządzenia i synchronizacji konta: użytkownik nie powinien prosić każdego kontaktu o wyłączenie i ponowne włączenie udostępniania lokalizacji po dodaniu kolejnego sprzętu.

Przekazany pakiet obejmował identyfikator relacji, indeks klucza, 32-bajtowy klucz haszujący reklamy oraz 85-bajtową reprezentację klucza prywatnego. Pola te wskazują, że odszyfrowywanie raportów lokalizacji Find My zależy od materiału przypisanego do konkretnej relacji i wersji klucza, który może być ponownie dystrybuowany przez IDS.

Publiczny opis pokazuje mechanizm synchronizacji i rotacji kluczy, ale nie ustala uniwersalnego interwału ich zmiany. To ważna granica wnioskowania: badanie pokazuje, jak dostarczany jest aktualny stan kluczy, lecz nie stanowi kompletnej, publicznej specyfikacji harmonogramu zarządzania nimi.

Co klient potrafił, a czego nie potrafił

Testowany klient miał celowo wąski zakres. Mógł odczytać już zaakceptowane udostępnienie lokalizacji na koncie Apple badacza i przetwarzać dane lokalnie. Również geofencing — czyli wykrywanie wejścia na określony obszar lub opuszczenia go — działał lokalnie, a nie po stronie Apple.

Według opisu projekt nie umożliwiał:

• wysyłania nowych zaproszeń do udostępniania lokalizacji;
• zmiany istniejących uprawnień;
• dodawania członków rodziny;
• tworzenia geostref hostowanych przez Apple;
• wydawania poleceń urządzeniom.

Dlatego wynik należy rozumieć jako odkrycie dotyczące interoperacyjności i granicy zaufania, a nie zdalny exploit pozwalający śledzić dowolną osobę. Bardziej realistyczne zagrożenie dotyczy przejęcia konta lub zaufanego urządzenia: jeśli atakujący uzyskałby kontrolę nad kontem Apple albo zarejestrował w nim nieautoryzowane urządzenie, potencjalnie mógłby ujawnić udostępnienia dostępne dla tego konta.

Czym różniło się to od badań nad nRootTag z 2025 roku

Oba projekty dotyczyły różnych części Find My i przedstawiały odmienne modele zagrożeń.

Praca Zerotistic dotyczyła Find My People. Badacz odtworzył stronę odbiorczą istniejącej, autoryzowanej relacji udostępniania. Konto i urządzenie musiały zostać zaakceptowane przez Apple, a lokalizacja danej osoby musiała być wcześniej udostępniona temu kontu.

nRootTag dotyczył Find My Network i wyszukiwania offline. Naukowcy poinformowali, że usługa Apple akceptowała także typy adresów Bluetooth wykraczające poza oczekiwane losowe adresy statyczne. Słabość ta mogła pozwolić sprawić, by komputer z Bluetooth zachowywał się jak lokalizator w stylu AirTaga, a pobliskie urządzenia Apple przekazywały jego położenie bez wiedzy właściciela śledzonego urządzenia.

W skrócie: projekt Zerotistic odbierał dane, które konto miało już prawo zobaczyć. nRootTag próbował stworzyć nieautoryzowany mechanizm śledzenia. Zrównywanie tych badań sprawiałoby, że demonstracja z Linuksem brzmiałaby znacznie groźniej, niż wynika to z przedstawionych dowodów.

Od automatyzacji na Discordzie do reverse engineeringu

Deklarowanym celem była automatyzacja oparta na zgodzie. Znajomy, który już udostępniał swoją lokalizację, zgodził się na system linuksowy utrzymujący lokalne geostrefy i wysyłający powiadomienia na Discordzie, gdy dana osoba przyjeżdżała do określonych miejsc albo je opuszczała.

Zerotistic początkowo zakładał, że wystarczy uwierzytelnione żądanie internetowe, i szacował pracę na mniej więcej jeden wieczór. Reverse engineering okazał się znacznie bardziej rozbudowany. Dostępne relacje nie podają precyzyjnego łącznego czasu realizacji całego projektu, dlatego dokładniejszy przedział byłby spekulacją.

Jak zareagowało Apple?

Cytowane materiały potwierdzają demonstrację, ale nie zawierają zweryfikowanego publicznego stanowiska Apple dotyczącego konkretnie tej implementacji Find My People na Linuksie. Nie ma też potwierdzenia poprawki ani ujawnionego wyniku programu bug bounty.

Najważniejsza lekcja pozostaje jednak aktualna: ograniczenie funkcji do sprzętu konkretnej firmy nie oznacza automatycznie, że sam sprzęt jest granicą bezpieczeństwa. Jeśli zaufanie po stronie serwera zależy głównie od poświadczeń, certyfikatów, deklarowanych możliwości i zgodności z protokołem, odpowiednio kompatybilny klient na innym systemie może przekroczyć granicę produktową — nadal pozostając ograniczony uprawnieniami konta i kluczami kryptograficznymi, które legalnie uzyskał.