iPhone Forensics: Wiped iPhone? Are You Sure?
There are many legitimate reasons why someone might wipe an iOS device. A corporate IT administrator might do so prior to assigning a device to a different user, or a user might do so before they install a major iOS update. A user might also wipe a device to hide potential evidence. If they are successful, the only reliable evidence may be the data wiping evidence itself. For instance, if an investigator determines that an iOS device is not new and the subject has had access to the device over a period of time, and/or the subject tended to send frequent text messages, but there is only one sms.db (and/or other associated messaging artifacts) with a recent creation date, there may be some support for a device wiping claim. If the device also contains artifacts unique to data wiping, an investigator can definitively support a device wiping claim.
How can an examiner prove a wipe has occurred? This blog discusses data wiping artifacts that may still be present if a user wiped an iOS device, if and how an examiner may recover these artifacts, and how an examiner can explain these artifacts during a legal proceeding.
The .obliterated File
When a wipe occurs, the iOS operating system creates a zero byte .obliterated file here:
Under some circumstances, even if a wipe occurred, the .obliterated file may no longer be present. But if an .obliterated file is present, an examiner can conclude that the device was in fact wiped. The file’s Date Created timestamp indicates when the wiping occurred.
In this example, the iOS device was wiped and set up for a new user by launching the ‘Settings’ application and choosing General>Reset>Erase All Content and Settings.
Unfortunately, a logical acquisition does not recover all of the data on the Data partition; an examiner must acquire a full forensic image of the iOS device to recover the .obliterated file. So, if a device is encrypted, the passcode is unknown, and an examiner cannot defeat the encryption (jailbreak) to acquire a full forensic image, a determination will not be able to be made as to whether or not an .obliterated file exists.
At the time of this writing, the only devices that examiners can consistently and successfully image using commercial imaging tools are the iPhone 4 (and older), iPad 1, and iPod Touch 4th generation (and older) devices running iOS 6.1.2 or earlier.
However, Elcomsoft’s iOS Toolkit can acquire full physical images of iOS 5 and iOS 6 devices including iPhone 4S and 5, iPad 2, 3 and 4, iPad Mini and the last generations of iPod Touch, provided the device has been ‘jailbroken.’
Note: An examiner should only ‘jailbreak’ a device as a last resort and should use great caution when doing so. If possible, consider performing a logical acquisition first to preserve evidence that may be lost during the ‘jailbreaking’ process.
If an analyst cannot acquire a full forensic image from an iOS device (devices with the A5 or A6 chip), they are not entirely out of luck. There are a few additional indicators and timestamp artifacts that may indicate device data wiping.
When a local or a remote wipe occurs on an iOS device, the device operating system creates a new file system. An examiner may use some of the (roughly 50) new core system files’ creation dates as reference points, as these timestamps represent the 30-40 second time period immediately after the data wipe occurred, depending on how quickly the operating system created the new filesystem.
Having said that, keep in mind that some files on an iOS device may not accurately indicate when the device was wiped. iOS devices use the HFS+ file system, and when files are copied from one HFS+ file system to another HFS+ file system, the original creation date from the source system is maintained. So, files that were not originally created on a wiped device may have pre-wipe Date Created timestamps. This is often seen with Application bundle files from a downloaded App Store app.
Therefore, analysts should focus on files that are directly ‘touched’ during a user’s device interactions. We mentioned the sms.db file earlier in this blog, and here are a few additional core system files that provide the most accurate ‘post-data wipe’ creation dates:
This screenshot shows several user-specific files that were created after we wiped our test device on Monday, February 4 of 2013 at roughly 1:40:40 PM.
This screenshot shows several files with older creation dates located on the same wiped device. Notice that these files belong to third-party applications (primarily reference files within an application bundle) that were copied back to the wiped device after the data wipe. Therefore, these creation dates do not provide an accurate indication of the data wipe.