Where am I???NOTE: portions of this post appeared in my presentation at the 2024 SANS DFIR Summit.
Where did the summer go? August is almost behind us, but it seems like yesterday the kids got out of school here in the U.S. Conferences, work and vacations have a way of making the time fly.
Back in May of this year Google finally starting sending emails to users about a new feature on Android’s Find My Device (FMD) network: allowing Bluetooth trackers to be located using the milions of Android phones out in the wild. This was after announcing plans to do so at I/O 2023. So what took long? After the privacy and safety issues that arose from the arrival of AirTags, Google and Apple decided it would be best to collaborate in order to ensure users of Android and iOS had a way to detect unwanted FMD trackers. This collaboration included the creation of a formalized specification on Bluetooth trackers. When iOS 17.5 was ready to be released, Google flipped the switch and more Bluetooth trackers were now available in the wild.
It doesn’t take much work to find articles about how individuals with malicious intent use AirTags for nefarious purposes. Stalking and ancillary offenses are not new. However, the near-ubiquitous availability of the technology and the low price-point makes it really easy and convenient for individuals who would otherwise not be inclined to do such things to do so from the comfort of their homes. Just before I left for the SANS DFIR Summit I had a 4-pack of AirTags shipped to my home in a matter of hours by Amazon for $70 USD. I could have easily driven to my local Target store to get the same thing much sooner. While there are not many FMD-compatible trackers on the market yet, they are coming, and the mass availability and cost will be the same.
Considering all of this, I decided to take a look at FMD from both an owner’s perspective and from a target’s (i.e., a victim). As forensic examiners, it will only be a matter of time before a phone comes across our benches involving FMD and these trackers. This is going to be one of my longer posts, so buckle up.
For testing, I had several devices that were used over a 2 and half month period:
- Pixel 5a (Android 14, May, June, July SPLs)
- Pixel 8a (Android 14, May, June, July SPLs)
- Pixel Tablet (Android 14, May, June, July SPLs)
- Chromebook
- Galaxy S22 (One UI 6, May, June, July updates)
- Galaxy S23 (One UI 6, May, June, July updates)
- iPhone 14 (iOS 17.5.1)
- iPhone 14 Pro (iOS 17.5.1 & 17.6, and 17.6.1)
The Pixel devices (5a, 8a, Tablet) and Chromebook were all on the same Google account. The Galaxy devices each had their own Google account. The iPhones had no Google accounts associated with them, but, because we are also talking about unwanted trackers, they were included in the testing because both could be “victims.”
I will go ahead and remove the suspense around the Chromebook – it never appeared in my FMD data. It is quite possible my particular hardware model was not compatible, but you will not see it again in the rest of this post.
The Trackers
As of the time of this post there are only two OEMs that make Bluetooth trackers that are compatible with the FMD network: Chipolo and Pebblebee. For testing, I chose the latter OEM. Specifically, I used the Pebblebee Clip.
The front of the Pebblebee Clip.
The back of the Pebblebee Clip.
Pebblebee makes FMD trackers in other form factors, so keep that in mind while reading this post. The first picture shows the front of the trackers; note the Pebblebee logo in the middle. There is a physical button underneath the logo, and different press-sequences caused the trackers to do certain things. Depending on the OEM, there may or may not be a button, and the hardware functionality will likely be different.
The second picture shows the back of the tracker. Note there is a serial number (left) and MAC address (right) on the bottom portion of the tracker. These will not be seen again in the rest of this post as I never found them in any of the data I examined, so pairing a physical tracker back to its owner is going to require help from Google. More on that later.
Setup and Enrollment
Being able to pair FMD trackers to a phone assumes that the user is already participating or is willing to participate in FMD. Users, like myself, were sent emails from Google when their accounts were eligible to start participating in FMD. At the time of this post, using trackers on FMD is only available to users in North America, with the rest of the world getting the capabilities in the future. Additionally, users will need a device running Android 6 or higher and be running the Google Services update from May 2024 or later. In order for a phone to detect and report locations about seen items back to FMD, it needs to be running Android 9 or higher.
When enrolling a phone in the FMD network a user has to decide how they want to participate in FMD in regards to detecting other people’s stuff. A user has two options:
- With Network in High-Traffic Areas Only. This setting means a user’s device will only report seen trackers to FMD while located in areas with a lot of other Android users. Think of being in a busy shopping mall/office complex, an airport, a traffic jam on a major highway, or major event where there are a lot of other people. This setting also enforces what Google calls “aggregated detection.” Basically, more than one Android device has to detect the tracker/thing being located in these high traffic areas before its location is reported back to FMD.
- With Network in All Areas. This setting basically removes to the two caveats in the other setting. A single Android that detects a tracker/thing will report its location back to FMD regardless of where the Android is.
Figure 1. Participation options.The default setting here is “With Network in High-Traffic Areas Only.” Google states this is done for privacy reasons, which I get; however, it does cause performance issues with FMD. A quick Google search will find several articles and Reddit posts that complain about how bad tracking performance is on FMD, and this setting seems to contribute to the poor performance. One example can be found here. Google recommends that users change the setting to “With Network in All Areas” to help with the performance (why isn’t this default then?), and state they are implementing improvements. My experience, especially with the trackers, was spotty at best, so FMD can definitely stand for improvement. During testing, I did use With Network in All Areas.
FMD trackers operate on the Google Fast Pair Service (GFPS), which means Bluetooth. If you are an iOS user and have never seen GFPS in action, it is similar to how iOS handles things like AirPods and AirTags. The phone just recognizes the device as soon as it gets into proximity of the phone and brings a card up to show the user the device is available for pairing. For the Pebblebee clip, a double-click on the button woke the tracker up and it was seen by the S23. See Figure 2.
Figure 2. GFPS pairing card.Clicking “Connect” brings a user to a second screen that basically asks the user to not use the tracker for malicious purposes.
Figure 3. Please don’t use this for badness.After that, pairing occurs. At the end of the process the user is prompted to use the Find My Device app.
Figure 4. You’ll need this.The app is not part of a default Android installation, so a user will have to go to the Play Store to download and install it. I suspect this was to curb any concerns about monopolistic practices. 
Once the device is paired, it appears in the app dashboard. Below is the dashboard for the Pixel 8a.
Figure 5. FMD app dashboard with a list of devices.Pressing on any of those devices in the list will locate the device. Figure 6 shows me locating the Pixel Tablet (left) and the Pebblebee tracker (right).
Figure 6. Locating devices.Locating owned trackers that are nearby with a phone is accomplished by pressing “Find nearby” when locating the tracker. The interface changes as depicted in Figure 7. You can see the phone getting progressively closer to the tracker (going from left to right) culminating in me playing a sound on the tracker.
Figure 7. Getting closer.Users have other options with the trackers. They can rename a tracker, place it in a pre-defined category, mark it as lost and add contact information to it in the event someone finds it, and share a tracker. The screens for those actions are seen below, left to right respectively, in Figure 8.
Figure 8. Tracker options.The Owner
The other surprising (lack of) finding was that location data for FMD devices did not seem to be cached anywhere on-device, at least not anywhere I could find.
With regards to owned trackers, the story is a bit better. While the trackers utilize Bluetooth, the normal go-to’s for Bluetooth devices on Android were lacking. bt_config.conf had no information about the trackers at all and bluetooth_db only had a MAC address with no other identifying information. So these two files were useless.
As mentioned earlier, the trackers utilized GFPS, and there is a file in Android that stores information about devices that are paired via this service: nearby_fast_pair_item_cache.db. It appeared on the Pixel and Samsung devices, and can be found in /data/data/com.google.gms/files/, so you will need a full file system (FFS) extraction in order to access it. Additionally, it is a levelDB, so you will need a viewer that can handle it. If you are not familiar with levelDBs, I recommend reading Alex Cathness’ article about them, which you can find here . For purposes of this post, just know that levelDBs operate using a key-value pair, and that, for this file, the key is the Bluetooth MAC address of the device being paired. To view this file and other levelDBs, I used Mushy, which is a free tool written by Ian Whiffin. See Figure 9.
Figure 9. nearby_fast_pair_item_cache.db, Part 1.There are a few items in this file. First, and highlighted in the red box in Figure 9, is the Bluetooth MAC address of the tracker at the time of pairing. That last part is important. Trackers on FMD are just like AirTags in that they randomize their Bluetooth MAC addresses. The specification that Google and Apple collaborated on state that the MAC address should rotate once every 24 hours, but that does not preclude them from rotating more often if so designed. From an investigative and examination perspective this is a major headache, but a win for privacy. Another file discussed later on really hammers home the randomization.
Going further into the file finds the area seen in Figure 10. There are two things highlighted here. First, the friendly name of the tracker at the time of pairing (blue box). Android will assign a name to the tracker during the initial pairing. If a user opts to change the name of a tracker later on after pairing, an examiner will not find the new name in this file. Second are the two Unix Epoch timestamps highlighted in the green box. In my testing these two timestamps were never exact, but typically differed by a second or two. These timestamps are indicative of when the device was initially paired to the phone.
Figure 10. nearby_fast_pair_item_cache.db, Part 2.The last thing of interest in this file is seen in Figure 11.
Figure 11. A png.The value included a picture of the tracker. This is the same picture that appeared in Figure 2. This could come in handy in the event you need to identify a physical tracker.
There are few notes about nearby_fast_pair_item_cache.db. First, if a tracker has been unpaired from an account (read disassociated from FMD), information about the tracker will still appear in here. Second, I have not been able to determine if there is any data retention threshold for this file. During testing, I found that unpaired tracker information stayed in this file a couple of months after it had been unpaired and after other GFPS devices had been paired with the phone. Because it has “cache” in the file name, I was surprised to see this type of behavior. Regardless, examiners should act to get the extraction as soon as feasible. Third, there is duplicate information found in the file nearby_scan_fast_pair_item_cache.db, which can be found in the same location within the file system.
The next file was found the Pixel, and was as surprising find. The file is maestro_devices. It is a SQLite database that is related to the app used to manage Google Pixel Buds (wireless headphones). It is found in /data/data/com.google.android.apps.wearables.maestro.companion/databases/. See Figure 12.
Figure 12. maestro_devices.While this file was found on the Pixel during my testing, this file could potentially be found on any Android device since Pixel Buds could be paired with other Android OEM devices. This file contains the same information as seen in nearby_fast_pair_item_cache.db. Highlighted in Figure 12 are the Bluetooth MAC address at the time of pairing (red box), the name of the tracker at the time of pairing (blue box), and a Unix Epoch timestamp that is indicative of when the pairing occurred (green box). In my testing this timestamp never exactly matched either timestamp in nearby_fast_pair_item_cache.db, but varied but a second or two from them. Again, it is indicative.
The next file is one that is exclusive to Samsungs because it is part of Samsung Rubin. If you are not familiar with Samsung Rubin just know it is similar to knowledgeC in iOS in that it tracks a lot of user activity. Cellebrite has a webinar about Rubin, which you can find here . The file is inferenceengine_logging.db and it is found in /data/data/com.samsung.android.rubin.app/databases/, so a FFS extraction is needed. Further, it is a SQLite database that is encrypted, so you will need the appropriate key from the Android keystore to decrypt it. See Figure 13.
Figure 13. inferenceengine_logging.db, decrypted.There are several tables in this database, but there are two that are relevant here. The first is all_bluetooth_dictionary. For purposes of this post, this table stores information about the tracker’s Bluetooth MAC address during pairing (column “address”), the time it was first paired (column “created_at”), and the name of the tracker at the time of pairing (column “alias”). These items are highlighted in Figure 14 in the red, green, and blue boxes, respectively.
Figure 14. all_bluetooth_dictionary.The other table of interest is all_bluetooth_log, which tracks connection/disconnection times for bluetooth devices. This table can get a little noisy, so I have filtered it by the Bluetooth MAC address seen in Figure 14. See Figure 15.
Figure 15. That’s it?The entries seen in Figure 15 are the only times this Bluetooth MAC address was seen even though this tracker had physically been with this phone for a few weeks. The timestamps reflect when the tracker had been initially paired with the phone. This really shows the effect of Bluetooth MAC randomization.
The next thing to discuss is Google Takeout/warrant return data. Because FMD is a Google service there is some data that is kept server-side about trackers that are associated with a Google account. Trackers on FMD are consider “Home” devices, and, as such, they are grouped with other accessories Google considers part of a home (e.g., a Nest Hub). In Google Takeout data, information about trackers appear in the file HomeApp.json. See Figure 16.
Figure 16. Tracker information in Google Takeout.This file contains a few good bits of information. First, the time the tracker was associated with the Google account (red box). Second, the name of the tracker (green box). In the event a user changes the name of a tracker, that new name will be seen here. Third, not highlighted but directly under the red box, is the email address associated with the tracker (i.e., the “owner”).
The final thing of interest here is the value seen in the blue box. At the time a tracker is paired with a phone a random 32-byte value is generated, concatenated with a value and hashed using SHA-256. This hashed value is called the Ephemeral Identity Key (EIK) and it used to derive other keys needed for FMD operations. The value seen in the blue box is the first 8 bytes of the Ring Key. In order to generate the Ring Key, the EIK is concatenated with yet another value and hashed using SHA-256. I have seen these values change, but nowhere near the frequency of the Bluetooth MAC addresses. During testing, I observed Ring Keys that did not change for over three weeks, which can be a good thing from an investigative perspective. More on this later.
The fact that this information was in my Takeout data is a good sign that Google likely has additional information available to those who have Search Warrant powers. In fact, in the tracker specification previously mentioned, it is stated that providers (read as Google and Apple) should keep enough information about trackers on the network so that they can identify an owner, and that they should make this data available to law enforcement when requested via appropriate legal process.
Takeout data has additional information that could be useful. In the event that a user shares a tracker with another person on FMD, the Takeout data will reflect that. Figure 17 shows how a shared tracker looks to a user, and Figure 18 shows how it looks in the Takeout data.
Figure 17. A shared tracker in the FMD app.
Figure 18. A shared tracker in Takeout data.When a tracker is shared, the email address of the recipient is added to owner’s Takeout data (red box in Figure 18) and the tracker will appear in the recipient’s Takeout data. This could come in handy in the event that a tracker’s owner “shares” the tracker with multiple accounts that they control in an attempt obfuscate their identity.
Information about sharing is also found on the owner’s device. The file 1_threads.notifications.db contains information about shared tracker; specifically to whom it was shared and when. Files by this name are scattered throughout the Android file system, but the one that contains this information is found in /data/data/com.google.android.apps.fdm/databases/. See Figure 19.
Figure 19. 1_threads.notifications.db.In order to find any indications of a shared tracker looking in the column thread_id for the string “sharing” will get you record entries that related to shared tags. In Figure 19 an example is highlighted in the red boxes. The record will have an associated protobluf BLOB in the rendered_message column. See Figure 20.
Figure 20. rendered_message.The decoded BLOB is seen in Figure 21.
Figure 21. Decoded BLOB.The BLOB contains two important pieces of information. First, highlighted in the red box in Figure 21, is what was shared (Pebblebee Clip) and with whom (hrphilby@gmail[.]com). The other piece of information is the time at which the tracker was shared, which is stored in a Unix Epoch timestamp and highlighted in the green box.
The Victim
There is a high likelihood that a victim is not going to know that they are a victim until one of two things happen:
- They find a physical tracker in their personal space. Think about a person finding a tracker while cleaning out their car, their hand bag, a gym bag, or if they have taken their car to a mechanic to get work done.
- Their phone notifies them that they have a tracker following them.
The second scenario is one that investigators and mobile device examiners will be most interested in in that it affects all of us now that the ability to notify users about unwanted tracker alert exist on both Android and iOS. The good news is that Google and Apple collaborated on a specification to handle unwanted trackers, so there is some similarities between how the two platforms handle unwanted trackers. On the Android side an example of a notification about an unwanted tracker is seen in Figure 22.
Figure 22. Unwanted tracker alert on Android.Clicking “More Info” in the notification card takes a user to the flow seen in Figure 23 (going left to right). A map is rendered (not in my screenshot, though 
) to show the user where the phone has seen the tracker, and the user is given an option to get more information about the tracker by clicking “Next steps.” Doing so fetches a set of instructions for the user to follow to put the tracker into a state in which it can be scanned by the phone. For the Pebblebee Clip, this required clicking the physical button three times. Once the tracker was scanned, Chrome opened and displayed a device identifier and a redacted email address. See Figure 23.
Figure 23. Unwanted tracker info on Android.Figure 24 shows an unwanted tracker alert on iOS.
Figure 24. Unwanted tracker alert on iOS.The flow a user goes through to get more information about an unwanted tracker on iOS is similar to what Android users experience. A map is rendered to show the user where the phone has seen the tracker, and the user is given an option to get more information about the tracker by clicking “Learn About This Item.” Doing so fetches a set of instructions for the user to follow to put the tracker into a state in which it can be scanned by the phone (a triple-click on the button). Once the tracker was scanned, Safari opened and displayed a device identifier and a redacted email address. See Figure 25.
Figure 25. Unwanted tracker info on iOS.The alerts seen in Figure 23 and 25 are for the same tracker during the same time frame. Keeping that in mind, see Figure 26.
Figure 26. Different identifiers. Android on the left, iOS on the right.On the left is the tracker info that was returned to the Android phone, and on the right, the tracker info that was returned to the iPhone. Again, these scans were from the same tracker for the same “following” time frame, but the Device IDs that were returned were different. Additionally, these scans took place less than one hour apart. Google defines this identifier as an “emphemieral identifier.” The identifier should only be valid for 5 minutes per Google’s developer documentation. If you were to look at the URL that fetched this information, it is the ephemeral identifier combined with the first 8 bytes of the tracker’s recovery key (set when it’s first provisioned to FMD by the owner). So, in theory, if the tracker was scanned by both devices within five minutes, the Device ID should have been the same. I was unable to test this theory, though.
When it comes to the forensics on a victim’s phone the most important thing to remember is this: just because a phone has not notified a user that a tracker is following them, does not mean the phone has not seen a tracker. Especially when it comes to Android phones. The database that is used to document unwanted tracker detection on Android is personalsafety_db, and it stores information about tags the phone has seen and ones that it has alerted the user about. The database is found in /data/data/com.google.android.gms/databases/. There are only two tables in this database. The first is Scan. See Figure 27.
Figure 27. Table Scan in personalsafety_db.I wrote about this database last year in relation to unwanted AirTag detection on Android, and most of what I discussed in that post applies to unwanted FMD trackers. The table Scan documents what trackers the phone has seen. While this includes trackers the phone has notified the user about, it includes trackers the phone has not alerted the user about. The table tracks Bluetooth MAC addresses (column macAddress), the time it sees the tracker (column creationTimestampMillis), and where the phone was when it saw the tracker (column locationScan), which is the most important part of the record entry. Data in locationScan is stored in BLOBs. Figure 28 shows the decoded BLOB from the highlighted record in Figure 27.
Figure 28. BLOB data from the highlighted record entry in Figure 27.The BLOB has three pieces of information that investigators are likely interested in: the latitude (red box) and longitude (blue box) of the phone when it detected the MAC address associated with the record and when the phone detected it (green box). This data can be helpful in many ways, so, even if your investigation/examination does not involve an unwanted FMD tracker/AirTag, you should still examine this file for additional location information.
The latitude and longitude are mapped in Figure 29.
Figure 29. Mapped coordinates.This location and the associated time is accurate. I was at this location for a birthday party.
The other table in personalsafety_db is DeviceData. See Figure 30.
Figure 30. DeviceData table from personalsafety_db.This table documents notifications that are served to the user when it detects an unwanted FMD tracker (and AirTag). I discuss this table in my previous article, but just to recap: the Bluetooth MAC address (the randomized one) of the detected tracker, the time at which the notification was created and the status of the notification (STAGED or SENT). Where this table differs when it comes to unwanted FMD trackers is the column in the red box in Figure 30. During my AirTag research, that column was empty, however, for unwanted FMD trackers, it was populated. The column contains a protobuf BLOB, which holds two pieces of information. Figure 31 shows the decoded protobuf.
Figure 31. Decoded protobuf BLOB.The first piece of information, highlighted in the blue box, is the tracker that was detected. Here, it’s a Pebblebee Clip. Second, highlighted in the red box at the top, is the detected tracker’s Ring Key value. See Figure 32.
Figure 32. Matched Ring Key in Google Takeout data.The Ring Key value can help you track back to the owner’s Google account via Google Takeout or a warrant return. Again, you need Google’s help, but it’s a pretty good way to tie a rogue tracker back to an account. There is a limitation, though. I have observed Ring Key values changing; however, they do not seem to change often; definitely not as often as the Bluetooth MAC address. As of the writing of this post (and my presentation) I had a Ring Key that had been persistent for a little over three weeks, even after the tag had been scanned and detected multiple times. So, if an examiner finds a Ring Key during their examination and there is an identified suspect, make sure to pull any cloud data that is available if you have authority to do so (e.g., consent, probable cause, local jurisdiction threshold). That could provide a quick win by associating an unwanted tracker to an owner.
Phone To Phone
Up until this point the discussion has been around Bluetooth trackers. But what about just tracking phones? Many instances of people being followed/stalked do not involve a Bluetooth tracker but rather simply locating the victim’s phone, and this is something that FMD has been able to do since the beginning. As it turns out, there are forensic artifacts that are left behind on the victim phone (the one being located) when it is located via FMD. See Figure 33.
Figure 33. Locating the Pixel 5a from the Pixel tablet.Earlier it was mentioned that the Pixel 5a, 8a, and Pixel Tablet were all using the same Google account. Figure 33 shows locating the Pixel 5a from the Pixel Tablet. When this happened, the Pixel 5a received a notification that it had been located via Find My Device. Note that the time the notification was received was on 2024-08-08 at 18:40 (UTC -0400), which matches the time seen in Figure 33. See Figure 34.
Figure 34. Find My Device notification.I found that each time I located any of the test Android devices, that device received a notification like the one see in Figure 34. In Android land, notifications are pushed to devices via the Firebase Cloud Messaging (FCM) platform. Pushed notifications are stored in a levelDB file named fcm_queued_messages.ldb, which is located in /data/data/com.google.android.gms/files/. You can read more about this database in another article written by Alex Caithness. Since we know when the notification occurred, we can use that time to search for the relevant entry in fcm_queued_messages.ldb by using the timestamp contained within the keys in the database. Figure 35 shows the relevant entry.
Figure 35. This is the entry we’re looking for.Part of the value payload shows that the phone received an FCM message for com.google.android.apps.adm, which is the apk name for the Find My Device app (highlighted in the red box in the value window pane). Just below that is data that is encoded in base64. See Figure 36.
Figure 36. base64 encoded data in the value.Decoding the base64 data finds that it is protobuf data. Decoding the protobuf data yields some important information. See Figure 37.
Figure 37. This is important.There are three pieces of information that can be useful here. First, in the red box, is the Android ID of the device that located the Pixel 5a. Looking at the Google Takeout data for the account confirms this. See Figure 38.
Figure 38. From the Google Takeout data. Bingo!Based on this, an investigator would know that the Google Pixel Tablet was used to locate the Pixel 5a. Further, in Figure 37, the entry highlighted in the blue box is the name of the SSID the Pixel Tablet was connected to when it located the Pixel 5a, which was different from the SSID to which the Pixel 5a was connected. See Figure 39.
Figure 39. SSID for the Pixel Tablet.And the last piece of important information in the decoded base64 blob is the time at which the Pixel Tablet located the Pixel 5a. See Figure 40.
Figure 40. The time of locating.This information could be extremely useful to investigators who are investigating an incident involving intimate partner violence, or some other incident where the victim and suspect are sharing a Google account. I will note that I did not observe this data on the victim phone every time I located it, but I observed it frequently enough that I am mentioning it here. So, just keep in mind that just because you do not see this specific data, does not mean the phone was not located.
What About iOS?
As of version 17.5, iOS and iPadOS devices have the ability to detect unwanted FMD trackers. An example of a notification about an unwanted FMD tracker was seen in Figure 24, which was the iPhone 14 Pro. Figure 41 shows a notification from the iPhone 14.
Figure 41. FMD tracker notification on the iPhone 14.Much of our community’s knowledge about unwanted AirTags on iOS applies to unwanted FMD trackers on iOS. 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.
So, the AirTag developer profile approach is impractical. However, for testing, I installed the profile on the iPhone 14 just to see what was potentially available and then generated a set of sysdiagnose logs. See Figure 42.
Figure 42. The unwanted FMD tracker notification from the Unified Logs.Working from the time the notification appeared on the phone (the anchor point), I found the log entry that showed the notification being delivered. A few things to note here. First, the Process name that handled the notification, and much of the FMD detections, is searchpartyd. Unified Logs can be extremely noisy, so filtering by this process name can help filter out some of the irrelevant data. Second, just like AirTags, FMD trackers also have a code name, although not specifically assigned to them. Third-party devices and FMD trackers have the code name “hawkeye” so searching by that name could also be done, but it could also include some (or a lot of) data that may not be specifically due to FMD trackers. Lastly, the message window at the bottom of the macOS Console contains some really good data. See Figure 43.
Figure 43. Message payload from the notification in Unified Logs.The message window contained three things that are noteworthy. First, highlighted in the blue box, is the metadata about the FMD tracker. Specifically, I can see that it is a Pebblebee Clip, I can the product identifier, and the UUID that was assigned to the FMD tracker by the iPhone. Second, in the green box, is the timestamp that is indicative of when the notification was triggered, which coincided with when the notification appeared on the screen. Third, highlighted in the red box, is the date & time, latitude, longitude, and horizontal accuracy for when the iPhone saw the FMD tracker. The orange box in Figure 43 also coincides with the “First seen” timestamp that is shown to the user when they click on an unwanted tracker notification. See Figure 44.
Figure 44. First seen time.The times match. Just to reiterate, the data seen in Figures 42 and 43 is coming from the Unified Logs after the AirTag developer profile has been installed on the device. Most users are not knowledgeable enough to know what a developer profile is, much less install one. Plus, with the limitations of the profile itself, it makes getting information about unwanted FMD trackers in this fashion impractical.
There is good news, however. While prepping for the SANS Summit presentation, I discovered that unwanted FMD tracker information is stored on-disk in iOS. It is encrypted, but I was able to determine how to decrypt it. This discovery opened up a new research project as it has other implications for examiners. Thus, a new blog post will be coming based on this discovery; however, the research is not completed, so that information will not be disclosed in this post. That aside, see Figure 45.
Figure 45. There be information here.Once the data is decrypted, it is found in a binary plist file. Using the same color-coding as Figure 43, the plist contained the trigger date/time (green box), the first seen time (orange box), and the location information (red box – latitude, longitude, horiztontal accuracy, and associated timestamps). The end of the file contains the metadata about the FMD tracker, which is highlighted in the blue box below in Figure 46.
Figure 46. Tracker metadata.One thing I did observe when comparing the plist file to the Unified Log entry is that it plist file contained more location data than the log entry. Again, research is on-going with these files and other files that are affected.
Finally
I have not written a post this long in quite some time. However, there is a lot to address when it comes to FMD trackers, and the potential for misuse is high. Investigators and examiners need to be prepared for the likelihood that they will, at some point, have to conduct an exam/investigate an incident involving the FMD network.
I am certain there will be more discoveries about FMD tracker and the FMD network capabilities in the future, but hopefully the information discussed here is a good starting point to help examiners and investigators understand what this network can do and what information can be recovered from devices that own FMD trackers, have been followed by unwanted FMD trackers, or have been located via the FMD network.
Article Link: Not All Androids Who Wonder Are Lost. A Look At Android’s Find My Device Network – The Binary Hick