Not Found Is Not Off: Evidence-State Accounting for Reconstructing Phone Security Settings from Full File Systems and Android Bug Reports

1 Introduction

After a phone has been acquired, an examiner is often asked how it was configured. Was a screen lock set? Was debugging enabled? Was the device managed by an organisation? How old was its security patch? The answers are scattered over preference files, settings tables, databases and service dumps, and some of them are not in the acquisition at all. Reading them looks like a lookup. It is not, because the reader must also decide what to say when it finds nothing, and what to say when what it finds was written by the acquisition rather than by the user.

A motivating example. Consider three things the research corpus examined here contains. In all 14 Android full file system extractions, developer options and USB debugging were on: the state an acquisition over USB requires [5], not necessarily a choice of the user. On 23 of 33 iPhone images, the effective-settings store held the platform's "no maximum" value for a passcode-policy cap, which records that no policy limits the setting, not that the user disabled the lock. And on 20 of 33 iPhone images the Messages preference store existed under two file names that differ only in letter case, of which only one held the retention setting; a reader that sees the other copy finds no key. Each of these produces a plausible value or a plausible blank, and none of them raises an error.

The problem. A reconstruction of device posture from an acquisition can be wrong in four ways that raise no error. The value it reads may not be the one the system applied, because it came from a store that does not govern the setting or because the stored value is wrapped in a typed container. The value may have been caused by the acquisition. An empty read may mean that the setting was never changed, that this kind of evidence does not carry it, that the store is missing, or that the reader failed. And a pass rate computed over what was found hides all three. This report addresses that problem: how to give every posture fact an accountable state, and how much of a phone's posture each evidence source can establish.

Approach. We describe a reconstruction design in which every fact on every evidence item ends in exactly one state with its provenance or its reason, and we measure the reference implementation of that design on the full file systems and bug reports of the Lab's research corpus. We ask four research questions.

• RQ1 (Determinability). How much of a defined set of posture facts can each evidence source establish, and why does the rest remain undetermined?
• RQ2 (Fidelity). Are the reconstructed values the values stored in the evidence, as read by a separately implemented extractor?
• RQ3 (Robustness). When a store is missing, unreadable or damaged, does the reconstruction state that the fact is not determined rather than report a value, and are its results the same on every run?
• RQ4 (Benchmarks). How many items of public mobile hardening benchmarks can an image of an unmanaged phone speak to at all?

Table 1 summarises the answers.

Contributions. This report makes four contributions.

• An evidence-state vocabulary for post-acquisition posture reconstruction, with qualified-source, authority, conflict and observed-only rules, and a design that applies it to three evidence sources through one catalogue per platform (Section 3).
• A measurement of determinability by evidence source and by dimension class, with the reasons for every undetermined fact, on 54 evidence items (Sections 5.1 and 5.2).
• An evaluation of fidelity and robustness: agreement with a separately implemented extractor, a damage suite and a determinism test, which also exposed three ways in which a recorded reason misdescribes a read failure (Sections 5.3 to 5.6).
• A count of the rules of three public DISA STIGs that an image of an unmanaged phone can speak to, with the reasons for the rest (Section 5.8).

2 Background and Related Work

2.1 Evidence sources and where settings live

A full file system extraction holds the files of the device, including the stores in which the operating system keeps settings: preference and configuration-profile property lists on iOS; the settings provider files, the lock settings database, account databases and build properties on Android [9]. Where each setting lives, in which format, and which reads return nothing without an error, is mapped in the Lab's white paper [4]; this report cites that map and does not repeat it. Two of its findings matter here: keys are written only after a setting leaves its default, so most files that exist lack most keys, and on Android 12 and later the settings files are Android Binary XML, which a standard XML parser rejects [4]. Some facts are inferred from the storage layout or from properties: devices launching with Android 10 and later must use file-based encryption, and the system properties record the encryption type [7].

An Android bug report is a text archive that holds the diagnostic output of system services (dumpsys), the system properties and logs [6]. It carries the live settings tables, the lock service state and the account, Wi-Fi and biometric service dumps, but no files: a setting that exists only in a database file is not in it. A bug report can also lose service output that the platform stopped at its time limit, which a section index makes visible [1]. What the iOS unified log says about security controls is a separate source, treated in [3]; iOS has no bug report counterpart in this study.

2.2 Hardening benchmarks presuppose management

Guidance for securing mobile devices is written for organisations that manage them [18]. The DISA Security Technical Implementation Guides (STIGs) for iOS and Android state their requirements as configurations that a mobile device management (MDM) or enterprise mobility management (EMM) system enforces [14]–[16], and the Android STIGs begin by provisioning the device as fully managed with a work profile. The CIS Benchmarks for iOS 26 and Android are distributed as PDF documents for non-commercial use [12]. On a personal phone none of these policies exists, so for many benchmark items an image can show only that no policy is installed. Apple's schema marks many restriction keys as available only on supervised devices [8]; the Lab's map counts 121 of 176 iOS restriction keys as supervised-only [4].

2.3 Tools that read settings from acquisitions

MVT, an open-source toolkit for finding signs of compromise in Android and iOS acquisitions, compares Android settings records against a list of ten settings with a safe value and raises an alert when a record holds another value [21]. It warns that public indicators are not enough to show that a device is clean [21]. A check of this kind reports a value it found; a setting with no record produces no alert, and the output does not say whether the record was absent at the factory default, absent from the evidence or unreadable. Validation literature asks that forensic tools be tested against known data and that their error be stated [17], and the Lab's earlier study found open-source parsers that returned empty tables instead of errors after a storage-layout change [2].

2.4 Absence, uncertainty and error

Casey argued that uncertainty in digital evidence is rarely measured and proposed to estimate and state it [11]. Carrier located the points at which analysis tools introduce error between the layers of abstraction they translate [10]. The question of what a missing fact means is old in databases: the closed-world assumption treats failure to find a fact as its negation [22], and SQL's three-valued logic can return answers that are not certain when values are missing [19]. A reconstruction that reads "no row" as "off" makes the closed-world assumption about a phone, whose settings stores do not satisfy it.

Position of this work. In the sources we read, the location of settings is documented [4], value checks exist [21], and the need to state uncertainty is argued [11], [17]. We found no description of a reconstruction that gives every posture fact an accountable state with a reason, and no measurement of how much of a phone's posture each evidence source can establish. The search was limited (Section 7); within it, the vocabulary, the per-source measurement and the benchmark count are new, and the reconstruction itself is engineering.

3 Reconstruction with Evidence-State Accounting

This section states the problem, describes the design of the reference implementation at the level needed to read the results, and defines the states every posture fact ends in. The catalogue of facts, the expected values and the scoring are not described.

3.1 Problem statement

Let an evidence item be one acquisition of one evidence source: an iPhone full file system, an Android full file system or an Android bug report. A catalogue is a fixed set of posture facts for a platform, such as whether a screen lock is set, the security patch level, or whether a debugging setting is on. A slot is one fact on one evidence item. The task is to give every slot exactly one record that holds a state, the value if one was established, the provenance of that value (source, key path, content hash, method), and, when no value was established, the reason. One rule constrains the task: no value may be inferred from the absence of a key, except a platform default that the platform documents, and then the record says so.

3.2 Design

Figure 1 shows the pipeline. Each evidence source has an adapter; all adapters of a platform feed one catalogue and one shared finaliser, so a fact read from a full file system and the same fact read from a bug report end in records of the same form.

Qualified sources. A source is chosen by its store, not by its file name. A configuration-profile key counts only when it lies in the operating system's profile stores; a downloaded profile, or an application file that holds the same key, is a non-qualifying candidate and is recorded as rejected, with the reason. Preference stores must lie at their system path, not in an application container, and symbolic links that leave the evidence tree are not followed. Android settings files are decoded from Android Binary XML before they are read, and SQLite stores are opened from scratch copies with their journals.

Typed values. iOS records the effective restriction set as typed wrappers, for example a Boolean wrapper around the applied value of a restriction. The adapter unwraps the value and keeps the full key path, so the value read is the value the system applied, and the provenance shows where it came from.

Authority and conflict. Each observation carries a rank derived from its store: an effective-settings store outranks a stored profile, and a direct device-owned store outranks both. The best rank wins. If two observations of the best rank disagree, no value is taken and the slot is a conflict. An observation of lower rank, such as a historical profile copy, cannot create a conflict.

Values that are not verdicts. Some values are real but say nothing about the user's choices. A value is observed only when the acquisition itself induces it (Android debugging, which an examiner must switch on to acquire over USB [5]), when the flag has had no effect since an earlier platform release, or when it is a management restriction at its platform default on a device that is not managed. A value is inconclusive when it cannot be a verdict: the effective-settings store holds the platform's "no maximum" value for a policy cap, which records that no policy limits the setting, not what the user chose; or the copies of the effective settings disagree.

Score and coverage. The reference implementation computes one score, the share of judged facts that meet an expectation, in one function used by every output, and shows it only beside the coverage, the share of slots with an established value. Observed-only, inconclusive and undetermined slots never enter the score. This report uses only the states and gives no score.

Reproducibility. A run records a digest over the relative paths and content hashes of the sources it read and the scoring revision. An unchanged digest lets a later run reuse the earlier result, and earlier runs are never overwritten.

3.3 Evidence states

Every slot ends in one of the states of Table 2. A slot is determined when a value was established (whether it is judged or observed only), inconclusive when a value exists but no single value can be taken, and not determined otherwise. A not-determined slot carries a reason class when the adapter recorded one; otherwise it carries only the generic statement that no readable source held the fact, which the reference implementation adds to every not-determined slot.

The states as implemented are a subset of a larger design. Two further states that the design names, "requires external evidence" and "not applicable on an unmanaged device", are not separate states in the implementation: the second is carried as an observed-only reason, and the first is not represented. Reason classes R1 to R5 are typed by the Android adapters and, for R5, by the iOS profile qualification; the iOS preference adapters record no typed reason (Section 5.2).

3.4 Dimension classes

To report determinability without naming catalogue facts, we group facts into six dimension classes by the kind of record that carries them on the device (Table 3). The classes describe the evidence, not security topics: two facts of different topics fall into one class when the device stores them the same way. Not every class occurs on every platform.

4 Evaluation Design

All measurements were made by one runner script, which ran every step in a fresh process with a time limit and wrote an aggregate report.

4.1 Evidence

The study used every full file system extraction and every Android bug report in the Lab's research corpus that was readable at the time of the run: 34 iPhone full file system extractions (20 on iOS 26, 13 on iOS 15 to 18 and one whose version could not be recovered; two extractions are of one device), 14 Android full file system extractions (Android 10 to 16, nine on Android 16; 12 Samsung, one Pixel and one Motorola) and seven Android bug reports from four vendor families (four Samsung on Android 16, one Motorola on Android 15, and one Transsion and one Huawei on Android 10). The extractions and bug reports were read only. The reference implementation staged only the stores it reads into a scratch folder, which was deleted after the run; the extractor did the same with its own reader.

4.2 Measures

Table 1 links each research question to its measure. Determinability is the share of slots in each state, computed per evidence source and per dimension class; slot counts are not given, because they would reveal the size of the catalogue.

4.3 A separately implemented extractor

To test whether reconstructed values equal the stored values, we wrote a minimal extractor for the study that imports nothing from the reference implementation. It reads the archives with its own ZIP central-directory reader, decodes Android Binary XML with a decoder written from the token layout of the platform's serializer, reads property lists, SQLite and text with the Python standard library, and parses the bug report sections with its own patterns. It covers a stated subset of stores: on iOS, the typed values of the policy and restriction keys in the effective-settings store, the Lockdown Mode flag in the global preferences, and the App Store automatic-update and Location Services switches; on Android, the settings-provider values of the settings-based facts, the lock credential quality and the release and patch level; in bug reports, the same settings values from the settings dump, the release and patch level from the system properties and the credential type from the lock service dump. For each stored value we compare the two readings, which is a form of differential testing [20], and classify the outcome as equal, different, read by the reference implementation only, or read by the extractor only. On iOS we make two comparisons: of the value both read from the same store, and of the value the reconstruction reports, which may come from another store, with the value in the effective-settings store.

The extractor was written for this study by the same team as the reference implementation, from documentation and the stored formats, not from the reference code. Both read the same bytes, so a misunderstanding of a format shared by both would not show. Agreement shows that the reconstruction reports the stored value; it does not show that the stored value matches what the device displayed.

4.4 Damage suite

For two items per evidence source, the first two in the collection's census order whose reconstruction completed (a rule fixed before the run), we staged the stores, copied them, damaged the copy in one controlled way, and ran the reconstruction again (Section 5.5): a store truncated to half its length, emptied, overwritten at its header, replaced by random bytes after a valid magic number, or removed; for bug reports, an archive cut to half, a report text cut to half, a service section removed, an empty archive and a file of random bytes. For every slot we compare the damaged run with the undamaged run of the same staged copy and count transitions: unchanged, unchanged from another source, value changed, lost with a typed reason, lost with only the generic statement, and newly determined. The pass criterion is that no value changes and none appears.

4.5 Benchmark observability

We coded the rule titles of three public DISA STIGs, retrieved on 27 October 2026: Apple iOS/iPadOS 26 (V1R3) [14], Google Android 16 COPE (V1R3) [15] and Samsung Android 16 COPE (V1R3) [16]. Each rule received one code. U: the rule has a counterpart that the user of a personal phone can set, or a device state that the phone holds regardless of management; this is a necessary condition for an image to speak to it. M: the rule presupposes management (a policy or restriction with no user-facing counterpart, supervision, enrolment, managed applications or accounts, a work profile, or an organisation's allow list). O: the rule concerns an organisation's content or procedure (training, a warning banner, certificates or applications of the organisation). The authors coded the titles; a second, mechanical coder applied keyword rules written afterwards, and we report agreement and Cohen's kappa [13]. The codes are not mapped to the reference implementation. CIS Benchmarks [12] were not coded, because their item text is licensed for non-commercial use and was not retrieved.

4.6 Same-device pairs, determinism and setup

Pairs. A full file system and a bug report of the same phone would allow the two reconstructions to be compared. We looked for such pairs only by device identifiers read from the data: the serial number in the Samsung factory partition, where present, and the Bluetooth adapter address of each full file system, and the serial-number properties and Bluetooth address of each bug report. Identifiers were compared as salted hashes in memory and never written in clear; model names were used only to count candidates.

Determinism. Each item was reconstructed twice, in fresh processes with different string-hash seeds and fresh staging; we compare the record listings (all fields except identifiers and times) byte for byte, and the snapshot digests.

Setup. The reference implementation was imported read-only from its source at a pinned commit and called through its public reconstruction entry point, with an in-memory stand-in for its database; it ran under Python 3.13 and the extractor under Python 3.14, on a workstation with an AMD Ryzen Threadripper 3990X (64 cores), 256 GB of memory and Windows 10, whose file system does not distinguish letter case. Evidence was read from the drives on which it is stored. Each reconstruction step had a time limit of 15 to 20 minutes; none was reached.

5 Results

5.1 Determinability by evidence source

The reconstruction completed on all 14 Android full file systems, all seven bug reports and 33 of the 34 iPhone images. On the remaining iPhone image no operating system version could be recovered, from the census or from the image, and the reconstruction returned the status "insufficient metadata" instead of running; it is excluded from the shares below. Figure 2 shows the share of slots in each state.

An Android full file system established 94% of the facts, a bug report 82% and an iPhone image 63%. The spread between items was small within each source: the per-item share had a median of 96% (range 85 to 96%) on Android full file systems, 85% (73 to 85%) on bug reports and 65% (46 to 73%) on iPhone images. Table 4 breaks the shares down by dimension class.

Two differences between the sources are properties of the evidence. A bug report carries the settings tables, the system properties and the account, Wi-Fi and biometric service counts, so classes A, B, E and F were established as often as on a full file system; but it does not carry the lock settings database, so 60% of the lock-state slots were not carried by the class (R4), and on one report from an Android 10 device the lock service printed no credential type and the settings table held no lock quality (R2). An iPhone image carries every store, yet most stored-setting keys are written only after the user changes the setting [4], so 57% of the class A slots stayed undetermined.

Release made little difference where the cells allow a comparison: 64% on iOS 26 (20 images) against 61% on iOS 15 to 18 (13 images), and 94% on Android 16 (9 images) against 94% on Android 10 to 14 (5 images). The two bug reports from Android 10 are fewer than three and are not compared.

5.2 Why facts stay undetermined

On the Android sources almost every undetermined slot carried a typed reason: all of them on bug reports and 19 of 22 on Android full file systems, where the three untyped slots belong to one image without build properties. On iPhone images 46% of the undetermined slots carried a typed reason, all of them R5: a candidate value existed only in a profile file that does not qualify. The other 54% carried only the generic statement. The extractor's store probe attributes these untyped slots: on 79% of them the store was present and the key absent, which is the situation that R1 names on Android, and on 21% the store was absent. The distinction exists in the evidence but is lost in the iOS records.

Inconclusive slots were frequent on iPhone images and absent elsewhere. On 23 of 33 images the effective-settings store held the platform's "no maximum" value for at least one passcode-policy cap, on 8 the effective settings conflicted between stores of equal rank, and on 6 their copies disagreed. Management restrictions at their platform default were reported as observed only on 32 of 33 images; the remaining image held an installed passcode-policy profile, so the reconstruction treated it as managed and judged its restriction values.

Some determined slots rest on absence by design: a documented platform default (2.4% of the determined slots on iPhone images, 5.6% on Android full file systems, none on bug reports), stated as such in the record. One iOS case shows why such inferences need care. On 20 of 33 iPhone images the Messages preference store existed under two file names that differ only in letter case, and only one of the two held the retention key. The workstation's file system does not distinguish letter case, so staging kept one copy and counted the collision. On 8 images it kept the copy without the key, and the reconstruction reported the documented default from absence. On those 8 the default happened to equal the value in the other copy, so no reported value was wrong; on another device it could have been.

5.3 Agreement with the separately implemented extractor

Table 5 compares the two readings over the stated subset. Of 1,200 stored values read by at least one side, 1,145 were read by both and were equal; no value differed. The 55 values read by one side only were all traced to a cause.

Most one-sided reads follow from design. A value withheld as inconclusive is the intended outcome, and a value taken from another qualified store is a difference of scope between the two readers. Two causes are defects of the reference implementation. First, its iOS preference adapters recognise a store by a path that ends in the system data directory; on two iPhone images in which the data volume is the root of a second file system, they did not read preference stores that were present, and up to 16 slots on those images received the generic not-found statement. Second, on one Android 10 image a setting record with no value was reported as an empty string, the form an "off" test accepts; the extractor reports it as missing. Neither produced a wrong value in this sample.

5.4 Acquisition-sensitive settings

Developer options and USB debugging were on in all 14 Android full file systems, the state that an acquisition over USB requires [5]. In bug reports developer options were on in 6 of 7 and USB debugging was off in all 7, which fits a report taken from the developer options on the device [6]. These values describe the acquisition, and the reconstruction reports them as observed only.

5.5 Absent, unreadable and damaged stores

No value was reported without its store. On 26 iPhone slots and 3 Android slots the extractor found that every store a fact depends on was absent, and none of these slots carried a value. The damage suite (Table 6) gave the same result under controlled damage: in 34 damaged runs no value changed and no fact became determined. Damage did change reasons. When one Android settings file was truncated, emptied or overwritten while the other two still decoded, the lost facts were labelled "absent at factory default" (23 slot losses), a wrong reason for a read failure. On iPhone images, an unreadable database, an unreadable preference file and removed profile stores all produced the generic statement, the same record as a key that was never written. Removing all settings files was labelled correctly as a store not in the item, and every bug report damage either lost facts with the correct reason or made the run refuse with a stated status.

5.6 Determinism and cost

All 54 completed items gave byte-identical record listings and identical snapshot digests in the two runs with different hash seeds. On the four full file system items of the damage suite, reading the staged copy as a directory gave the same listing as reading the archive. Table 7 gives the cost. On iPhone images almost all of the time and memory went into reading the index of an archive with millions of entries to find the few dozen stores; the reconstruction itself took a median of 0.5 s and at most 1.7 s.

5.7 Same-device pairs

The collection holds no full file system and bug report of the same phone. Device identifiers were readable in all 14 Android full file systems and in 6 of the 7 bug reports; none of the 98 possible pairs shared an identifier, and none shared even a model. The cross-source agreement measure could therefore not be computed.

5.8 Benchmark observability

Of the 177 rules of the three STIGs, 58 (33%) have a counterpart that the user of a personal phone can set or a device state the phone holds (Figure 3). The other 106 presuppose management and 13 concern an organisation's content or procedure; on an unmanaged phone an image can speak to these only by showing that no policy is installed. The share was 41% for iOS/iPadOS 26, 28% for Google Android 16 and 22% for Samsung Android 16. The mechanical coder agreed with the authors' codes on 80% of the rules (Cohen's kappa 0.66); in 28 of its 35 disagreements it coded a management rule as user-reachable, because the title did not name the management mechanism.

6 Discussion

6.1 What each source can say

An Android full file system answered almost every question the catalogue asks. A bug report answered the questions held in settings tables, properties and service counts as well, but not those held only in database files; an examiner who needs lock-store facts from a phone known only through a bug report must say they are not determinable from this evidence, not that they are off. An iPhone image holds every store, but on an unmanaged phone most of what it records about policy is the platform default, which the reconstruction reports as observed rather than as the user's choice, and most stored-setting keys appear only after a change. The lower share on iPhone images therefore says more about how iOS stores settings than about what an iPhone image contains.

6.2 The reason is part of the answer

The damage suite separated two properties that are easy to conflate: whether a reconstruction reports a wrong value, and whether it reports the right reason for not reporting one. The reference implementation never reported a value without its store and never changed a value under damage, yet in three situations its reason did not describe what happened: a settings file that failed to decode was reported as a setting at its factory default; an unreadable or unmatched iOS store produced the same record as a key that was never written; and on iPhone images most undetermined facts had no typed reason at all, although the evidence distinguished the cases. An examiner reading "absent at factory default" may conclude that the user never changed the setting; reading "store present but not read" leads instead to a second tool. The fix is cheap: decide the reason per store file (absent, present but not decoded, decoded without the key) and carry it to every fact that depends on that file.

6.3 When absence may be read

A documented default is a legitimate inference only if every copy of the store was read and none holds the key. The case-variant copies of Section 5.2 break that condition silently on a host file system that ignores letter case: one copy is dropped before the reader sees it. The default reported on those 8 images happened to be right, but the condition, not luck, should carry the inference. Two rules follow: stage names that differ only in case to distinct places and treat their disagreement as a conflict, and infer a default only when the staging report shows that no copy was dropped. On a host that distinguishes case the collision does not arise; we did not test one.

6.4 Values that describe the acquisition

Debugging settings were on in every Android full file system, and developer options were on in six of seven bug reports. A reconstruction that judges these values judges the examiner, not the user. Marking them observed only is the minimum; recording the acquisition method beside them would show when such a value can still inform.

6.5 Benchmarks are not a yardstick for a personal phone

Two thirds of the STIG rules presuppose management or an organisation, and even the third with a user-reachable counterpart needs a store that records it before an image can speak to it. A share of benchmark rules "passed" by an image of a personal phone therefore measures mostly the absence of management; observability should be reported first.

7 Threats to Validity

Internal. The separately implemented extractor and the reference implementation were written by the same team. They read the same bytes, so a misunderstanding of a format that both share is invisible to the comparison; the extractor was written from the stored formats and platform documentation, not from the reference code, which reduces but does not remove this risk. The damage suite and the determinism test were run by the same runner that produced the other numbers. The dimension classes and the reason classes were defined by the authors before the run; a different grouping would give different shares.

Construct. A stored value is not proof of the user's choice, nor of the state at an earlier time, and an acquisition can change the state it records (Section 5.4). Agreement measures whether the reconstruction reports the stored value, not whether the stored value matches what the device displayed; that needs a controlled study on a phone that can be switched and acquired again. Determinability depends on the catalogue: a fact that the catalogue does not hold is not counted, so the shares describe the catalogue's facts, not all of a phone's posture. The benchmark codes rest on rule titles, not on each rule's full check text, and the codes say whether an image can speak to a rule at all, not whether a given store records it.

External. The evidence is skewed: most iPhone images run iOS 26, most Android images are Samsung phones on Android 16, the bug reports come from seven devices of four vendor families, and the devices are personal phones, only one of which held an installed policy profile. Results may differ on managed devices, other vendors and other releases. We claim nothing for cells of fewer than three items.

Conclusion. The comparisons are counts on a convenience sample; no statistical test is applied and none is needed for the claims made.

Limitations. The reference implementation's catalogue and expectations are not published, so readers cannot recompute determinability; the measurement method, the states and the reason classes are given so that another reconstruction can be measured the same way. No same-device pair was available, so the agreement between a full file system and a bug report of one phone was not measured. The literature search was limited to the sources cited; a systematic search of the digital forensics venues remains to be done.

8 Conclusion and Future Work

Reconstructing a phone's security settings from an acquisition fails silently when an empty read is taken for "off" and when values written by the acquisition are taken for the user's choices. We described a design that gives every posture fact one accountable state with its provenance or a typed reason, and measured its reference implementation on 54 evidence items. An Android full file system established 94% of the facts, a bug report 82% and an iPhone image 63%; bug reports did not carry most lock-state facts, and on iPhone images most undetermined facts lacked a typed reason although their stores were present. Against a separately implemented extractor no value differed and every one-sided read was explained; damage never changed a value, but it showed that a reason can be wrong when a value is not. Only a third of the rules of three public STIGs have a counterpart on an unmanaged phone. For reconstructions of this kind, including open-source ones, the result suggests reporting the reason for every undetermined fact and the observability of any benchmark used.

Three studies remain. A controlled toggle study on research phones that can be switched and acquired again would measure agreement with the state the device displayed, which this report could not. Pairs of a full file system and a bug report of the same phone would measure cross-source agreement directly. A second human coder and the licensed CIS item text would make the benchmark count firmer.