Most Ordinary Phones Trip a Naive Clock-Anomaly Check: Base Rates of Clock Anomalies in Unselected Mobile Extractions

1 Introduction

A phone keeps several clocks. The wall clock that dates most records can be set by the network, by the user or by an application; a continuous counter measures time since boot; and file times, logs and databases each copy one of these clocks at the moment they write. When a user moves the wall clock, some records follow it and others do not, and a check that compares them can expose the change. Such checks have been built and tested on phones whose clock was changed on purpose [6], [8], [10].

A motivating example. Consider the simplest check an examiner might run on a full file system extraction: raise an alarm if any file in the user data area is dated more than 48 h after the extraction ended. Future dates cannot come from a correct clock, so the check sounds safe. On the research devices examined here, it raised an alarm on 16 of 46 devices. We have no independent record of what happened to these clocks, but most of the future-dated files sat in application caches (Section 5.2). An examiner who saw this alarm on a single phone, without knowing that one ordinary phone in three raises it, would overrate it.

The problem. The value of an alarm depends on how often the same alarm occurs on devices whose clocks were not manipulated: the base rate. Studies of manipulation measure whether a check fires when the clock was changed, and the Lab's earlier report found recovery-log clocks that print 1970, a fixed year or a constant impossible year on ordinary Android phones [1]. What has not been reported is how often ordinary devices show each kind of clock anomaly, and therefore what an alarm means. This report measures those base rates.

Approach. We wrote fifteen checks down before computing any of them, ran them read-only on every readable full file system extraction, sysdiagnose and Android bug report in the Lab's research corpus, and reported each rate with a confidence interval. We ask three research questions.

• RQ1 (Prevalence). On how many devices does each clock anomaly occur, and how large are the anomalies?
• RQ2 (Composition). Which kinds of record produce the alarms on these devices?
• RQ3 (Meaning). How often does a naive comparison of two clocks fire, and what does an alarm from each check mean at the measured base rate?

Contributions. This report makes four contributions.

• A pre-registered set of fifteen clock-anomaly checks that can be computed from an extraction alone, with definitions precise enough to be re-run (Section 3, Table 1).
• Base rates with 95 percent intervals on 46 full file system devices, 31 iPhones with unified-log time-sync records and 7 Android bug reports, by platform and, where a cell holds five or more devices, by operating system version and vendor (Sections 5.1 and 5.5).
• A breakdown of what the alarms consist of: constant default times, cache files, clocks set during boot and time zone changes (Sections 5.2 and 5.3).
• A translation of the base rates into what an alarm is worth, with the positive predictive value at stated prior rates and the bound that a check which never fired still carries (Section 6.1, Table 6).

Scope. Nothing is known independently about what happened to their clocks, so no alarm is classed as true or false; an alarm means that the data are inconsistent with an ordinary clock history in the way the check defines, not that a clock was manipulated. The rates describe this sample and are not rates from cases. Section 7 states the limits.

2 Background and Related Work

This section describes the clocks the checks read, then places the work among studies of timestamp manipulation, studies of clock behaviour, and work on base rates.

2.1 Clocks in an extraction

The wall clock. On Android, a time detector service sets the system clock from time suggestions; network time and telephony time are enabled by default, with satellite and external sources available but off by default [2]. A bug report records the state of this service and of the alarm service, which counts time changes since boot and prints the current wall-clock and elapsed-realtime values together. On iOS, the unified log keeps time-sync records.

Time-sync records. The unified log stores, per boot, a boot record with a boot identifier, the timebase, the wall-clock boot time and a time zone offset with a daylight-saving flag, followed by records that pair a continuous (Mach continuous) time with a wall-clock time, each again with a zone offset and a flag [7]. Within one boot the continuous time only advances, so the difference between the wall-clock step and the continuous-time step between two records measures how far the wall clock was set in between.

File times in an extraction. Full file system extractions are delivered as ZIP containers whose entries carry the extended-timestamp extra field, a signed count of seconds since the Unix epoch in UTC [5]. It keeps the modification time each file had on the device, written by the device's clock (or set explicitly by the software that wrote the file).

2.2 Detecting timestamp and clock manipulation

Verma, Govindaraj and Gupta proposed preserving kernel-generated event times off the device so that later manipulation of dates and timestamps on an Android phone can be detected [10]. Pieterse, Olivier and van Heerden manipulated timestamps in SQLite databases on one rooted Android phone and derived heuristics from the file system and the databases that indicate manipulation [8]. A DFRWS APAC 2026 study changed the system clock on four Samsung phones (unmodified, backdated and forward-dated), found that some artifacts follow the device clock while others keep external time, and proposed comparing the two to detect manipulation [6]. A systematization of timeline-based event reconstruction lists the detection of manipulation among the strands of that field [4]. These studies establish whether a check can see a manipulation; as far as we could read them (Section 7), none reports how often the same check fires on unselected devices.

2.3 Clock behaviour and base rates

Schatz, Mohay and Clark showed for personal computers that real clock behaviour departs from common assumptions about it, and correlated local timestamps with an independent source to characterize a machine's clock over time [9]. For intrusion detection, Axelsson showed that when the events of interest are rare, the false-alarm rate rather than the detection rate limits the probability that an alarm is real [3]. The same arithmetic applies to clock checks. The Lab's earlier report classified the header clock of Samsung recovery logs into five behaviours: plausible and in order, 1970, a fixed year (2010), a constant year that cannot be the true year, and unresolved [1]. Its central lesson was that a wrong clock does not show in the date it prints.

Position of this work. Manipulation studies measure sensitivity on a few devices; this study measures the other half of the problem, the alarm rate on devices selected without regard to their clocks, across three evidence families and both platforms. The checks are simple on purpose: they are the kind an examiner or a tool would apply first, and the earlier report's clock classes reappear here as properties of file systems and logs rather than of one log file.

3 Method

This section states how the checks were fixed in advance, defines them, describes the reference clocks and the unit of analysis, and gives the statistics.

3.1 Pre-registration

Before any check was computed, we wrote the sampling frame, the unit of analysis, the fifteen checks with their thresholds, the area classes used to attribute alarms, the statistics and the planned figures into a dated private note. Probes run before that note looked only at formats: which ZIP extra fields exist, how container paths are laid out, which section names bug reports contain, and how many time-sync records one archive holds. Analyses added after the results were seen are labelled post hoc wherever they appear. One pre-registered check, T2, is computed in two ways (Section 3.6).

3.2 Checks

Each check gives one alarm per device if at least one instance occurs. Table 1 defines the fifteen checks. Thresholds of 48 h absorb any confusion of time zones (at most 14 h). The first two file-system checks are the file-system form of the earlier report's 1970 and fixed-year classes [1].

3.3 Reference clocks and areas

Acquisition reference time. Where the extraction tool's metadata records an acquisition end time with its zone offset, that workstation time is used. Otherwise the container file's last-write time on Lab storage is used; it cannot precede the end of acquisition, so it makes the future-time check conservative.

Build time. On Android, ro.build.date.utc from the system build properties; on iOS, the file time of SystemVersion.plist on the system volume of the same container. Both are read from the extraction; no external table of release dates is used.

User area and area classes. The user area is /data on Android (a duplicate mirror view excluded) and /private/var on iOS. Alarms are attributed to five area classes fixed in advance: application payloads (installed packages, compiled code, downloaded assets), media, application data, logs and other system data. A variant of F1 to F3 that ignores payloads was also pre-registered.

3.4 Unit of analysis

The unit is the device. Sources of the same device were merged privately: iPhones by shared unified-log boot identifiers or a hashed hardware identifier, Android devices by a hashed identifier from the extraction metadata, bug reports by a hashed serial number. For the file-system checks the extraction with the latest reference time represents a device; for the time-sync checks all unique records of a device are pooled. Devices were not matched across evidence families, so a phone may appear in more than one family.

3.5 Statistics

Each rate is reported as k of n devices with a 95 percent Wilson score interval [11]. Rates by operating system version and vendor are reported only for cells of at least five devices. The meaning of an alarm is expressed as a positive predictive value (Listing 1). With an alarm rate f on the sample, an assumed sensitivity s and a prior share π of manipulated devices among those examined, the probability that an alarm is a manipulation is given below. We set s = 1, the most favourable value for the check, and evaluate π at 1, 10 and 50 percent. If any sample device was in fact manipulated, f overstates the false-alarm rate and the values below are lower bounds.

PPV(π) = s·π / ( s·π + f·(1 − π) )
LR+     = s / f          (posterior odds = LR+ × prior odds)

3.6 T2 definition and post hoc analyses

The definition of T2 in Table 1 speaks of boots, so T2 compares distinct boots. Time-sync files repeat the header of a boot when a new segment starts, so a variant that compares every boot header with the one before it also compares the repeated header of the same boot with its own earlier records; both results are reported (Table 3). Post hoc we also (1) split each time-sync step above 60 s by whether the clock before it read a date before 2007 (an unset clock) and by direction, (2) split T2 inversions by whether the later boot's wall-clock time was before 2007, (3) grouped file times before 2007 into families of values, and (4) located future-dated files within application containers.

4 Evidence and Setup

Sample. The sampling frame is the Lab's census of its research corpus on the drives attached at the time of the study: 101 unique extractions. Extractions held on other drives were not readable for this study and are not part of the sample. Every frame item of the four eligible classes was processed, and none was selected by its clock behaviour (Table 2). One container listed as an iOS full file system held no device file system and was excluded; an engineered test trace (a 1.8 kB archive of eight small text members with identical member times, one of them named as a placeholder) and four truncated sysdiagnose archives (which ended before any time-sync member) were also excluded. Logical extractions and backups (36 items) are outside the scope.

Composition. The 46 file-system devices are 32 Apple devices (20 on iOS 26, 11 on iOS 15 to 18, one undetermined) and 14 Android phones (9 on Android 16, 5 on Android 10 to 14; 12 Samsung and two other vendors). The 31 time-sync devices run iOS 15 to 27, 21 of them iOS 26; per device they cover 4 to 3,051 boots (median 84) and a span of wall-clock time of 1 to 2,445 days (median 293). The 7 bug-report devices come from four vendors (four Samsung) and run Android 10 to 16. In all, the checks read 21,561,059 user-area file times, 508,299 time-sync records in 7,751 boots and 7 bug reports. Every user-area file carried the extended timestamp. The acquisition reference time came from tool metadata on 29 file-system devices and from the container's write time on 17.

Procedure. One runner script processed every source in sequence, each in its own process with a time limit, and wrote an aggregate report; no source hit its limit. It reads the ZIP central directory without extracting the container, decompresses only the few members a check needs (build properties, the persistent property store, SystemVersion.plist, time-sync files), and streams sysdiagnose archives. It is written in Python with the standard library only and was not derived from an existing parser; the time-sync layout follows a public open-source description [7]. All inputs were opened read-only.

5 Results

Simple checks fired on almost every device; checks that compare the device clock with an anchor fired rarely or never. Figure 1 and Table 3 give every rate.

5.1 How often each anomaly occurs (RQ1)

File-system times. At least one file-system check fired on 45 of 46 devices (98 percent; 95 percent interval 89 to 100). A file time within a day of the epoch occurred on 41 devices, a file time before 2007 on 36, and a file dated more than 48 h after acquisition on 16 (15 of 32 iOS devices, 1 of 14 Android). On 10 devices the latest future time lay more than a year ahead. Ignoring application payloads changed only F1, from 41 to 40 devices. The one device without any file-system alarm runs iOS 15.

Time-sync records. Every one of the 31 iPhones showed a wall-clock step above 1 s inside a boot, 23 a step above 60 s and 18 a step above an hour; all 74 steps above an hour exceeded a day. Of 500,548 pairs of consecutive records, 108 differed by more than 60 s. The first record after a boot differed from the boot time by more than 60 s at 353 of 7,751 boots. A boot that started earlier than the previous boot ended (T2) occurred on 18 devices, and more than one zone offset on 27.

Bug reports. The alarm service had counted one or more time changes since boot on 4 of 7 devices (one to three changes). The first-boot property of the runtime agreed with the boot time derived from the current wall clock and elapsed time to within 42 to 453 s on six devices and differed by 4,589 s on one. No boot-history order break, no wall clock before the build time and no disagreement above 48 h with the time the report reached Lab storage occurred; the largest such difference was 0.05 days.

5.2 What the file-system alarms consist of (RQ2)

Times before 2007. Of the 46 devices, 44 held user-area files dated before 2007, and most of these times are constants shared by many files (Figure 2). On the median device 93 percent of such times belonged to a value shared by at least 100 files, and on 27 of the 44 devices at least 90 percent did. Files at exactly the Unix epoch occurred on 37 devices and files within a day of it on 35. A family within five weeks before the start of 1980, the epoch of the DOS date format used in ZIP and FAT, occurred on 34 devices; values around the turn of 2000 on 6. Times between the second and sixtieth day of 1970 occurred on 15 devices (24,799 files); we did not identify their writer. By area, epoch-zero times lay mostly in application payloads (98,162 files on 16 devices) but also in other system data on 38 devices and in application data on 22; times before 2007 lay in application data on 32 devices and in payloads on 20. These are the earlier report's 1970 and fixed-year clock classes [1], now seen in file times: values written by software, not read from a running clock.

Future times. The 1,786 future-dated files on the 16 alarm devices lay mostly in application data: 683 files under Library/Caches of iOS application containers on 13 devices, 154 under Documents on 3, and 875 inside installed application bundles on 2 (Table 4). The excess over the acquisition time was under 30 days for 440 files, 30 to 365 days for 305, 1 to 10 years for 930 and 10 years or more for 111. Per alarm device, 2 to 655 files were future-dated (median 17). That cache files carry times in the future is consistent with software that sets a file's time to a planned expiry, but we did not test this. The rate was 7 of 29 devices when the acquisition time came from tool metadata and 9 of 17 when it came from the container's write time, although the latter makes the check more lenient; the two groups also differ in extraction tool and device mix, so the difference is not attributed to the reference time.

5.3 What the time-sync alarms consist of (RQ2)

Most large wall-clock steps are a clock that read an impossible date being set, but not all (Figure 3). Of the 108 steps above 60 s, 40 started from a wall clock before 2007, an unset clock, on 18 devices; all were above an hour. Of the rest, 44 were forward (31 of them above an hour, on 14 devices) and 24 backward on 11 devices: 21 between 1 and 28 minutes and 3 of about 12, 12 and 23 days, each on a different device.

Boot order. Of the 46 boots that started earlier than the preceding boot ended, 44 started on a wall clock before 2007; only 2, on two devices, started on a plausible date, 4.5 and 28.7 days before the end of the preceding boot. A check that compares boot times without testing for an unset clock therefore mostly detects that iPhones boot on an unset clock.

Zones. Four devices carried one zone offset, fifteen two, and twelve three to eight. On 9 of the 27 devices with a change, the less frequent offsets held at most 1 percent of the records; on 18, more. The daylight-saving flag took both values on 27 devices. Travel and a default zone before the zone is set would both produce such changes; the records do not tell them apart.

5.4 Checks anchored to another clock (RQ3)

Checks that compare the device clock with an anchor outside the record being tested fired rarely. No device's newest ordinary file preceded its build time (0 of 44; upper bound 8 percent), and no bug report's wall clock preceded its build time or differed from the Lab storage time by more than 48 h (0 of 7 each). The naive two-clock check F6 fired on 8 of 29 devices. On 7 of them it fired because future-dated files made the device look ahead; measured with the newest file that is not in the future, the device clock agreed with the workstation within 2 days on 28 of 29 devices and within an hour on 15. The remaining device's newest ordinary file was more than a year older than the acquisition, which is consistent both with a device that wrote nothing in that time and with a clock that was behind. The Android boot-reason history broke order on 1 of 14 devices.

5.5 Operating system version and vendor

Only four cells hold five or more file-system devices and one cell five or more time-sync devices (Table 5); all others are suppressed. Within them the pattern is the same as overall. The difference in future-dated files between iOS 26 (8 of 20) and Android 16 (0 of 9) is the one platform contrast in the data, and the intervals overlap.

6 Discussion

The results say less about whether these clocks were wrong than about which checks can carry weight. This section turns the base rates into what an alarm is worth and draws the consequences for examiners and tools.

6.1 What an alarm means

With a sensitivity of 1, an alarm multiplies the prior odds of manipulation by 1/f. For the combined file-system check (f = 0.98) the factor is 1.02: the alarm carries almost no information, and at a prior of 1 percent the probability that an alarming device was manipulated stays at 1 percent (Table 6, Figure 4). The time-sync step check (0.74) raises it to 1.3 percent, the future-file check (0.35) to 2.8 percent. Even at a prior of 50 percent, where half of all examined devices would have been manipulated, no check with an alarm rate above 0.3 gives more than 0.74.

Two cautions bound this reading. First, a sensitivity of 1 flatters every check; a real check that misses some manipulations is worth less. Second, a low alarm rate is necessary but not sufficient: the checks that never fired (F4, A5, A6) see only a narrow kind of manipulation, a clock set back before the build date or a capture clock far from the workstation, and their sensitivity to anything else is unknown. Their value lies in the bound: if they fire, the alarm is rare in ordinary data, and on this sample it would multiply the odds by at least 12 for F4 (upper bound 0.08) and at least 2.8 for the bug-report checks (upper bound 0.35).

6.2 Consequences for examiners and tools

1. Do not report a single file time at the epoch, before 2007 or in the future as a clock anomaly. On these devices such times were the norm, written by software rather than read from a running clock.
2. Before comparing two clocks, remove what is known to be written, not measured: constant values shared by many files, payload and cache files, and records written while the clock was still unset.
3. Prefer checks anchored outside the tested record: the build time, the acquisition workstation, the continuous time within a boot. In this sample they rarely or never fired; their sensitivity has to be measured on devices with a known clock change.
4. Report a clock finding as an inconsistency with a stated check and its base rate, not as manipulation.

6.3 Relation to the earlier report

The earlier report found, in one Samsung log file, clocks that print 1970, a fixed year and a constant impossible year [1]. The same classes are common elsewhere: epoch and fixed-year times appear in the file systems of 44 of 46 devices, and an unset clock that is set during boot appears in the time-sync records of 18 of 31 iPhones. What the earlier report showed for one source holds across sources: a date does not reveal the clock that produced it, and a check must establish that clock first.

7 Threats to Validity

Construct validity. No independent record says what happened to these clocks, so an alarm is classed only as an inconsistency with the check's assumption. A sample device may have been manipulated, in which case the alarm rate overstates the false-alarm rate and the values in Table 6 are lower bounds. File times are the modification times stored in the container; software can set them explicitly, so a file time is not always a reading of the clock. The acquisition reference time for 17 devices is the container's write time, an upper bound. The time-sync layout follows an open-source description [7] rather than vendor documentation; the parser reproduced its record sizes and found no undecodable record in the sources read.

Internal validity. The checks and thresholds were fixed before computation, but a second computation of T2 and several breakdowns are post hoc; both are labelled. Device merging used identifiers and shared boot identifiers; two extractions of one device that share neither would be counted twice. A further iOS extraction may duplicate a device seen only through a sysdiagnose.

External validity. The devices are the Lab's research corpus, most from one market; iOS 26 and Android 16 make up 29 of the 46 file-system devices, and most other version cells hold one to four devices. Two families are small: 7 bug reports and, for F5, 14 Android devices. The rates should not be read as rates from cases or for any population.

Conclusion validity. Intervals are wide where n is small; a zero count bounds a rate only from above (8 percent for F4, 35 percent for the bug-report checks). The positive predictive values assume a sensitivity of 1 and an exchangeable sample.

Limitations. We did not run controlled clock changes, so no sensitivity is measured; we did not read the full text of the DFRWS APAC 2026 study [6], whose page could not be fetched, so its discussion of ordinary devices may go beyond its abstract; database timestamps, application logs and Android logs other than the bug report were not examined; the A3 zone check could be evaluated on two bug reports only; and the extractions on drives not attached during the study were not read.

8 Conclusion and Future Work

A clock-manipulation check is only as useful as its alarm is rare on devices whose clocks were not manipulated. We measured that rate for fifteen checks on every readable extraction of a research corpus. Simple checks fired on almost every device: epoch and pre-2007 file times on most, future-dated cache files on one device in three, wall-clock steps inside a boot on three iPhones in four, and at least one file-system alarm on 45 of 46. Most file-system alarms consist of values that software writes rather than reads from a clock, and most boot-order alarms of an unset clock at boot; the forward and backward steps on 21 iPhones are not explained by the data. Checks anchored to the build time never fired, and the workstation comparison fired on one device of 29 once the newest ordinary file was used. On these devices, therefore, an alarm from a simple check says almost nothing about manipulation, and a clock finding needs its check and base rate stated beside it. Tools that flag clock anomalies, open-source parsers included, can report the same base rates with their alarms.

Future work, in order of value: (1) controlled forward and backward clock changes on the Lab's own test devices, to measure the sensitivity of each check and turn Table 6 into measured values; (2) the same census on the parts of the collection held on other drives, to fill the suppressed version and vendor cells; (3) checks on database and application-log timestamps, the records that manipulation studies show to follow the device clock [6].