Special thanks Jared Barnhart for his help with the AirGuard research.
Last month I released an Android 12 public image, and if you looked, you would have seen an app that was added at the very end of the data generation period. Tracker Detect is an app that was released by Apple in early December to address privacy and safety concerns surrounding AirTags and Android users. General concerns about potential misuse of AirTags were raised shortly after they were released in April of 2021.
Well, it did not take too long but, as always, people have found a way to abuse technology. Last month there were reports in various news outlets about AirTags and how they were being used for malicious purposes such as stalking and automobile theft. As I was writing this article there was also a report of a Sports Illustrated model finding a random AirTag. All of this is not surprising because people have been abusing electronic tracking devices for a while. Using small Bluetooth devices for tracking also isn’t new. Tile has been producing Bluetooth trackers since 2012, and even has a limited crowdsourcing network. What makes AirTags unique in this arena, though, is the size of Apple’s crowdsourcing network. Millions of iPhones on Apple’s FindMy network can be used to track an AirTag, so a user who lost one has a much better chance of finding it than a Tile user has of finding their lost Tile. This also means a person who is using an AirTag with ill intent has a better chance of achieving their objective (stealing a car or stalking a victim).
Privacy & Safety
Apple introduced AirTags in April of 2021. Immediately following their release there was recognition of their potential for misuse. So, in June, Apple added a feature to iOS that would notify users if an AirTag had been traveling with a person (not the owner) anywhere between 8 and 24 hours while not in range of the AirTag owner; this time frame was significantly lower than the original three (3) days…
…but this was on iOS. At the time, there was no such mechanism to alert Android users. When this new iOS feature was released, Apple also mentioned they were developing an app to help Android users detect unwanted AirTags but did not describe what that would look like or how it would work. I decided to take a forensic look at Tracker Detect (Apple’s Android app), and Jared and I both looked at another Android app, AirGuard, which was released by the Technical University of Darmstadt in Germany. AirGuard arrived in the Google Play Store in September, and Tracker Detect in December. I decided to take a look at both apps to see if there was any data that would be forensically valuable. If you are interested in the iOS side of things, I recommend checking out the latest I Beg To DFIR episode.
For testing I used the trusty Pixel 3 running the October 2021 patch of Android 12, and two AirTags. This is the last run for the Pixel 3 since it can’t be updated beyond the October patch, so I thought this would be a nice way for it to ride off into the sunset.
(Basic) Tracker Detect
Apple’s app, Tracker Detect, is a bare-bones application. A user can download it from the Google Play Store, accept the terms of service, and then manually scan for any AirTags that may be near by. In order for Tracker Detect to find an AirTag the tag must be out of range of its owner. This means it can’t be near any iPhone, iPad on which the owner is signed in; if Bluetooth is turned off on these devices it counts as being “out of range.” Figure 1 shows the main screen of the app, and Figure 2 shows results after a tag has been found after a scan.
One thing to note here: Tracker Detect does not currently have any automated/background scanning capabilities. It is up to the user to manually initiate a scan each time they want to know if there are any AirTags in the vicinity. In other words, a user of the app will not get any notifications from Tracker Detect about found AirTags. From a victim standpoint this seems a bit counterintuitive but maybe Apple will update the app in the future to include this functionality.
If Tracker Detect does locate an AirTag, the user has two options. The first option is a user can cause the AirTag to emit a noise; however, they must wait at least 10 minutes after the AirTag has been located. I suspect this is a feature to keep the user from pinging AirTags that may be transient to their location. The second option is to learn more about the AirTag. Figure 3 shows both options, and opting to learn morre about the AirTag shows the screen in Figure 4.
The tag can be scanned with any NFC-capable phone. Scanning the AirTag opened Chrome on the Pixel 3, which is seen in Figure 5.
The information is…thin; the user does not get any information about who the AirTag may belong to. All that is available is the serial number of the AirTag and the last four digits of the phone number of the owner. An interesting thing about the URL that is opened, though, is that it is not unique to the AirTag. More on this later.
Tracker Detect is very basic in usage. As it turns out, its forensics are more so. There was literally one (1) file in the /data/data/com.apple.tracker directory path and it is a file of interest. The file com.apple.trackerdetect_preferences.xml resides in the shared_prefs folder. The file name is a bit misleading. See Figure 6.
The file contains a value indicating whether or not the terms of service had been agreed to, but it also keeps track of MAC addresses of seen AirTags and times those MAC addresses are first seen. The numerical value in each tag (red box) is the number of milliseconds since the the phone last booted. I was unable to locate any additional information about these MAC addresses (part of the XML tag – blue box). The lack of context about them (e.g. the location where they were first seen) makes it virtually impossible to link them to anyone or anything other than the phone being examined, and a no indication as to where the AirTag was first seen by the phone.
But wait, it gets worse. com.apple.trackerdetect_preferences.xml is volatile; it will reset when a phone reboots. Figure 7 shows the file after I rebooted the phone.
The XML tags with MAC addresses and associated numerical values which were seen in Figure 6 are now gone. From an examiner’s standpoint, this is not great news. Some of the extraction methods used by examiners do require a device reboot, which would reset this file and cause a loss of what little evidence is available.
Revisiting Figure 6, four distinct MAC addresses can be seen. During my testing, I only found the two AirTags that I had set up. What I discovered is that the AirTags generated new random MAC addresses periodically. While I was generating test data I observed new MAC addresses being generated anywhere between 4 and 20 hours, which is a huge window of time. I believe one of the things that may trigger a new random MAC address is a lack of movement by the AirTag, but that is just based on my observations. I observed more frequent new random MAC addresses during the night time hours while I was sleeping but less during the day while I was moving around. More testing would need to be done in order to confirm or disprove this.
Long story short: one AirTag may be represented by several different MAC addresses.
Keep the randomized MAC addresses in mind because they will appear again.
AirGuard
AirGuard has a bit more data, and it is not volatile, which is good. What’s bad is that there hasn’t been as much media attention given to it, so I suspect it will not be seen as much in the wild. Figure 8 shows the main dashboard of the app.
While AirGuard does offer the ability to manually scan for AirTags, what sets it apart from Tracker Detect is its ability to scan for tags in the background. In Android 12 (an 11) there is a need to modify some of the Permissions and Battery settings for the app, though. First, AiGuard needs access to Location Services all the time (not just while the app is being used). Second, the battery settings for the app need to be modified from “Optimized” to “Unrestricted.” Leaving it at Optimized will cause the app to not operate properly in the background, which will affect its ability to scan for AirTags automatically. I found that these settings were not automatically set during setup.
When an AirTag is found the graph and top number seen in Figure 8 will change. A user can then go to the Devices screen to see how many AirTags have been found. If multiple AirTags are found, they will all be listed. See Figure 9.
Choosing one of the devices on the list will take a user to a screen such as that seen in Figure 10. Here, a user can see the location at which the AirTag was last seen, first and last seen times (red box), and the AirTag Bluetooth MAC address (blue box).
If a user presses on the area in the red box in Figure 10, they are presented with the screen seen in Figure 11. In this screen, the map is again displayed with all of the locations where the AirTag has been seen, along with the ability to have the AirTag to play a sound (button not pictured) in order to locate it. The user can also choose to identify the tag as a known AirTag. See Figure 11.
If a user wants to know every location at which any AirTag has been seen they can press on the Locations button on the dashboard (see Figure 8).
If an AirTag has been seen by the phone for a while AirGuard will generate a notification. Figure 12 shows a notification.
AirGuard, from a user’s standpoint, is simple but not as basic as Tracker Detect. AirGuard also keeps a bit more data, and the forensics show it. The main database of importance is att_db which is located in /data/data/de.see moo.at_tracking_detection.release/databases directory path. There are two tables of interest. The first is device. See Figure 13.
This table tracks all of the AirTags seen by the phone. They are tracked by Bluetooth MAC address. The user has the option to apply a custom name to a seen AirTag, which can also be seen in Figure 13 (column “name”). Also tracked is the first seen time (red box), last time seen (blue box), an indication if a user was provided a notification (green box), and, if a notification was sent, the last time that happened (purple box). Note that all times stored in this database are stored in local time.
The other table of interest in this database is beacon. See Figure 14.
In this table are times (again, in local time) an AirTag was seen (purple box), the signal strength at the time it was seen (green box), the Bluetooth MAC address (red box), and a set of GPS coordinates (blue box) that show where the AirTag was at the time it was seen. Note that the latitude and longitude columns are backwards – latitude values are stored in the longitude column, and longitude values are stored latitude column. An examiner could sort this table by time and get GPS coordinates for where the phone first saw a specific AirTag or any AirTag.
As previously mentioned, the two test AirTags were observed rotating randomized MAC addresses, so while the table in Figures 13 and 14 seems to be a lot, just know that they represent just two tags. Again, examiners should be aware that a single AirTag can be represented by multiple MAC addresses in this database. One thing I also noted during testing is that some of FindMy devices also appeared.
A quick SQL query can pull all of this data together:
SELECT
beacon.deviceAddress AS “Device MAC Address”,
beacon.receivedAt AS “Time (Local)”,
beacon.longitude AS “Latitude”,
beacon.latitude as “Longitude”,
beacon.rssi AS “Signal Strength (RSSI)”,
beacon.firstDiscovery AS “First Time Device Seen”,
beacon.lastSeen AS “Last Time Device Seen”,
device.lastNotificationSent as “Last Time User Notified”
FROM
beacon
LEFT JOIN device on device.address=beacon.deviceAddress
The query compensates for the reversed lat/long values, and puts the values in the correct columns.
There is an additional database, cache, which may be of interest. It is located in in the /de.see moo.at_tracking_detection.release/files/osmdroid/tiles directory path. The table tiles contains PNG files, in the form of BLOBs, of the map tiles used to display map data to the user (e.g. Figure 10). The timestamps seen in the expires column (red box – Figure 15) do not seem be consistent enough to rely on, so any timestamps should be pulled from att_db.
Don’t Forget Web History
AirTags can be scanned with any NFC-capable device, which will open a web page displaying information about the scanned tag. This may benefit examiners. For example, if a stalking victim is fortunate enough to find the suspect AirTag and scans it, the URL is kept in the web history. Figure 16 shows the Chrome history from my Pixel 3.
The URLs remain active, which is especially helpful if a user was using Tracker Detect and the phone had rebooted. I was able to take the URLs from Chrome on the Pixel and plug them into Safari on my Mac, and was brought to the same page. While the URLs contained information on the same AirTag, they were different. Specifically, the portion at the end (pi=RANDOM_STRING). I ran Ryan Benson’s unfurl tool against the URL, but did not get anything substantive.
Wrapping Up
As usual, Apple has taken an existing concept, identifying the location of things using Bluetooth trackers, and implemented it on a whole new level. AirTags are a great piece of technology that has been, as happens from time to time, co-opted by people with malicious intentions. And while Apple has implemented several safeguards into iOS, they have, to some degree, neglected Android users. Fortunately for users, there is an alternative app that works a bit better. Regardless, it is important for examiners and investigators to understand what forensic evidence is available to them on the Android platform, and the nuisances that go along with it.
As usual, Alexis Brignoni has updated ALEAPP to parse Tracker Detect and AirGuard. Make sure you grab the latest copy from his GitHub.
2 thoughts on “Androids & AirTags. Oof.”