Accurate depiction of my test phones.

Note: this post is a quasi-continuation of my previous post about Bluetooth trackers on the Google Find My Device network.

While I typically write about Team Green on this blog, I will occasionally tiptoe into iOS/iPadOS land. I recently gave a presentation and wrote a blog post that, among other things, discussed unwanted Google Find My Device (FMD) trackers and how they were detected by Android and iOS devices. While I was finalizing my slide deck for that presentation I stumbled across something interesting in the iOS Unified Logs: information about unwanted trackers was being written to disk. After some digging, Googling, and some yelling at my keyboard, I discovered that examiners do have a way to obtain location data about where an iPhone was when it saw an unwanted tracker, AirTag or otherwise. This discovery lead to a few other things contained within iOS that could be helpful to examiners and investigators, which resulted in this post.

AirTags have been around for three years now and need no introduction. If you need a primer on Google Find My Device trackers, I wrote a post about them recently that should help.

Wild Tags

As a recap, this batch of research started in the iOS Unified Logs. I summarized Unified Logs in my previous post:

“Up until this point the thought process was that examiners would need the Unified Logs from an iOS device in order to determine where an iPhone was when it first saw a tracker, which could help investigators retrace the steps of a victim in the hopes that they could find some physical evidence or a potential crime scene. The problem, however, arises in the fact that any useful information such as locations and associated timestamps are redacted in the Unified Logs, thus rendering them useless. There is always the AirTag developer profile that Apple offers to developers, but there are two problems with this approach:

Applying the profile does not retroactively un-redact previously redacted data.
The profile expires automatically after five days and is removed from the device.”

Additionally, there is the issue of Bluetooth MAC address randomization, which is used by both AirTags and FMD trackers. This is done for privacy reasons, but it plays havoc when trying to find the absolute first time a phone saw an unwanted tracker. Knowing exactly when a tracker was placed on an individual could yield a new crime scene or evidence sources (e.g., surveillance footage), but interviewing the victim (if available) is crucial in making the final determination. The specification Apple and Google jointly wrote specifies that Bluetooth MAC addresses should rotate every 24 hours, so if a tracker has been following a user for more than a day, it is likely the address has rotated at least once. Further, the UUID assigned to an unwanted tracker by a victim iPhone is not the same UUID assigned by the tracker’s owner’s device. All of this makes it almost impossible to connect a physical tracker back to the owner without help from Apple or Google.

Part of my research into Google FMD trackers involved their interactions with iOS devices. As of iOS 17.5 devices now have the ability to detect unwanted trackers on that operate on the Google FMD network. For testing, I was using an iPhone 14 running iOS 17.5.1 and working with full file system extractions; the files discussed in this post are not present in logical extractions. When inspecting the Unified Logs after I received an alert for an unwanted Pebblebee tracker, I found that information about the unwanted tracker was being written to /private/var/mobile/Library/com.apple.icloud.searchpartyd/WildModeAssociationRecord/. See Figure 1.

Figure 1. A .record file being written to disc.

For reference, the log entry for the notification is highlighted in the blue box. The log entry highlighted in the red box is of interest. A file, 6EA4278F-DD8D-4541-8C9A-17364A17CDA5.record, was being written to in the previously mentioned directory path. The file name was the same as the UUID that was referencing the Pebblebee Clip. When I went to that location in the file system, there was the lone file. See Figure 2.

Figure 2. The .record file.

Inspecting this file finds that it is a binary plist file. Figure 3 shows how it appears in Mushy, a free tool written by Ian Whiffin.

Figure 3. The .record file is actually a bplist.

At first glance there does not seem to be much going on here. However, searchpartyd (the iOS process responsible for handling AirTag and beacon tracking) was writing to this file, so there must be something important here. The two values highlighted in green and blue are 16-byte values, but the value in the red box at the bottom looks like gibberish. Apple uses AES-GCM in Apple CryptoKit, which typically means a key, a nonce (or IV), and a GCM tag. The 16-byte values would certainly pass for a nonce or GCM tag, which leaves the key. For that, we head to the Keychain.

In order to proceed from this point your extraction method has to pull the keychain contents and you will need a tool to view them. For that I turned to another freely available tool written by Ian: ArtEx. ArtEx is able to, among other things, parse keychain content. Parsing it and filtering the content by “searchpartyd” (the process that was writing to the file) yielded a handful of results. See Figure 4.

Figure 4. The key.

Highlighted in Figure 4 is the entry for the BeaconStore service, which is in the searchpartyd Access Group. On the far right also highlighted in a red box is a 32-byte value (the key length for AES-256). Using that 32-byte value as the key, the 16-byte value in the green box in Figure 3 as the nonce (IV), and the 16-byte value in the blue box in Figure 3 as the GCM tag, we get what is seen below in Figure 5.

Figure 5. There be clear text here!

The decrypted payload is another bplist. Figure 6 shows how this appears in Mushy.

Figure 6. Decrypted unwanted tracker information, Part 1.

searchpartyd wrote quite a bit of information to this file. In the red box is the randomized Bluetooth MAC address of the tracker at the times of detection by the iPhone. The green box contains the trigger date/time of the notification to the user (me). The blue box contains all of the locations the unwanted tracker was seen; specifically, latitudes, longitudes, horizontal accuracies, and timestamps associated with those locations. For additional clarification, I have highlighted the first location entry in the orange box. The timestamp associated with it is the “first seen” timestamp that is displayed to a user when viewing alert information. See Figure 7.

Figure 7. Alert seen by the user. Displayed time is UTC -0400.

In all, this encrypted bplist contained 26 location entries. I have observed encrypted bplists with more entries than that so an examiner can expect to find a healthy amount of location information in this file. Just to reiterate: because trackers rotate their Bluetooth MAC addresses every 24 hours, the first location in this bplist may not be the location at which the tracker was initially planted on a victim; some physical work may be necessary to make that determination such as visiting the first location documented in this file in conjunction with interviewing the victim. As investigators, we would hope a victim would come to us as soon as possible after having received the unwanted tracker notification, but that may not always be feasible. However, this location data can be helpful in that endeavor and others, and should not be overlooked.

The rest of the encrypted bplist contains other information that may be useful, namely the metadata about the tracker. See Figure 8.

Figure 8. Tracker metadata.

Highlighted in the blue box is the manufacturer, model, and the UUID assigned to the tracker by the victim phone.

So, I was able to find this file for unwanted FMD-based trackers, but what about unwanted AirTags? Well, the behavior and the process to get the data is the same. See Figure 9 for the initial alert about an unwanted AirTag and the map displayed to the user. Note the “first seen” time displayed to the user is UTC -0400.

Figure 9. An unwanted AirTag alert.

The ~/WildModeAssociation/ folder from earlier contained a single entry. See Figure 10 for the file, and Figure 11 for how it looks in Mushy.

Figure 10. The sole entry.
Figure 11. .record file seen in Figure 10.

The file has the same composition as before. Value 0 is the nonce, value 1 is the GCM tag, and value 2 is the encrypted bplist. Using the BeaconStore key from the keychain decrypts the encrypted bplist, which is confirmed in Figure 12.

Figure 12. A decrypted bplist for an unwanted AirTag.

Figure 13 shows the decrypted bplist rendered. Using the same color coding as before, the red box highlights the randomized Bluetooth MAC address during the times of detection, the green box highlights the trigger date/time of the notification, the blue box highlights the location data, and the orange box highlights the “first seen” time that is displayed to the user.

Figure 13. Rendered decrypted bplist for the unwanted AirTag.

The remainder of the file is unremarkable.

Three notes here. First, if the device being examined is running any version of iOS prior to 17.5, the key needed to decrypt the encrypted bplist is different. Instead of the key being stored as “Key” (seen in Figure 4), the key will be stored as the GenericAttribute for BeaconStore. The nonce and GCM tag are the same as describe above. Cellebrite Physical Analyzer will decrypt the < 17.5 encrypted bplist payloads. I have it on good authority that parsing support is planned for both versions.

Second, these .record files for unwanted trackers go back to at least to iOS 15.3.1 (my public iOS 15 image).

Finally, other Apple devices can be considered unwanted and trigger notifications. For example, during testing, I dropped a single AirPod into my pocket with my test phone and eventually received a notification about it following me. The .record file associated with the unwanted AirPod looked and behaved the same as the AirTag, but had additional information that made it perfectly clear that an AirPod had triggered the notification. So, keep in mind that you may not always be looking for an AirTag.

Other Stories

This method of decrypting the .record files found in ~/WildModeAssocationRecord/ applies to the rest of the .record files found in /com.apple.icloud.searchpartyd/. This opened up the possibility of uncovering more information than previously available and getting information that had been traditionally found in other files that are now encrypted (e.g., the .data files found in /private/var/mobile/Library/Caches/com.apple.findmy.fmipcore/). The files discussed in this section went through the same decryption process described above unless otherwise stated.

The first folder to look at is one that contains the names of beacons owned by the device owner: ~/BeaconNamingRecord/. Records in folder contain the name assigned to the beacon (Key “name“), the emoji of the beacon (Key “emoji“), and key named associatedBeacon that contains a UUID value that will allow examiners to track the beacon in the rest of the folders in com.apple.icloud.searchpartyd. See Figure 14 for name (blue box) and emoji (green box), and Figure 15 for associatedBeacon UUID (red box). Note that any beacon that is shared with the owner of the phone will not have a name record in this folder. More on sharing and shared beacons later. Additionally, unwanted trackers will not appear in this folder.

Figure 14. BeaconNamingRecord with the AirTag name and emoji.
Figure 15. BeaconNamingRecord with the assocatedBeacon UUID.

The next folder of interest is ~/OwnedBeacons/. The names of the .records files in this folder correspond to the associatedBeacon UUID values found in ~/BeaconNamingRecord/ .record files. An example is seen below in Figure 16. The important keys here start with pairingTime (blue box), which is, as the name suggests, the time (in UTC) at which the AirTag was paired with the phone. The stableIdentifier, in the green box, contains the serial number of the AirTag (see the string after the hashtag symbol). Finally, the identifier UUID (red box) links the .record file back to the BeaconNamingRecord.

Figure 16. Owned beacon with serial number, pairing timestamp, and BeaconNamingRecord UUID.

iOS 17 brought the ability to share AirTags with other users that may not be part of your family circle. Information about AirTags that are shared with you are stored in the folder ~/SharedBeacons/. See Figure 17 for how it looks to the user (highlighted in the red box), and Figure 18 to how it looks in the file system.

Figure 17. Beacons shared with me as seen in FindMy.
Figure 18. Beacons shared with me in the file system.

The bplist contains information about the owner of the shared AirTag and the time it was shared. In Figure 19 below, the keys destination (the person who shared the AirTag – it’s an email address in this example), identifier (the UUID assigned to the AirTag on the phone being examined), and shareDate (timestamp of the time of sharing in UTC) are highlighted in the red, green, and blue boxes, respectively.

Figure 19. Record for a shared AirTag.

Two notes. First, the UUID value in of the key identifier is used to identify the AirTag in other folders in com.apple.icloud.searchpartyd. The key shareIdentifier (highlighted in the purple box) can be used to find a corresponding record in the folder ~/MemberSharingCircle/, but I have not yet found any investigative value to records in that folder.

What about AirTags being shared with others? Information about them is contained in two folder. First, ~/OwnerSharingCircle/ contains information about the AirTag itself. See Figure 20.

Figure 20. OwnerSharingCircle record with member UUID.

Highlighted in the red box above is the members key and associated UUID value. The UUID is used to determine with whom the AirTag was shared (more on that in a moment. Also in the red box is a key acceptanceState with a value of 1. The other party accepted this AirTag when it was shared with them. Below in Figure 21 is the end of the bplist.

Figure 21. UUID of the AirTag being shared with the other party.

Highlighted in the blue box is the UUID of the AirTag being shared with the other party. Based on the information in Figures 14 and 15 we know the tag being shared is DFIR 4 Test Tag, which aligns with what the user sees as highlighted in the red box in Figure 22.

Figure 22. Shared AirTag from the user’s perspective.

In order to determine with whom the AirTag was shared we match the UUID seen in Figure 20 with a .record file by the same in in the folder ~/OwnerPeerTrust/. See Figure 23.

Figure 23. Matching UUID in OwnerPeerTrust folder.

Decrypting the encrypted bplist here finds with whom the AirTag was shared. See Figure 24.

Figure 24. The recipient of the AirTag.

The two areas highlighted in the red boxes are the same AppleID, which in this case is the phone number of the individual with whom I shared the AirTag. Depending on the AppleID that is used, these fields could contain an email address instead of a phone number. While there was no timestamp that explicitly said it was the time at which the AirTag was shared, I did find a key NS.time that had a timestamp value that was indicative of when I shared the AirTag. Again, not explicit. See the red box in Figure 25.

Figure 25. Indicative timestamp.

The records in the ~/SafeLocations/ folder are interesting. These are locations that are either identified by the iPhone automatically or manually by a user as locations where the iPhone will not notify you that you have left something behind. For example, I leave my AirPods at home because I don’t need them when I go to work, so I don’t want my iPhone to notify me everyday that I left them at home. Figure 26 shows how this looks to the user.

Figure 26. Safe Locations.

The iPhone made some assumptions based on my behavior. On the left in the red box is what was automatically populated by the phone without my intervention. It had automatically identified my home address without me having to do anything and labeled it as “Home”; it also suggested another location I had stayed at for about 10 days while I was visiting my work office near D.C, which is seen in the blue box on the left. The green box on the right highlights a location that I added. I applied that location to all of the beacons I had, but I could have easily applied it to just a single beacon. In the ~/SafeLocations/ folder each .record file represents a location, suggested or manually created by the user. The .record file for the manual location (green box) is seen in Figures 27, 28, and 29. I will note that a user need not visited a location to identify it as “safe.” Any location can be used, so just because and examiner finds a location in this file does not mean the owner has been there.

Figure 27. Longitude for a Safe Location.
Figure 28. Indicative timestamps.
Figure 29. Name of the location, the latitude, and affected beacons.

In Figures 27 and 29, the longitude and latitude are highlighted in the blue boxes, respectively. In Figure 29, the value highlighted in the red box is the name assigned to the Safe Location, and the values in the orange box represent which beacons were affected; the UUIDs correspond to the .record files in ~/OwnedBeacons/. These .record files do not contain an timestamp that explicitly states it is related to when the record was created, but the two timestamps highlighted in the green box in Figure 28 are indicative of when I created it. I was unable to identify a value in these .bplist files that differentiate the records that are automatically created and those that are manually created by the user.

Locations

Location information about beacons is found in ~/BeaconEstimatedLocation/. See Figure 30.

Figure 30. Beacons with location data.

Each of the UUIDs here correspond to a beacon that is either owned or shared with the device being examined. So, in order to determine which beacon is being represented, examiners will have to look at .record files in ~/OwnedBeacons/ and ~/SharedBeacons/. Opening the folder with the name of the UUID highlighted in the red box in Figure 30 finds that we have multiple .record files. The UUID is the AirTag named DFIR 4 Test Tag. See Figure 31.

Figure 31. .record file with location data for DFIR 4 Test Tag.

Each one of the .record files seen in Figure 31 represents a single location for DFIR 4 Test Tag. My observations found that I had more saved location data for scans actually performed by any of the owner’s devices versus when the AirTag was detected by other Apple devices while it was away from the owner (i.e., crowd-sourced). Figure 32. shows the contents of the decrypted bplist in the .record file highlighted in the red box.

Figure 32. A location.

The latitude (red box), longitude (blue box), and timestamp (green box – stored in UTC but shown here in UTC -0400) are all here. Additionally, not highlighted, is the UUID of the AirTag (key associatedBeacon) and a horizontal accuracy (key horizontalAccuracy). Figure 33 show the latitude and longitude mapped, and Figure 34 shows the location in the FindMy UI.

Figure 33. Mapped in Google Maps.
Figure 34. Mapped in FindMy.

Beacons shared with the device being examined behave the same way. Figure 35 shows all of the available .record files for one of the beacons shared with me, and, again, each file represents a set of location data for the tag. Figure 36 shows the location data in the .record file highlighted in the red box in Figure 35. Figure 37 shows the mapped location information pulled from the .record file, and Figure 38 shows the mapped location in the FindMy UI.

Figure 35. Available location records for a shared beacon.
Figure 36. Shared beacon location information.
Figure 37. Mapped location of the shared beacon in Google Maps.
Figure 38. Mapped location of the shared beacon in the FindMy UI.

A few notes here. First, since each of the folders in ~/BeaconEstimatedLocation/ represents a beacon and they can each contain multiple .record files, it means it is possible to get a history of location information for each beacon. Keep in mind, that it is not going to be the entire history of the beacon, just the ones that have been reported back to FindMy. Further, location records do have a shelf life, but I have observed inconsistency with how long the .record files are kept. If it is anticipated that these records are going to be needed, I recommend getting a full file system extraction as quickly as possible.

Second, during testing I found locations for beacons when I did not check on them. So, I suspect there is some background refreshing happening. Keep that in mind when examining this data.

Third, you may have noticed the key “type” in Figures 32 and 36. While I do not have anything concreate, I do suspect they relate to how the beacon was detected; by one of the owner’s devices, crowd-sourced location or some other mechanism. So far I have observed values of 2, 7, 8, and 15, and highly suspect 7 is the value for crowd-sourced.

Fourth. Since other things (i.e., MacBooks ,AppleWatches, iPads and AirPods) can be “beacons,” it’s important to remember that just because you find a location here doesn’t mean the device being examined has been in that location. It could be that one of the owner’s devices (or a beacon that is shared with them) was in that location.

And finally, if the device being examined is part of an iCloud family plan, you may see beacons that do not belong to the owner of the device being examined if location sharing is enabled between the parties.

As with all things, corroborate what you find here.

Epilogue

FindMy has come quite a ways since 2021, and the forensics have definitely changed since then. I think it is a good microcosm of how mobile device forensics is, generally speaking: research is done, it holds true for a while, and then things change and practitioners have to change tactics re-learn things. It is this constant back-and-forth that makes it appealing and frustrating at the same time.

Practitioners now have new sources of information when it comes to AirTags and other Apple devices attached to FindMy. This is great considering some of the previously available information is now protected, but these new sources seem to offer a little more than what was previously available. Hopefully, this will hold true for a while.

Article Link: Where The Wild Tags Are & Other AirTag Stories. – The Binary Hick

1 post – 1 participant

Read full topic

​Accurate depiction of my test phones.
Note: this post is a quasi-continuation of my previous post about Bluetooth trackers on the Google Find My Device network.
While I typically write about Team Green on this blog, I will occasionally tiptoe into iOS/iPadOS land. I recently gave a presentation and wrote a blog post that, among other things, discussed unwanted Google Find My Device (FMD) trackers and how they were detected by Android and iOS devices. While I was finalizing my slide deck for that presentation I stumbled across something interesting in the iOS Unified Logs: information about unwanted trackers was being written to disk. After some digging, Googling, and some yelling at my keyboard, I discovered that examiners do have a way to obtain location data about where an iPhone was when it saw an unwanted tracker, AirTag or otherwise. This discovery lead to a few other things contained within iOS that could be helpful to examiners and investigators, which resulted in this post.
AirTags have been around for three years now and need no introduction. If you need a primer on Google Find My Device trackers, I wrote a post about them recently that should help.
Wild Tags
As a recap, this batch of research started in the iOS Unified Logs. I summarized Unified Logs in my previous post:

“Up until this point the thought process was that examiners would need the Unified Logs from an iOS device in order to determine where an iPhone was when it first saw a tracker, which could help investigators retrace the steps of a victim in the hopes that they could find some physical evidence or a potential crime scene. The problem, however, arises in the fact that any useful information such as locations and associated timestamps are redacted in the Unified Logs, thus rendering them useless. There is always the AirTag developer profile that Apple offers to developers, but there are two problems with this approach:

Applying the profile does not retroactively un-redact previously redacted data.
The profile expires automatically after five days and is removed from the device.”

Additionally, there is the issue of Bluetooth MAC address randomization, which is used by both AirTags and FMD trackers. This is done for privacy reasons, but it plays havoc when trying to find the absolute first time a phone saw an unwanted tracker. Knowing exactly when a tracker was placed on an individual could yield a new crime scene or evidence sources (e.g., surveillance footage), but interviewing the victim (if available) is crucial in making the final determination. The specification Apple and Google jointly wrote specifies that Bluetooth MAC addresses should rotate every 24 hours, so if a tracker has been following a user for more than a day, it is likely the address has rotated at least once. Further, the UUID assigned to an unwanted tracker by a victim iPhone is not the same UUID assigned by the tracker’s owner’s device. All of this makes it almost impossible to connect a physical tracker back to the owner without help from Apple or Google.
Part of my research into Google FMD trackers involved their interactions with iOS devices. As of iOS 17.5 devices now have the ability to detect unwanted trackers on that operate on the Google FMD network. For testing, I was using an iPhone 14 running iOS 17.5.1 and working with full file system extractions; the files discussed in this post are not present in logical extractions. When inspecting the Unified Logs after I received an alert for an unwanted Pebblebee tracker, I found that information about the unwanted tracker was being written to /private/var/mobile/Library/com.apple.icloud.searchpartyd/WildModeAssociationRecord/. See Figure 1.

Figure 1. A .record file being written to disc.
For reference, the log entry for the notification is highlighted in the blue box. The log entry highlighted in the red box is of interest. A file, 6EA4278F-DD8D-4541-8C9A-17364A17CDA5.record, was being written to in the previously mentioned directory path. The file name was the same as the UUID that was referencing the Pebblebee Clip. When I went to that location in the file system, there was the lone file. See Figure 2.

Figure 2. The .record file.
Inspecting this file finds that it is a binary plist file. Figure 3 shows how it appears in Mushy, a free tool written by Ian Whiffin.

Figure 3. The .record file is actually a bplist.
At first glance there does not seem to be much going on here. However, searchpartyd (the iOS process responsible for handling AirTag and beacon tracking) was writing to this file, so there must be something important here. The two values highlighted in green and blue are 16-byte values, but the value in the red box at the bottom looks like gibberish. Apple uses AES-GCM in Apple CryptoKit, which typically means a key, a nonce (or IV), and a GCM tag. The 16-byte values would certainly pass for a nonce or GCM tag, which leaves the key. For that, we head to the Keychain.
In order to proceed from this point your extraction method has to pull the keychain contents and you will need a tool to view them. For that I turned to another freely available tool written by Ian: ArtEx. ArtEx is able to, among other things, parse keychain content. Parsing it and filtering the content by “searchpartyd” (the process that was writing to the file) yielded a handful of results. See Figure 4.

Figure 4. The key.
Highlighted in Figure 4 is the entry for the BeaconStore service, which is in the searchpartyd Access Group. On the far right also highlighted in a red box is a 32-byte value (the key length for AES-256). Using that 32-byte value as the key, the 16-byte value in the green box in Figure 3 as the nonce (IV), and the 16-byte value in the blue box in Figure 3 as the GCM tag, we get what is seen below in Figure 5.

Figure 5. There be clear text here!
The decrypted payload is another bplist. Figure 6 shows how this appears in Mushy.

Figure 6. Decrypted unwanted tracker information, Part 1.
searchpartyd wrote quite a bit of information to this file. In the red box is the randomized Bluetooth MAC address of the tracker at the times of detection by the iPhone. The green box contains the trigger date/time of the notification to the user (me). The blue box contains all of the locations the unwanted tracker was seen; specifically, latitudes, longitudes, horizontal accuracies, and timestamps associated with those locations. For additional clarification, I have highlighted the first location entry in the orange box. The timestamp associated with it is the “first seen” timestamp that is displayed to a user when viewing alert information. See Figure 7.

Figure 7. Alert seen by the user. Displayed time is UTC -0400.
In all, this encrypted bplist contained 26 location entries. I have observed encrypted bplists with more entries than that so an examiner can expect to find a healthy amount of location information in this file. Just to reiterate: because trackers rotate their Bluetooth MAC addresses every 24 hours, the first location in this bplist may not be the location at which the tracker was initially planted on a victim; some physical work may be necessary to make that determination such as visiting the first location documented in this file in conjunction with interviewing the victim. As investigators, we would hope a victim would come to us as soon as possible after having received the unwanted tracker notification, but that may not always be feasible. However, this location data can be helpful in that endeavor and others, and should not be overlooked.
The rest of the encrypted bplist contains other information that may be useful, namely the metadata about the tracker. See Figure 8.

Figure 8. Tracker metadata.
Highlighted in the blue box is the manufacturer, model, and the UUID assigned to the tracker by the victim phone.
So, I was able to find this file for unwanted FMD-based trackers, but what about unwanted AirTags? Well, the behavior and the process to get the data is the same. See Figure 9 for the initial alert about an unwanted AirTag and the map displayed to the user. Note the “first seen” time displayed to the user is UTC -0400.

Figure 9. An unwanted AirTag alert.
The ~/WildModeAssociation/ folder from earlier contained a single entry. See Figure 10 for the file, and Figure 11 for how it looks in Mushy.

Figure 10. The sole entry.

Figure 11. .record file seen in Figure 10.
The file has the same composition as before. Value 0 is the nonce, value 1 is the GCM tag, and value 2 is the encrypted bplist. Using the BeaconStore key from the keychain decrypts the encrypted bplist, which is confirmed in Figure 12.

Figure 12. A decrypted bplist for an unwanted AirTag.
Figure 13 shows the decrypted bplist rendered. Using the same color coding as before, the red box highlights the randomized Bluetooth MAC address during the times of detection, the green box highlights the trigger date/time of the notification, the blue box highlights the location data, and the orange box highlights the “first seen” time that is displayed to the user.

Figure 13. Rendered decrypted bplist for the unwanted AirTag.
The remainder of the file is unremarkable.
Three notes here. First, if the device being examined is running any version of iOS prior to 17.5, the key needed to decrypt the encrypted bplist is different. Instead of the key being stored as “Key” (seen in Figure 4), the key will be stored as the GenericAttribute for BeaconStore. The nonce and GCM tag are the same as describe above. Cellebrite Physical Analyzer will decrypt the < 17.5 encrypted bplist payloads. I have it on good authority that parsing support is planned for both versions.
Second, these .record files for unwanted trackers go back to at least to iOS 15.3.1 (my public iOS 15 image).
Finally, other Apple devices can be considered unwanted and trigger notifications. For example, during testing, I dropped a single AirPod into my pocket with my test phone and eventually received a notification about it following me. The .record file associated with the unwanted AirPod looked and behaved the same as the AirTag, but had additional information that made it perfectly clear that an AirPod had triggered the notification. So, keep in mind that you may not always be looking for an AirTag.
Other Stories
This method of decrypting the .record files found in ~/WildModeAssocationRecord/ applies to the rest of the .record files found in /com.apple.icloud.searchpartyd/. This opened up the possibility of uncovering more information than previously available and getting information that had been traditionally found in other files that are now encrypted (e.g., the .data files found in /private/var/mobile/Library/Caches/com.apple.findmy.fmipcore/). The files discussed in this section went through the same decryption process described above unless otherwise stated.
The first folder to look at is one that contains the names of beacons owned by the device owner: ~/BeaconNamingRecord/. Records in folder contain the name assigned to the beacon (Key “name“), the emoji of the beacon (Key “emoji“), and key named associatedBeacon that contains a UUID value that will allow examiners to track the beacon in the rest of the folders in com.apple.icloud.searchpartyd. See Figure 14 for name (blue box) and emoji (green box), and Figure 15 for associatedBeacon UUID (red box). Note that any beacon that is shared with the owner of the phone will not have a name record in this folder. More on sharing and shared beacons later. Additionally, unwanted trackers will not appear in this folder.

Figure 14. BeaconNamingRecord with the AirTag name and emoji.

Figure 15. BeaconNamingRecord with the assocatedBeacon UUID.
The next folder of interest is ~/OwnedBeacons/. The names of the .records files in this folder correspond to the associatedBeacon UUID values found in ~/BeaconNamingRecord/ .record files. An example is seen below in Figure 16. The important keys here start with pairingTime (blue box), which is, as the name suggests, the time (in UTC) at which the AirTag was paired with the phone. The stableIdentifier, in the green box, contains the serial number of the AirTag (see the string after the hashtag symbol). Finally, the identifier UUID (red box) links the .record file back to the BeaconNamingRecord.

Figure 16. Owned beacon with serial number, pairing timestamp, and BeaconNamingRecord UUID.
iOS 17 brought the ability to share AirTags with other users that may not be part of your family circle. Information about AirTags that are shared with you are stored in the folder ~/SharedBeacons/. See Figure 17 for how it looks to the user (highlighted in the red box), and Figure 18 to how it looks in the file system.

Figure 17. Beacons shared with me as seen in FindMy.

Figure 18. Beacons shared with me in the file system.
The bplist contains information about the owner of the shared AirTag and the time it was shared. In Figure 19 below, the keys destination (the person who shared the AirTag – it’s an email address in this example), identifier (the UUID assigned to the AirTag on the phone being examined), and shareDate (timestamp of the time of sharing in UTC) are highlighted in the red, green, and blue boxes, respectively.

Figure 19. Record for a shared AirTag.
Two notes. First, the UUID value in of the key identifier is used to identify the AirTag in other folders in com.apple.icloud.searchpartyd. The key shareIdentifier (highlighted in the purple box) can be used to find a corresponding record in the folder ~/MemberSharingCircle/, but I have not yet found any investigative value to records in that folder.
What about AirTags being shared with others? Information about them is contained in two folder. First, ~/OwnerSharingCircle/ contains information about the AirTag itself. See Figure 20.

Figure 20. OwnerSharingCircle record with member UUID.
Highlighted in the red box above is the members key and associated UUID value. The UUID is used to determine with whom the AirTag was shared (more on that in a moment. Also in the red box is a key acceptanceState with a value of 1. The other party accepted this AirTag when it was shared with them. Below in Figure 21 is the end of the bplist.

Figure 21. UUID of the AirTag being shared with the other party.
Highlighted in the blue box is the UUID of the AirTag being shared with the other party. Based on the information in Figures 14 and 15 we know the tag being shared is DFIR 4 Test Tag, which aligns with what the user sees as highlighted in the red box in Figure 22.

Figure 22. Shared AirTag from the user’s perspective.
In order to determine with whom the AirTag was shared we match the UUID seen in Figure 20 with a .record file by the same in in the folder ~/OwnerPeerTrust/. See Figure 23.

Figure 23. Matching UUID in OwnerPeerTrust folder.
Decrypting the encrypted bplist here finds with whom the AirTag was shared. See Figure 24.

Figure 24. The recipient of the AirTag.
The two areas highlighted in the red boxes are the same AppleID, which in this case is the phone number of the individual with whom I shared the AirTag. Depending on the AppleID that is used, these fields could contain an email address instead of a phone number. While there was no timestamp that explicitly said it was the time at which the AirTag was shared, I did find a key NS.time that had a timestamp value that was indicative of when I shared the AirTag. Again, not explicit. See the red box in Figure 25.

Figure 25. Indicative timestamp.
The records in the ~/SafeLocations/ folder are interesting. These are locations that are either identified by the iPhone automatically or manually by a user as locations where the iPhone will not notify you that you have left something behind. For example, I leave my AirPods at home because I don’t need them when I go to work, so I don’t want my iPhone to notify me everyday that I left them at home. Figure 26 shows how this looks to the user.

Figure 26. Safe Locations.
The iPhone made some assumptions based on my behavior. On the left in the red box is what was automatically populated by the phone without my intervention. It had automatically identified my home address without me having to do anything and labeled it as “Home”; it also suggested another location I had stayed at for about 10 days while I was visiting my work office near D.C, which is seen in the blue box on the left. The green box on the right highlights a location that I added. I applied that location to all of the beacons I had, but I could have easily applied it to just a single beacon. In the ~/SafeLocations/ folder each .record file represents a location, suggested or manually created by the user. The .record file for the manual location (green box) is seen in Figures 27, 28, and 29. I will note that a user need not visited a location to identify it as “safe.” Any location can be used, so just because and examiner finds a location in this file does not mean the owner has been there.

Figure 27. Longitude for a Safe Location.

Figure 28. Indicative timestamps.

Figure 29. Name of the location, the latitude, and affected beacons.
In Figures 27 and 29, the longitude and latitude are highlighted in the blue boxes, respectively. In Figure 29, the value highlighted in the red box is the name assigned to the Safe Location, and the values in the orange box represent which beacons were affected; the UUIDs correspond to the .record files in ~/OwnedBeacons/. These .record files do not contain an timestamp that explicitly states it is related to when the record was created, but the two timestamps highlighted in the green box in Figure 28 are indicative of when I created it. I was unable to identify a value in these .bplist files that differentiate the records that are automatically created and those that are manually created by the user.
Locations
Location information about beacons is found in ~/BeaconEstimatedLocation/. See Figure 30.

Figure 30. Beacons with location data.
Each of the UUIDs here correspond to a beacon that is either owned or shared with the device being examined. So, in order to determine which beacon is being represented, examiners will have to look at .record files in ~/OwnedBeacons/ and ~/SharedBeacons/. Opening the folder with the name of the UUID highlighted in the red box in Figure 30 finds that we have multiple .record files. The UUID is the AirTag named DFIR 4 Test Tag. See Figure 31.

Figure 31. .record file with location data for DFIR 4 Test Tag.
Each one of the .record files seen in Figure 31 represents a single location for DFIR 4 Test Tag. My observations found that I had more saved location data for scans actually performed by any of the owner’s devices versus when the AirTag was detected by other Apple devices while it was away from the owner (i.e., crowd-sourced). Figure 32. shows the contents of the decrypted bplist in the .record file highlighted in the red box.

Figure 32. A location.
The latitude (red box), longitude (blue box), and timestamp (green box – stored in UTC but shown here in UTC -0400) are all here. Additionally, not highlighted, is the UUID of the AirTag (key associatedBeacon) and a horizontal accuracy (key horizontalAccuracy). Figure 33 show the latitude and longitude mapped, and Figure 34 shows the location in the FindMy UI.

Figure 33. Mapped in Google Maps.

Figure 34. Mapped in FindMy.
Beacons shared with the device being examined behave the same way. Figure 35 shows all of the available .record files for one of the beacons shared with me, and, again, each file represents a set of location data for the tag. Figure 36 shows the location data in the .record file highlighted in the red box in Figure 35. Figure 37 shows the mapped location information pulled from the .record file, and Figure 38 shows the mapped location in the FindMy UI.

Figure 35. Available location records for a shared beacon.

Figure 36. Shared beacon location information.

Figure 37. Mapped location of the shared beacon in Google Maps.

Figure 38. Mapped location of the shared beacon in the FindMy UI.
A few notes here. First, since each of the folders in ~/BeaconEstimatedLocation/ represents a beacon and they can each contain multiple .record files, it means it is possible to get a history of location information for each beacon. Keep in mind, that it is not going to be the entire history of the beacon, just the ones that have been reported back to FindMy. Further, location records do have a shelf life, but I have observed inconsistency with how long the .record files are kept. If it is anticipated that these records are going to be needed, I recommend getting a full file system extraction as quickly as possible.
Second, during testing I found locations for beacons when I did not check on them. So, I suspect there is some background refreshing happening. Keep that in mind when examining this data.
Third, you may have noticed the key “type” in Figures 32 and 36. While I do not have anything concreate, I do suspect they relate to how the beacon was detected; by one of the owner’s devices, crowd-sourced location or some other mechanism. So far I have observed values of 2, 7, 8, and 15, and highly suspect 7 is the value for crowd-sourced.
Fourth. Since other things (i.e., MacBooks ,AppleWatches, iPads and AirPods) can be “beacons,” it’s important to remember that just because you find a location here doesn’t mean the device being examined has been in that location. It could be that one of the owner’s devices (or a beacon that is shared with them) was in that location.
And finally, if the device being examined is part of an iCloud family plan, you may see beacons that do not belong to the owner of the device being examined if location sharing is enabled between the parties.
As with all things, corroborate what you find here.
Epilogue
FindMy has come quite a ways since 2021, and the forensics have definitely changed since then. I think it is a good microcosm of how mobile device forensics is, generally speaking: research is done, it holds true for a while, and then things change and practitioners have to change tactics re-learn things. It is this constant back-and-forth that makes it appealing and frustrating at the same time.
Practitioners now have new sources of information when it comes to AirTags and other Apple devices attached to FindMy. This is great considering some of the previously available information is now protected, but these new sources seem to offer a little more than what was previously available. Hopefully, this will hold true for a while.
Article Link: Where The Wild Tags Are & Other AirTag Stories. – The Binary Hick
1 post – 1 participant
Read full topic