A security researcher has successfully reverse-engineered Apple’s private Find My People protocol, demonstrating that a Linux machine can register with Apple’s internal services, receive an existing location-sharing key, and decrypt a friend’s live location without ever touching a Mac or iPhone.
The project began innocently: the researcher wanted to build Discord geofence alerts using location data a friend was already sharing via Apple’s Find My app. What looked like a simple authenticated API call turned into roughly a week of reverse-engineering Apple’s private device-identity and messaging infrastructure, since no prior open-source project had fully replicated the flow.
Using decompilations of Apple’s fmfd, findmylocated, and searchpartyd daemons alongside open-source tools like FindMy.py and pypush, the researcher rebuilt the entire pipeline field by field.
Faking an Apple Device From Scratch
The first hurdle was authentication. Standard iCloud login tokens returned 401 errors against the old Find My Friends API, because each Apple service issues its own scoped credentials through a broker exchange.
After authenticating via GrandSlam, Apple’s account login protocol, the researcher obtained a delegate token for IDS, Apple’s private identity and encrypted-messaging layer that underpins iMessage and Find My alike.
Turning that token into a working device identity required a certificate signing request with very specific, undocumented constraints: a 2048-bit RSA key, a SHA-1 signature, and a common name derived from the SHA-1 hash of the account’s profile ID, wrapped in a gzip-compressed XML property list.
Registering as a Find My device was equally particular, requiring enrollment under Apple’s “alloy” multiplexer service with six specific sub-services rather than registering Find My Friends directly.
The most conceptually tricky part was convincing Apple to send the encryption key for an already-accepted share to the new Linux “device.”
According to a Zerotistic researcher, a SubscribeAndFetch request with an intent of distributeKeys triggers the sharing device to redistribute its current key over Apple Push Notification Service, wrapped in a signed, ECDH-verified envelope called pair-ec.
Critically, this required no resharing or account changes, since Apple’s architecture is designed to hand existing keys to newly added devices automatically.
The delivered key turned out to use elliptic-curve cryptography on the P-224 curve, distinct from the P-256 keys used in the messaging envelope itself.
With that per-share key in hand, the researcher queried Apple’s SearchParty service, which stores encrypted location reports, and decrypted the ciphertext locally using ECDH key exchange and AES-GCM. The result: a live, verified coordinate, accuracy radius, and timestamp for the consenting friend’s device, obtained entirely through Linux tooling.
The exercise didn’t uncover a security flaw that Apple would need to patch, since it only accessed a location already voluntarily shared with the researcher’s account.
Its value lies instead in documenting, for the first time in detail, how Apple’s private IDS and SearchParty protocols distribute and rotate location-sharing keys, information useful to researchers building interoperable or self-hosted Find My clients.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC
