Samsung recovery and reset trail

Summary

• Samsung phones keep a log of every recovery run in two files, efs/recovery/history and efs/recovery/extra_history. Copies of recent runs may also sit in cache/recovery.
• Each run has a two-letter code. A factory reset confirmed in Settings appears as --wipe_data with --reason=MasterClearConfirm and a --requested_time=. The same code in extra_history shows /data, /cache and /metadata being formatted.
• A region change after a SIM swap is logged as --just_exit with [SIMBasedChangeCSC]. It is a run through recovery, not a reset.
• After a wipe the recovery clock can read 1970. On the one device we checked, the gap between two wipe entries matched the gap between their requested times to within a second, so later entries could be given an estimated time. On a second phone with two wipes the same check failed by more than a year, so treat any estimate as unreliable.
• In our research collection the Samsung efs history files were only in full file system extractions. In seven bug reports, recovery files were present in three, as copies in cache/recovery, and none showed a wipe.

This is early research. Treat each item as an indicator that is consistent with a reset, and read the limits before you rely on it.

Background

Android has no single reset date. Earlier public work looked at how a factory reset can be recognised after the fact. It points to the Samsung recovery history file we describe here [1] [3] [4], and to a boot reason of reboot,factory_reset kept in persistent_properties, where only the last three boots were found to survive on the Pixel tested [1]. The same author published the work again in DFIR Review [2]. An academic study from 2014 asked a different question, what data a factory reset leaves behind [5].

We wanted to know whether the layout is unchanged on a current Samsung build on Android 16, how the records link to each other, whether a time can be recovered when the recovery clock cannot be trusted, and which of these traces survive into a bug report, which is a far more common thing to be handed than a full file system extraction.

Method

We read the recovery files, the boot reason history, the setup flags and the settings of full file system extractions of Android phones, among them a phone whose recovery history holds two wipe requests. No independent record of what was done to that phone is used here, so the entries are read as the device recorded them. Entries were matched between files by run code and counted twice by independent routes. For the bug report side we read seven reports from our research collection and checked which of the same artifacts they hold.

Everything on this page is shown as abstractions: offsets from t0, no model numbers, no real dates. The two phones differ in size of history (five and three history entries). The timeline in Figure 1 comes from the larger one.

Findings

A reset in the recovery log

Every recovery run is written to efs/recovery/history, oldest first. The header carries a two-letter code, the recovery program's own date, and the firmware. The lines below it are the options recovery was started with. Figure 1 shows five runs from one phone.

A factory reset confirmed in Settings shows --wipe_data and --reason=MasterClearConfirm, plus --requested_time=, the wall-clock time the request was made. The three formatted volumes are in the second file.

+ [Je | <recovery clock> | FIRMWARE] -
--wipe_data
--requested_time=<t0, wall clock>
--reason=MasterClearConfirm
NP -

One code links the two files

The file efs/recovery/extra_history repeats the run code on each line, followed by [S] or [E] for the start and end of a step, as in [Je][S] format_volume : /data. For a wipe, the code in the history entry also appears on lines that format /data, /cache and /metadata. That link is what separates a real wipe from a run that only carries the option. Figure 2 shows the link for all five runs.

SIM region changes are not resets

When a SIM from another carrier is inserted, many Samsung phones switch their region and carrier software (CSC) and reboot into recovery. The run is logged with --just_exit and a reason such as [SIMBasedChangeCSC] XAA -> TMB. In our images, XAA is the unbranded, unlocked US software, TMB is T-Mobile US and VZW is Verizon. A fourth code appears as another region code. No format lines follow, which is the difference from a wipe.

A region change matters for a reset question in two ways. It must not be counted as a reset, and it can still be dated, because it sits in the same log.

Time: the recovery clock and an estimate

The date in a history header is the recovery program's own clock. After a wipe it can read 1970 (and 2010 in one bug report we looked at), so on its own it dates nothing. --requested_time= is different: the program that asked for the reset wrote it, and it is a real wall-clock time.

On the one device we could check, the gap between the recovery clocks of two wipe entries matched the gap between their requested times to within a second. The recovery clock was wrong in absolute terms and right in elapsed terms on that device. A cautious rule would give a later entry an estimated time by anchoring it to the nearest earlier wipe, using the anchor's requested time plus the clock gap. We then tested a second phone with two wipes: the clock gap and the requested-time gap differed by 526 days. The rule is therefore not safe to apply without a check against the requested times, and we do not recommend using it on its own.

Other artifacts we examined

• Boot reason history. persistent_properties keeps the last few boots as reboot,<epoch> or reboot,<sub>,<epoch>. We read it from both images (two and three entries) and from all seven bug reports. We found no factory_reset entry in any real image or report we checked, so its absence tells you nothing.
• Setup flags. user_setup_complete and device_provisioned changed from 1 to 0 to 1 around system updates. A change in these flags alone is not a reset indicator.
• Settings storage. On Android 16 the settings are Android Binary XML, so a plain text search will not find them. A parser must decode them first.
• cache/recovery copies. The names last_history, last_all_history and last_extra_history exist for recent runs. In both full file system images we examined the folder was empty.

Where each indicator lives

The same trail looks different in a full file system extraction and in a bug report. The Samsung efs history was only in the full file system extraction. In seven bug reports, recovery files were present in three and none showed a wipe. The boot reason history was present in all seven.

What this does not prove

Reproduce

1. On a test phone you own, write down the time. In Settings, start a factory reset and confirm it.
2. After setup, insert a SIM from another carrier and let the phone restart. Write down the time of each step.
3. Take a full file system extraction and open efs/recovery/history and efs/recovery/extra_history. Look in cache/recovery too.
4. List the entries oldest first. For each, read the command and the reason. Look the code up in extra_history.
5. For a time, use --requested_time= when it is there. Otherwise anchor an estimate to the nearest earlier wipe and label it.
6. Write down what is missing and why that does not prove anything.

For a bug report, generate one on the device and look for the same files and for the boot reason history. Expect the recovery files to be absent.

Open-source parsers

Merged Readers for these artifacts are merged in the open-source parser ALEAPP: recovery history entries, including the copy of the log inside a bug report kept in an extraction (ALEAPP #1834), and boot reason history and setup flags (ALEAPP #1835). The files are plain text, so you do not need them to repeat this work. See Open Source for status.

Appendix: downloads

Small synthetic files that reproduce the figures. They contain offsets from t0 and no real dates or identifiers. Licence: CC BY 4.0.

References

Titles, authors and dates of these sources were checked against each page on 7 November 2026.

Version history and corrections

Corrections log

No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.

Related