Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with Apple's Find My app. #39

Open
StefanNienhuis opened this issue Apr 8, 2021 · 12 comments
Open

Compatibility with Apple's Find My app. #39

StefanNienhuis opened this issue Apr 8, 2021 · 12 comments
Labels
question Further information is requested wontfix This will not be worked on

Comments

@StefanNienhuis
Copy link

Awesome project!

I was just wondering, now that Apple has released the 'Items' tab in the Find My app, does this project work with it or could it be made compatible?

@StefanNienhuis StefanNienhuis added the question Further information is requested label Apr 8, 2021
@Bubba8291
Copy link

+1
I would like to see this too

@schmittner
Copy link
Member

TL;DR: In principle, this could work. In practice, it won't.

There are essentially two ways that we could implement this.
Option 1: We extract the advertisement keys from the genuine Find My app and display all devices in our OpenHaystack app (this is what #37 suggests).
Option 2: We inject the advertisement keys of our OpenHaystack devices into Apple's Find My app.

Both options would require us to access the secured storage (e.g., keychain) of the Find My processes. To do this on macOS, you need to disable system integrity protection (SIP), which would leave your system vulnerable to all sorts of attacks. This is nothing that you should do on a production machine. And this is why we won't go down that road. Also, we would need to conduct more manual reverse-engineering to figure out where to inject/from where to extract the keys.

For completeness sake: Certified third-party Find My devices use a proprietary pairing process involving Apple-issued certificates to appear in Apple's Find My app.

@StefanNienhuis
Copy link
Author

Thanks for the detailed response.

@schmittner
Copy link
Member

I'll leave this open so others can easily find it

@schmittner schmittner reopened this Apr 14, 2021
@schmittner schmittner added the wontfix This will not be worked on label Apr 14, 2021
@schmittner schmittner pinned this issue Apr 14, 2021
@mrx23dot
Copy link

Interesting, the site below says:

  • the app generates ONE private key per user
  • and multiple public keys, which are assigned to devices

https://news.ycombinator.com/item?id=20129942

So chances are it assigns public keys in plain text. (no point encrypting)
And the tag simply broadcasts that public key.
The mac will need to connect to the tag for assignment. The type of the tag I guess is simply identified by the BLE MAC with a random id part. (I guess it will work offline, so it wouldn't check for copycat tags)
An ad said it does this automaticaly for connected earpods.

Would be interesting to record the BLE traffic for assigning an original airtag and see the broadcast at the end. Does anyone have one?

If Apple took the shortest path everywhere then we can easily mass produce airtags.

@mrx23dot
Copy link

Also it would be easy to trigger a sound from any nearby tags since a 3rd party user can also do this (stalking mode). It would be easy to destroy the whole apple airtag brand 🗡️

@Sn0wfreezeDev
Copy link
Member

To me the text hacker news post basically looks like the person paraphrased our paper about the Find My network.

The main difference for OpenHaystack for now is that our firmware and apps do not change the advertised public keys and it seems like AirTags send a slightly different BLE advertisement. The rest is almost identical and that's why OpenHaystack actually worked before AirTags have been released.

I plan on buying some AirTags so analyze their Bluetooth packets.

@mrx23dot
Copy link

mrx23dot commented May 4, 2021

If you have some wireless accessory (like earpods) you can already use the finding feature for those.

@mrx23dot
Copy link

Someone dumped the airtag's firmware:
https://twitter.com/ghidraninja/status/1391148503196438529

@throwaways
Copy link

There are essentially two ways that we could implement this.
Option 1: We extract the advertisement keys from the genuine Find My app and display all devices in our OpenHaystack app (this is what #37 suggests).
Option 2: We inject the advertisement keys of our OpenHaystack devices into Apple's Find My app.
Both options would require us to access the secured storage (e.g., keychain) of the Find My processes. To do this on macOS, you need to disable system integrity protection (SIP), which would leave your system vulnerable to all sorts of attacks. This is nothing that you should do on a production machine. And this is why we won't go down that road. Also, we would need to conduct more manual reverse-engineering to figure out where to inject/from where to extract the keys.

How possible is it to do this on a jailbroken iOS device? Or, on a version of macOS running in a VM?
Not exposing your main machine would make this a whole lot safer. Heck, getting an iOS device with findmy support is probably cheaper than a pack of airtags now.

@schmittner
Copy link
Member

@throwaways this would work in principle as I mentioned. But quoting myself:

Also, we would need to conduct more manual reverse-engineering to figure out where to inject/from where to extract the keys.

@llama
Copy link

llama commented Jun 3, 2021

Both options would require us to access the secured storage (e.g., keychain) of the Find My processes. To do this on macOS, you need to disable system integrity protection (SIP)

I have SIP enabled. When I run, for example, security find-generic-password -l 'FindMyAccessories' -g, I'm able to see the keychain data for OpenHaystack accessories. What's different about the BeaconStore keychain item that prevents me printing it in this way (at least without SIP disabled)?

Is there really no way to extract it from the keychain without disabling SIP? Even if so, as long as this key does not change it should only be necessary to obtain once, then SIP could be reenabled.

Thanks for your awesome work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

7 participants