Old Dog, New Tricks – Lost Apples 2.0

If you are not familiar with Lost Apples, please read the original post before proceeding.

There have been some interesting cases in the news lately that have caused me to give some thought about devices being in proximity to each other, and how to prove that proximity, especially when those who are intent on doing harm are going dark prior to doing their bad deeds. This raised the question: is there a way to determine proximity when a device is powered off? My previous research into Observations.db seemed like a good candidate for iOS devices.

With that in mind, I set out to test this, and, if possible, upgrade Lost Apples. If you recall, Lost Apples can decrypt and parse Observations.db, the database that logs all of the FindMy-compatible devices an iOS device sees in a location, and since it uses Bluetooth, that range can be approximately 30 – 33 feet (~ 10 meters). Modern iPhones (read iPhone 11 and above) have the ability to be located via the FindMy network while they are powered down. The idea is that if you lose your iPhone, it is still locatable via FindMy. It becomes, in essence, a very large AirTag. This feature is on by default.

I also decided to include the AirTag as part of this exercise because why not?

States & Keys

There has been two great pieces of research on the FindMy network. One by the folks at Secure Mobile Networking Lab, who created AirGuard (the Android app for detecting AirTags) and Open Haystack, a utility that allows users to create their own AirTags and leverage the FindMy network to track them. The paper they wrote can be found here. The other piece of research is by Christine Fossaceca at Microsoft, which she presented at Objective By the Sea 6.0. If you are interested in knowing about the math, I would recommend reading/watching these pieces of research. I will try to summarize as best I can in the following paragraphs.

From a forensics perspective the important thing to know is the “state” of the FindMy thing that is of interest. AirTags can be in one of three states: connected, nearby, or separated. A connected state means the AirTag is connected to something – one of the owner’s devices. For example, when someone sets up a new AirTag, the tag has to connect to the person’s iPhone/iPad to complete the setup process. It can also enter a connected state later on for other reasons (e.g., a firmware update). An AirTag enters a “nearby” state when it disconnects from one of the owner’s devices but is still close by. An AirTag will enter a “separated” state when it is not nearby one of its owner’s devices. So, for example, if I take my AirTag out of my home and I do not have any of my i-Devices with me then it is no longer “nearby” – it is separated. iPhones are a bit easier as they really only have two states: online or offline.

The above states are important to know because they will dictate what evidence an examiner can expect to find. When an AirTag is in a nearby state it will emit a nearby key payload (Pi) four bytes in length. This is referred to as a “primary key.” I can tell you from testing that I have not seen a four-byte payload in Observations.db. The shortest payload I have observed is six bytes, the contents of which were the BT MAC addresses. I have not been able to identify a “nearby” payload for iPhones, but they may not even exist considering if they are online they’re trackable via FindMy. Regardless, nearby keys rotate every 15 minutes.

When an AirTag is in a separated state they emit a separated key payload (Pwj), which is referred to as a “secondary key.” This key is obvious in Observations.db because it is 28 bytes in length. The first six bytes represent the current randomized BT MAC address at the time the device was observed. If you recall from my Further Observations blog post, there is a difference in the two most significant bits of the payload so as to make the BT MAC address conform to the requirement for private, non-resolvable BT MAC addresses. Figures 1 and 2 are screenshots of the same AirTag, but note that the payload and the observed address are off by one character.

Separated key payloads rotate every 24 hours at 4:00 am local time. I will note that iPhones do not have a secondary key – the OwnedBeacon plist file for them do not contain key/value for it, which, again makes sense as it only has two states. Figure 3 shows the OwnedBeacon plist for an AirTag, while Figure 4 shows a plist for an iPhone. Note the lack of the key “secondarySharedSecret” in Figure 4 (the iPhone).

Seems pretty simple, right? Well, not quite. While I was doing research and testing I found that AirTags have an in-between state: “latch separated.” This state occurs when an AirTag (or other non-iPhone, FindMy-compatible device) transitions from nearby to separated. When that happens the AirTag (or other non-iPhone, FindMy-compatible device) continues to use the primary key, albeit in the 28-byte form, until 4:00 am local time. If the tag stays in separated mode, then the tag will switch to the secondary key. If it transitions back to nearby, then it will use the next primary key in the rotation. Based on my testing, iPhones exhibited no such state, likely due to their two-state nature.

As previously mentioned, primary keys rotate once every 15 minutes and secondary keys rotate once every 24 hours. So how will an owning device know what keys to look for to find the nearby or separated device? It is because the owning device and the AirTag (or lost iPhone) are doing the same math to calculate the keys. The lost device does the math to generate the primary and secondary keys for broadcasting, and the owning device does the same math so it knows what primary and secondary keys it should be looking for. The key material needed to do the math calculations only resides on devices on the iCloud account, which is why a person cannot not log into iCloud and see AirTags and offline phones – the key material needed to calculate the primary and secondary keys is not visible to iCloud.

The key material, as it turns out, is present in the OwnedBeacons plist files for each beacon owned by the iCloud account. This is where Lost Apples comes in…

Upgrades

Lost Apples was already able to decrypt the OwnedBeacon plist files and present them, but knowing about the above keys, states and how that operates presented an opportunity for some enhancements. To start, Lost Apples is now able to calculate the primary and secondary keys for any FindMy device on a given iCloud account so long as the OwnedBeacon plist file is present on the device being examined. These calculations cover the entire lifetime of the beacon while it is on the iCloud account.

To accomplish this, you simply use the “Generate Key Schedule” from the main window, load an OwnedBeacons CSV export from Lost Apples, and then pick the beacon (i.e., the FindMy item) you want to generate keys for.

In Figure 6 note there is a date range picker. That is the estimated amount of days relative to the pairingDate key/value from the OwnedBeacons plist file, so it is not exact. The CSV export is there in the event a user needs to get these results into some other tool. For the primary keys, users simply pick the amount of days to calculate starting from the first set of keys.

What about unwanted/rogue tags (beacons), or WildMode tags? Lost Apples can now compare the randomized BT MAC address found in those WildMode plist files (generated when a beacon is identified as unwanted) to the primary (due to the latched separated mode) and separated keys of a set of Owned Beacons from another device. This would be ideal when attempting to quickly determine if a rogue AirTag (or iPhone) belonged to a particular iCloud account, and you are waiting on Apple to return data to you but have a phone of interest and a FFS extraction from said phone.

To help streamline this, the Export Results window now includes a Wild Mode unified CSV export – it simply exports the MAC/key payload for each UUID in the WildModeAssocation folder. Users can import up to three Wild Mode unified CSV (one per phone) along with the OwnedBeacons CSV export from your “suspect” phone. For ease of reading, you can label each “victim” phone.

Results are presented in a new window.

In situations where the WildMode (rogue) beacon is seen more than once, there is an observation column showing the number of times it was seen. Clicking on the row brings up the times the WildMode beacon was seen.

Here the AirTag “Test AirTag” belonging to my suspect was seen and identified as an unwanted tracker by Josh’s iPhone (iPhone 14 Pro) and This Is DFIR’s iPhone (iPhone 14). Lost Apples took the Owned Beacon key material from the suspect phone (an iPhone 12), derived roughly three years worth of randomized BT MAC addresses, compared them to the WildMode plist files, and found matches. The results also include the separated key value to further confirm the match.

The nice thing about this is that all that is needed is one device from a given iCloud account and Lost Apples can calculate the keys and randomized BT MAC addresses; it can be an older the device the user used to use and hasn’t reset, or it can be a newer device that was not used as the original owning device.

As an additional example, I used my iOS 17 public image, created in July of 2024 as a test. There was a test AirTag that I used to generate unwanted tag alerts on the phone, which triggered WildMode plist files. The AirTag was attached to an iPhone XS that had not been powered on in over a year and a half. I took the iCloud account associated with the AirTag and used it to setup the aforementioned iPhone 12. I obtained a FFS extraction, pulled the OwnedBeacon keys, and ran the comparison. The results are seen in Figure 13.

There were two matches. The iPhone 11 from the iOS 17 Public image saw the same AirTag on two days in July of 2024. Why the two matches? Because the secondary key rotated over that period. Again, the beacon keys were derived in March of 2026 from a phone that was merely connected to the same iCloud account. It was not the original owning device.

While these alerts can absolutely indicate (extended) proximity, what about things that are seen by a victim iPhone, but do not trigger an unwanted tracker alert where the proximity is less time? That is where Observations.db comes in, and there is a new feature in Lost Apples that can compare beacon keys from one phone (or two or three) to what is seen in Observations.db from a victim phone. Below I took an iPhone 14 out (the victim phone) along with an iPhone 12 that was powered down, an AirTag that had been separated from it’s owner, an Apple Watch that had been powered off, and a Chipolo SPOT card (3rd party FindMy accessory for bill folds – I forgotten I had it during testing), and another AirTag from a travel backpack that I own. I drove around with these items for about an hour, and never received an unwanted tracker alert. I pulled the searchpartyd data and exported it via Lost Apples. There is a new button “Compare Observations” that is used to run the comparison.

As with the Wild Mode comparisons, users can load up to three Lost Apples OwnedBeacons CSV files (three different phones) and label them, and can select which beacon(s) they want to search for. A Lost Apples Observations CSV output is also required.

Below is the comparison output.

Five beacons were seen by the iPhone 14. The Test AirTag was seen via its secondary/separated key. The AppleWatch, Wallet, and backpack AirTag were all seen by their latch separated key. None of the beacons triggered an unwanted tracker alert. Most importantly, the iPhone 12 (“DFIR’s iPhone”) was seen by the iPhone 14…while it was powered down. The Wallet was also a nice discovery as I had forgotten the Chipolo was in my pocket during testing.

Some caveats with all of this data:

• Examiners can expect to find the key material needed to calculate the primary and secondary keys on any device that is logged into the iCloud account of interest. That could be previous devices, or new devices. It could also be iPhones, iPads, or Macs.
• For iPhones and iPads, a FFS extraction is needed along with the associated keychain. This data is not present in an iTunes backup or advanced logical extraction.
• If the “lost device” (AirTag, iPhone, iPad, etc.) is removed from the user’s account, the keys needed to calculate the primary and secondary keys are lost, and there is no way to do the calculations. However, if a user removes the lost device but one of the devices on the account hasn’t sync’d with iCloud to get the update, then the keys may still be available (remember to isolate!).
• Just because a match is not found, does not mean devices were not in proximity – it just means the victim device did not see the suspect device or the records were vacuumed. Remember that Observations.db quickly removes records and unwanted tracker alerts stick around for roughly 48 hours.

New Tricks

Putting devices in proximity of each other is something examiners are asked to do often. It is a bit easier when the devices are online, but when one of the device is powered down, it becomes more difficult. However, the evidence can be extremely valuable. Apple’s FindMy capabilities gives examiners a source of information they can use to place two devices within proximity of each other. Lost Apples can now assist in that endeavor. It can also match randomized BT MAC addresses in unwanted tracker alerts when examiners have a suspected owning device.

You can find Lost Apples here.