I hope everyone has had a great first quarter of 2023. For me, it has been a busy one with settling into a new role at a new employer. As things continue to settle I hope to get back into a blogging routine as time allows.
I was recently presented with a question surrounding how an Android phone was setup. This question was great because not only could I not find anything about it, but I felt it could be a Part II of sorts to my original Wipeout post. It is good to know when a phone was wiped but it is better to also know how the phone was setup. Examiners have had this ability to some degree on iOS devices for a while now so it only makes sense to explore this on Android.
Generally speaking, setting up phones has come a long way in the past 15-20 years. I am old enough to remember getting a new phone at my local Cingular store and the sales rep using a Cellebrite utility to transfer contacts from my old phone to the new one. Since then OEM’s have given users methods to back up and restore their devices up to their local workstations/laptops, to cloud infrastructure, and even over ad hoc connections between devices, all of which gives users options when setting up a new phone or restoring an existing one. Both methods continue to be useful in investigative and forensic matters so knowing how a phone was setup can be a great investigative lead.
For testing I used a Pixel 5a running Android 13 (February SPL), a Galaxy S22 running Android 12, and a Pixel 3 running Android 12. The Pixel 5a and S22 were backed up locally and to their respective cloud infrastrucure(s), wiped, and restored. Multiple times. Examiners will need a FFS extraction in order to view the files referenced in this post. Keep in mind the methods discussed here may not be the only setup options for Android phones from other OEMs, which could cause the artifacts described in this post to appear differently or to not appear at all. So is life with Android forensics.
The (Literal) Setup – No Backups
Most Android phones have the ability to backup to some type of cloud infrastructure. Pixels can natively backup to Google and Samsungs can backup to Google or Samsung depending on the choice of the user, so I opted to start there. First, I wanted to see what the phones looked like when they were setup as “new.” The first place I looked was the public Android 13 image. Figure 1 shows the shared_prefs folder of USERDATA/data/com.google.android.setupwizard of the Pixel 5a. Note the file DeviceOrigin.xml, the contents of which are shown in Figure 2.
Figure 1. com.google.android.setupwizard/shared_prefs from public Android 13 image.
Figure 2. DeviceOrigin.xml.For the public image, the Pixel 5a was setup as a new device, which initially led me to believe DeviceOrigin.xml meant exactly what its name implied: the origin of the device was a wipe. However, when I wiped the device and set it up again to try to replicate this, DeviceOrigin.xml was missing. See Figure 3.
Figure 3. DeviceOrigin.xml is missing here.The Samsung S22 also had DeviceOrigin.xml in the same location, but the contents were slightly different. See Figure 4.
Figure 4. DeviceOrigin.xml from the S22 after a setup as new.The contents of this version of DeviceOrigin.xml seems to be a bit more straight foward. The S22 was setup as a new device, which seems to be what this file is conveying. For the Samsung, there are other indicators in addition to this file that convey a new setup which will be discussed later in this post. There are also other indicators for the Pixel. In the same directory path (seen in Figure 1) is the file SetupWizardCredentialProtectedPrefs.xml. See Figure 5.
Figure 5. SetupWizardCredentialProtectedPrefs.xml from the Pixel 5a.Here the value is Null, and the file was identical in the S22. The value changes if the phone was restored from a backup from Google as we will see shortly. For now, just know the Null value is another indicator of either phone not having been restored from a Google backup.
There is one last place to examine for signs of newly restored/non-Google backup restoration. See Figure 6.
Figure 6. USERDATA/backup/ folder.The USERDATA/backup/ folder here is from the Pixel 5a but was identical to that on the S22. This is how it appeared when either phone was not restored from a Google backup. Taking this along with the other items discussed above is indicative of a phone having been setup as “new.”
There is one additional note here: the file backup_enabled (highlighted in Figure 7) contains the setting that determines if the phone is set to backup to Google. The file contains a single byte. Based on my testing, if the byte is 0x00, then the phone is not set to backup to Google. If the byte is 0x01, then the phone is set to backup to Google. See Figures 8 & 9.
Figure 7. backup_enabled.
Figure 8. Byte is 0x00 (backup to Google is off).
Figure 9. Byte is 0x01 (backup to Google is on).Backups
So what happens when the phone is restored from a backup stored on Google’s infrastructure? Revisiting the USERDATA/data/com.google.android.setupwizard/shared_prefs/ directory path finds things are…slightly different. See Figure 10.
Figure 10. shared_prefs in com.google.android.setupwizard. Again.The file DeviceOrigin.xml is missing, which is not surprising. However, there are changes in SetupWizardCredentialProtectedPrefs.xml. See Figure 11.
Figure 11. Packages and a restore token.The contents have changed from Null to two XML tags. The first appears to contain a list of package names with the tag “packagesToRestore” (highlighted in the top red box). The bottom red box highlights the other string, “restoreToken.” This was consistent across the Pixel, the S22, and other Samsung extractions I had where the phones had been restored from a Google backup. The population of this file is an indicator of a restoration from a Google backup.
Revisting USERDATA/backup/ also finds some changes. See Figure 12.
Figure 12. The Pixel’s USERDATA/backup folder after a restoration from a Google backup.I have highlighted the backup folder in the red box. The file in the blue box, ancestral, is one of the key files here. The last modified timestamp is when the restoration from the Google backup occurred. The file contains a list of apps that were restored to the phone, including third party apps. The other file that is key, unadded_account_syncsettings.json, contains what I suspect is a list of apps that were restored who’s account information could not be restored; some of the apk names that appeared in ancestral also appeared in unadded._account_syncsettings.json. The last modification time of this file also appears to align with the restoration time. Figure 13 shows the same folder from the S22.
Figure 13. USERDATA/backup folder from the S22 after a restoration from a Google backup.Figures 14 and 15 show the contents of ancestral from the Pixel 5a and S22, respectively.
Figure 14. ancestral from the Pixel 5a with Signal and WhatsApp highlighted
Figure 15. ancestral from the S22 with WhatsApp highlighted.The files in USERDATA/backup/ along with the changes in SetupWizardCredentialProtectedPrefs.xml are, collectively, indicative of the phones having been setup using a backup from Google.
The S22 has the added capability of being restored from a backup from Samsung’s cloud infrastructure. This is accomplished if the user logs in to their Samsung account during the phone setup process. Fortunately, Samsung keeps a log of setup activity in USERDATA/log/ conveniently named setupwizard.txt. See Figure 16.
Figure 16. Top of setupwizard.txt log file from the S22.This file contains information related to the Samsung Setup Wizard, which is a seperate thing from the Google Setup Wizard; they have different apk names. setupwizard.txt logs activity related to the Samsung Setup Wizard only. Searching for the time I restored the S22 from the Samsung backup finds the log entry seen in Figure 17.
Figure 17. backup_restore_done.The highlighted entry containing “backup_restore_done true” indicates the restoration from a backup stored with Samsung was successful, and the timestamp aligns with when I noted the restoration was completed. This entry was present in each extraction I ran after restoring the S22 from a Samsung cloud backup, plus another extraction conducted by someone else. The inverse was also true; this entry did not exist in any extraction which was not restored from a Samsung backup.
Proximity Restorations
Android phones also have the ability to transfer data between themselves during the setup process; the data transferred can vary, but usually includes things such as accounts, contacts, messages, call logs, calendar entries, along with information about third party apps. The process can be either wired or wireless. The former requires connecting the two phones via a compatible cable, and the latter requires the two phones be near each other. For testing, I conducted both. For the Pixel, I used the Pixel 3 as the source (the “old” phone) from which to transer data to the 5a (the “new” phone). The first place to look is a familiar location: USERDATA/data/com.google.android.setupwizard/shared_prefs/. See Figure 18.
Figure 18. com.google.android.setupwizard/shared_prefs from the Pixel 5a.The file DeviceOrigin.xml has returned, and the last modified timestamp aligns with the time when the proximity transfer was initiated. The contents are also relevant. See Figure 19.
Figure 19. DeviceOrigin.xml from the Pixel 5a post-proximity transfer.The file contains the name of the source device, in this case the Pixel 3, along with the type of device, “android.” I suspect the source_device XML tag would have contained “iOS” had the source device been an iPhone. The other file of interest, SetupWizardCredentialProtectedPrefs.xml, is shown in Figure 20.
Figure 20. SetupWizardCredentialProtectedPrefs.xml from the Pixel 5a post-proximity transfer.The file looked slightly different than what was seen in Figure 11. The XML tag “packagesToRestore” was not present, but the “restoreToken” tag was present. The next location checked was USERDATA/backup/. See Figure 21.
Figure 21. Looks familiar.Again, the file ancestral is present and contains a list of migrated apps, including third part apps, which can be seen in Figure 22. While not exact, the last modification time is approximate to when the migration occurred. Also present is unadded_account_syncsettings.json (contents not shown).
Figure 22. ancestral from the Pixel 5a, post-proximity transfer, with Clubhouse and Session highlighted.Proximity transfers on Samsung devices look slightly different because they use Samsung’s Smart Switch app (aka Kies). When a user opts to copy data from an old device to the new Samsung device during setup, the new phone will download Smart Switch to the phone prior to the transfer. Additionally, the old device must also have Smart Switch installed, regardless of platform or whether or not it is a Samsung phone. The apk name is com.sec.android.easyMover. The directory path ~/files contains a history of migrations. See Figure 23.
Figure 23. com.sec.android.easyMover.There are a few things to note here. First, the directory ~/files/History/ contains a folder who’s name is a Unix Epoch timestamp (blue box in Figure 23). To understand the timestamp it is important to understand how Smart Switch works. When a user opts to transfer data using Smart Switch there are two stages. In the first stage the data is migrated to the new phone. In the second stage, the data is “organized” on the phone. A user can open Smart Switch on the new phone while the data is being organized to view the status. The folder name/Unix Epoch timestamp is the time at which the data is finished organizing, and is representitive of when the proximity restoration has finished.
The second thing of note in Figure 23 is the file peerDeviceInfo.json (highlighted in the green box) located in the folder with the Unix Epoch timestamp name. This file contains information relevant to the proximity transfer. See Figure 24.
Figure 24. peerDeviceInfo.json from the S22.The information highlighted in the red box represents the source phone’s (the “old” phone) model and OS and OS version. The information highlighted in the blue box is the source phone’s vendor along with it’s name (can be set by the user). This information can be extremely useful for investigators for a number of reasons, including giving them information about an additional device that may have been previously unknown.
The information highlighted in the green box is also important. Here the field is blank, which was consistent across my testing when either a wired or wireless proximity transfer occurred. However, I observed another value in this file under a different circumstance which is discussed in the next section.
One last item of note is the folder ApkInfo in the same Unix Epoch timestamp folder (not highlighted in Figure 23). The folder contains PNG files of application icons that are displayed on the home screen of a phone. Additionally, the file AppList.json contains a list of files that mirror the PNG files in the folder. The list of apps and app icons will be a mix of 3rd party and non-native Google apps. I found the app names and their respective PNG files persisted even after the apps were deleted from the phone, which could prove beneficial to examiners/investigators. See Figure 25.
Figure 25. ApkInfo.PC Backups
Galaxy phones have always mirrored iOS devices…or vice versa…depending on the point of view. One of the features Galaxy phones share with iOS devices is the ability to create a local backup on a PC. To do this, both the phone and the PC have to have Smart Switch installed. If a user decides to setup a new device (or restore an existing device) using a backup on a PC, the Smart Switch artifacts and behavior are the same as previously discussed. However, the ConnectionType value changes. See Figure 26.
Figure 26. Second ConnectionType value.Again, this is the same file name/location as before. However, the ConnectionType value is now “pc” (highlighed in the green box), which makes sense seeing how the S22 was connected to the PC in order to facilitate the restoration from the backup. Additionally, the information highlighted in the red and blue boxes represent the S22 which was the make, model, operating system version, and name of the phone that was contained in the backup. Knowing that a backup exists somewhere could give an examiner/investigator a valuable lead that could expand their event horizon on the device being examined.
If you have noticed, I have not discussed ADB backups, and that is on purpose. ADB backups have been deprecated and Google, allegedly, is phasing it out.
Restore Complete
Knowing how an Android phone was setup can benefit an investigator. Discovering that there is a second set of data out there can extend the event horizon of a device examination and even an entire investigation. Examiners have had a way to detect how iOS devices have been setup for some time now, and now, hopefully, they have ways to determine how an Android device was setup/restored.
Article Link: Wipeout! Part Deux – Determining How an Android Was Setup – The Binary Hick