Where Device Security Settings Live on Disk: A Verified Path and Key Map for Unmanaged iPhones and Android Phones, and Pitfalls That Produce Silent Empty Reads

1 Problem

Examiners are asked to state how a phone was configured: whether it had a passcode policy, whether updates installed automatically, whether Lockdown Mode, Find My or Mail Privacy Protection was on, whether USB debugging was enabled. On a full file system extraction these settings are read from files: property lists on iOS, settings XML files, SQLite databases and build property files on Android. A reader of such a file can fail without an error. It may look under the wrong path, open the wrong one of several files with the same name, parse a binary file as text, open a database without its journal, or look up a key that the platform writes only after a user changes the setting. Each failure produces the same output as a setting that is unset: an empty field.

A motivating example. On Android 12 and later the platform writes the settings files in Android Binary XML (ABX), a binary encoding of XML [5], [10]. In our sample, 53 of 58 settings files were ABX. A standard XML parser rejected all 53, and a text search for the pattern name="…", which finds every setting in a plain XML settings file, found nothing in any of them, while a decoder for the binary format recovered between 69 and 505 settings per file. A reader that catches the parse error and returns an empty list, or that searches the text, reports every setting on these phones as absent.

The gap. Paths and key names for these settings are scattered across vendor schemas, platform source, tool modules and practitioner notes. They are rarely stated together with the condition under which a read of them is valid, and we found no published map that was checked against a set of real extractions, with counts of how often each source exists. This white paper supplies such a map for phones that are not under device management, and names the conditions that turn a correct path into an empty result.

Questions. We ask three questions.

• Q1 (Locations). Where do common security settings live on iOS and Android full file system extractions (path, file, key or table, format), and how often is each source present?
• Q2 (Preconditions). Which condition must hold for a read of each source to be valid, by operating system family and version?
• Q3 (Pitfalls). Which reading errors return an empty result without an error, and how often did their trigger occur in the sample?

Contributions. (1) A path and key map for iPhone and Android settings in which every entry is either verified on real extractions, with the number of extractions that carried it, or marked as taken from documentation and not verified (Section 4.1 to 4.3). (2) The preconditions for a valid read, by format and version range (Section 4.4). (3) Ten pitfalls that produce silent empty reads, each with the trigger counted in the sample and a guard (Section 4.5). (4) A reading of Apple's device-management schema that shows which restriction keys can occur at all on an unsupervised iPhone (Section 4.6).

Scope. The map describes where settings are stored and what makes a read of them valid. It does not say what a value means for security, which values are acceptable, or how settings should be assessed; value semantics are given only where the platform documents them and are otherwise out of scope. Counts describe 48 extractions of research devices (Section 3.1). No device was toggled and re-extracted, so the map establishes where a key is stored, not how each value changes when a user changes a setting.

2 Background

2.1 Storage formats

Property lists (iOS). iOS preferences are property lists in one of two encodings: binary (the file begins with bplist00) or XML. A reader that accepts only XML finds nothing in a binary file. Preferences of system daemons are usually under /private/var/mobile/Library/Preferences/; data shared by a group of apps sits in an app-group container whose directory name is a random identifier, mapped to the group by a metadata property list in the container.

Android Binary XML. ABX files begin with the four bytes 41 42 58 00 (“ABX” and a version byte of zero). Each token is one byte that combines a command (start tag, end tag, attribute, text) with a value type, and repeated strings are stored once and then referenced by index [5]. The format first appeared on Android 12 test images, mostly in system files [10].

SQLite and its journal. In write-ahead logging (WAL) mode, committed changes are appended to a separate -wal file and reach the main database file only at a checkpoint; a database separated from its WAL file can lose committed transactions [14]. Bytes 18 and 19 of the database header are 1 for a rollback journal and 2 for WAL [15], so the header tells a reader whether a -wal file must accompany the database. A previous report measured the effect on one iOS store: counts changed when the log was not applied on 14 of 17 stores [4].

2.2 Users, containers and storage classes

Android keeps per-user data in directories named by user number: device-encrypted (DE) storage under /data/system_de/<user>, /data/user_de/<user> and /data/misc_de/<user>, credential-encrypted (CE) storage under /data/system_ce/<user>, /data/misc_ce/<user> and /data/user/<user> [6]. Settings are stored per user under /data/system/users/<user>/. A previous report showed that a parser that takes the first matching file can return only a second user's copy [3].

2.3 Device management on iOS

Apple publishes the schema of its device-management payloads [7]. For each key it states the release that introduced it and whether it requires a supervised device, that is, one enrolled by an organisation. A supervised-only restriction cannot be set on a personal iPhone, so its absence there is expected and says nothing about the user. On a personal device, effective restriction and passcode values are kept in a profile store whose typed wrapper (restrictedBool, restrictedValue) has been described in practitioner work on the auto-lock and passcode settings [12].

2.4 Related sources and position of this work

Open-source parsers read several of the files mapped here: ALEAPP reads the Android settings files and decodes ABX [8]; iLEAPP reads the Find My accounts file, the system version file and the App Privacy Report streams [9]; MVT reads the Lockdown Mode key from the global preferences [13]. Earlier Lab reports measured silent failure modes of parser suites on current releases [3], the ABX settings files on two Android 16 images [2], the App Ops files [1] and the effect of the WAL on the Screen Time store [4]. Tool testing literature calls for validation against known data [11]. This paper does not test or compare tools. It contributes a location map in which each entry carries the number of real extractions that held it, the precondition for a valid read, and the pitfalls that defeat a read, gathered in one place.

3 Method

3.1 Evidence

The evidence is every full file system extraction in the Lab's research corpus: 48 extractions, read only (Table 1). One duplicate copy of an extraction was counted once.

3.2 Candidate map

We compiled a candidate list of sources from Apple's device-management schema [7], Android platform documentation and source [5], [6], the modules of open-source parsers [8], [9], [13] and practitioner notes [10], [12]. The list covers commonly discussed security settings: operating system release and patch level, passcode and lock screen, automatic updates, Lockdown Mode, Find My, Mail Privacy Protection, iCloud Private Relay, Screen Time restrictions and App Privacy Report on iOS; and on Android the settings namespaces, lock screen store, credential files, developer options and USB debugging, installation from unknown sources, app verification, device administrators, users, accounts, Wi-Fi, Bluetooth and runtime permissions.

3.3 Verification on extractions

Each extraction is a zip archive (a vendor container or a plain archive). A verification script read the archive's central directory, which lists every member, and matched each candidate path against it. Because the containers place the file system under different prefixes, the script first found the prefix from a known anchor (the global preferences directory on iOS, data/system/ on Android) and removed it. For every matched source it then recorded:

1. Presence, and every other directory in which a file of the same name occurred (user numbers and container identifiers normalised; third-party app containers collapsed to a placeholder).
2. Format, from the first bytes: binary or XML property list, ABX or plain XML, SQLite with its journal mode (header byte 18) and the sizes of any -wal or -journal file.
3. Decoding: property lists with a standard library parser; ABX with a decoder written from the platform serializer [5]; for comparison, each settings file also with a standard XML parser and a text search; SQLite databases opened from private copies, once with and once without their -wal file.
4. Key presence for named keys, structures and table rows. Values were never recorded.

Separately, we parsed the restriction and passcode payload schemas of Apple's device-management repository at release Release-v27.2 [7] and counted, for every key available on iOS, whether the schema marks it supervised-only, and whether five key names that are easy to derive from user-facing labels exist in the schema.

3.4 Ratings

An entry is rated verified when the file was found at the stated path and, where a key is named, the key was found in at least one decoded file; the table then gives the number of extractions that carried the source and the key. An entry is rated documentation only when the source was not found on any extraction or its key could not be checked; it is listed so that a reader knows it was not confirmed here. Neither rating says what a value means.

4 Findings

The verification ran over all 48 extractions with no read errors. Archives held between 45,837 and 3,068,129 members. Figure 1 shows the five steps of a read at which the pitfalls in this section occur.

4.1 iOS path and key map

Table 2 gives the iOS map. Paths are relative to the root of the file system. Every property list among the system preference files we decoded was a binary property list (192 files); the profile store files were XML in 26 and binary in 17 of 43 cases, so a reader must accept both encodings.

Three points need comment. First, the Find My accounts file was not always where tools look for it: the file was at /private/var/mobile/Library/Preferences/ on 19 extractions, inside a system data container with a random name (/private/var/containers/Data/System/<UUID>/Library/Preferences/) on 14, all of them iOS 26, and in the system group container systemgroup.com.apple.icloud.findmydevice.managed on 7; it was absent from 13. Two copies existed on 20 extractions and differed in size on all of them, so a reader that knows only one path reads one of two different files. Second, the profile store holds the typed wrapper on every extraction that had it: entries of restrictedBool carry one key, value, and entries of restrictedValue carry value, rangeMinimum and rangeMaximum. Each store held between 40 and 275 restrictedBool entries, which is more than a user sets, so the presence of a key in this store does not show that a person or a profile set it. Third, the companion files ProfileTruth.plist, PayloadManifest.plist, UserSettings.plist and PublicInfo/NamespacedUserSettings.plist exist on current releases (34, 34, 31 and 34 of 34 extractions), in both profile store directories. The profile store itself occurred in both directories on 8 extractions; the copies differed in size on 8, and on 8 the archive recorded a later modification time for the copy in the mobile user's directory.

4.2 Android path and key map

Table 3 gives the Android map, Table 4 the presence of individual settings keys. Paths are relative to the root of the file system image; <u> is a user number.

Three observations matter for readers. First, keys that guides describe as legacy are still written: install_non_market_apps was in the secure settings of all 14 extractions, so its presence says nothing about the current release. Second, the lock screen store no longer holds the keys older guides name: lockscreen.password_type was present on 2 extractions (Android 10, 13) and lock_pattern_autolock on none, while sp-handle, which points to the synthetic-password blob, was present on all 14. Third, not every numbered directory under data/system/users/ is a user: on 3 Samsung extractions a directory numbered 1000 held only files of the vendor's data-protection engine and appeared in no other per-user tree, so user numbers should be taken from userlist.xml. The second user that does appear, number 150, was present on 6 extractions and had its own secure and system settings files, but never a global one, which is device-wide.

4.3 Sources that were not found

Several sources named in documentation or older guides were absent from every extraction or held none of their documented keys (Table 5). A reader that depends on them returns nothing on current devices, and their absence must not be read as a setting being off.

4.4 Preconditions by format and version

Table 6 states, for each format, the version range in which we observed it and the condition a read must meet. Figure 2 shows the switch from plain XML to ABX for the Android settings files.

4.5 Pitfalls that produce silent empty reads

Table 7 lists ten pitfalls. For each it names what returns empty, how often the trigger occurred in the sample, and a guard. Figure 3 shows the pitfall that is easiest to miss on iOS: a preference file that exists but does not hold the key, because the key is written only when the setting is changed.

4.6 What the iOS schema implies for unmanaged iPhones

In Apple's restriction payload (com.apple.applicationaccess) at Release-v27.2, 176 keys are available on iOS, and 121 of them are marked supervised-only [7]. On a personal, unsupervised iPhone these 121 cannot be set, so a reader should report them as not applicable, not as missing. All 10 iOS keys of the passcode policy payload (com.apple.mobiledevice.passwordpolicy) are available without supervision. Five key names that are easy to derive from the labels in Settings do not exist in the schema in that form, and a lookup by them returns nothing (Table 8).

5 Recommendations

For authors of readers and for examiners who check a reader's output, the findings reduce to one rule: a reader must report why a field is empty. We recommend the following.

1. Report four states, not two. Distinguish a value that was read, a key that is absent from a file that was read, a source that is absent from the extraction, and a source that could not be read (wrong format, missing journal, decode error). Only the first is a statement about the setting.
2. Find the root before matching. Derive the container's path prefix from an anchor file and match relative paths; do not anchor a pattern at the start of the member name.
3. Choose the copy deliberately. Prefer the canonical system path; list every other same-named file (asset copies, managed-preference copies, backup copies, third-party bundles) and say which one was read.
4. Resolve containers by metadata. Find app-group and system containers through their metadata files, and search the known container classes for relocated preference files.
5. Enumerate every user. Read settings, accounts, lock screen rows and permissions for each user number, and expect device-wide settings only under user 0.
6. Sniff the format. Decode ABX when the first four bytes are 41 42 58 00, accept binary and XML property lists, and treat a parse error as “not read”, never as an empty list.
7. Bring the journal. Read a SQLite database together with its -wal file whenever header byte 18 is 2, and state whether the log was applied.
8. Treat a missing key as unknown. Many preferences are written only after a change. Use a documented default only when the platform documents it, and label the result as a default.
9. Check key names against the schema and the release. Validate iOS restriction names against the device-management schema, mark supervised-only keys not applicable on unsupervised devices, and expect renamed and partition-prefixed keys on Android (Section 4.3).
10. Test with a second user and a binary file. A reader's test set should include an ABX file, a binary property list, a database with a non-empty -wal file, and an extraction with a second Android user.

6 Limitations

No toggle study. No phone was switched between settings and re-extracted. The map therefore establishes where a key is stored and in what format, not which value corresponds to which state, and not whether a change in Settings always reaches the file. A controlled toggle-and-diff study on a test iPhone and a test Android phone is the next step and would be needed before the map supports statements about value semantics.

Sample. The sample is one research corpus. Of the 14 Android extractions, 12 are Samsung, and Android 11 and 15 are absent; 20 of 34 iOS extractions run iOS 26. One iOS extraction was acquired before first unlock, one held neither the system volume nor the mobile user's directory, and for one the iOS version could not be determined. Counts are reported per version where the version matters and are not generalised beyond the devices examined.

What was checked. Presence was checked against archive member names and key presence against decoded files; the script recorded no values. A source found under a path not in the candidate list would be missed unless its file name was among those searched for relocated copies. The management state of the devices was not determined; that most were personal phones is an assumption from their provenance, not a measurement, and the entries in the profile store do not separate user choices from defaults. Value semantics stated in Section 2 come from documentation. The App Privacy Report check counted non-empty stream files, not records.

Not covered. Settings held only in the keychain, in secure hardware or in a server-side account (for example the activation state of Find My on Apple's servers) are outside a file system map. Logical and backup extractions, sysdiagnose archives and Android bug reports were not examined.