DS-0001

Samsung reset and recovery: paired extractions

12 invented Samsung handsets, each captured two ways: a full file system folder view and a bug report view of the same phone. Each was reset at known times, had SIM region changes between, and was captured afterwards. Compare what each evidence source keeps. Every file is synthetic.

Full file system viewBug report viewSynthetic filesVersion 1.0Data CC BY 4.0Code MIT

Get the dataset See one pair Try the challenge

At a glance
What is inside
What each source keeps
Reference answers
One pair
Try it
Download and licence
Hashes
Cite

At a glance

What the set is, how it was made, and how it may be used.

Built from what the Lab learned on real devices provided to the Lab by partners; every file here is synthetic, so no case data is exposed.

Describes the same files as LAB-0001. Plain text, so any editor opens them. Read with the bug report categories in LAB-0002.

Device class: None (invented Samsung-style handsets; model SYNTH-SM-001)
OS: Android 16 class, invented firmware names (SYNTH-FW-A, SYNTH-FW-B)
Evidence type: Full file system view and bug report view, as synthetic files
Made on: A script (generate.py, Python standard library) with seed 20261106. No device, no case data and no real identifiers. The same seed gives the same bytes. All times are UTC.
Contents: 12 pairs in 5 categories: 24 factory resets and 26 SIM region changes in 50 recovery runs. 179 files in the zip.
Size: 93 KB as a zip (95,730 bytes)
Version: 1.0
Licence: Data: CC BY 4.0. Generator code: MIT.
Maintainer: Daniel Addai, SectraTEK Lab

What is inside

Each pair folder holds two views of one phone. The full file system view (ffs/) has the Samsung recovery files, the cache folder, the region code, the bootstat record and text renderings of two more files. The bug report view (bugreport/) has the main text file with an uptime line, system properties and dumpsys excerpts, and in 4 pairs a copy of the latest recovery run.

Folder layout (one pair shown)

samsung-reset-pair/
  README.txt  LICENCE.txt  WORKSHEET.txt
  reference_answers.json  reference_answers.csv
  generator/generate.py
  pairs/
    p01-two-resets-plain-01/          (12 pair folders, same layout)
      ffs/
        efs/recovery/history
        efs/recovery/extra_history
        efs/imei/mps_code.dat
        cache/recovery/last_log  last_log.1 ...  last_history  last_extra_history
        data/misc/bootstat/factory_reset
        data/property/persistent_properties.txt
        data/system/users/0.xml
      bugreport/
        bugreport-SYNTH-SM-001-<firmware>-<build>-<date>.txt
        dumpstate_log.txt  main_entry.txt  version.txt
        FS/cache/recovery/last_history  last_extra_history  last_log   (4 pairs)

Two files are text renderings of formats that are not plain text on a real phone: persistent_properties.txt (the real file is binary) and users/0.xml (real files may be Android Binary XML). factory_reset is an empty file whose modification time is the value, as in AOSP bootstat; in the zip that time is stored with 2-second resolution. The bug report is an excerpt: it holds the sections the set models and leaves the rest out. The layout of the FS/ folder inside the bug report is invented.

The 12 pairs

The pairs in DS-0001 and how each differs
Pair	Runs (W reset, R region)	Recovery clock	Cache folder	Bug report copy	Boot history entry
p01-two-resets-plain-01	`W R W R`	Real time	Present	No	factory_reset kept
p02-two-resets-plain-02	`W R R W R R`	Real time	Present	Yes, a region change	Rolled off
p03-two-resets-plain-03	`W R W`	Real time	Present	Yes, shows a reset	factory_reset kept
p04-clock-1970-01	`W R W R`	Reads 1970	Empty	No	Rolled off
p05-clock-1970-02	`R W R W R R`	Reads 1970	Present	No	factory_reset kept
p06-clock-1970-03	`W R R W`	Reads 1970	Present	No	Rolled off
p07-clock-gap-disagrees-01	`W R W R`	Reads 1970	Present	No	factory_reset kept
p08-clock-gap-disagrees-02	`W W R R`	Reads 1970	Present	Yes, a region change	factory_reset kept
p09-one-reset-01	`W R R`	Real time	Present	No	factory_reset kept
p10-one-reset-02	`W`	Real time	Present	Yes, shows a reset	Rolled off
p11-three-resets-01	`W R W R W R`	Real time	Present	No	factory_reset kept
p12-three-resets-02	`R W W R W`	Reads 1970	Empty	No	factory_reset kept

What each source keeps

Counts over all 12 pairs, as the set is built. A reset leaves the efs folder alone and formats the data and cache volumes, so the model keeps every run in the efs history while the bug report holds only what has been written since the last reset.

What the full file system view and the bug report view keep
Question	Full file system view	Bug report view
Every factory reset the phone went through	24 of 24, in efs/recovery/history, each with its requested time and its three formatted volumes in extra_history.	12 of 24 show any trace and 9 of those name a reset directly. Only the last reset of each phone is visible; the 12 earlier ones are not.
SIM region changes	All 26, each with its from and to region.	12 of 26 show a boot through recovery after the last reset; 2 name the region change directly (a copy of the latest run). The current region is in every report.
Time of the last reset	The requested time, written by the program that asked for the reset.	The time of the first boot after it (user creation, system package install times): a few minutes after the request. 1 report prints the creation time as unknown.
Boot reasons	The same boot-reason history as the bug report, as a text rendering of persistent_properties.	Up to 3 boots since the last reset. 8 of 12 still hold the reboot,factory_reset entry; in the rest it has rolled off.
Recovery logs	cache/recovery in 10 of 12 phones: the logs of the runs from the last reset on. Runs before the last reset are gone from the cache folder.	A copy of the latest run only, in 4 of 12 reports (2 show a reset, 2 a region change).
Recovery clock	Printed in every history header; reads 1970 on 6 phones.	Not present, except inside a recovery copy.

These counts describe this synthetic set. They are not a statistic about real phones. A missing trace never proves a missing action: the bug report not showing the first reset is an effect of what it keeps, and says nothing about whether a first reset happened.

Reference answers

12 pairs in 5 categories. For each pair the set holds a record of what was generated and what each source shows of it.

Categories in DS-0001 and the reference answer for each
Category	Pairs	Setup	Reference answer	Resets / region changes
Two resets, real clock	3	Reset, SIM region change(s), second reset, SIM region change(s). The recovery clock prints the real time.	Both resets in the full file system view, only the last in the bug report; which region changes the bug report can show.	6 / 7
Recovery clock reads 1970	3	From the first reset on, the recovery clock prints a 1970 date. Some histories open with a region change.	The requested time of each reset, an estimate for each later region change, and the error of that estimate.	6 / 8
Jump in the recovery clock	2	As above, but a jump of 180 to 330 days enters the recovery clock partway through. In one pair the check between the two resets fails; in the other it passes and the entries after the jump are still wrong.	Which check fails, which estimates are wrong and by how many seconds, and where the bug report boot history gives a real time to compare with.	4 / 4
One reset	2	A single reset. One pair has two region changes after it; the other ends on the reset and its bug report holds a copy of that run.	One reset, nothing earlier to find; what the bug report shows directly and what it shows only by inference.	2 / 2
Three resets	2	Three resets with region changes around them. One pair prints the primary user creation time as unknown; one has a 1970 clock and an empty cache folder.	Two earlier resets that the bug report cannot show, and the one it can.	6 / 5

The answers are in reference_answers.json (one record per pair) and reference_answers.csv (one row per recovery run). They are kept outside the pair folders so you can work blind and compare after. Each pair record gives the device, the capture times, flags, the file lists, a summary of each view, the clock checks between resets, and one record per run: the run code, the type, the true time, the requested time, the recovery clock as printed, the region change, the time a reader would give from the files with its basis and error, and how directly the bug report shows it (direct, indirect or none, with where). A comparison block counts what each source shows. WORKSHEET.txt lists 18 questions to answer from the files.

Limits. The recovery clock, the boot-history cap of 3 entries, the wording of the dumpsys lines and the FS folder of the bug report are modelled, not measured. LAB-0001 reports a phone whose two reset clocks differed from the requested times by 526 days; the clock jump here is 180 to 330 days. The estimate rule (requested time of the nearest earlier reset plus the clock gap) is shown with its error in every 1970 pair; 1 pair has a gap check that fails.

One pair, read end to end

Pair p02-two-resets-plain-02: two resets with region changes between and after, a real recovery clock, and a bug report taken 3 days after the last region change. Start from the full file system view.

efs/recovery/history

+ [Rz | 2026/04/18 16:27:51 | SYNTH-FW-A] -
--wipe_data
--requested_time=1776529667
--reason=MasterClearConfirm
NP -
+ [wY | 2026/04/21 05:42:35 | SYNTH-FW-A] -
--just_exit
--reason=[SIMBasedChangeCSC] VZW -> USC
NP -
+ [Sz | 2026/04/23 23:23:00 | SYNTH-FW-A] -
--just_exit
--reason=[SIMBasedChangeCSC] USC -> TMB
NP -
+ [gy | 2026/04/24 13:56:56 | SYNTH-FW-A] -
--wipe_data
--requested_time=1777039011
--reason=MasterClearConfirm
NP -
+ [LY | 2026/04/27 06:50:17 | SYNTH-FW-A] -
--just_exit
--reason=[SIMBasedChangeCSC] TMB -> VZW
NP -
+ [Yr | 2026/04/28 07:18:15 | SYNTH-FW-A] -
--just_exit
--reason=[SIMBasedChangeCSC] VZW -> CCT
NP -

Two --wipe_data entries with MasterClearConfirm, run codes Rz and gy. The other four are region changes. The same code shows the formatted volumes in the second file:

efs/recovery/extra_history (lines for run gy)

[gy][S] format_volume : /data
[gy][E] format_volume : /data
[gy][S] format_volume : /cache
[gy][E] format_volume : /cache
[gy][S] format_volume : /metadata
[gy][E] format_volume : /metadata

Now the bug report of the same phone

Selected lines from the main text file (the dumpstate time is 2026-05-01 06:27:04 UTC):

bugreport/bugreport-....txt (selected lines)

== dumpstate: 2026-05-01 06:27:04
 06:27:04 up 2 days, 4:59,  0 users,  load average: 1.20, 1.10, 1.05
[persist.sys.boot.reason.history]: [reboot,recovery,1777272710
reboot,recovery,1777360781
reboot,1777426080]
[ro.csc.sales_code]: [CCT]
      Created: +6d16h27m5s0ms ago
  Package [com.android.settings] (a1b2c3d):
    firstInstallTime=2026-04-24 14:00:33

Reading it: the creation time of the primary user is written as a time-ago, so subtract it from the dumpstate time: 2026-05-01 06:27:04 UTC minus 6d16h27m5s0ms is 2026-04-24 13:59:59 UTC. That, and the install times of the system packages, sit a few minutes after the last reset (gy, requested at 2026-04-24 13:56:51 UTC). The boot history holds the last 3 boots; the reboot,factory_reset entry has rolled off. Nothing here mentions the first reset. A copy of the latest run is in FS/cache/recovery/last_history:

bugreport/FS/cache/recovery/last_history

+ [Yr | 2026/04/28 07:18:15 | SYNTH-FW-A] -
--just_exit
--reason=[SIMBasedChangeCSC] VZW -> CCT
NP -

What the reference answer says about it

Reference answer for pair p02-two-resets-plain-02, one row per run
Run code	Type	Time from the full file system view	Bug report	Where in the bug report
Rz	Factory reset	2026-04-18 16:27:47 requested_time	Not shown	Nothing found
wY	Region change (VZW to USC)	2026-04-21 05:42:35 recovery clock	Not shown	Nothing found
Sz	Region change (USC to TMB)	2026-04-23 23:23:00 recovery clock	Not shown	Nothing found
gy	Factory reset	2026-04-24 13:56:51 requested_time	Indirect	dumpsys user: Created; dumpsys package: firstInstallTime of system packages
LY	Region change (TMB to VZW)	2026-04-27 06:50:17 recovery clock	Indirect	persist.sys.boot.reason.history: reboot,recovery entry (a boot through recovery, not the region)
Yr	Region change (VZW to CCT)	2026-04-28 07:18:15 recovery clock	Direct	persist.sys.boot.reason.history: reboot,recovery entry (a boot through recovery, not the region); FS/cache/recovery/last_history, last_log

Both resets and all four region changes are in the full file system view. The bug report shows the last reset by inference (a time 188 seconds after the requested time, which is the first boot and not the request, consistent with a reset), and one region change directly. It does not show the first reset at all. That is what the 12 earlier resets in the set look like from the bug report side. The values are invented.

Try it with free tools

A plain text editor and Python 3 are enough. No file in this set is a database, so no SQLite browser is needed.

Download the zip below and check its SHA-256 against the hash on this page. On Windows: Get-FileHash samsung-reset-pair-1.0.zip -Algorithm SHA256. Elsewhere: sha256sum samsung-reset-pair-1.0.zip. Unzip it.
Pick a pair. Open ffs/efs/recovery/history and list the entries oldest first. Mark each as a factory reset (--wipe_data, MasterClearConfirm) or a SIM region change (--just_exit, [SIMBasedChangeCSC]).
Search extra_history for each run code. A reset has six lines (start and end for /data, /cache and /metadata); a region change has none.
Convert a requested time: python -c "import datetime as d; print(d.datetime.fromtimestamp(1777039011, d.timezone.utc))", with your own number.
If the history clock reads 1970, give each region change an estimated time: the requested time of the nearest earlier reset plus the clock gap. Then check the rule: does the gap between the clocks of two resets equal the gap between their requested times, within 2 seconds?
Open ffs/cache/recovery/last_log and the numbered logs. They carry no run code; match each to a history entry by the clock on its first line.
Open the file in bugreport/. Search for == dumpstate, up , persist.sys.boot.reason.history, ro.csc.sales_code, Created: and firstInstallTime. Is there an FS/ folder?
Write down, for each reset and each region change, whether each source shows it, how directly, and what time it gives. Then open reference_answers.json and compare. To print one pair: python -c "import json; d=json.load(open('reference_answers.json')); print(json.dumps(d['pairs'][1]['comparison'], indent=2))".

Try the challenge: Read a Samsung reset trail (Starter). Also built on this set: Map an Android bug report, One question, three evidence sources.

Get the dataset

One zip, 95,730 bytes. It holds 179 files: the pairs, the reference answers, the worksheet, the licences, a short README and the generator. Check it against the hash below.

Download samsung-reset-pair-1.0.zip (93 KB)

Served from this site, versioned. The manifest and the hashes are linked below.

SHA-256 of the zip

df3e311f0dbc8274850e209093654b3416f95e52a2e3c0e47f84c982a73f4d1e

The loose files, manifest.json and SHA256SUMS.txt sit beside the zip on this site. To rebuild every byte yourself, run python generate.py from the generator folder (Python 3, standard library only).

Licence

There is no acceptance step. Use the link above.

Data: Creative Commons Attribution 4.0 (CC BY 4.0)

A plain-language summary. The full text is at creativecommons.org/licenses/by/4.0 and in LICENCE.txt inside the zip.

You may

copy and share the files in any medium or format;
adapt them, for example to make test fixtures, and use them for any purpose, including teaching, research, casework and commercial work.

You must

give credit, using the citation on this page;
link to the licence and say if you changed the files.

Please also

keep the hashes beside any copy you share, so others can check it;
say that the files are synthetic. Do not present them as taken from a real phone or a real case. They are not.

Code: MIT

generate.py is under the MIT licence. Keep the copyright notice with copies.

The dataset is provided as is, without warranty.

Hashes

Check every file after download. The set hash is the SHA-256 of manifest.json, which lists the size and hash of every other file.

Set hash (SHA-256, manifest.json)

a1b27e2374927cbc6602b1af1128c756cb2522f98bc1fb9d1d825eac93fd9fa2

Files in DS-0001 with SHA-256 hashes
File	Content	Size	SHA-256
samsung-reset-pair-1.0.zip	Archive	95,730 bytes	df3e311f0dbc8274850e209093654b3416f95e52a2e3c0e47f84c982a73f4d1e
reference_answers.json	Reference answers	107,184 bytes	95218ef9de45f485851745ac0bce304152290d62f356120a5c50a26ad47163d8
reference_answers.csv	Reference answers (one row per run)	11,987 bytes	30017c5d1f51ccc74743206a76dfcf82b4edc5e4de87a15b6a7febc264b8d05b
WORKSHEET.txt	Questions to answer from the files	2,240 bytes	b66aa722be7a86c4530898f98befc993d0b16b74d18327cc5f9d32c7aee7d1d5
README.txt	Notes	3,380 bytes	631a64dd6a03d87f325cf1ad7147a635e1c7d071a64fd6c5a6d5ba5da1b8f896
LICENCE.txt	Licences	1,454 bytes	28870b199b4c02c69708156df9be3cc042d1db93999b19ae6a1066668e692003
generator/generate.py	Generator (MIT)	38,830 bytes	0f6301fadada687a8bd267da641aedce0cff185d28af60e9fdb88e600c71404a
manifest.json	Manifest (file, bytes, SHA-256)	34,746 bytes	a1b27e2374927cbc6602b1af1128c756cb2522f98bc1fb9d1d825eac93fd9fa2
SHA256SUMS.txt	The same hashes in sha256sum format	22,750 bytes	988d25698cf46f944d3b4c626857f26fc0402e5831aa01cc01ddb8e5e9183188
pairs/ (173 files)	Full file system and bug report views of the 12 pairs	51,585 bytes	Per-file hashes are in manifest.json

The zip holds the same files as the folder (the zip itself, manifest.json and SHA256SUMS.txt excepted). Together the files are 312,390 bytes before compression. Hashes and sizes on this page are read from manifest.json.

Cite this dataset

Cite as

Addai, D., SectraTEK Lab (2026). Samsung reset and recovery: paired extractions (DS-0001), version 1.0. SectraTEK Lab Datasets. https://lab.sectratek.com/datasets/samsung-reset-pair/. SHA-256 of manifest.json a1b27e2374927cbc6602b1af1128c756cb2522f98bc1fb9d1d825eac93fd9fa2

Citation guide

BibTeX

@dataset{sectratek-lab-ds-0001,
  author    = {Addai, Daniel},
  title     = {Samsung reset and recovery: paired extractions},
  year      = {2026},
  version   = {1.0},
  publisher = {SectraTEK Lab},
  url       = {https://lab.sectratek.com/datasets/samsung-reset-pair/},
  note      = {DS-0001, SHA-256 of manifest.json a1b27e2374927cbc6602b1af1128c756cb2522f98bc1fb9d1d825eac93fd9fa2}
}

Datasets carry their own licence. This one is CC BY 4.0 for data and MIT for code. Articles are CC BY 4.0. All licences.