Samsung Smart Switch transfer history

Summary

This contribution adds one module, samsungSmartSwitch.py, with eight artifacts for Samsung Smart Switch (com.sec.android.easyMover): transfer sessions, transferred data categories, the other device's app and category list, its accounts, its message and contact counts, the transferred history list, and the backup media index. It produces one set of rows per Android user and reads the duplicate storage views of one file once.

On four Android 16 images the numbers were uneven: 2, 0, 1 and 1 sessions. One image held the app but no history folder. Among the other research images, ten Samsung images carry some Smart Switch data and none holds a history folder, a transfer list or a backup media database, so all eight artifacts report no rows on them. The rows described here come from Android 16 only.

The issue

A phone that arrived by transfer rather than by a fresh set-up raises a question: where did its contents come from? Samsung's Smart Switch is the app that moves data between phones, and it keeps notes about each session in its own data folder. ALEAPP had no artifact for them, so a report said nothing either way.

The notes are not hard to open by hand, but there are many of them: one folder per session with up to three JSON files, a list of transferred entries, and a database with thousands of rows. Reading raw JSON for categories, counts and peer fields is slow, and two properties make it error-prone. Newer files drop keys that older files held, so a reader written against one image shows blank columns on another. And a phone with more than one Android user holds a copy of the app data per user.

There is also a trap on the empty side. The app was present on some phones without any history at all, so an absent folder is not evidence that no transfer took place. Figure 1 shows where the records sit and which artifact reads which file.

The essence

The module reads each Smart Switch file into its own artifact and keeps the values as stored. A session is one history folder, identified by the Android user and the folder name, which is a number that reads as epoch milliseconds and is shown as UTC. The other device's description, its lists of apps and accounts, and its message and contact counts come from the peer file in the same folder, exactly as that file wrote them. They are not checked against the other device.

Our methodology

We began by mapping the files. Across the Android 16 images that held data, the same JSON files carried different keys: Connect Type, Product Code, Predicted Backup Time, Restore Step, Backup Result, Backup Step, Backup Error and, on one image, the message counts were absent from newer files. So the parser treats every key as optional and reads a missing one as blank. A folder that lacks one of its three files is still reported, with that file's columns empty.

Keys were next. A session is the pair of Android user and History ID. The user comes from the path: data/data counts as user 0, and the user, user_de and mirror forms carry their own numbers. Duplicate storage views of one file are read once. Times are converted from milliseconds to UTC and blank when absent or zero, and the time columns are moved to the front of each report.

Checking took five forms. An independent script, with no ALEAPP code, parsed the JSON files and counted the bkmedia rows and gave the same numbers as the artifacts. Figures in the notes, such as 32 and 11 categories in two sessions, 29 with a status of COMPLETED and 3 with NODATA, 118 apps, 8 accounts and 6 message periods per session, were re-derived from the raw JSON. The tool's output checker found columns that held one value on every row, for example Android User on a single-user image, and Restore Error and Backup Error that were identical because the file stores the same text in both objects. We wrote these into the notes instead of leaving the reader to wonder. A synthetic tree built by a fixture script, with invented values, an all-zero IMEI and a placeholder identifier, covers user 0, its mirror and user 10, with six new unit tests that pass. And a doubling test on a tree built from the real files read all eight artifacts exactly double.

One check failed, and we kept it. On the synthetic tree, seven of eight artifacts doubled, but Transfer Sessions went from 3 rows to 4 instead of 6, because the fixture already holds a user 10 folder with the same History ID, so the restaged copy lands on it. The pull request records this as a known failure with the arithmetic. The suite otherwise passed 140 cases with no failure.

We also left things out on purpose. Galaxy Wearable data was examined and not built, because its databases were empty. Newer images carry result fields that this module does not report, and the notes say so. Figure 2 shows the steps; Figure 3 shows the counts per image.

The value

For an examiner the module turns a folder tree into answers to concrete questions. Was a Smart Switch session recorded on this phone, and how many? Which data categories did it list, with what status and counts? What did the other device describe itself as, and which apps and accounts did it list? Is there a media index, and how large? A session folder is an indicator that the app recorded a transfer session. It does not prove that a category moved in full, and a category missing from the list is not evidence that its data was absent from the other device.

The records carry personal identifiers, including an identifier, a display name, an account and a device number. The Lab publishes the structure and the counts, never a value. Figure 4 shows, with invented times, how an examiner can line up a folder name with the transferred list entry; on one real image the later folder name fell within one second of the entry's time. The parser does not make that match, and what event a folder name marks is not established.

Where this sits in the Lab's research

No Lab report is devoted to this store; the method above comes from the pull request. It is one of five case studies in Lab Technical Report LAB-TR-0006, Section 7.1 and Table 8, which gives the same counts per image (sessions 2, 0, 1, 1; categories 43, 0, 92, 65; backup media 5,169, 0, 0, 0) and lists as not verified the One UI versions before 7. That report also describes the doubling test used here.

Cite as: Addai, D. (2026). Empty Is Not Absent: Silent Failure Modes in Open-Source Mobile Forensic Parsers on iOS 26 and Android 16. LAB-TR-0006, version 1.0, preprint. doi:10.5281/zenodo.23717929.

Sources

Every number and claim on this page, and where it comes from. Figures marked synthetic example use invented values.

Related posts