Tracking on non-Macs

Problem
The problem: it's limiting to not be able to track things on non-Mac computers.

Solution
Reverse-engineer either the local Find My API or the Find My web app and allow for tracking on non-Macs

Alternatives

Host a macOS server to track stuff. If not self hosted it allows whoever hosts it to access private information. I believe this was discussed earlier
Upload the keys to Apple somehow and use the web Find My App to do this. May require temporarily disabling SIP, or possibly it's possible to use the Mail-app entitlement route to upload it.

Additional context
I understand that this is an long term goal and that either way it's easier said then done. It may be worthwhile to try seeing how auth is done for the Find My web app and then MITM'ing the connection to see how it requests the location.

The web API (icloud.com) won't show your offline devices as far as I know. Because that would mean that Apple had access to the private advertisement keys to decrypt the location – which they claim they don't.

@schmittner

The web API (icloud.com) won't show your offline devices as far as I know. Because that would mean that Apple had access to the private advertisement keys to decrypt the location – which they claim they don't.

@schmittner Well, I guess we have to reverse engineer the local Find My app then. My guess is that it uses HTTP(S) like location services but it wouldn't be too farfetched for it to use a proprietary protocol.

I assume you are aware of https://github.com/picklepete/pyicloud ? This is a python framework to access Apple device location. The issue is that it does not yet support "objects" like AirTags. For this to be implemented, the iCloud API endpoint would need to be known, which does not seem to be the case.

I assumed I could find the API endpoint by using a man-in-the-middle-proxy (mitmproxy) with my iPhone, but of course Apple is using certificate pinning and the Find My app simply refused to work through the proxy. Other apps and websites worked.

So we'll probably have to wait until someone with a jailbroken iPhone and https://frida.re finds the time to dig this up.

@hhf42

Was not aware of that Python framework, thanks.

So we'll probably have to wait until someone with a jailbroken iPhone and https://frida.re finds the time to dig this up.

@hhf42 Is there any particular reason we have to use a jailbroken iPhone and not a Mac?

Oh, right. Of course you could also do this with a Mac and it might even be easier. Maybe as easy as running strings against the Find My app?

Apple has not yet implemented Find My for objects in the iCloud.com website, once that is available, that may also be an option.

Oh, right. Of course you could also do this with a Mac and it might even be easier. Maybe as easy as running strings against the Find My app?

Sorry, my RE knowledge is pretty lackluster, so I have no idea how to do that. Could you explain further?

Apple has not yet implemented Find My for objects in the iCloud.com website, once that is available, that may also be an option.

Apparently this is impossible for reasons explained above.

@hhf42

Hi,
thank your for the recommendations.
@hhf42 we actually tried using exactly this framework to access the location reports. So we can guarantee that at the moment it won't be easily possible.

@AwesomestCode you don't need to reverse find my. We already did that and all work you can find here is largely based on the reverse engineering we did. All the necessary http requests are implemented in OpenHaystack.

It has already been discussed if we can port this to windows. And the answer here is maybe. Windows has an iCloud app that can be downloaded and that is able to produce similar access tokens as the Mac.
You can refer to our paper to see what access tokens are necessary to download location reports: https://arxiv.org/abs/2103.02282

We need:

Apple Anisette Data
A search party token, which is stored in the Keychain.
Is highly obfuscated code by Apple and we have not been able to reverse engineer it. But generally it produces tokens that are used to access iCloud services that are protected by 2FA. Those tokens are generated on Windows as well and AltStore already accesses them. https://github.com/rileytestut/AltStore
I don't know if this is actually available on Windows

So the actually best option to port this to the web or any other system is to have one macOS server running in the background that downloads location reports and forwards them. This is basically not a big security issue (for now), because all the reports are protected by end-to-end encryption.

And I have already implemented a very simple Mac server that actually does just this. I just don't want to host it somewhere publicly.

It's available on my private fork:
https://github.com/Sn0wfreezeDev/openhaystack

Windows has an iCloud app that can be downloaded and that is able to produce similar access tokens as the Mac.

Was hoping for Linux support, not Windows. This way, it'll be easy to self-host finding/forwarding servers. While I have a Mac, I don't want to use it as a server that's on 24/7. I do sort of hope that it's possible to install OpenHaystack's finder app on all devices eventually.

Another, albeit silly-sounding option: could we possibly run the Windows iCloud app in a sandbox just for token generation? This sounds inefficient and silly, but it could be a viable path forward.

@Sn0wfreezeDev

@Sn0wfreezeDev

we actually tried using exactly this framework to access the location reports. So we can guarantee that at the moment it won't be easily possible.

Thanks for the answer, can you elaborate further? The pyicloud framework works for devices, so should it not work for objects once the API endpoint is known? Or do you know it already and there are other issues?

@hhf42

@hhf42 the "old" Find My (to find iPhones, Macs) and the "new" Find My (for finding offline devices via Bluetooth incl AirTags) use two completely different protocols. The Find My app integrates them both.

The "old" one works via iCloud. The "new" one does not work via iCloud by design, so this will not come as a future update (read our paper to understand why this is the case, essentially this provides stronger privacy for the user).

Oh, I am reading the linked paper and I get it:

the owner device fetches location reports from Apple’s servers by sending a list of the most recent public advertisement keys of the lost device.

So the python framework would have to have access to those keys, they will not be in iCloud. So this would not work on a Linux or Windows device. Maybe on a Mac if the python framework could have access to keychain, but maybe only if jailbroken or with frida instrumentation.

This is disappointing :- ) I was very much looking forward to nice tracking beyond automated screenshots of Find My app.

@schmittner

@schmittner @Sn0wfreezeDev
Just thought of something: if the keys are never uploaded to iCloud, how do other devices track them? For example, if I add an AirTag on my iPhone, I can still track it on my Mac... this seems to imply that the keys are uploaded to a server somewhere.

The keys that are needed for fetching location data are uploaded to iCloud (Drive).

Thanks for this awesome work guys!
Just a quick question: Would you still recommend using a secondary Apple ID for this or should it be fine using the primary one in the meantime?

I've always used my one and only Apple ID for this, but I like living on the edge 😝 (also I don't use it for anything else, so you might call it a secondary ID). If in doubt create a burner ID.

biemster/FindMy is now updated to use SMS 2FA, that completely removes the requirement for Apple hardware at any point in the process. I guess that basically resolves this issue fully?

Does it still allow a code generated from another authenticated device?

biemster/FindMy is now updated to use SMS 2FA, that completely removes the requirement for Apple hardware at any point in the process. I guess that basically resolves this issue fully?

Does it still allow a code generated from another authenticated device?

It does actually, but you'll need to switch that in the code (I should actually put that behind a flag yes):
https://github.com/biemster/FindMy/blob/7bf7dda0b83f0294ea675ebfc29ee062ccda26e2/pypush_gsa_icloud.py#L109-L110

you'll have to commend out sms_second_factor and uncomment trusted_second_factor by hand for now.

Thank you, that's enough for me.

I know it's super off-topic, but this seems to be the most active place right now.

I have a hard time figuring out if rotating keys as implemented here is actually end-to-end usable: https://github.com/dakhnod/FakeTag

How would the openhaystack app be able to know the different keys? I only see the possibility to enter a single static one per tag.
Do people that use rotating keys implement this by themselves or did I miss something?

That's quite off-topic indeed! I've noticed many people are monitoring the FakeTag and my FindMy repos so it's totally fine to next time open a new issue and tag some people there.

That said, I'm not aware of any way for the requesting app to exactly know which key is broadcasted, except calculating back from the moment it was switched on. I was planning on keeping track which key is last seen, and only request that current one and the next. With a request interval much tighter than the key update interval.
And in case the tag resetted somehow, also start from the beginning if no reports are found for a while. Something like that.

@Jaykob

@Jaykob that is why I (FakeTag) calculate 100 keys using my own seeding algorithm and always request all 100 from apple. That way, if my chip resets or whatever, I cannot lose track of which key it uses, since there is a limited number of possible keys.

I had a modified version of openhaystack somewhere that allowed for adding all 100 keys to one single accessory.

Thanks so much for the quick replies!
Sorry again for the OT.

Implementations such as https://github.com/dchristl/macless-haystack (and derived work https://github.com/HouzuoGuo/hzgl-air-bridge) now support hosting a location tracking service on a Linux server.

Did anybody manage to set up macless haystack in recent times?

I am always getting HTTP error 503...

@parawanderer

For anyone landing here on the HTTP 503 sign-in failures: the cause is known and fixed.

Apple's edge refuses any Grand Slam request whose X-MMe-Client-Info names com.apple.dt.Xcode, before any credential is examined — it returns a small HTML error page rather than a GSA plist, which reaches clients as HTTP 503 and looks like an Apple outage. Reporting the client as com.apple.akd, the daemon that actually makes this call on macOS, is answered normally.

Nothing to do with any particular account, password, network or machine. It broke every client that hardcoded the Xcode identifier, at once.

Found and isolated by AltStore: altstoreio/AltStore#1790 (shipped in AltServer 1.7.6). They established that only the app token matters — the version, the user agent and the hardware portion of the header make no difference.

Fixes per project:

AltStore / AltServer — 1.7.6 and later
FindMy.py — fix: report the client as akd, not Xcode, to stop Apple refusing sign-in with 503 malmeloo/FindMy.py#271
anisette-v3-server — change auth client type from xcode to authkitd to fix 503s Dadoum/anisette-v3-server#60 (merged)

Reproducible without an account, if you want to confirm it yourself:

curl -so /dev/null -w '%{http_code}\n' -X POST --data-binary t \
  -H 'X-MMe-Client-Info: <Mac14,2> <macOS;15.7.5;24G624> <com.apple.AuthKit/1 (com.apple.dt.Xcode/3594.4.19)>' \
  https://gsa.apple.com/grandslam/GsService2      # 503

curl -so /dev/null -w '%{http_code}\n' -X POST --data-binary t \
  -H 'X-MMe-Client-Info: <Mac14,2> <macOS;15.7.5;24G624> <com.apple.AuthKit/1 (com.apple.akd/1.0)>' \
  https://gsa.apple.com/grandslam/GsService2      # 401 — it reached the service

Interactively co-authored by Claude Code and @parawanderer

I cloned the latest anisette repo, built it using docker, and I am still getting 503. Am I missing something?

Seems like patching anisette is not anough, I think that macless-haystack makes a request itself. Let's see how that can be patched.

This worked for me:

dchristl/macless-haystack#245 (comment)

Navigation Menu

Repository navigation

Tracking on non-Macs #63

101 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking on non-Macs #63

Description

Activity

schmittner commented on May 28, 2021

raymondjxu commented on May 28, 2021

hhf42 commented on May 28, 2021

raymondjxu commented on May 28, 2021

hhf42 commented on May 28, 2021

raymondjxu commented on May 28, 2021

Sn0wfreezeDev commented on May 28, 2021

Sn0wfreezeDev commented on May 28, 2021

raymondjxu commented on May 28, 2021

hhf42 commented on May 28, 2021

schmittner commented on May 28, 2021

hhf42 commented on May 28, 2021

raymondjxu commented on Jun 5, 2021

Sn0wfreezeDev commented on Jun 7, 2021

101 remaining items

Jaykob commented on Nov 26, 2023

biemster commented on Nov 26, 2023

olivluca commented on Nov 26, 2023

biemster commented on Nov 26, 2023

olivluca commented on Nov 26, 2023

Jaykob commented on Nov 30, 2023

biemster commented on Nov 30, 2023

dakhnod commented on Nov 30, 2023

Jaykob commented on Nov 30, 2023

HouzuoGuo commented on Apr 18, 2025

dakhnod commented on Sep 11, 2026

parawanderer commented on Sep 13, 2026

dakhnod commented on Sep 15, 2026

dakhnod commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions