The core finding: hardware exclusivity was not the whole trust model

Apple’s device restriction turned out to be an implementation and product-policy boundary in this path, rather than an absolute cryptographic requirement for Apple-made hardware. Once the Linux client supplied the account credentials, device identity, certificates, capabilities, and network behavior expected by Apple’s services, Apple’s servers treated it as another trusted receiver.

That distinction matters. The research did not show that anyone could simply query Find My from an anonymous Linux computer. It showed that a non-Apple operating system could reproduce the relevant client behavior after completing Apple’s authentication and enrollment steps.

How the Linux client recreated the Find My flow

The project connected several normally hidden pieces of Apple’s ecosystem:

1. Account authentication: Zerotistic used Apple’s GrandSlam login protocol. The reported flow included a Secure Remote Password exchange and two-factor authentication, producing account identifiers and a short-lived password-equivalent token.

2. Device enrollment: The client generated a PKCS#10 certificate-signing request containing a 2048-bit RSA key and a SHA-1 signature. It sent that request to Apple’s legacy authenticateDS profile-enrollment endpoint, which returned an Apple Identity Services certificate.

3. IDS registration: With the certificate and associated device material, Linux could register as an Identity Services-capable device, declare supported encryption types, subscribe to the required messaging subservices, and obtain Apple Push Notification Service delivery credentials.

4. Find My synchronization: The client reproduced the native Find My People request sequence, including initialization, refresh operations, and a SubscribeAndFetch request using intent: distributeKeys and mode: proactive. Apple then instructed the consenting contact’s device to deliver the current location-key material to the newly enrolled identity through IDS and APNs.

5. Local decryption: The encrypted IDS payload contained relationship and SearchParty key material. Open-source pypush handled the push and IDS layer, while FindMy.py queried and decrypted the resulting Find My reports into location coordinates, timestamps, and accuracy data.

This was protocol emulation, not a forged Apple certificate. The server still issued the credentials after the account-authentication and enrollment sequence completed.

What the IDS payload revealed about key distribution

The demonstrated SubscribeAndFetch behavior suggests that Apple can deliver current location-key material to a newly authorized device after a sharing relationship already exists. That is a practical requirement for device replacement and account synchronization: users should not have to ask every contact to stop and restart location sharing whenever they add another device.

The reported payload included a relationship identifier, a key index, a 32-byte hashed-advertisement key, and an 85-byte private-key representation. Together, those fields indicate that Find My location-report decryption depends on relationship-specific and key-version-specific material that can be redistributed through IDS.

The public write-up demonstrates synchronization and rotation behavior, but it does not establish a universal key-rotation interval. That is an important limit on what can be inferred: the research exposes how current key state is delivered, not a complete public specification of Apple’s key-management schedule.

What the Linux client could—and could not—do

The tested client was deliberately narrow. It could read an already accepted location share on the researcher’s Apple Account, then process that data locally. The geofencing logic also ran locally, rather than through an Apple-side Find My feature.

According to the write-up, it had no functionality for:

• sending new location-sharing invitations;
• changing existing sharing permissions;
• adding family members;
• creating Apple-hosted geofences; or
• issuing device commands.

That makes the result an interoperability and trust-boundary finding, not a remote arbitrary-person tracking exploit. The more realistic security concern is account or trusted-device compromise: if an attacker gained control of an Apple Account or enrolled an unauthorized device into it, shares already available to that account could potentially be exposed.

How this differed from the 2025 nRootTag research

The Zerotistic demonstration and nRootTag involve different parts of Find My and present different threat models.

Zerotistic’s work focused on Find My People. It reproduced the receiver side of an existing, authorized sharing relationship. The account and device had to be accepted by Apple, and the person’s location had to have been shared with that account.

nRootTag targeted Find My Network and offline finding. The researchers reported that Apple’s service accepted Bluetooth address types beyond the expected random static addresses. That weakness could let an attacker make a Bluetooth-capable computer behave like an AirTag-style tracking beacon, using nearby Apple devices to relay its location without the target owner’s knowledge.

In short, Zerotistic’s project received data that an account was already authorized to see; nRootTag sought to create an unauthorized tracking primitive. Conflating the two makes the Linux demonstration sound more powerful than the evidence supports.

The original goal and how long it took

The stated motivation was consent-based automation. A friend who was already sharing their location agreed to a Linux system that would maintain local geofences and send Discord notifications when they arrived at or left specific places.

Zerotistic initially expected the task to involve an authenticated web request and estimated roughly an evening of work. The reverse engineering expanded substantially beyond that initial expectation. The available reporting does not establish a precise total duration for the completed project, so a more exact timeframe would be speculative.

What Apple has said

The available cited reporting confirms the demonstration, but does not provide a verified public Apple statement addressing this specific Linux Find My People implementation, a confirmed fix, or a disclosed bug-bounty result.

That leaves the central lesson intact: restricting a feature to Apple hardware does not automatically make the hardware itself the security boundary. If server-side trust is granted based mainly on credentials, certificates, capabilities, and protocol behavior, a sufficiently compatible client on another operating system may be able to cross the product boundary—while still remaining constrained by the account permissions and cryptographic keys it legitimately obtains.

The core finding: hardware exclusivity was not the whole trust model

Apple’s device restriction turned out to be an implementation and product-policy boundary in this path, rather than an absolute cryptographic requirement for Apple-made hardware. Once the Linux client supplied the account credentials, device identity, certificates, capabilities, and network behavior expected by Apple’s services, Apple’s servers treated it as another trusted receiver.

That distinction matters. The research did not show that anyone could simply query Find My from an anonymous Linux computer. It showed that a non-Apple operating system could reproduce the relevant client behavior after completing Apple’s authentication and enrollment steps.

How the Linux client recreated the Find My flow

The project connected several normally hidden pieces of Apple’s ecosystem:

1. Account authentication: Zerotistic used Apple’s GrandSlam login protocol. The reported flow included a Secure Remote Password exchange and two-factor authentication, producing account identifiers and a short-lived password-equivalent token.

2. Device enrollment: The client generated a PKCS#10 certificate-signing request containing a 2048-bit RSA key and a SHA-1 signature. It sent that request to Apple’s legacy authenticateDS profile-enrollment endpoint, which returned an Apple Identity Services certificate.

3. IDS registration: With the certificate and associated device material, Linux could register as an Identity Services-capable device, declare supported encryption types, subscribe to the required messaging subservices, and obtain Apple Push Notification Service delivery credentials.

4. Find My synchronization: The client reproduced the native Find My People request sequence, including initialization, refresh operations, and a SubscribeAndFetch request using intent: distributeKeys and mode: proactive. Apple then instructed the consenting contact’s device to deliver the current location-key material to the newly enrolled identity through IDS and APNs.

5. Local decryption: The encrypted IDS payload contained relationship and SearchParty key material. Open-source pypush handled the push and IDS layer, while FindMy.py queried and decrypted the resulting Find My reports into location coordinates, timestamps, and accuracy data.

This was protocol emulation, not a forged Apple certificate. The server still issued the credentials after the account-authentication and enrollment sequence completed.

What the IDS payload revealed about key distribution

The demonstrated SubscribeAndFetch behavior suggests that Apple can deliver current location-key material to a newly authorized device after a sharing relationship already exists. That is a practical requirement for device replacement and account synchronization: users should not have to ask every contact to stop and restart location sharing whenever they add another device.

The reported payload included a relationship identifier, a key index, a 32-byte hashed-advertisement key, and an 85-byte private-key representation. Together, those fields indicate that Find My location-report decryption depends on relationship-specific and key-version-specific material that can be redistributed through IDS.

The public write-up demonstrates synchronization and rotation behavior, but it does not establish a universal key-rotation interval. That is an important limit on what can be inferred: the research exposes how current key state is delivered, not a complete public specification of Apple’s key-management schedule.

What the Linux client could—and could not—do

The tested client was deliberately narrow. It could read an already accepted location share on the researcher’s Apple Account, then process that data locally. The geofencing logic also ran locally, rather than through an Apple-side Find My feature.

According to the write-up, it had no functionality for:

• sending new location-sharing invitations;
• changing existing sharing permissions;
• adding family members;
• creating Apple-hosted geofences; or
• issuing device commands.

That makes the result an interoperability and trust-boundary finding, not a remote arbitrary-person tracking exploit. The more realistic security concern is account or trusted-device compromise: if an attacker gained control of an Apple Account or enrolled an unauthorized device into it, shares already available to that account could potentially be exposed.

How this differed from the 2025 nRootTag research

The Zerotistic demonstration and nRootTag involve different parts of Find My and present different threat models.

Zerotistic’s work focused on Find My People. It reproduced the receiver side of an existing, authorized sharing relationship. The account and device had to be accepted by Apple, and the person’s location had to have been shared with that account.

nRootTag targeted Find My Network and offline finding. The researchers reported that Apple’s service accepted Bluetooth address types beyond the expected random static addresses. That weakness could let an attacker make a Bluetooth-capable computer behave like an AirTag-style tracking beacon, using nearby Apple devices to relay its location without the target owner’s knowledge.

In short, Zerotistic’s project received data that an account was already authorized to see; nRootTag sought to create an unauthorized tracking primitive. Conflating the two makes the Linux demonstration sound more powerful than the evidence supports.

The original goal and how long it took

The stated motivation was consent-based automation. A friend who was already sharing their location agreed to a Linux system that would maintain local geofences and send Discord notifications when they arrived at or left specific places.

Zerotistic initially expected the task to involve an authenticated web request and estimated roughly an evening of work. The reverse engineering expanded substantially beyond that initial expectation. The available reporting does not establish a precise total duration for the completed project, so a more exact timeframe would be speculative.

What Apple has said

The available cited reporting confirms the demonstration, but does not provide a verified public Apple statement addressing this specific Linux Find My People implementation, a confirmed fix, or a disclosed bug-bounty result.

That leaves the central lesson intact: restricting a feature to Apple hardware does not automatically make the hardware itself the security boundary. If server-side trust is granted based mainly on credentials, certificates, capabilities, and protocol behavior, a sufficiently compatible client on another operating system may be able to cross the product boundary—while still remaining constrained by the account permissions and cryptographic keys it legitimately obtains.