Key Takeaways
- A Linux‑based client can be made to act like an authorized Apple device for the Find My People location‑sharing service, but only after completing the full authentication and registration chain that Apple normally requires of its own hardware.
- The process does not bypass Apple ID login, two‑factor authentication, or any consent mechanism; it relies on an existing, willingly‑given sharing relationship and a valid Apple ID.
- Find My People uses two separate elliptic‑curve layers: a P‑256‑based messaging layer for delivering keys and a P‑224‑based key for encrypting actual location reports.
- The research highlights a privacy concern unrelated to a security flaw: once a user authorizes someone to see their live location, that recipient could process the data outside Apple’s official apps (e.g., custom geofencing, logging, or integration with other services).
- The best defense remains protecting the Apple ID (including two‑factor) and regularly reviewing active sharing relationships via Find My, Safety Check, or account device lists.
Overview of the Research
Published on 19 August 2026 by the researcher “Zerotistic,” the project reverse‑engineered Apple’s private Find My People protocol stack. The goal was to reproduce, on a Linux machine, the exact steps an authorized Apple device performs to receive a friend’s live location and display it outside Apple’s native apps.
Motivation: From Discord Automation to Protocol Reverse‑Engineering
The work began with a simple aim: use a friend’s existing Find My location‑sharing permission to trigger automated Discord notifications when that person entered or left a geographic area. Although Apple already offers arrival/departure alerts within Find My, the researcher wanted the functionality to run on Linux and integrate with external software. What seemed like a straightforward API call quickly turned into a deep dive into undocumented Apple services.
Authentication: More Than iCloud Credentials
Initial attempts using standard iCloud authentication failed because Apple’s backend treats general iCloud access as insufficient for specialized services like Find My People. Success required interaction with Apple Identity Services (IDS). After completing GrandSlam‑based account authentication and two‑factor verification, the researcher obtained a short‑lived token that could be exchanged for a delegated credential scoped to com.apple.private.ids. This step proved that the demonstrated workflow still depended on legitimate Apple ID login and did not circumvent any authentication controls.
Registering as a Messaging Identity
Possessing an IDS delegate token was only the first half. Apple’s infrastructure also needed to recognize the Linux process as a registered messaging‑capable identity. The researcher had to craft an IDS authentication certificate that matched an undocumented format: a 2048‑bit RSA key, SHA‑1 signature, a subject common name derived from the uppercase SHA‑1 hash of the IDS profile identifier, all wrapped in a gzipped XML property list. Adding pinned Apple root certificates resolved missing trust‑chain issues while preserving TLS verification.
Service Registration Under a Multiplexed Endpoint
A direct registration for the legacy Find My Friends service was rejected. Analysis of community protocol implementations showed that Apple instead registers a broader multiplexed service (com.apple.private.alloy.multiplex1) with six sub‑services covering messaging, status, key sharing, and item sharing. The Linux client successfully registered under this endpoint, acquiring the necessary push‑notification identity, device messaging keys (P‑256), and account handles required to act as an authorized endpoint.
Obtaining the Location‑Sharing Key via Push Notifications
The actual location‑sharing key is delivered through Apple’s private Push Notification service (APNs). After subscribing to both the specific Find My sub‑services and the broader private IDS topic, the client began receiving APNs messages. A SubscribeAndFetch request with distributeKeys and proactive mode asked the friend’s already‑sharing device to redistribute its current location‑sharing key to the newly registered recipient. The key arrived asynchronously, and the researcher verified the sender’s identity via Apple’s messaging directory before accepting the encrypted key envelope.
Two Independent Elliptic‑Curve Layers
An unexpected discovery was that the messaging layer and the location‑report encryption layer use different curves. Device‑to‑device messaging (including key delivery) relies on P‑256 keys as part of Apple’s newer messaging identity system. The location‑sharing key itself, however, is a P‑224 elliptic‑curve key (85 bytes: 57‑byte uncompressed public point + 28‑byte private scalar). The researcher confirmed the key’s validity by deriving the public point from the private scalar and comparing it to the supplied component. This separation means compromising one layer does not automatically break the other.
Decrypting Location Reports from SearchParty
With the P‑224 key in hand, the Linux client queried Apple’s SearchParty infrastructure, which returned encrypted Find My reports associated with the sharing relationship. The ciphertext could not be read directly; instead, the client performed an elliptic‑curve Diffie‑Hellman exchange using the report’s ephemeral P‑224 public key and the previously obtained private scalar. The resulting shared secret was processed through an X9.63 key‑derivation function (SHA‑256) to produce AES‑GCM decryption material. After decryption, the report yielded the contact’s latitude/longitude, accuracy radius, and timestamp. The researcher also implemented checks for stale reports and timestamp validation to ensure the most recent location was used.
Why This Is Not a Tracking Exploit
The research does not enable strangers to locate arbitrary iPhone users. It required:
- A valid Apple ID and successful two‑factor authentication,
- Registration of a client identity with Apple’s internal services,
- An existing, consented location‑sharing relationship,
- The sharing partner’s device to be online long enough to process the key‑redistribution request.
No evidence suggests the technique bypasses consent, defeats two‑factor, or exposes unshared data. Consequently, there is no CVE, patch, or indication that Apple’s underlying cryptography was broken.
Privacy Implications for Authorized Recipients
While the work does not reveal a security flaw, it raises a legitimate privacy question: once a user shares their live location with another person, how much control do they retain over what that recipient does with the data? Apple’s official Find My interface provides visible controls for recurring notifications and requires the shared party’s approval for such alerts. However, a third‑party client that already possesses authorized access could process those updates outside Apple’s UI—e.g., custom geofencing, historical logging, integration with messaging platforms, or automated monitoring. For individuals facing harassment, stalking, or coercive control, this distinction between “sharing with a person” and “allowing continuous export and analysis” can be significant.
Account Security Remains Paramount
The findings reinforce that compromising an Apple ID (including bypassing two‑factor) would grant an attacker access to all services tied to that account, including any location data others have voluntarily shared. Apple recommends regularly reviewing the devices linked to an Apple ID via Settings, removing unrecognized or trusted entries, and using Safety Check on iPhone to inspect and reset sharing relationships. The Linux client’s IDS identity may not appear in the ordinary device list, so users should not assume that a simple device‑list check reveals every internal registration.
How to Stop Sharing
Apple provides several straightforward ways to end location sharing:
- Open Find My → People → select contact → Stop Sharing Location.
- Disable sharing broadly via the Me tab in Find My.
- Use Safety Check on iPhone to review, terminate, or reset sharing permissions.
Deleting the Find My app does not automatically revoke existing sharing permissions; explicit settings changes are required.
Potential for Legitimate Interoperability
For developers and security researchers, the project offers a rare view into Apple’s private location‑sharing infrastructure. Possible benign uses include accessibility tools, self‑hosted family dashboards, privacy‑conscious home‑automation hubs, or cross‑platform integrations where all parties have explicitly consented to share data. Nonetheless, any unofficial implementation faces substantial hurdles: Apple’s private APIs and enrollment requirements may change without notice, automated login attempts can trigger extra security checks, and handling of sensitive location data demands rigorous protection against insecure storage, unintended forwarding, or key leakage.
Conclusion: A Protocol‑Interoperability Study, Not a Vulnerability
The significance of Zerotistic’s work lies in documenting how multiple layers—Apple ID authentication, delegated service authorization, device‑identity enrollment, private push messaging, per‑relationship key distribution, and local decryption—interact to produce a functioning location‑sharing endpoint on non‑Apple hardware. It shows that Find My People is far more than an undocumented web API returning coordinates; it is a layered, encryption‑heavy system designed to protect data from outsiders while still permitting authorized recipients to use the data as they see fit. For Apple users, the immediate lesson is not that strangers can track iPhones from Linux, but that location‑sharing permissions deserve the same vigilance as account credentials and other sensitive personal information. Once authorized, the technical boundaries of Apple’s official app may not fully dictate how that information can be subsequently employed.