Wednesday, 13 April 2022

[Air]Tag You're It!

 This is the accompanying blogpost to the Magnet User Summit 2022 talk: [Air]Tag You're It!

Bluetooth Low Energy and You

First, a primer on Bluetooth based tracking. Bluetooth Low Energy (BLE) is often used with bluetooth beacons in order to transmit location from a beacon back to a smartphone. These devices are often just a 1 way transfer, sending data back to smartphones, not reading data from them. Typically, these beacons are used by specific applications, so only that given application can track the user. These beacons can serve multiple functions, such as alerting you that you're near an Apple Store so you can make an appointment. Others might be used in museums to give you more information about an exhibit as you approach it. There are different types of BLE beacons, including Apple's own "iBeacon" used in retail stores and other locations worldwide. For more info on BLE, please refer to  this article. 

While beacons can have a number of varied purposes, one of their most common is that they're used as trackers for lost items. Similar to other devices such as the Tile, Chipolo, or TrackR devices, these beacons can help you locate lost items such as keys. iBeacons work by broadcasting a UUID (universally unique identifier) that can only be understood by using an online source to translate this back to a separate identifier. Apple uses this system to help maintain user privacy. 

Capitalizing on this function of BLE, Apple released the AirTag devices April of 2021. These devices are similar to other BLE tracker devices, however, feature several more unique features. Most device trackers like Tile, for example, require a device to have the Tile application in order to broadcast back to these devices and alert the user where they are located. Apple's AirTags instead utilize the FindMy service and BLE so that they can communicate to virtually any smartphone in the world without the need of an application. This gives Apple a much wider mesh network for those that use the AirTags worldwide. 

AirTags also utilize Apple's U1 chip to perform ultra-wideband broadcasts. These are high speed broadcasts that are designed to send a lot of data very quickly. The UWB (ultra-wideband) technology isn't extremely new, but has been used by Apple in mobile devices and AirTags since 2019. The UWB technology is used for precise item location for the AirTags which allow you to see which direction your AirTag is from you and how far away the device is. 

 Apple's AirTags use the FindMy service so that any devices that come within range of an AirTag will broadcast back to Apple where that beacon was seen. While this is great from a usability perspective, what happens when someone uses one of these for a more nefarious purpose? What if a user slips an AirTag (normally $29USD) into someone else's property and uses it to track them? This principle isn't new, and I have personally worked multiple cases where bluetooth tracking devices were used to stalk an individual. With Apple having a much larger network of devices than some of its other tracker counterparts and the user not needing an application to report locations, how is Apple keeping people safe from this unauthorized tracking? 

The short answer, is that they're trying, but not doing the best job in the world. But more on that in a minute. 

First, let's explore AirTags from a physical perspective. The devices are roughly the same size in diameter as a lid from my favorite drink of choice, Diet Coke. They feature a metal cover embossed with the Apple logo on one side and white plastic on the other. Underneath the metal cover is a CR2032 battery which powers the device which Apple states should have "more than a year" of life. Under the battery there is also some identifying information of the AirTag including the device's Serial Number. This is where the teardown ends unless you choose to get destructive. Below the cover, though, is a layered donut-shaped board. 

Two sides of the AirTag board and its multi-purposes antenna.

(Image credit

The chips include Apple's U1 ultra-wideband chip, a Nordic Semiconductor BLE/NFC Controller, and a NOR storage chip boasting a whopping 32Mb of storage space.

Pairing and Using AirTags

To use AirTags, Apple requires the user to have an Apple ID. The Apple ID is used so Apple can take the broadcasted information and report it back to a specific user. Once the small plastic tab is removed from the AirTag, which separates the battery and its connectors, all users have to do is bring it near their iOS device. Once there, a prompt will allow the user to start the connection and pairing process. Users can also set a custom emoji and name in addition to a set of pre-created names to help identify their devices. Setting the device's type is important because it can allow Siri to locate your device, especially if you're like me, and ask her to "Find my Keys" about 5 times a day. 

During the pairing process, information, including a key pair, is exchanged with the AirTag and stored on the iOS device; it gets shared via CloudKit to other devices on the Apple ID, including shared family members. You cannot "share" an AirTag, but the identifiers do get shared automatically with other family share members. Several services track the use of AirTags within Apple's Unified Logs, including: 


  • locationd
  • FindMy
  • searchpartyd

The process "searchpartyd" seems to be the most commonly used when discussing information found within the Unified Logs for AirTag devices. Once the device is paired, data such as the serial number, the provided UUID, key storage location, pairing date, and custom name can be found in the logs. 

Note that the word "durian" gets used in the above screenshots. This is because durian is the device codename given to AirTags. Using that value will help you identify records relating to AirTags in the Unified Logs; however, Apple highly privatizes this information. To actually see the UUID values listed above in a sysdiagnose capture, users must first install the AirTag mobile configuration profile. The following example is from a capture of the logs using a sysdiagnose capture method without the profile being installed: 

The data including the UUID of what devices were seen are redacted by Apple with the <private> tag. Without the isWild and UUID, users won't be able to see if these are owned devices.

Playing Sounds and Locating Devices: 

When the user presses the "Play Sound" function as seen above, it triggers several events in the unified logs showing which device (by UUID) that the sound is being played on and if it has been connected. 

When the user tries to locate the device, because of the UWB connection, a large number of logs will be generated while the proximity location is being triggered. 

The UUID of the device being searched in the file system shows that the path /private/var/mobile/Library/ will store the key pair values and records for the detected broadcasting devices. Within the OwnedBeacons folder here, there are several UUIDs listed for the AirTags as well as other devices including iOS and macOS devices. 

Unfortunately, the UUIDs of the suspect or unauthorized AirTags won't always be here. While some "wild" device observations do get stored, there is a bigger problem here for forensics and tracking when a device was first seen. 

"Protecting" Users with Randomization

As seen above, when an owned AirTag is broadcasting with a device either owned by that same user or one in their family share plan, it will use the UUID value. This value seems to stay static in these situations. However, if the AirTag is not already trusted with that device, the broadcast UUID is actually randomized. While this would be okay if it at least remained static, the UUID actually randomizes and changes multiple times each day. I saw an AirTag change its broadcast UUID to unauthorized devices numerous times each day in my testing. 


While that is happening in the internal logs of the device, what is happening that the user can see? Once an unauthorized AirTag (or compatible FindMy accessory) has been seen traveling with the iOS/macOS device owner for a period of time, a graphical alert will display on that device. As of iOS 15.4, Apple changed this icon from the standard FindMy alert icon to a unique icon showing the difference between a device that has been left behind and an unauthorized device. 

Once the alert is clicked on (which is classified as a "Time Sensitive" notification and MAY override certain Focus settings), it will open the FindMy app so that the user can see information including where the device has been seen with them as well as when it was "first" seen. This information, however, may not be completely accurate. 

From my testing, the window of time is a big concern. Apple states in their limited documentation that the alert will trigger after the device has been seen with a user at a random time between "8 and 24 hours." Later versions of iOS 15 seemed to shorten this window, but Apple has not provided any official documentation on the how, when, or why this happens. From my testing I received a range of time between 1 hour and 8 hours. Apple also seems to trigger these when you reach locations they have deemed as "Significant Locations" but it also may alert at other times as well. The above screenshot is an example of one such test where the device is "first" seen with me at 0500 (even though I had it a long time before that) and it shows me traveling down the road, flying to Atlanta, and finally arriving in the Washington D.C. area. However note that the time on the phone is 1307. This was opened only minutes after I received the notification meaning that Apple took eight hours to alert me this AirTag had been traveling with me! The other issue is that Apple will alert only when the user's trusted devices are not seen near that AirTag so close range tracking may not alert as frequently. 

What happens on the phone though when you trigger one of these "Play Sound" functions on the unauthorized devices? 

Like before, you can see a UUID showing up and that the device is "unauthorized." Unfortunately, this UUID will NOT match what the owner of the AirTag would see (nor would it be stored on the device the same way). 


Once the device has been located, all the user can do is get an NFC broadcast from the AirTag, which will open a page in the default browser. This page from will then display the listed serial number of this device. 

Problems with Randomization

The other problem with Randomization is that currently it seems that iOS/macOS devices don't have a way to reconcile requests once the UUID is rotated. This means that if the user does not press on the notification or views the record to find the AirTag, they might be unable to find it until ANOTHER alert is generated. This is especially problematic as all you can do with a detected unauthorized device is play a sound as precision location finding is not allowed. [Note: Apple has said they are looking to enable louder chimes and precision location finding of unauthorized devices in a later iOS release but as of the writing of this post it was not available.]

The above screenshot shows 3 "Unknown AirTags" but it's actually the same device which has alerted 3 different times because of the UUID rotation. 

How can we identify the owner with no stored artifacts on our victim device, directly tying unauthorized AirTags to the owner, and the UUID being rotated? Unfortunately, we can't do it alone. We'll need Apple's help with that. Because the records are passing back information to Apple's servers, Apple will be able to show who the owner of the AirTag is as long as it's been registered to an AppleID (which it should have been during the setup process for tracking). Apple's own Law Enforcement Guidelines state they can provide AirTag pairing history for up to 25 days with a "subpoena or greater legal process." It is unknown if Apple has a way to show how long an unauthorized device has been detected by a victim's device. Their own guidelines state, "Location services information for a device located through the Find My feature is customer-facing. Apple does not have content of maps or alerts transmitted through the service." They also state that they cannot view the location of any AirTag. 

In a traditional Apple Warrant Return, you will also see the serial number of purchased AirTags under the "APPLE_CONFIDENTIAL.xls" spreadsheet. 

Unfortunately while we can't track the owner or when it was potentially placed, there is a good bit of information we can track if we have the owner of the AirTag's devices. 

Stored AirTag (and Other) Aritfacts

Since AirTags are tracked and viewed through the FindMy application, that's where we'll look. By searching for the UUIDs within the previously mentioned OwnedBeacons folder, several hits (as well as hits for the unique names and serial numbers) were found within a .data file in the path: /private/var/Library/mobile/Caches/ Within this path there are several .data files (which are really just JSON files) called: 
  • FamilyMembers
  • SafeLocations
  • Items
  • Owner
  • ItemGroups
  • Devices

The file is fairly self explanatory. It holds the Apple ID of the owner who is signed in to the Find My service on the device. 

The file stores information about other Apple IDs that are tied to the owner via Apple's Family Share features. 

The file stores information about what are considered "Safe Locations" for not alerting when FindMy supported devices are left behind. These Safe Locations do NOT have to be locations that the user has ever visited. The locations can be listed in this file as "suggested" locations to the user as well as locations actually set by the user. 

Within the file itself, a "Type" value will reflect a 0 or a 1. A 0 is simply a suggested location that the user MAY have visited, while the 1 is a SET location by the user. 

The file will store the listed AirTag device as well as some other Find My accessories. Third-party accessories may be divided between both the and files. The JSON file will store for each device: 

  • Names
  • Serial Number
  • Custom Emoji
  • Last Detected Location
  • Last Crowd Sourced Location

The Devices.items file stores similar information to the file however it tracks other stored iOS and macOS devices that have been tied to the user's Apple ID. While the device's serial number or UDID will not be readily available, other information for both iOS and macOS devices are tracked here including: 
  • Model Numbers
  • Names
  • Address last seen
  • Other status data
Some of this other status data will even track information such as if a wipe attempt is pending or if it is in lost mode. Information about the passcode length may be available in here as well. 

It is also possible to track this information on a macOS device. This information is stored in the same format as above but can be found in the directory ~/Library/Caches/ 


AirTags and Apple's use of Bluetooth tracking beacons certainly aren't going anywhere. There have already been many cases where people are trying to use AirTags to stalk or follow someone else and to be honest, Apple still has some work to do to protect users. While the artifacts are great once you have a suspect device, the UUID randomization can be problematic if you only have the victim's device. While Apple does allow for information to show us the paired records between Serial Numbers and Apple IDs, it will require some legal process which is not always an option. 


On the other side, once you have located a rogue AirTag, you can match it via Serial Number within the owner's macOS or iOS device. Other artifacts such as KnowledgeC or PowerLog may also show you when the Find My application was used to view this tracker (although not precisely the rogue tracker, just the service in general). The .data files can be beneficial since they store the name of the device, saved emoji, and the serial number. If the AirTag has been called something specific such as "Lisa's Car" it could potentially help to support your case. 


While the transition to the new notification icon for rogue devices in 15.4 is helpful, I believe Apple still has a way to go to protect people from planted rogue devices. Just playing the sound is not enough, and precision location finding would be helpful, but Apple has still yet to implement that function. This would also require UWB equipped devices such as an iPhone 11 or higher, meaning not all devices will be able to locate it. There's also the Android problem. While Apple has released an application to allow you to sweep for AirTags, it's still a manual process, and just because one is detected doesn't mean it hasn't been with you for a long time. Apple's documentation also needs work on the when, how, and why they choose to alert users that unknown devices are with them. 


As Apple continues to evolve the safety mechanisms of this technology, I know I'll keep my eye on these little AirTags. That being said, I'm a HUGE fan of them myself, and I do appreciate Apple's work to keep others from using my broadcasted UUID to track my movements. Until next time, Tag! You're it!a

Friday, 18 June 2021

Android - Tracking Device Migration

 In this multi-part series of blogs on tracking device migration, we're going to take a look at some of the core artifacts one might be able to track on Android devices. Android devices will likely not have local backups restored from computers like iOS, however, device-to-device and Gdrive/Cloud backups will allow users to transition data from one device to another. This doesn't just include Android to Android but can include iOS to Android too!

While multiple Android device manufacturers have created their own switch over applications like Samsung's Smart Switch, Android has its own. Android users can restore information from Google Drive down to their device or by hooking up a cable and backing up the data device-to-device. There are several relevant artifacts that get left behind. Unfortunately, most of these artifacts will require a file system level image. Some of the information will be left in the /media/0 directory which can help provide some context at least, and available in quick style images. 

In the case of a standard Android device migration, users should locate the folder /data/data/ Within this folder there will be several relevant .xml files. 

The DeviceOrigin.xml file will list out where the original source data came from. In the case of both iOS an Android devices, this information will be here and will reflect the manufacturer and model. 

If the DeviceOrigin.xml file doesn't list out a device, it could be a cloud backup from GDrive in play. Within the same directory, a file SetupWizardCredentialProtectedPrefs.xml, will list out what Google Account was backed up. This file may exist if the device was a device-to-device or a cloud backup, but only if the account was passed over. 

The Phenotype.xml file in this directory can also contain the google account used and passed over. This information may also be available with the accounts_de.db or accounts_ce.db database files responsible for storing the accounts saved to the android device. 

Data gets moved over fairly seamlessly in Android device-to-device or GDrive backups in the case of the /media/0 (emulated SD) area. However, in iOS device-to-device to Android, the data gets stored in a folder called "Restored from iPhone." 

Android devices may also have their own migration packages. Since our target device in this case was a Pixel there is a package that can reveal some additional information. 

Within the data/data/ directory another shared_prefs directory has some interesting files. 

In the case of iOS to Android, users can find a file called ios_preferences.xml which will list out the UDID of the original source iOS device as well as a created date/time which can help show when the migration took place. 

In the case of Android to Android, users won't find a file here unforunately. But in the case of device-to-device (and cloud restores) a xml file called can help show what was transferred from the source device. 

For the cloud restores from GDrive, a file called cloudrestore.component.CloudRestoreFlowActivity.xml will be in this directory. An Android_ID value within this file can be used as a keyword search against a target device to see if this was the original source device. It also contains a "restore_started" value which will reflect that the cloud backup was started. 

Unlike the iOS counterpart (which can be found at this link), it's not quite as descriptive or readily available. Still the information can be beneficial when tracking the movement of data across devices. 

Wednesday, 16 June 2021

iOS - Tracking Device Migration

Sometimes I get the privilege of helping someone with a case and it really puts me down a rabbit hole of research. This is that situation. A brief overview: I get contacted for assistance in tracking device migration because a "bad file" (let's leave it at that) is found on a phone. However, the phone it's found on doesn't match the EXIF data of the file. Now, the argument is that the file was "planted" on the target device without the user's knowledge and that it didn't originate from the user. While this is harder to prove, one of the things I was asked was how to determine if the device was restored from another source. 

While the plist file "" has been around a while and had some good information, it's also been a bit limited. So let's dig a little deeper and see what else we can find. 

Within iOS, there's a great plist file that can help talk about device backups. This is the "data_ark.plist" that can be found within a file system image of an iOS device at the path /private/var/root/Library/Lockdown. 

This file has several important keys.

[0] - FirstPurpleBuddyCompletion - This is a Unix millisecond epoch value which can help show the first time the "Purple Buddy" or Apple's setup assistant was completed. The main PurpleBuddy plist (anyone else always think of "bonzai buddy" when they hear purple buddy?) has its own timestamp value but other things can update it including system updates between certain iOS versions. 

[4] - 
[5] -

This will show information about how the device was setup and/or restored. It will contain information relating to one of (at least) three values. 

RestoredFromDevice - A Device-To-Device setup
RestoredFromiTunesBackup - Pushing a device backup from iTunes
RestoredFromiCloudBackup - Pushing a device backup from iCloud

This file can also show the computer name of where an iTunes backup has been stored from a target device. This makes tracking both source and target devices easier. 

I'm one for additional validation. Also, I've found that the data_ark.plist hasn't always been so forthcoming on information. If we navigate over to private/var/mobile/Library/Preferences and locate the file we can find some additional information. 

The key "SetupState" will show one of two values: 

SetupUsingAssistant - This is the same for device to device and local backup to device. 
RestoredFromCloudBackup - When restored from an iCloud backup. 

The "SetupLastExit" key can also help to show when Purple Buddy was exited and can be compared to the value in data_ark.plist if available. 

In this same directory (private/var/mobile/Library/Preferences) there is another very informative plist file called 

This plist file has some awesome data for tracking migration!

By reviewing the above records, it's possible to see how the device backup was restored either from device-to-device, iTunes backup, or iCloud backup! It will also list out the build version of the software it was restored FROM which can help show a pattern of upgrades/restores. The RestoredBackupProductType key also gives the model ID of the source device. 

A word of warning about the "BackupDeviceUUID" value. I'm still trying to track where this value comes from but it's not the UDID in all cases that we have come to know. It would make a great keyword value on a target device though!

The Reason key is also incredibly informative and maybe my favorite. This value will show the TARGET device's UDID (which we likely already know because it's the device we're analyzing) but does show the date and time of the restore! Woo!

Now in the case of any of these backup restorations, who is going to have data on what devices are part of the Apple account? Hint, they're a fruit company and I'm not talking about Banana Republic. Obviously it's Apple.

There are several values that you can use to send off to Apple to find out some more information if you have search warrant or subpoena powers. Within the database Accounts3.sqlite (found within /private/var/mobile/Library/Accounts), a key referencing the "appleid-authentication" type will reveal the email address of the Apple ID. However, users can change their Apple ID email address over time. There's actually a better value. 

The DSID or Directory Services Identifier is the numerical backing to the Apple ID used by Apple to track the account. This value can be found in a variety of places depending on which iCloud services are being utilized by the user. One of the easiest places to find this is within the plist files or If you don't have access to these legal routes, getting access to a user's "Download Your Data" results from Apple can also have most of this same information to track devices users have migrated between. 

That is going to wrap up the part of this multi-part series. For the first part, please see this link on device migration artifacts form iOS to a Samsung device. Up next will be tracking device migration on generic Android. 

Friday, 28 May 2021

iOS / macOS - Tracking Downloads from Safari Without Downloads

This week I got some huge news! This blog was nominated for a 4:cast award for Blog of the Year! I'm incredibly honored for this nomination! It also spurred me to remember I had a bunch of posts I wanted to work on but the last few weeks have been packed with teaching and work. Today I'm going to talk about a methodology for how to track files that have been downloaded from the Safari browser on iOS or macOS. 

Safari is an interesting beast when it comes to its storage. Apple lauds the browser as "Safe and Secure" and this default browser on the macOS and iOS ecosystem can cause examiners some headaches due to how long it chooses to keep its data. For more information on preferences for macOS and how this is controlled, see this post I did previously,

While the methods to track data in macOS and iOS are similar, there will be a slight difference depending on what you're working with and looking for. Let's start with macOS. 


First things first. macOS will only keep Safari downloads for 24 hours by default. This is obviously problematic. In addition, it only tracks the last 20 files so if your user has downloaded more than 20 in the last 24 hours, again, harder to track. The Downloads.plist file found within the path: ~/Library/Safari/ will store this information. 

When a file is downloaded in Private Browsing mode, the Downloads.plist is still used, but stores a value within it called "DownloadEntryRemoveWhenDoneKey" which will be flagged as True. This means that files that are downloaded will immediately be cleared even if within the last 24 hours. 

Again by default (set within the Safari preferences), the downloads will land in the ~/Downloads/ directory. So looking here is a good place to start. However, before we just jump here, we might want to also consider what happens to a file when it's downloaded. Essentially, downloading a file on macOS/iOS works like this: 

1. Container is created. Container is named the name of the downloaded file with ".download" at the end of it. Container will live in the directory where the file is supposed to be downloaded.
2. Info.plist file created within the container containing matching information from the Downloads.plist file. 
3. File data streamed into the ".download" container. 
4. Upon completion, data moved from .download container (folder) into appropriate directory. 
5. macOS's GateKeeper will quarantine the file and scan it creating an entry in the quarantine database. 

Based upon the above logic, there are a couple of things we can now start looking for. 

Quarantine Data

Using the "" database found within ~/Library/Preferences, information can be tracked to find what files landed on the system that were scanned by GateKeeper. Examiners should look for the package name containing "" because depending on HOW the file was downloaded the data under application name may reference either "Safari" or others including "" The information can store the original download URL as well as the displayed URL and when it was "Quarantined" which will be extremely close to the finished date of the download. 

To be honest, this can be hit or miss. I find that if a user is actively opening files they download it may get cleared from the Quarantined events, but not always. It does, however, last longer than the standard 24 hours of the Downloads.plist file in many cases. 

A note about files downloaded in Private Browsing mode. Files downloaded within this mode will still be checked by GateKeeper, however, it will not store the download URL of the file. It will however still store its "Quarantined File Identifier" which is going to be important in tracking what file that was. 

File System Events

Since examiners now know the process of the file, we can actually use the File System Events tracked by both iOS and macOS to find out some information. It's handy when you have a starting date and time, so using an event like Quarantine Events to gather when a file was downloaded (even if you can't see what the file was or where it came from like in a private browsing record), you can use this as your launch point. 

Filtering your file system events from that start point, you may see files created in the same timeframe on the system, but remember, files are downloaded into a container that ends in .download. 

By reviewing these records, examiners can see how the file system events are tracking the flow of the downloaded file originally listed above. The "Important" folder is created, the .zip and .plist file created inside, then when complete, the .zip is moved out, and the .plist is destroyed as well as the .download container. [NOTE: These events can happen quickly in small files and creation/deletion may happen within the same recorded event]

Files that were not completed will have a similar structure but without the final removal events. 

These events can also help to show when a file was moved from the downloads directory to a new location. Now that we can track that a download occurred a couple of different ways, can we match up records in the Quarantine Events to the file that was downloaded? In some cases, yes!

Extended Attributes

macOS will record extended attributes to files downloaded. This will include in many cases what browser was used to download the file as well as in many cases the URL that the file was downloaded from. A Quarantine Event GUID is also embedded into the Extended Attributes metadata. Now this information can also be tracked with Spotlight Metadata as well, however, files that are downloaded in Private Browsing mode will not have that spotlight metadata. 

Let's compare two files from the downloads directory. The first was downloaded with Safari NOT in private browsing mode. Here's one from my local system where I downloaded the file with Safari without using private browsing mode. By looking at this, you can actually see the value kMDItemWhereFroms which lists where this file was downloaded from: "" 

The extended attributes of the same file can store this information as well. If the data is living in a directory where indexing is not done, this can still reveal the information. However, the information in the extended attributes can also store the quarantine information. While we may not be able to track where the information was downloaded from (not tracked in files downloaded from private browsing mode), we can use the quarantine information to help show it came from Safari and that it was private browsing. 

For a file that is downloaded within private browsing, spotlight metadata may not show as much. However, we can still track the information that shows that this file, "Important" was downloaded from the Safari browser and it has a GUID. This can be matched to the Quarantine Events artifact to see its match (if it is still there)!

macOS WrapUp: 

So to summarize, when tracking downloads, a good methodology is to check in the following locations: 

  • ~/Library/Safari/Downloads.plist
  • Check the Safari Preferences to see where the downloads are default going to. 
  • Use File System events looking for ".download" records to find data relating to files downloaded from Safari. 
  • Use quarantine events to find that files are downloaded using Safari
  • Use extended attributes metadata to look for the events with Safari.


Now iOS can be a slightly different beast. It still has some of the same functionality we can apply if we know where to look. When downloading files, the Downloads.plist file is still going to be used but users can't control as many preferences. The Downloads.plist file is going to be found within the Safari's app directory (not the Library/Safari directory as the browser history is). 

The same information is stored but note the Saved to Path. This is the default storage location that will send the data to the "iCloud Drive" area of iOS. Which, honestly, is interesting. It takes your download and then tries to send it back to its own cloud storage. 

Now these downloads are also not tracked forever. There is also not any way to have preferences to change how long these are going to be kept. 

File System Events:

In a similar manner to the macOS Safari downloads, when a file is downloaded in iOS/iPadOS, the file is stored within a .download container (folder). This folder is not contained within download target directory like in macOS, but is stored within a folder within the Downloads folder (that the plist lives in). 

This folder is named with a GUID which will match the "Download Identifier" in the Downloads.plist file. The data gets placed into a [Filename].[ext].download folder within a folder named the download GUID then moved to the final directory on successful download. 

No info.plist file here unfortunately. 

Files that are incomplete downloads will still live in this directory. Now the interesting thing is that a user can choose to store them within the iCloud Drive directory, but also can choose to store them on the "On My iPad" setting which puts them into a different directory. By looking at the file system events using the target filename, we can see where the file moved to. This time it didn't move to the Mobile Documents directory but to part of the data that tracks back to the iOS Files app. [For more info on the Files App, check out this post here]

The ID of this folder tracks pack to the "local storage" manager used by the Files app. which can be seen in the "" within the root of this storage container. 

iOS WrapUp: 

So as you can see there's not as MUCH to track through with the downloads from Safari but may also be less common to find. Even when you don't find any Downloads.plist entries, by checking both paths: 
  • /private/var/mobile/Library/Mobile Documents/com~apple~CloudDocs/Downloads
  • /private/var/mobile/Containers/Shared/AppGroup/B00E5705-4543-4123-9309-0F6D70BE27C6/File Provider Storage/Downloads

By then working backwards to confirm these were downloads, using File System Events may help to track that they started in the Safari/Downloads/ directory. 

Final Wrap-up: 

Whew! That was longer than I originally intended. Once again the big thing is that just because the "Downloads.plist" file is empty doesn't mean you can't track the data in other ways at times. Hopefully these methodologies of where to turn can be useful to anyone reading! Again, big thanks for anyone reading this who nominated me for a 4:cast award and if you feel it's deserved, I'd love to earn your vote again for the award itself! If you're so inclined you can go vote here:

Thursday, 4 March 2021

Android - Samsung Smart Switch // iOS Transfer Artifacts

 Recently I was trying to set up an Android device to run some testing on and I just happened to pick a Samsung this time around. I needed some sample data on it but I didn't have a lot of time to generate information. Luckily, Android has a way you can restore information from one device to another, even if that device isn't an Android. 

If you happen to be transferring over to a Google Pixel phone, Android will allow you to use the USB-C adapter to connect a USB-A to Lightning cable that has an iOS device running on the other side. I thought this was a pretty slick process and will likely be checking into it more in time to see what happens on the Pixel side. 

Since Samsung is one of the most popular device manufacturers it shouldn't surprise anyone that they are copying this functionality on their device line. In order to do this, Samsung has the user download the Samsung Smart Switch application which can also be found on the Google Play store. (Link) Samsung isn't alone on this, with OnePlus, LG, and 3rd party groups using this same functionality, but Samsung is the one we'll focus on today. 

After grabbing my iPhone test device I plugged it into the S20 I was testing out and followed the step by step process that the device had displayed on the screen. 

Samsung allowed me to select quite a bit of information including SMS/MMS, Contacts, Photos/Videos, and even Application data. So after this process, what is left behind by the Smart Switch application that could be relevant to our investigations? 

The application uses the bundleID of Looking for that in the file system, there weren't many databases that appeared there at first. Within the shared_prefs folder, there was a "smartswitch_prefs.xml" file that had some great information in it including: 

  • Source Device Type
  • Target Device Type
  • Google Account Sign-In

Within the "files" folder of the application directory, there was a LOT of interesting files left behind. First off there is a folder: data\data\\files\iosotgmanagerv2\
Within this folder, a Plist file can be found identifying the source device the data came from. This is the lockdown plist file that is used as part of the Trust Pairing process of iOS. 

There is a folder called SmartSwitch which also has some great data. An "iosApps.json" file will store information about iOS applications detected from the source device. 

A "requestedApps.json" is a JSON file keeping a log of the matching Android versions that will be requested from the Play Store as well as version. 

The "BrokenRestoreInfo" directory of my device had some additional interesting JSON files. The DevInfo.json file contained UDID information, model number, OS versions, Display Name, and what was asked to be backed up. 

The JobItems.JSON will let the examiner know what was able to be downloaded from the source device. 

A PHOTO folder will contain additional JSON files that contain metadata about recovered photographs from the source device. 

Another folder, SmartSwitchLog contains several log files about the transfer process. This folder also contains the most important piece of the application as well. In this source image, a DATA_0 folder was found containing the bulk of the transferred information. This folder contains a multitude of ZIP files that have the information backed up from the Source device. These files within the zips may be named in some cases the same SHA1-named structure as the files would be from within the original iOS device's iTunes-style backup. Several examples will be linked below: 

 BACKUP DATA: --> Contains the Manifest.db for the iTunes-style backup which will give you a listing of every file included in a backup on the source device as well as helping to decipher the SHA1 names in the recovered files. 

ALARMS: --> Contains the file cc723e4537a6d5120fb720dda7dd18b10f3f4a97 which is the Library/Preferences/ from the iOS device. --> Converted.xml: The converted version of the above Plist file. 

BOOKMARKS --> Contains the file d1f062e2da26192a6625d968274bfda8d07821e4 which is the Bookmarks.db from Safari. Also contains BookMark.xml which is the converted version of this database. 

CONTACTS --> Contains the file 31bb7ba8914766d4ba40d6dfb6113c8b614be442 which is the AddressBook.sqlitedb from the iOS device. --> Converted VCard (.vcf) data from the above database. 

MEMO / NOTES --> Contains the file ca3bc056d4da0bbf88b5fb3be254f3b7147e639c which is the notes.sqlite and the file 4f98687d8ab0d6d1a371110e6b7300f6e465bef2 which is the NoteStore.sqlite database. --> Contains a which has a JSON file inside it which is the converted notes data of the two above databases. 

MESSAGES --> Contains the file 3d0d7e5fb2ce288813306e4d4636395e047a3d28 which is the sms.db from the iOS device. --> Contains several relevant files including: 
sms_restore.json - All of the SMS messages from the above database converted into a JSON file. 
mms_restore.json - All of the MMS messages from the above database converted into a JSON file. 
NOTE: iMessages are organized into the appropriate JSON above for their type either SMS/MMS. 
PART_files - Attachments recovered from the SMS/MMS/iMessage attachments. 

The PHOTO folder contains information about the photographs and videos extracted from the source iOS device, but not the media itself. 

But what if you don't have a full filesystem of the device and you're stuck with just a Quick image of the data? In that case, examiners should turn to the media/0 (or emulated sdcard) directory to find the SmartSwitch directory. Within this directory under "tmp" an ENTIRE copy of the iTunes-Style backup was recovered!

Within the SmartSwitch/tmp directory there were several folders to support the transferred data. Unfortunately, not all of these kept the JSON files that were available from the data's stored information from within /data/data. Some of these folders did, such as the message_json folder containing all of the same JSON values from earlier. 

The photos/videos transferred from the source iOS device were also discovered within a folder in the emulated sdcard directory called iPhoneData. This directory contained all of the recovered documents and media items transferred over. The names from the source device were not kept in this directory and the previously discussed photo logs keep the information about how the files are renamed. 

Android is well known for duplicating data across multiple areas of the filesystem. If the SmartSwitch application is found on a subject's device, several directories should be checked for this previous device's transferred data. Some of these areas are more available to the end user than others so each directory may or may not still have data within it. 

As a wrap up and reminder, the directories that should be checked are: 

/data/data/ --> Look for the iosotgmanagerv2, SmartSwitch, and SmartSwitchLog files. Search for any DATA_0 folders for the stored .zip files containing both original source information and converted JSON data. 

/data/media/0/iPhoneData --> Contains the recovered documents and media from the iOS device (original source names NOT kept). 

/data/media/0/SmartSwitch/tmp --> Look for the original backup of the iOS device as well as the converted JSON data within the appropriately named folder. 

And that's it for this post! In the future, I definitely want to explore the same data but for an Android to Android transfer as well as exploring the Pixel version and other manufacturer's version of the same processes.