Synthetic Pixel-class full file system baseline

Reference answers

26 cases in 6 categories. For each case the set holds the files and a record of what was done: every action with its true time, the file and field where its trace sits and how the time is stored, what the removed app left in each store, and bounds on the removal time.

The answers are in reference_answers.json (one record per case), reference_actions.csv (one row per case and action) and reference_residue.csv (one row per case and store, for the removed app). A case record gives the clock offset used for wall-clock strings, the extraction time, both apps with their install and open times, the account, the Wi-Fi network, the Bluetooth sections (paired and only seen), the list of actions with their evidence (file, item, value as stored, time in UTC, role), what the removed app left behind, the bounds on its removal time, and expected_rows: the number of rows each public ALEAPP artifact should return.

What the removed app left behind

These counts describe this synthetic set, in which each case fixes one profile on purpose. They are not how often a real phone keeps each trace; for that see LAB-TR-0035. In 1 of the 24 handsets no store names the removed app at all.

Limits. No file in a case stores the removal time; the answers give a lower bound (the removed app's last foreground event, readable in 21 handsets, and with its name in 2) and an upper bound (the extraction time). Where the app was removed from the package installer dialog or the Play Store, a foreground event of that app a few seconds before the removal is an indicator, not proof; an adb removal has none. The Bluetooth Timestamp key equals the pairing time here; on a real phone the key can be rewritten when the stack saves the device again, so it need not. A section with a link key is consistent with a bonded device; a section without one does not show a pairing. A missing trace does not prove an action did not happen.

Try it with free tools

Python 3, a SQLite browser and a plain text editor are enough. Nothing here needs a commercial tool.

1. Check the download. Compute the SHA-256 of the zip and compare it with the value below: python -c "import hashlib,sys;print(hashlib.sha256(open(sys.argv[1],'rb').read()).hexdigest())" pixel-ffs-baseline-1.0.zip
2. Unzip it and open one case folder. Do not open reference_answers.json yet. Note the stated extraction time in SYNTHETIC.txt.
3. Open the accounts databases in DB Browser for SQLite or the sqlite3 shell. In accounts_de.db read last_password_entry_time_millis_epoch (Unix milliseconds) and the debug_table time (device wall clock). Which gives UTC without knowing the offset?
4. Read the binary XML. Most XML files here are Android binary XML. Run python tools/abx_to_xml.py data/misc/apexdata/com.android.wifi/WifiConfigStore.xml. Plain text cases open in any editor. Find the creation time of the saved network and work out its UTC time from the offset in the answers.
5. Find the apps. In packages.xml list the packages that start with org.synthlab and convert ut (hexadecimal milliseconds): python -c "import datetime,sys;print(datetime.datetime.fromtimestamp(int(sys.argv[1],16)/1000,datetime.timezone.utc))" 19f0e42b19b (the value in v03-standard-03; use the one in your case). One of the two apps from the script is missing.
6. Look for the missing app elsewhere. Search the whole case folder for its package name (a text search over the decoded XML and the databases). Which files still name it? Which do not? Are its usage records there under an empty name?
7. Read the Bluetooth file in a text editor. Which sections have a LinkKey and which do not? Is there a Timestamp?
8. Compare with reference_answers.json: your timeline against actions, your list of files that name the removed app against removed_app_names_still_held_by.
9. Optional. Point the public ALEAPP at a case folder. The Lab ran the parsing code of 14 ALEAPP artifacts (accounts, Bluetooth, Wi-Fi, install sessions, package restrictions, orphaned package states, installed apps from the Play Store, settings and Android IDs) over all 26 cases without its window, at commit 7bc49e3e of 24 October 2026. Row counts agree with expected_rows, and four times (account added, first app install, install session, Bluetooth Timestamp) agree to the second. Usage statistics and package_info were not run there because the libraries they need were not installed; their expected counts are in the answers (usagestats_event_rows, package_info_rows).

Try the challenge: Same artifact, different Android versions (Practitioner). Also built on this set: What a missing setting means, Link records across stores.

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)

Cite this dataset

@dataset{sectratek-lab-ds-0003,
  author    = {Addai, Daniel},
  title     = {Synthetic Pixel-class full file system baseline},
  year      = {2026},
  version   = {1.0},
  publisher = {SectraTEK Lab},
  url       = {https://lab.sectratek.com/datasets/pixel-ffs-baseline/},
  note      = {DS-0003, SHA-256 of manifest.json 38e2bddc3a94a2058f29b0bd5a316d74a6e27516f52dd61e3464ccea46559574}
}

Related

• Report: Where removed apps leave tracesA per-store measurement on real Android and iOS extractions; this set applies one profile per case
• Dataset: Synthetic recovery-history setThe Android-side synthetic set built the same way
• Dataset: iPhone sysdiagnose-style setThe iPhone counterpart, with the same script idea

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.