Reverse-engineering Find My People to stalk ̶m̶y̶ ̶e̶x̶ a friend, cause I can

As the author was feeling bored, they decided to explore a complex system. They had a friend who shared their locations using Apple’s “Find My” feature, and the author proposed piping this data into some automations. The author wanted to set up geofences around places his friend frequently visited and make Discord announce when he arrived or left. The author had previously created a Steam tracker with similar functionality, so they believed that “Find My” would be straightforward to reverse engineer.

However, their initial attempt using the iCloud web API did not yield any results related to “Find My People.” The author then researched existing open-source clients and reverse engineered the code from various projects like fmfd, findmylocated, and searchpartyd. The process involved manipulating fields and encoding until Apple’s status codes changed.

The client could only read an already accepted share from the author’s Apple account, and it did not have any methods for sending invitations, changing shares, adding family members, creating geofences, or performing device actions. The geofencing happened locally after decryption.

The author found a useful old initClient call used by fmfd, which was part of Apple’s old MobileMe namespace. After logging into iCloud, the author obtained MobileMe tokens for different services. However, none of the tokens worked for the "Find My" feature. The MobileMe delegate exchange revealed that the login acted as a token broker, providing each iCloud service with its own credentials.

The author discovered that the "Find My" feature required additional parameters such as the account’s Find My Friends host, a courier token for Apple Push Notification service connection, client context, and anisette headers. These values were tied to the emulated machine and required a short-lived one-time code. The author used the findMy.py script to generate these headers and provisioned identity.

Once the author had all the necessary values matching the native daemons, Apple finally returned the accepted share containing the list of people sharing their location. The author was able to find their friend and obtain the opaque fmId, but there was no location or key provided. The response also indicated that the client was properly set up, but it was not enough to receive the existing key.

The author continued working on the encrypted path through IDS, Apple’s private device-identity and encrypted-messaging layer, and eventually used GrandSlam, Apple’s account login protocol, to obtain an ADSID and a short-lived password-equivalent token. This allowed the author to access the com.apple.private.ids delegate and receive the necessary location key.