When was this phone last factory reset? It sounds like a simple question, and it comes up constantly in mobile device work. The answer usually matters a great deal. It establishes a timeline of evidence preservation, it proves or disproves claims about device wipes, and it settles whether any activity from before a given date could have survived on the device at all.

We worked a case recently on an unlocked Samsung Galaxy A16 5G where that was the whole question.

Starting with Cellebrite, and where it stops

The first move is a full extraction parsed in Cellebrite Physical Analyzer. Searching the activity timeline for "reset" returns two distinct kinds of hit: entries labeled "Reset" and entries labeled "Factory Reset." Anyone doing this for the first time runs straight into the obvious question of what separates the two.

In Cellebrite's timeline, a generic "Reset" entry usually means a soft reset. A reboot, a system restart, a routine recovery event, nothing that wipes user data. The on/off history of any phone produces a long trail of these, because every power cycle leaves one. A "Factory Reset" entry is meant to represent the destructive --wipe_data operation that erases user data and returns the device to a clean state.

Those labels are Cellebrite's interpretation of the underlying data, not the underlying data itself. To confirm a real factory reset and pin down when it happened, you have to go verify the artifacts yourself.

Three signatures inside 99 seconds

A genuine Android factory reset leaves a fingerprint that no OTA software update can reproduce. On this device, three independent artifact sources agreed on the same moment, within a span of about 99 seconds.

Samsung's recovery log at efs/recovery/history recorded the literal text PANIC: Hard Reset Hook. That is the kernel-level entry written when a --wipe_data recovery operation begins.

81 seconds later, a brand-new yearly usage-statistics database was initialized at data/system/usagestats/0/yearly/. A factory reset wipes the entire /data partition, existing usage stats included. A fresh yearly bucket appearing at that moment is only possible on a clean filesystem.

98 seconds after the recovery log entry, data/system/packages.xml was rebuilt, and every system app on the device was re-stamped to that exact moment. Package manager does not behave that way during an OTA update. It behaves that way on first boot after a /data wipe.

Any one of those three, on its own, could be explained some other way. All three landing inside a hundred-second window cannot. They only co-occur during a real factory reset.

The restored backup

After confirming the reset, we wanted to know what happened next.

The device's WiFi configuration store (WifiConfigStore3.xml) held several dozen saved networks, all of them marked HasEverConnected=false with identical reboot counts. That is the textbook signature of a bulk restore from Google backup during the post-reset setup wizard. The networks had been imported from the cloud, but the device had not yet physically connected to any of them at the moment they were written to the file.

So the owner restored their data after the wipe and went on using the phone normally from there.

Ruling out a swapped handset

For thoroughness we cross-referenced the on-device identifiers, meaning IMEI, serial number, model code and production date, against Samsung's official IMEI lookup service. Every field that could be checked matched: manufacturer, marketing name, both IMEIs, serial number, model number, production date, ship date, country of sale. No discrepancies between Samsung's records and what came off the device.

That closed off the possibility that the device had been spoofed, or that we were reading artifacts from a different physical handset than the one on the table.

Where to look on a case like this

If you are working a similar question, these are the on-device locations worth pulling:

What this case came down to

A label on a Cellebrite activity line is a hypothesis. Confirming a factory reset, and separating it from a routine reboot or an OTA update or any other system event, means triangulating multiple independent artifacts that can only line up the way they do for a real --wipe_data operation.

Three signatures inside a hundred-second window, plus corroborating evidence of a backup restoration in the hours that followed, gets you a defensible answer about when the device was wiped and what happened afterward. One artifact on its own does not.

Case details have been generalized to protect client confidentiality. Published with client consent.

Need to establish a wipe timeline on a device in your matter? Our Mobile Forensics and Litigation Support teams handle this work — open a case to discuss yours.