The Footprint of Acquisition on an Android Phone: Footprint Classes, a Separation Rule, and Base Rates in Research Devices

1 Introduction

An acquisition is an action on a device. To read an Android phone over USB, an examiner needs developer options and USB debugging switched on and a host computer authorised [1, 2]. Some methods also install a bootloader or a software component, or accept wireless connections [3]. Each step writes something, and the writes land in the stores a later reader consults to learn what the user did last: the settings records, install records, directory times and the boot history. Guidance acknowledges that extraction may leave digital artifacts and asks for contemporaneous notes [3]. A second examiner, a reviewer or an expert for the other side often has only the device or its extraction, and no notes.

A motivating example. Suppose a question asks whether the user turned on USB debugging in the days before the phone was handed over. A constructed extraction (the values are invented for illustration) shows the developer-options and debugging settings switched on by the system Settings application 35 minutes before the extraction ended, the last start of the phone 50 minutes before, and the temporary-files directory written 20 minutes before. Read as use, this says the user prepared the phone for a computer at the last moment. Read as footprint, it says nothing about the user. In our data a pattern of this shape is common: in 6 of 8 settings histories a developer or debugging change lies within 6 hours of the end, and in the retained history before the last 72 hours the same change appears in 1 of 240 daily windows (Section 6).

The problem. Studies of acquisition ask whether the user’s data stay intact [4, 5, 6], and case reports use traces to show that a particular extraction tool was used [7, 8, 9]. What is missing is a measurement of the traces themselves on ordinary devices: which classes exist, how often they appear, when they fall relative to the end of the acquisition, and whether a rule can separate them from activity of the user. We ask four research questions.

• RQ1 (Classes). Which classes of footprint does an Android acquisition predict, and how long should each persist?
• RQ2 (Prevalence and timing). How often are footprint indicators present in research devices that were not selected for them, and when do they fall relative to the end of acquisition?
• RQ3 (Separation). Can a rule separate footprint from other activity, and how often does it fire where no acquisition took place?
• RQ4 (Named agent). Does the agent of one named acquisition method leave a trace in the collection?

Contributions. This report makes four contributions.

• Six vendor-neutral footprint classes with predicted artifacts, where each is read, and how long it should persist (Section 3).
• A separation rule that needs two classes inside a 24-hour epoch, with a false-alarm estimate for the two classes that have a history (Section 4).
• Measurements of the timing and prevalence of these indicators, which we did not find in earlier work, in 14 Android extractions and 7 bug reports, including the timing of settings written by the shell or root identity relative to the last start (Section 6).
• A search for the package of one named acquisition agent in all 21 sources, with a null result and a stated need for a controlled run (Sections 6.7 and 8).

Scope. The results describe the Lab’s research corpus: 14 Android full file system extractions (nine on Android 16 and 12 from one vendor) and 7 Android bug reports. The data do not record the steps of the acquisitions, so every statement says that an indicator is consistent with acquisition, never that a step was performed. Section 8 states the limits.

2 Background and Related Work

2.1 Guidance and acquisition studies

The best-practice document of the Scientific Working Group on Digital Evidence says that extracting mobile device storage may require installing a bootloader or a software component, gaining root access or accepting wireless connections, that these techniques may leave digital artifacts, and that documentation should include all changes made by interacting with the device and its settings [3]. Early collection work on Android noted that preparing a device alters its state somewhat and that rooting alters portions of it [4]. A study of user-data integrity during Android acquisition examined whether the user’s data change [5], and an evaluation of local-backup acquisition found backups to match the original storage in most but not all cases on two devices, with pending database changes a named corner case [6]. These studies ask whether the data survive the acquisition. We ask what state the acquisition itself writes, and how a later reader can mistake it.

2.2 Traces used to show that an extraction took place

Civil-society investigators have used device-side traces to conclude that a specific extraction tool was used. A 2026 report on four seized phones found, on the one Android phone, a package installed the day after seizure and deleted shortly after, with install and delete logs and usage statistics recovered, and attributed it to a named vendor with high confidence [7]. A 2024 report on Serbian cases gives a forensic timeline in which developer mode was enabled and, minutes later, disabled, and security features were switched off over the debug bridge [8]. A security talk describes how one tool’s interface asks the examiner to trust its keys permanently, so that an authorisation stays on the handset unless revoked [9]. These are case studies on selected devices that attribute a tool. We measure base rates on devices that were not selected for suspicion, in vendor-neutral classes, and we do not attribute any tool.

2.3 Android mechanisms and earlier Lab measurements

Developer options are enabled by tapping the build number, and USB debugging is a switch inside them [2]. When a host connects, the device shows a dialog that asks whether to accept its RSA key; wireless debugging adds a pairing step [1]. On recent releases an authorisation for a host that has not reconnected within seven days is revoked automatically unless a developer option disables this [10]. The settings provider names the relevant keys, for example one for ADB over USB and one for a boot count [11]. A bug report is captured through developer options or the debug bridge and holds the system log, service dumps and a start marker [12, 13]. Earlier Lab reports found developer options and USB debugging on in all 14 Android extractions, which they called acquisition-sensitive [14]; described the boot-reason history and the clocks of reset indicators [15]; measured how far back volatile stores reach [16]; and measured how often clock-anomaly checks fire on ordinary devices [17]. We build on all four and repeat none of their results.

2.4 Position of this work

This is a measurement of timing and base rates together with a rule, not a detection of any tool or vendor. It is restricted to the traces that Android itself keeps, and it treats a trace as consistent with acquisition, not as proof of it.

3 Footprint Classes

We derived the classes from the documented steps of an acquisition over the debug bridge (Section 2.3) and from the stores that the Android platform keeps. A class is vendor-neutral; the artifact that carries it may not be. Table 2 lists, for each class, the predicted artifacts, where we read them, how long they should persist, and the basis of the prediction. Figure 1 puts the classes on the time axis of an acquisition.

Two points follow from the table. First, classes F1 and F6 change what the device can still show: a restart is predicted to empty volatile logs and so to make the user’s recent use look sparse, the opposite error to mistaking footprint for use. Second, classes persist for different times, so the footprint seen by a later reader depends on when it reads: a directory time lasts until the next write, a host key for at most days, a settings change for months.

4 A Separation Rule

Let T be the end of the acquisition and E the epoch from T minus 24 hours to T. A class is observed if its test in Table 3 holds inside E. The rule has one step.

Rule. An extraction is footprint-consistent when at least two classes are observed in E. A change inside E of an observed class is then discounted: it does not stand alone as evidence of an act of the user. Everything else is not separable.

The rule never labels a change as the user’s activity: it says that the pattern is consistent with preparation for an acquisition and that a single change then proves nothing about the user. Two classes are required because each class alone has ordinary causes: users restart phones, and developers use shell commands.

A class counts as unobservable when its store is absent; the rule is then evaluated on the remaining classes.

False alarms. To estimate how often a class appears where no acquisition took place, we applied the two settings-history tests to 24-hour windows that end 72 or more hours before T, 30 windows back per device. This is a placebo, not an error rate: the retained history may be trimmed, and these windows are not guaranteed to be free of other acquisitions. The restart class and the directory class have no history and therefore no placebo.

5 Evidence and Setup

5.1 Evidence

The evidence is the Android part of the Lab’s research corpus, read-only (Data Handling Statement): every readable Android full file system extraction, held as a zip container, and every Android bug report. Table 4 gives the classes. Hash comparisons of device identifiers show that the 14 extractions are 14 different phones (14 distinct Bluetooth addresses, 12 distinct serial numbers on the 12 that carry one). The 7 bug reports carry 6 distinct serial numbers, none shared with an extraction; one carries none. We therefore count 14 phones and 7 further sources, not 21 phones.

5.2 Acquisition time and admission

Timing needs T. For 11 extractions the extraction metadata records the end time of the extraction; for 3 only the container file time is available. We admit an extraction to the timing analysis if T comes from the metadata, or if the newest system-state file lies between 0 and 24 hours before the container time. One container-time extraction passed. Two failed, one with its newest system-state file 237 days before the container time and one with a file time later than it; they enter the counts of states (Section 6.3) but not those of timing, which leaves 12. This follows the clock logic of earlier work [17].

5.3 Indicators and procedure

One script read the central directory of each archive, which gives every member’s path, size and modification time, and then copied a few small system files to a private scratch area to decode them: the settings values and their change history, the package and install-session records, the key files, and the persistent properties that hold the boot-reason history. Android binary XML was decoded with our own decoder. Times are the UTC fields stored in the archive. The script wrote only counts, minutes before T and class labels: package names were reduced to the class of their installer, and setting changers to a class (the Settings application, shell or root, the platform, another component). For the seven bug reports it read the uptime in the report header, the span of the system log (counted from the start of its body, see Section 6.6), and the install times of packages. The epoch was first set to 6 hours and changed to 24 hours after a first run, because two extractions had started 15 and 17 hours before the end and because a day is what examiners call recent. In that first run the shell or root test also required writes in both the last 72 and the last 24 hours, and the rule fired on 10 of 12; we simplified both before writing the results. A separate step searched for the vendor name contained in the package identifier of one named acquisition agent (Section 6.7).

6 Results

6.1 Restart

The phone had been started recently when the extraction ended. Across the 12 admitted extractions the median uptime at T was 3.7 hours (interquartile range 1.4 to 8.2); 5 were at most 2 hours, 9 at most 6 hours, 11 at most 24 hours, and the longest was 35.8 hours (Fig. 2). We read up to three boot sources: the boot-statistics file time, the file time of the install-session record, and the last step of the boot counter in the settings history (two sources on 6 extractions, three on 8). They agreed within two minutes on 12 of the 14 extractions. On one admitted extraction the boot-statistics file lagged the others by 44 hours, and one extraction outside the admitted set disagreed; we take the latest source.

The persistent boot-reason history held 2 to 4 entries on every extraction (median 3). Among the 12 admitted, entries from the last 24 hours were 18 in number and 8 of them (44%) held no reason string; of the 18 older entries 2 (11%) did. Five extractions had such an entry within 6 hours of the end. No history held a download-mode or bootloader reason; two extractions outside the admitted set held a recovery reason.

6.2 Debug state and shell or root origin

Developer options and USB debugging were on in all 14 extractions, wireless debugging in none, and stay-awake while charging was set on 10 (the finding for the first two repeats earlier work [14]). What the values cannot say is when they were set. The settings history can: it records, for each change, the time and the identity of the writer. It was present on 8 extractions. On 7 of them a change to one of the five developer or debugging keys was recorded in the last 24 hours, on 6 within the last 6 hours. Of the 46 such changes, 25 were written by the Settings application, 12 by the platform, 5 by another component and 4 carried no writer. By writer alone, more than half would pass as the user’s.

The shell and root identities are rarer. On 7 of the 8 histories they had written between 4 and 7 settings in the last 24 hours (median 5). The eighth ended 36 hours after the phone was last started and held none in that window, but it did hold five, written 35 hours before the end. No history held a shell or root write older than 72 hours: 0 of 8, with the histories reaching back 129 to 1,699 days (median 424). In the final 24 hours the history recorded a median of 142 changes of any key, of which a median of 12 (8.6% on the seven that recorded any) belonged to the debug and shell classes.

The shell and root writes follow the last start. On every history they touched the same few settings, four distinct ones on 7 histories and three on the eighth, spread over the three settings histories. The first write came 3 to 23 minutes after the last step of the boot counter on 7 of the 8 histories, and 100 minutes after it on the eighth, which recorded two boot-counter steps within 6 hours. Of the 40 boot-counter steps the histories retain, 9 lay within 30 minutes of a shell or root write: 7 of the 8 last steps and 2 of the 32 earlier ones. The write that is 35 hours before the end on the longest-running extraction has the same relation to its start. We therefore read the shell or root class as a marker of the last start more than of the acquisition end; it cannot be told apart from the restart class here (Section 6.5).

6.3 Directories, host keys and packages

The temporary-files directory was modified within 2 hours of the end on 9 of the 12 admitted extractions and within 6 hours on 11, a median of 85 minutes before (interquartile range 44 to 134); it was empty on 11 of the 12. The bridge directory was modified within 2 hours on 7 and within 6 hours on 10. A directory time survives after the files are removed, so an empty directory with a recent time is itself an indicator. Host key files were present on 3 of the 14 extractions (the permanent store on 2, the temporary store on 3), all on Android 12 or 13, and on none of the nine Android 16 extractions; the Android 16 containers hold the directory but no key file.

No agent remained on any device. Of 1,804 non-system packages on the 12 admitted extractions none had an install time in the 7 days before the end, whatever the installer, and no install session was created in the 72 hours before it. The package-settings file was nevertheless written within 2 hours of the end on 9 of the 12, which is consistent with a state change that left no package behind but does not show one.

6.4 File times

Modifications of system-state files concentrate at the end. For each extraction we took the share of all system-state file modifications in the last 7 days that fall in the last 6 hours; the median was 35% (interquartile range 28 to 45%) against 3.6% for a uniform spread, and 11 of 12 were above uniform (Fig. 3). For app and media files the median share was 13%. The extraction that had run for 36 hours showed a share of zero. A reader who takes file times of the last hours as the user’s activity will count the start-up of the phone and whatever else was done to it.

6.5 The rule

Table 5 gives the prevalence of each indicator. The rule fired on 11 of the 12 admitted extractions: 5 showed five classes, 2 showed four, 1 showed three and 3 showed two (Fig. 4). The twelfth, which had been quiet for 35 hours, showed none and is not separable. The two settings classes are the only ones with a placebo: in 240 daily windows ending 72 or more hours before the end, a developer or debugging change appeared in 1 and a shell or root write in none, against 7 of 8 histories in the final 24 hours for each. The restart class is common outside acquisition, as the bug reports show (Section 6.6), and is used here only as corroboration. The restart and shell or root classes are not independent, since the writes follow the last start (Section 6.2); counting them as one class, the rule still fires on 11 of 12, with four classes on 5, three on 3, two on 3 and none on 1.

6.6 Bug reports

The 7 bug reports had an uptime of 0.1, 1.0, 7.5, 25.8, 153, 254 and 399 hours: 2 had been started within 1.5 hours of the report and 3 had run for more than 6 days. The span of the system log, counted from the start of its body, covered the whole uptime on one report (1.0 of 1.0 hours), 67% on another (0.07 of 0.1 hours), and 0.4 to 2.9% of it on the five reports with an uptime of 7.5 hours or more (0.2 to 3.2 hours of 7.5 to 399). The body is the part of the log that follows a few stray old lines: on four of these five reports the oldest line, a stray, was as old as the uptime (1 to 287 lines, separated from the body by 7 hours to 16 days), and a count from the oldest line would have shown full coverage, as the first reading in this report did. The log of the fifth had rolled over without strays (0.6 of 25.8 hours, 2.4%). The slightly negative span of the first reading came from reading to the end of the file instead of the end of the log section. The definition of the body follows LAB-TR-0021 [16]. Eighteen packages had a first-install time within 24 hours of the report, all on one device with 7.5 hours of uptime and all from an app store, a pattern of set-up and not of an agent; no report held a non-store install in that time. A restart within 1.5 hours of a report occurred on 2 of 7 reports and an uptime of at most 24 hours on 3, so a restart alone is not a sign of acquisition.

6.7 The named agent

We searched all 21 sources for the package identifier of one commercial agent-based method, as case-insensitive text in UTF-8 and UTF-16; we did not verify the mapping of the identifier to a product release. In the 14 extractions we searched the names of 4,517,957 archive members and the content of 55,016 files (each up to 40 MB) in the system, settings, log, crash, local and vendor areas, including usage statistics, install sessions, DropBox entries and compressed members. In the 7 bug reports we searched every member, which covers the package dump, window, input, battery and usage-statistics sections and the log. We found no occurrence. With fewer than 3 observations we can report neither which artifact families keep an agent’s trace, nor how long, nor whether the trace survives removal; a case report shows that an install and a delete, with their logs and usage statistics, can be recovered on a seized phone [7]. A controlled run on a Lab-owned device is the test this paper cannot make (Section 8).

7 Discussion

A “recent change” is not the user’s. On these devices the stores that an examiner reads for the last hours were written by the start-up and preparation of the phone: a third of the week’s system-state modifications fall in the final six hours, the median extraction had been started less than four hours before, and a median of 12 of 142 recorded setting changes in the last day belong to the debug and shell classes. A statement such as “USB debugging was enabled at 14:03” is true and uninformative about the user unless the epoch is reported with it.

The changer dates the start, not the user. The Settings application wrote more than half of the debug changes, so the changer cannot tell user from examiner there. The shell and root identities wrote nothing in the retained history before the last 72 hours on any of the 8 devices, but on 7 their first write came within 25 minutes of the last start, and on the extraction that had run for 36 hours the writes sit 35 hours before the end. On these devices they therefore date the last start, and whether an acquisition caused that start these data cannot say. With 8 devices this is an observation, not a law, and it holds for one vendor on one release.

Practice. A report that dates an event within 24 hours of the end of acquisition should state the epoch, the uptime, the classes observed, and the changer identity; should not read file times of the last hours as use; and should treat a sparse recent log as a possible effect of the restart. The classes also run the other way: displaced logs and a fresh start may make the user’s last day look quieter than it was [16].

Relation to earlier reports. We add the time to the acquisition-sensitive settings of an earlier report [14], use the boot-reason history that another described with its clock caveats [15], and rely on the retention horizons of a third [16] to say how long a footprint stays visible.

8 Threats to Validity and Limitations

Construct. Timing is not cause. A device may be restarted or its settings changed by its user or a repairer shortly before an acquisition, and the data do not record the steps of the acquisitions; all statements are of consistency. The class tests were fixed before the measurement except the epoch and the shell or root test (Section 5.3), and the rule was not tested against known acquisitions, so we report how often it fires, not how often it is right. The classes are not independent: restart, shell or root origin and the file-time burst all follow the last start (Sections 6.2 and 6.4), so two classes in the epoch may reflect one event.

Internal. T comes from the extraction metadata for 11 of 12 admitted extractions, and the boot sources are not independent: all are written by the same system. Directory times show the latest write only. The settings history is trimmed by the platform, so it cannot show how many earlier shell writes existed.

External. The sample is one collection of research devices: 9 of 14 extractions on Android 16, 12 of 14 from one vendor, and a settings history on 8 devices, all of one vendor and release. Results for other vendors, for Android versions before 16, and for phones acquired by another method may differ. Counts are small (12 and 8), so we report counts and not intervals.

Limitations. No controlled run was made. The agent search found no occurrence in 21 sources, so the footprint of that agent is untested here, and the null result cannot be taken as evidence that the agent leaves no trace: nothing in these sources says the agent was ever used on them. A controlled test on a Lab-owned device would give the missing measures (which artifact families keep a trace, for how long, and whether it survives removal) and the only test of the rule against a known acquisition.

9 Conclusion and Future Work

On the Android research devices we read, indicators consistent with acquisition were common and recent: nine of twelve extractions had started within six hours of the end, and on eight settings histories the shell or root identity wrote a few settings within two hours after the last start and none more than 72 hours before the end. The two settings classes of a rule that needs two classes in a 24-hour epoch were rare in earlier windows (1 of 240), but they follow the same start as the restart class, and the rule has never been tested against a known acquisition. Next, a controlled run on a Lab-owned device with before and after bug reports will measure persistence per artifact family for the named agent; a second run with no agent will separate drift from effect. Repeated acquisitions of one device would give persistence directly, and other vendors would test the classes beyond the 8 histories we had.