Upgrade From NULL—Detecting iOS Wipe Artifacts
One of the most common questions we’re asked is, “How do you determine when an iOS device was wiped?” Wiping is a common way to trample potential evidence on a device. Over the years, we have seen some savvy moves to try to cover up wiping efforts on devices and prevent the act from being detected. These include:
- Wiping the device far enough in advance and conducting as much activity as possible to create “noise” on the device and make it look “used,” as Ruth Langmore demonstrates in the Cellebrite CTF example below.
- Wiping the device and pushing old backup data to it to make it look “used.”
- Wiping a device and pushing someone else’s data to it to make it look “used.”
In this blog, we want to help you quickly identify whether an iOS device has been wiped. Keep in mind, a wipe doesn’t mean something nefarious has occurred as there are many legitimate reasons to wipe a device. We are simply helping you determine when the wipe occurred. We’ll leave you with the fun part of determining the “why” behind the wipe.
Test Device Used In Screenshots Below
- Ruth Langmore’s iPhone X from the Cellebrite CTF. Her device was wiped on July 27, 2020 at 7:08 PM UTC. During this time, the offset from UTC is GMT-4 to hit Eastern Daylight Time. So, in local time, the wipe occurred at 3:08 PM.
As always, we validated our findings across several devices to include an iPhoneSE (running iOS 13.7) and an iPhone 6S (running iOS 14.2).
Some examiner’s rely on dates that are parsed by tools or that seem to make sense based upon how the artifact is named. We want to first identify files that are not as reliable as the others we discuss in this blog.
Up first, the SetupLastExit date found in /root/private/var/mobile/Library/Preferences/com.apple.purplebuddy.plist. This date is NOT the best indication of when a device was wiped. There are many factors that can impact this timestamp. For example, when you set up an iPhone, you can ignore Wallet and other settings. When you go back and add those items, this timestamp is changed. If you change your credit card for Apple Pay down the road, this timestamp will be updated. So really, it reflects the last time the user of the device changed something in the Settings screen.
For our test device, while the date is correct for the wipe time, you can see that SetupLastExit occurred a few hours after the wipe. This time reflects when we updated Ruth’s Apple Pay.
If you recently wiped and set up a device, you see that red alert in the device to “Finish Setting Up Your iPhone.”
In summary, the SetupLastExit is tracking the phone setup and all changes made there. You may find some devices that are wiped and immediately set up, which is fine, but you may also come across some that aren’t fully set up for days or months. And for that possibility alone, we are ignoring this file.
There are several files that you will find that support the correct datetime when an iOS device was wiped. We are going to share a few of our favorite ones that we have relied upon over the years to aid in detecting the correct wipe date. The first is going to reside within the com.apple.purplebuddy.plist, which contains useful dates and is accessible using most iOS acquisition methods including iTunes backups all the way to full-file system extractions.
Within the com.apple.purplebuddy.plist, we see a timestamp for GuessedCountry on 7/27/2020 at 7:13:13 PM, which is around the time Heather was setting up the iOS device after wiping it.
You have to think that when the user presses the button to “Erase All Content and Settings” and proceeds, there may be a few minutes between that action and when the phone actually boots up as a “freshly-wiped” device. One of the first screens the user will see is “Select Your Country or Region,” which is represented as GuessedCountry inside of this plist.
To rely on this time, please make sure the SetupState is SetupUsingAssistant. If the SetupState is RestoredFromiCloudBackup, the date may reflect an old wipe from the restored device. For iCloud restores, we recommend obtaining a full-file-system extraction and examining the artifacts mentioned later in this blog. If that is not possible, you are going to have to examine the creation dates and usage of the device, which will be a manual process.
In summary, there are many dates accessible in com.apple.purplebuddy.plist, which is accessible even by using an iTunes backup. We recommend you examine the GuessedCountry from this plist to get a good grip on the first time the phone was successfully booted after a wipe and when the country was presented to the user upon that boot (mine suggested United States).
Remember, if the device was restored from an iCloud backup, you will have to look beyond the GuessedCountry as it may reflect an older wipe date. If you want to know more about what the user did to set the device up after wiping (Restored from iCloud, Fresh setup, Restored from iTunes) refer to the DFIR Review blog published by Heather Mahalik: https://dfir.pubpub.org/pub/2q177smo/release/5
The next file of interest can be found within full-file-system extractions. The containermanager is a series of log files that are updated when, amongst other things, the device boots. They are located /private/var/root/Library/Logs/MobileContainerManagerThe files are appended as .log files but include a secondary, numerical extension, which is directly related to the age of the file. So, you may see containermanager.log.0, containermanagerd.log.1, and containermanagerd.log.2 for example. It is important to note that the higher the number, the older the file. This means that containermanager.log.0 is always the most up-to-date file.
As we are interested in the date the device was wiped, which will be stored in the oldest file, we need to look at the file with the highest numeric value. The entry we are most concerned with is during the boot process where the device is checked to see if an update has just occurred:
This entry shows that upon booting, the OS build was found to be 17C54, which is the same as the last time it booted. Therefore, no upgrade has taken place.
This entry shows that the OS was being upgraded from build 17C54 to build 17D50.
But when the device is booted for the first time after an erase, the build information is missing, resulting in the entry:
Each of these records is prepended with a date and time that the record was made. The timestamps are in local time of the device at the time the record was made. It is important to note that upon first boot the device defaults to US Pacific Time (UTC-8). This may be updated during the setup process.
This means that the first few records (including the entry we are interested in) are shown in UTC-8 regardless of how the device was set up prior to being wiped. If we take Ruth’s device and look at the record described, we can see the timestamp is 12:11:38 on 07/27/2020.
If we treat it as a Pacific timestamp, we need to add 7 hours to bring it to UTC time (due to Daylight Savings). This gives us 7:11PM, which is a few minutes after the device was wiped. Again, it may take a few minutes for the device to finish wiping and reboot.
This seemed a little odd and prompted us to do further testing.
A Secondary Device – Validation:
This test device was wiped at 4:32PM UTC. It was set up at 5PM UTC and rebooted at 5:07PM UTC. However, the container information shows 8:33AM. As we are now in Pacific Standard Time, we must subtract eight hours to get to the UTC time of 4:33PM, which we know to be about correct.
During this research, Ian identified logd.0.log, which contains shut down and time zone change information. This file can be found in private/var/db/diagnostics/logd.0.log. If you recall, the setup of this device was started at 5PM UTC. If we look at the logd.0.log file, we can see the first line refers to a time zone change.
This time zone change was a result of the set up process and shows that the timestamp is 10:01 UTC-7, which is correct for both the time I ran the setup and my time zone location. The second entry is made when the device is shutting down and matches the time that I rebooted the device at 5:07PM UTC.
Finally, to bring this back to where we started, we can see that the timestamp in containermanagerd is now displayed in local time to the device.
It’s worth noting that this file now appears to have a shelf life and is not guaranteed to be in every extraction you open. Interestingly, Ian previously found a record on his personal device that was approximately three months prior to the device being available for sale. It wasn’t an epoch date and his only assumption was that it was a record of the device being booted up in factory.
Ruth’s Device – Validation:
To ensure nothing was misinterpreted we validated Ruth’s data in ArtEx, a tool developed by Ian. Below we can see that the containermanagerd is identical to what we examined in Physical Analyzer and shows the 07/27/2020 12:11:38 timestamp. (Heather lives in Eastern Time, so three hours must be added to match her local time). This is correct, just as we previously noted.
When examining the Metadata for containermanagerd.log.0 we see that the Creation time matches when the device was wiped and is shown in UTC.
So, it is easiest to look at the creation data for the containermanagerd.log.0, but it’s important that you understand the contents and what they mean so you do not misjudge when the device was wiped. As previously stated, there are other file creation times that can be relied upon to identify when the iOS device was booted after a wipe. Below, can see additional files from Ruth’s iPhone.
private/var/mobile/Library/AddressBook/AddressBook.sqlitedb– creation time 7/27/2020 7:11 PM UTC. The modified date has nothing to do with the wipe time and has no correlation.
private/var/mobile/Library/CallHistoryDB/CallHistory.storedata– creation time 7/27/2020 7:12 PM UTC.
A common file that is used to identify a device wipe is the .obliterated file that can be found at /private/var/root.
This is a zero-byte file created by the device upon booting after a wipe.
If we look at the .obliterated file on Ruth’s device, we can see that it was created at 3:11:25PM (Eastern Daylight Time).
By comparing that timestamp to the other times we have found, we can see that this file was created about 14 seconds before the time shown in containermanagerd.
The .obliterated requires a FFS and may not be found in every extraction. It is, however, another great reference for determining when the device was wiped.
Bottom line, you can find solid evidence on when an iOS device was wiped. If you only have an iTunes or advanced logical extraction, simply compare the GuessedCountry from the com.apple.purplebuddy.plist. If you want more correlation to other artifacts, compare this date to the creation times of Addressbook.sqlitedb and Call_History.storedata creation, which should be around the time the device was wiped and then rebooted. Other files may make sense, too, but these are the ones we rely upon for consistency.
If you have a full-file-system extraction, start with the containermanagerd creation time and then take a look at the contents and make sure you convert from Pacific time to the local time of the device. Then go to logd.0.log and determine the time that the device time zone was updated (unless of course you are in Pacific Time). From here, you can go to the com.apple.purplebuddy.plist or you can simply sit back and feel like you pinned down that pesky assumption you have been chasing. You now know when that iOS device was wiped.