Understanding how files are created on a system after a wipe will also provide a close correlation with the exact time of a wipe. For example, many of the files listed above will contain valuable information.
The appops.xml file located at /data/system/ will include xml tags along with a unix epoch timestamp closely tied to wiping activities.
The XML tags below are specific to the device manufacturer:
com.google.android.setupwizard - XML tag (Pixel)
com.sec.android.SecSetupWizard - XML tag (Samsung)
Digital Wellbeing is an artifact that presents on modern Android devices (Android 10 +). The database, which logs events along with their associated Android package, contains DEVICE_SHUTDOWN and DEVICE_STARTUP events tied to the “android” package. Shortly thereafter, activity related to the “setupwizard” package can be found on freshly wiped and restored devices. This artifact varies slightly per manufacturer.
Path to database for Digital Wellbeing:
/data/data/com.google.android.apps.wellbeing/databases/app_usage (Pixel)
/data/data/com.samsung.android.forest/databases/dwbCommon.db (Samsung)
Android setupwizard packages:
com.google.android.pixel.setupwizard (Pixel)
com.google.android.setupwizard (Samsung)
com.sec.android.app.SecSetupWizard (Samsung)
You may recognize Android’s internal.db, the database that tracks internal, on-device files, by its similarly sounding name and external storage tracking equivalent, external.db. Using this database, only available on FFS acquisitions, you will notice many of the system files that created after a device boots into the operating system for the first time. Again, the artifacts will differ slight per manufacturer but the date_added column timestamp can be closely correlated to a factory reset of an Android device.
Path to internal.db:
/data/data/com.android.providers.media/databases (Pixel)
/data/user/%USER%/com.google.android.providers.media.module/database (Pixel)
/data/user/%USER%/com.android.providers.media.module/databases (Samsung)
In fact, there are many actions carried out following a wipe and reboot process will can be closely tracked to their corresponding artifacts. To illustrate the process of wiping/factory resetting a device, several make/model/firmware versions were utilized and reviewed to find the best collective evidence that would suggest a wipe.
The artifacts that proved to be the most consistent across devices were those located at the paths listed below:
• userdata/misc/keychain/serial_blacklist.txt
• userdata/misc/keychain/metadata/version
• userdata/misc/keychain/pins
• userdata/misc/keychain/pubkey_blacklist.txt
The creation dates of most files will be reflective of steps in the reboot process occurring after the factory reset/device wipe. In some cases, the creation date is not accurate (i.e., 1/1/1970, and, therefore, the modification date should be used).
The images in this slide reflect the on-screen prompts that occur during reboot after reset and the corresponding files that have timestamps consistent with when the artifact was created.
It’s also important to note that depending on the user’s selections, different artifacts could be created. For example, in this case, the user connected to a network as part of the initial setup process, which generated the artifact seen in the herrevad.db.
Lastly, don’t overlook manufacturer or service provider artifacts, like in this case, many of the service provider artifacts (T-Mobile) correlate with the time of reboot after factory reset.
Reference:
[1] https://thebinaryhick.blog/2021/08/19/wipeout-detecting-android-factory-resets/