EFFECTS OF THE FACTORY RESET ON MOBILE DEVICES

Riqui Schwamm and Neil C. Rowe
U.S. Naval Postgraduate School

Computer Science Department
Monterey, CA 93943 USA

rschwamm@nps.edu, ncrowe@nps.edu

ABSTRACT

Mobile devices usually provide a "factory-reset" tool to erase user-specific data from the main secondary storage. 9 Apple iPhones, 10 Android devices, and 2 BlackBerry devices were tested in the first systematic evaluation of the effectiveness of factory resets. Tests used the Cellebrite UME-36 Pro with the UFED Physical Analyzer, the Bulk Extractor open-source tool, and our own programs for extracting metadata, classifying file paths, and comparing them between images. Two phones were subjected to more detailed analysis. Results showed that many kinds of data were removed by the resets, but much user-specific configuration data was left. Android devices did poorly at removing user documents and media, and occasional surprising user data was left on all devices including photo images, audio, documents, phone numbers, email addresses, geolocation data, configuration data, and keys. A conclusion is that reset devices can still provide some useful information to a forensic investigation.

This paper appeared in the Proceedings of the 6th International Conference on Digital Forensics and Computer Crime (ICDF2C), New Haven, Connecticut, USA, September 2014.

Keywords: mobile device, forensics, factory reset, file types, Cellebrite, privacy

1. Introduction

An increasing amount of criminal activity uses mobile devices (McMillan, Glisson, and Bromby, 2013). Devices do provide ways to erase user information from secondary storage and criminals will likely use them. However, these methods are not entirely effective and information of forensic value can be left after these attempts to erase it. In addition, with frequent device upgrades by manufacturers, discarded older devices are common. This paper attempts to determine how much and what kind of residual user data are left after a "factory reset" or "wipe" intended to remove user data. This analysis will aid forensic examiners that encounter reset drives.

Recently a number of researchers have developed methodologies for forensic investigation of mobile devices (Owen, Thomas, and McPhee, 2010; Marturana et al, 2011; Omeleze and Venter, 2013). Systematic analysis of mobile devices differs somewhat from that of desktop and laptop computers because of the difficulty of accessing the main secondary storage, which is usually a flash storage soldered to the device board. Cutting out and removing the storage (Alghafli, Jones, and Martin, 2012) usually destroys the device functionality. Hence most mobile forensic tools attempt to access the storage through the operating system. Several issues particular to mobile devices arise such as finding where data are stored and dealing with data aggregation. For instance, on most smartphones the call records are stored in a single file. In addition, the operating system may not permit access to all files.

The term "factory reset" is used by manufacturers to mean restoring an electronic device to the state when it left the factory, deleting all user data and third-party applications in the process (Rouse, 2013). It should be done when discarding a device or transferring it to a new owner. The concept is clear when referring to music players and other simple devices, but its meaning is less clear for complex mobile devices where some user data may be necessary to configure it adequately, and some user data are stored within operating-system files.

No systematic testing appears to have been done of the factory reset on mobile devices, although technology websites report gripes (The Guardian, 2013). For example, (Smith, 2012) tested secondhand phones purchased through Craigslist where a factory rest had been performed on the devices. Data that they found included court records, social security numbers, resumes, college applications, child support documents, employee records, bank statements, credit-card statements, tax returns, email, contact lists, and photos. One investigation (Cardwell, 2013) studied the effects of a factory reset on network data left on an Android phone. Data was transferred between Android phones and multiple network access points (cellular, wireless, and Bluetooth). Residual data in secondary storage on test phones after the reset included "userdata" partitions containing Service Set Identifiers, wireless-router Subscriber Identity Modules, DHCP ACKs from wireless routers, and base-station metadata that included the Mobile Network Code, Mobile Country Code, Local Area Code and Cell Identification, wireless router Media Access control addresses, and Bluetooth addresses of devices paired with the phone.

These reports suggests that useful forensics on reset devices is indeed possible. They also raise worrisome questions about the privacy of information stored on mobile devices. Privacy of personal information is currently subject of much attention (Payton and Claypoole, 2014). If private data are left on devices after users have reset them, users may be able to sue manufacturers, and this needs to be factored into business decisions (Kauffman, Lee, and Sougstad, 2009). Matters are even worse if the data left on devices are unpredictable as it appears to be from the anecdotal reports.

2. Experimental setup

Tools from Cellebrite (www.cellebrite.com/ mobile-forensics) were used to extract data from the main storage of test devices. The Cellebrite UME-36 Pro Universal Memory Exchanger 1.2.2.3 hardware accessed the devices, and the Cellebrite UFED Physical Analyzer 3.7.2.0 software analyzed the images. Other products claiming similar functionality include the Forensic Toolkit (www.accessdata.com), Oxygen Forensic Suite (www.oxygen-forensic.com), EnCase Neutrino (www.guideancesoftware.com), Recuva (www.piriform.com), and ViaExtract (viaforensics.com). The Oxygen Forensic suite was tested on some of our phones and it appeared to work well. ViaExtract showed compatibility issues with some Android phones (the Samsung Galaxy SIII and the Motorola Atrix 4G). Recuva is primarily for hard drive recovery; it could extract small data sets but did not provide useful analysis.

A full ufd-format dump of the file system on each device was made by the Cellebrite Physical Analyzer. A program was written to calculate DFXML metadata (www.nsrl.nist.gov/DFXML /fileobject.xsd) on the dumps, including calculation of hash values on files. Another program discussed in section 4.2 was written to compare the pre-reset and post-reset DFXML metadata. A taxonomy from (Rowe, 2013) was used to classify files by extension and directory. The Bulk Extractor tool from digitalcorpora.org (Garfinkel, 2013) was used to extract strings. We did not exclude operating-system files from analysis because our previous work (Rowe, 2013) found some user data in them.

Except for two unresponsive phones and also in section 3.4, resets were performed through software using each device's setup menu under "Privacy" or "Backup & Reset". The reset takes a few minutes after which the device restarts.

2.1 Other Storage for Devices

This work focused on the main nonvolatile storage. A separate removable memory card on some phones ("SIM" or "subscriber identity module") contains the user's identity, account information, and keys, and is necessary to make phone calls. It may also contain text messages and contacts depending on the phone. SIM cards were not available for most of our phones. SIM cards are unaffected by a factory reset and contain information of definite forensic interest, so they should be analyzed if available.

Besides SIM cards, many devices have additional removable storage in the form of SD or MMC cards that is not subject to the factory reset. No such cards were available for the devices tested in section 4, but 76 cards comprising 54,279 files were acquired from smartphone images from an international corpus. Classifying its files by extension using our taxonomy, 31.7% were camera pictures, 15.0% were audio, 11.8% were video, 5.6% were documents, and 5.6% had no extension. Hence these cards had rich materials for forensic investigation compared with 4.3% camera images, 4.8% audio, and 0.1% video on the mobile-device main-storage corpus to be described. That suggests that the cards should be checked first when available in a forensic investigation.

3. Experiments with two phones

To get a more detailed view of what a reset accomplishes, experiments were done with an Apple iPhone 4S phone (p18 in Table 3) and an Android Samsung Galaxy SIII phone (p9), after making copies of the original pre-reset and post-reset images to use later. These experiments placed specific files on the phones that we thought should be deleted by a reset.

3.1 Experimental Protocol

The phones were "factory-reset"; a protocol was followed to put applications and data onto the phones; images were taken of the phone with the Cellebrite Physical Analyzer; the phones were reset again; and images were taken again. The furnished data included distinctive keywords to make it easier to recognize forensically. The phones were not connected to a cellular account, so messaging services could not be tested. The protocol was:

1.     Reset the device.

2.     Visit four specified websites: nps.edu, fark.com, yahoo.com, and npr.org.

3.     Take six pictures with the built-in camera and rename three distinctively.

4.     Click on eight specified links to Web pages and documents (4 html, 1 docx, 1 pdf, 1 pptx, and 1 wav file).

5.     Download to the root directory of the phone a specified text document and zip file.

6.     For the Android: (a) download and install the Facebook app, login, and browse specified pages; (b) download and install the Google Drive app, login/sync, and open three specified files; (c) download and install the DropBox (www.dropbox.com) app, login/sync, and open three specified files; (d) download and install the YouTube app, login, and watch three specified videos; (e) download and install the Audible app, login, and download three specified excerpts; (f) download and install the Kindle app, login, and open three specified PDF files; and (g) download and install the "Reddit Is Fun" app, and visit three specified postings.

For the iPhone: (a) view three YouTube videos with the installed software;
(b) create three specified note entries with the installed software; and (c) create three specified reminders with the installed software. (The iPhone does not allow download of arbitrary software and files.)

3.2 Analysis of the Android Test Phone

On the Android, 5,141 files were recovered pre-reset and 3,578 post-reset, of which 3,292 matched exactly in both path and contents. After deleting partial matches or analogous files (defined as being on filename and hash, hash only, path only, or path ignoring digits), there were 968 pre-reset and 65 post-reset files that did not match in both path and contents between pre-reset and post-reset images. We conclude that 968 files were deleted and 65 were added by the reset. 278 of the post-reset files had zero size of which 227 also had zero size before the reset. The number of executable ".apk" files went from 396 to 277, ".dex" files from 140 to 121, and ".so" files from 302 to 254, so executables were not filtered much by the reset. The "copies and backup" category went from 512 to 33 files, but otherwise the Android reset did not seem to target any particular extensions or directories.

The reset of the Android was not effective at deleting emplaced files as it did not delete any images taken with the camera, nor the created txt, doc, pdf, and ppt files, nor some cache and deleted copies of these files and their image components. (The other Androids similarly did not delete these files, so the operating-system version did not affect this.) The reset did delete most third-party applications, but it had trouble with the Kindle and DropBox applications and left documents of the previous owner of the phone. Using BulkExtractor, 116 links to three visited Web sites were found pre-reset in various files, but all were deleted post-reset.

The reset left intact many operating-system files; 1,971 files with modification times older than one week before the reset were present before the reset and exactly the same number after. Our previous research showed that user data may be contained in operating-system files of settings and logs. Table 1 lists some example files remaining after the reset that could be interesting for forensic purposes. None of the Android phones still had a SD card and directories used to store SD-card data were not specifically searched. However, data was found under ‘USERDATA/Root/media/0', which should have been erased during a reset. Again, there is a variety of indirect information about usage in addition to the direct information of the undeleted user files.

Table 1: Some Forensically Interesting Files on the Test Android after Reset

3.3 Analysis of the iPhone Test Phone

On the iPhone, 61,276 files were recovered pre-reset and 43,165 post-reset, of which 42,728 matched exactly in both path and contents; iPhones had more files than Androids. After deleting partial matches (defined as in section 3.2), there were 17,914 pre-reset files and 115 post-reset that did not match, so we conclude 17,914 files were deleted and 115 added by the reset. 36,319 of the post-reset files had zero size of which 36,292 were also had zero size before reset; that indicates that zero-size files after the reset convey some forensic information since they are almost certainly present before the reset. The number of executable ".app" files went from 24,862 pre-reset to 8,062 post-reset, but the number of files of all kinds in recognizable operating-system directories went from 29,812 to 27,621, so the operating-system files were generally preserved.

The reset on the iPhone did well in deleting most files put on it by user activity, due to Apple's tighter control on what can be put on the phone. All the images and documents were deleted by the reset except for some cache and settings information from YouTube, and all third-party software except for Facebook. Table 2, however, lists example files remaining after the reset that could be interesting for forensic purposes by providing indirect information about what the user was doing.

Table 2: Some Forensically Interesting Files on the Test iPhone after Reset

Despite Apple's claims (Apple, 2014) of using AES-256 hardware encryption to protect user data and deleting the key during a factory reset, we did find unencrypted data in the form of Ascii files in cache, log, and preference files though its precise purpose was unclear. 115 new post-reset files did include files of forensic value in directories UserSettings, EffectiveUserSettings, com.apple.mobilemail/Cache, fsCachedData, photostream, and bulletinboard, apparently from the reset and subsequent rebooting, and Table 2 includes some examples.

"Preferences" can include private user information (Zhu et al, 2014) though we saw none here. However just using the data we found using BulkExtractor, an investigator could determine where the user was, when and how they used the device, their deleted applications, network configuration, cache data, keywords, and even some plaintext keys

Timeline analysis showed the reset reduced the number of files with modification times within the last month from 18,000 before the reset to 500 after the reset. On the other hand, of the files with modification times earlier than one week before the reset, there were 43,984 before the reset and 42,468 after. It appears that older files are rarely deleted in a reset, but it is unclear whether this is due to their timestamps, location, or contents.

3.4 Effects of Alternative Resets

Most devices provide an alternative "hardware reset" using the hardware keys (with many different device-specific procedures described on factory-reset.com), and this is usually coupled to rebooting. On the test Android, the hardware reset gave a new menu which enforced a "cache reset" as well (an option for the software reset). An image after this kind of reset was taken on our test Android after the regular reset, and 3391 files out of 3578 remained identical. It did not delete any of the files and media put on the device, and deleted only the sixth interesting file in Table 1. Only four files all with extension "db" were deleted, two for Bluetooth and two for "optables". Six new files were added, two Bluetooth cache files and four "telephony" files. Thus it appears that the cache reset does not do much beyond the regular reset, though it apparently does not execute identical code.

The iPhone hardware reset just sends the user to the regular reset "Erase All Content and Settings" used in section 3.2. But newer iPhones provide six additional software reset options that can confuse users: "Reset All Settings", "Reset Network Settings", "Reset Keyboard and Dictionary", "Reset Home Screen Layout", and "Reset Location and Memory". In our experiments, all of these were selected, an image taken, and the results were compared to that of just doing the first option. 222 additional files were deleted and 144 were added to the 43,165 files, so it did delete additional files, but nothing in Table 2. No obvious patterns were discerned in the deletions. Thus it appears that the additional reset options do not affect very much though they do not execute identical code as the regular reset.

We also employed a "firmware reset" to restore the test Android back to the standard Android operating system after a regular reset.  We then took an image, did a regular software reset, took an image, did another software reset, and took a final image. The second regular reset deleted 161 files and added 259, and the third regular reset deleted 98 and added 88. This shows that effects of the firmware reset were inconsistent even on a previously reset device, which suggests opportunities for investigators.

4. Experiments with a set of devices

4.1 The Mobile Corpus Used

To see how general this analysis was, pre-reset and post-reset images of 21 previously owned devices were analyzed (Table 3). Some were from the Real Data Corpus (Garfinkel et al, 2009) of drives purchased as used equipment and were unmodifiable. Others were smartphones that have been used for other research projects at our school and were modifiable. Additional files were created and downloaded for the modifiable devices similarly to the experiments in section 3. None of the phones were password-protected and no data were explicitly encoded or encrypted. Unlike in section 3, the devices were not reset before taking pre-reset images (and the two phones of section 3 were imaged before the tests reported there) to test persistence of a wider range of files.

Table 3: Devices Tested in Our Mobile Corpus

The table lists the devices tested, with a variety of manufacturers and operating-system versions to provide breadth to experiments. Very few files were found on the BlackBerry images and no software, so Cellebrite appears to have had trouble imaging them. Those not identified as Apple or BlackBerry were Google Android devices, and two had a custom operating system CyanogenMod 10.1. The table indicates several problems in using the devices, resetting them, and analyzing them. Some devices (p22 and p28) could not be handled at all by Cellebrite. Some devices (p27) were apparently faulty. Some (p19) had special requirements that could not be accomplished. Some (p9 and p14) had special requirements for reset. Some (p17, p24, and p26) had a too-efficient reset that made the devices subsequently unable to restart. Also, four phones needed to be processed more than once due to Cellebrite crashes. It appears that forensic investigators will need to accept a significant failure rate in attempts to analyze devices they acquire.

4.2 Effects of Resets on File Counts

Many files were unchanged by the reset. Table 4 gives a summary of pre-reset and post-reset file counts. As before, there were four types of partial matches between pre-reset and post-reset: filename and hash (typically, when a file is moved), hash only (when a file is copied), path only (when a file is modified), and path ignoring digits (for temporary files). The "unmatched" files post-reset are interesting as they represent new records created by the reset itself and routine operating-systems activity. As we saw in section 3, resets do not simply erase devices; they delete many files, but rename others and add some new ones.

Table 4: Summary Data on the 21 Usable Devices

To get a better understanding of what kinds of files are being removed, files were classified by type of file extension (E) and type of the immediate directory (D) (Table 5). Our current taxonomy classifies 8,346 extensions and 6,445 directory names, labeling the rest as "miscellaneous".  Proposed extensions longer than 10 characters were ignored, and the file path above the bottom-level directory was searched until a directory was found which could be classified.

Overall, it appears that resets preponderantly target files with extensions of pictures, video, documents, copies and temporaries, disk images, logs, XML and games. They had little effect on extensions of operating-system files, configuration files, and executable files. Results were similar with classifying files by immediate directories. The resets primarily targeted files in directories mentioning pictures, video, documents, temporaries, Web pages, applications, and games. They had little effect on directories of the operating system, security, and the root. Thus resets appear to predominantly target third-party software and some (but not all) categories of likely user files, but ignore user data in the operating system and other configuration data. We observed that the number and types of files deleted did not differ significantly on the more-recent operating systems (p10, p15, p16, and p18).

Table 5: File Type Counts Before and After Reset