You’ve probably heard of Apple’s Find My network protocol for offline finding. Now implemented in over 1 billion devices, Find My has enabled Apple to introduce the AirTag, a low-cost, low-power location tracking beacon with worldwide coverage, but without the need for a GPS or cellular modem.
But did you know you can piggyback on the Find My network with your own tracker? And even transmit arbitrary data over the network? Or operate in a special “stealth” mode to track your belongings without alerting potential thieves?
This article will explain how the protocol works and explore how this ubiquitous network can be piggybacked on — and even extended — with self-built AirTag clones.
How Does Find My Work?
When AirTags are not in proximity of their paired device, they constantly emit Bluetooth Low Energy beacon messages. Nearby Apple devices that receive those beacon signals recognize them as Find My broadcasts and upload their own location to Apple. The location reports are associated with the received broadcast and encrypted in a way that allows only the AirTag owner to decrypt the location, not even Apple themselves.
In more detail, the AirTag pairing and finding process works like this:
1. When pairing an AirTag with an Apple device, a key pair and a shared secret are generated. The shared secret and the public key are stored on the AirTag, but only the Apple device knows the corresponding private key.
2. Every 2 seconds, the AirTag sends a Bluetooth Low Energy broadcast with a public key as content, which changes periodically and is generated using the previously shared secret.
3. Nearby Apple devices recognize the Find My broadcast, retrieve their current location, encrypt the location with the broadcasted public key, and then upload the encrypted location report.
4. When searching for the AirTag, the paired Apple device generates a list of the rolling public keys that the AirTag has used in the last days and queries an Apple service for their hashes. The Apple backend returns the encrypted location reports for the requested public key hashes.
5. The Owner Device decrypts the location reports and shows an approximate location.
Luckily for hackers and makers, this design does not allow differentiating the broadcasts of legitimate Apple devices (or licensed third parties) from those of homemade clones. Furthermore, the Apple location retrieval backend does not (and cannot) check whether the user actually owns the AirTag they are requesting location reports for. It’s a free ride, ripe for DIY experimentation.
However, the encryption still guarantees that no user can extract the location from downloaded reports or devices that they themselves did not set up, as they would be missing the correct private key.
Building an AirTag Clone Using OpenHaystack
All of this implies that an open-source implementation of the protocol is possible, which allows clone devices to piggyback on the Find My network — meaning that their location is forwarded by nearby Apple devices and can later be retrieved from Apple’s server and decrypted.
OpenHaystack, developed by the Secure Mobile Networking Lab of TU Darmstadt in Germany, is precisely such an open-source implementation and the result of extensive reverse engineering and analysis.
“OpenHaystack is an application that allows you to create your own accessories that are tracked by Apple’s Find My network. All you need is a Mac and a BBC micro:bit or any other Bluetooth-capable device,” the developers claim.
At the moment, you still need either a macOS computer or a virtual machine (and an Apple ID) to retrieve location reports. This is because the Apple backend requires extensive authentication data (based on an Apple ID), whose generation has not been reverse-engineered and reimplemented yet. For this reason, the retrieval app also includes a custom Apple Mail plugin that is used to fetch the required credentials.
The project page at github.com/seemoo-lab/openhaystack includes detailed installation instructions and contains firmware compatible with ESP32 and nRF51822 microcontroller boards (it’s currently not possible to track actual AirTags using OpenHaystack).
This provides two appealing DIY tracker deployment options:
1. Using an ESP32, a power bank, and USB cable — all of which you might already have at home (Figure A).
2. A sleeker version using an nRF51822-based beacon and a small coin cell in case the battery is not included (Figure B). This version also requires the use of an SWD programmer to flash the firmware (Figure 
C).
After following the OpenHaystack installation instructions, flashing a tracker, and waiting a bit for the first location reports to arrive, the AirTag clone’s last location can be seen on a map in the OpenHaystack macOS app (Figure D).
The team has recently also released a mobile version of OpenHaystack for iOS and Android (Figure E), however it requires the user to build the app themselves and host an API backend running on a Mac.
Adding Features: Arbitrary Data Transmission
I was curious whether Find My’s offline finding network could be (ab)used to upload arbitrary data to the internet, from devices that are not connected to Wi-Fi or mobile internet (Figure F). Such a technique could be employed by small sensors in uncontrolled environments to avoid the cost and power consumption of mobile internet. It could also be interesting for exfiltrating data from Faraday-shielded sites that are occasionally visited by iPhone users.
I found two options to accomplish this: The first relies on a 1-byte “status” field that is part of Find My broadcasts and forwarded as-is to the Apple backend where it can be retrieved again. This method has been implemented by Daniel Dakhno in the FakeTag project to continuously transmit the state of a 6-bit counter (and 2 bits of battery level information).
The second option is more generic and would still work if Apple were to restrict the usage of the status byte (e.g. via an iOS update). The idea is that we can treat the Apple backend as something like a dead drop, or more precisely as a public key-value store with public key hashes as key, and encrypted location reports as value, with basic operations:
- We can probe whether location reports for a specific public key hash exist or not
- We can add location reports for a specific public key hash by broadcasting the corresponding public key
I guess you can already see where this is going: We can set arbitrary bits in the shared key-value store and query them again. If both the sender and receiver agree on an encoding scheme, we can transfer arbitrary data.
Because there’s no guarantee as to when or whether specific broadcasts are uploaded to the Apple backend as location reports, our data encoding must be independent of the ordering in which location reports are received, and able to recover partial data streams.
To achieve this, I decided to encode a single bit of data per broadcast together with an index value indicating which bit of the message is being set. Additional message and modem ID fields allow the system to be reused for multiple messages and by multiple users.
For sending a specific bit, we create a 28-byte array of the form:
[4b bit index] [4b message ID] [4b modem ID] [padding 0s...] [bit value]
and treat this as the public key in order to send BLE advertisements to broadcast, for example, the information “bit 0 of message 0 is 1.”
To send a full message, the program simply loops over its bits and sends out one advertisement per bit with the public key that encodes its index and value (Figure G).
When fetching data, the receiving application will generate the same 28-byte arrays (two per bit, for the possible bit values 0 and 1) and query the Apple service with the hashes of those “public keys.” There should be location reports for only one of the two key IDs, which can then be interpreted; for example, “bit at index 0 equals 1” (Figure H).
Instead of only transferring one bit per message, we could also send a full byte by setting the last 8 bits of the public key. While this increases the sending bandwidth, we now need to request 255 different key IDs to fetch/”brute force” one byte (compared to 16 when encoded bit-by-bit).
I implemented this technique in Send My, a modified version of OpenHaystack that turns an ESP32 into a serial (upload only) modem and includes a DataFetcher application (Figure I) to retrieve sent messages for different modems.
Stealth Mode
Apple added a feature to iOS to detect unknown AirTags traveling with the user and warn of them, with the goal of preventing the tracking of other people or their belongings. After numerous news reports of AirTags being used to stalk women or being placed in expensive cars to be stolen when they arrived at the owner’s home, Apple also issued an update for AirTags and iOS to reduce the time until those warnings are triggered to play a sound on the AirTag.
For Android, Apple released the TrackerDetect app, though it does not run in the background and requires the user to perform an “active scan” via the app while being tracked. AirGuard, released by the OpenHaystack team, is an alternative app that also supports continuous scanning in the background.
As a side effect of trying to prevent this misuse, AirTags also lose their appeal for recovering stolen items, as thieves will also be notified of an AirTag and can even trigger sounds to locate and remove it.
Both Apple’s and AirGuard’s detection methods rely on the fact that an unmodified AirTag is only changing its public key once per day and can therefore be “tracked” by nearby devices for a limited time. We can bypass their detection by rotating over many public keys and only sending one broadcast per public key (or waiting long enough until repeating one key). This basically emulates thousands of different AirTags and, to a detection app, makes carrying this tracker almost indistinguishable from going through a busy area with many different AirTags quickly passing by, which should not trigger an alert.
I created such a “stealth” AirTag clone and confirmed it working in a real-world experiment, where I tracked an iPhone user (with their consent of course) for over 5 days without them receiving any notification. The stealth tracker is also not detected by an active scan with Apple’s Tracker Detect app for Android (Figure J).
The modified firmware and a macOS retrieval application optimized to handle thousands of virtual trackers can be found in the Find You repository on our GitHub.
Potential Use Cases
The possibility to piggyback on the Find My offline finding network with AirTag clones enables many use cases that were infeasible or much more expensive before:
• Adding loss/theft prevention to anything: AirTags inform thieves of their presence by playing a sound and triggering tracking alerts. Once found, an AirTag can simply be removed and deactivated.
An AirTag clone would not have this problem and could stay hidden for longer. Devices that already have Bluetooth onboard (e.g. Bluetooth speakers or some 2FA devices) could simply also send out Find My broadcasts (in stealth mode) to make them locatable. For others, a small Bluetooth beacon could be embedded in the product itself (e.g. in a suitcase, purse, or e-bike battery).
After publishing the Find You research, we were also contacted by a security engineer who wanted to use such stealth trackers to fight the rising number of kidnappings of children in their area.
• Industrial/large-scale usage: The Find My app limits the number of AirTags to 16 per account, and the raw location reports are not exposed to the user. When using OpenHaystack, no such limits exist and it’s possible to have a fleet of thousands of low-cost trackers whose location reports can be further processed in an automated way. This could make it attractive, for example, for rental car companies to fit their cars with such trackers, or for logistics companies to put one such tracker in every shipment for live-tracking of all their goods across various delivery subcontractors.
When considering the possibility of arbitrary data transmission, even more possibilities emerge:
• Low-cost, low-power distributed sensors: Using one of the approaches outlined above, it’s possible to upload sensor readings or any data from IoT devices without a broadband modem, SIM card, data plan, or Wi-Fi connectivity. Considering the fact that Amazon is running a network called Sidewalk, connecting Echo devices to achieve exactly this, there seems to be some demand for it.
One such implementation is the previously mentioned FakeTag mailbox sensor, which uses a vibration sensor glued to the flap to detect new mail and continuously transmits the current mail count via the Find My network (Figure K).
I heard from one person who considered using the technique for gathering sensor readings from a boat out in a harbor (e.g., for its bilge pump) and got contacted by a nonprofit organization that sees a “use for it in environmental, air quality, and microclimate modeling, collecting data from remote sensors.”
Since the Finding devices cache received broadcasts until they have an internet connection, the sensors can even transmit data from areas without mobile coverage as long as iPhone users, even just briefly, pass through Bluetooth range —about 50 meters depending on the environment, hardware, and transmission power.
• Data exfiltration: In the world of high-security networks, visitors’ Apple devices might become feasible intermediaries to exfiltrate data from certain air-gapped systems or Faraday-caged rooms. Even where another connection to the outside exists, Find My can act as a covert channel that is less likely monitored than for instance a normal IP connection. Also note that newer iPhones at least remain findable — with Bluetooth, NFC, and UWB radios still running — even when the device is powered off.
NOTE: The data transmission and stealth mode modifications can in theory also be implemented in an actual Apple AirTag, by updating its firmware. Check out the paper “AirTag of the Clones: Shenanigans with Liberated Item Finders.
Conclusion
We’ve shown how to create AirTag clones that are compatible with Apple’s Find My network and how those clones’ capabilities can even surpass the original AirTag’s. In particular, it’s possible to send arbitrary data over the network and to bypass all of Apple’s “anti-stalking features,” making the technology also appealing again in anti-theft (or anti-kidnapping) scenarios.
Both the possibility to use the Find My network with “unauthorized trackers” as well as the described weaknesses are inherent to the privacy-focused design of the system. One interesting trade-off lies in Apple wanting AirTags to be untrackable via Bluetooth (to prevent a network of distributed Bluetooth receivers from tracking devices over a longer period) while relying exactly on this trackability for triggering reliable stalking warnings.
As in the current Find My design, Apple can’t limit its usage to only genuine AirTags (and official partners’ devices), they need to take into account threats of custom-made beacons (or AirTags with modified firmware) that might implement the Find My protocol in weird or malicious ways.
For hackers and makers, however, unless there’s is a major redesign of the Find My offline finding protocol, this ecosystem will likely stay open to be explored and tinkered with. 
Learn more about Find My and AirTags.
