“The CSR had to conform to older standards because authenticateDS is a legacy endpoint,” the researcher who goes by “Zerotistic” told The Register, offering a single, telling explanation for a string of unexpected technical constraints.
Zerotistic enrolled a Linux device into Apple’s Find My network
A 22-year-old security researcher using the handle “Zerotistic” demonstrated that a Linux machine can be registered into Apple’s Find My network and can be made to receive live location data that Apple normally reserves for Apple hardware. Find My is Apple’s app for locating items, devices and people; while Apple hardware such as an iPhone or Mac normally provides the full experience, iBiz offers a reduced "Find Devices" capability through the iCloud website that lacks Find My’s people-tracking feature. The researcher’s work did not enable arbitrary retrieval of any Apple user's location: it allowed a non‑Apple device to receive the people-location data that had already been shared with the account holder.
How an identity delegate and a legacy CSR won an IDS certificate
Zerotistic began by tying the Linux device to their Apple account. They obtained an identity delegate through Apple’s GrandSlam authentication protocol and used that delegate to build a custom certificate signing request (CSR) in pursuit of an Apple Identity Services (IDS) device certificate. After trial and error they discovered the CSR had to be in PKCS#10 format with a 2048‑bit RSA key signed using SHA‑1. The CSR was encoded into a compressed XML file and submitted to Apple’s authenticateDS profile‑enrollment endpoint. Apple signed the CSR and issued the IDS certificate, linking the Linux device’s public key to the researcher’s Apple account.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildRegistering as a Find My receiver: subservices, APNs, and a TLS session
Enrollment did not end with an IDS certificate. To convince Find My that the Linux machine could receive people-location data, the device’s registration had to: subscribe to six different subservices; declare the types of encryption it supported; provide public keys compatible with Apple’s device‑to‑device messaging format; and include signatures created with both the IDS certificate and an APNs certificate obtained during initial network setup. With those elements in place, the Linux device established a persistent binary TLS connection to Apple’s private APNs servers, positioning it as a valid recipient for the push‑delivered location information.
SubscribeAndFetch and the flow of shared location keys
The researcher noted that a freshly registered device does not automatically receive people-location shares that a user has been seeing on Apple hardware. Issuing a SubscribeAndFetch request prompted the friend’s device to push an encrypted location key to the newly registered Linux device, enabling that device to fetch subsequent location data for an existing share. In other words, the technique relied on normal location‑sharing mechanics: the Linux endpoint was coaxed into participating in the same exchange of encrypted keys that Apple uses between trusted devices.
Decoding SearchParty: unwrapping Apple’s messaging envelope
Receiving the pushed data was only half the work. The researcher wrote a Linux script to unwrap Apple’s messaging envelope returned by the SearchParty service, extract the shared location key, and decrypt the Find My location payload. The decrypted data structure contained coordinates, timestamps and accuracy information. Once the script was complete it could fetch and decode follow‑on location reports for the existing location share. Zerotistic says the whole effort — from enrollment to decryption tooling — took less than a week of tinkering.
What this means for technologists, end users, and Apple
- Technologists and security teams: The steps the researcher followed expose how legacy endpoints and specific CSR constraints can be chained into a working registration flow; teams responsible for device enrollment and certificate validation will want to examine whether similar legacy paths exist in their systems.
- End users and the public: This technique did not grant access to arbitrary user locations; it accessed the people-location data already shared with the account holder. Still, the demonstration shows non‑Apple hardware can be placed into a position to receive those shared feeds once it holds a valid IDS certificate and participates in the SubscribeAndFetch flow.
- Apple: The researcher submitted details to The Register and Apple was asked whether it was aware of the work and whether it had plans to address it; Apple did not immediately respond. The researcher’s identification of a legacy authenticateDS requirement — specifically the PKCS#10, 2048‑bit RSA key signed with SHA‑1 and XML encoding — highlights a concrete protocol point Apple might examine.
The experiment is narrowly scoped but concrete: a non‑Apple device can be registered, can be told to fetch shared location keys, and can decrypt the Find My location reports once it holds the necessary keys and certificates. The only remaining open question in the public record is whether Apple will change the authenticateDS enrollment path, the APNs acceptance rules, or other parts of the flow that made the registration possible. The Register sought comment from Apple; Apple did not immediately respond.
