What the iOS Unified Log Says About Device Security Controls: Most Leave a Trace, Few Record a Change

1 Introduction

iOS offers its user, and a device administrator, a set of security controls: Lockdown Mode, Stolen Device Protection, the passcode and the lock state, privacy permissions, configuration profiles and device management, VPN and content filters, among others [13]. In an investigation the question is often whether one of them was on at a given time, whether it changed, or whether it blocked something. A sysdiagnose, the diagnostic archive an iPhone writes on request, carries the unified log of the last days, and the log is written by the daemons that implement these controls. Whether a control's state can be read from that log is therefore a practical question with no measured answer.

A motivating example. Lockdown Mode is turned on by the user and needs a restart [10], so one might expect a line that records the change. In the iOS 27.0 log examined here, the Lockdown Mode daemon wrote “Lockdown Mode is off” twice, the telephony daemon told the baseband eight times that the mode was false, and the messaging daemon skipped a Lockdown-only check 32 times because the mode was not enabled (Figure 1). The iOS 26.6 log holds one line from the daemon and two from the telephony daemon. In the three sysdiagnoses of two devices listed in Table 2, all 11 lines of a Photos flag read NO. No line in any of these logs records the mode being switched, and none has the “on” form. The log therefore supports “off when these lines were written”; it says nothing about the hours between them, and nothing about how an “on” state would be written.

The problem. The example is one instance of the question this report addresses: for each security control of a current iPhone, does the unified log carry a trace, is that trace a change, a decision or a restated status, and which part of it does the platform redact? Without an answer, an examiner cannot tell an absent line from an absent event, and a search that keys on a subsystem name or on a repeated line can report events that did not occur. We ask three research questions.

• RQ1 (Coverage). Which documented security controls leave a trace in the unified log, and of what kind: state change, enforcement decision or periodic status?
• RQ2 (Redaction). What do the traces withhold?
• RQ3 (Extraction). Can markers on literal message text collect the traces without counting repetition or look-alike lines as events?

Contributions. This report makes four contributions.

• An inventory of 45 security controls drawn from Apple's documentation, each with the strength and the kind of its trace as measured on two decoded unified logs (Sections 3.1 and 5.1, Table 4).
• Counts of the marker lines per control in both logs, showing that explicit state changes are rare, that most traces restate a status, and that several controls were seen only in their negative form (Section 5.2, Figure 4).
• A map of what redaction withholds, including network endpoints printed as hash tags in nearly every connection line (Section 5.3, Table 5).
• Marker-based extraction for nine trace families, with the design rules that keep it from over-counting, results on real and public-corpus sysdiagnoses, and the look-alike lines it must exclude (Sections 3.4, 5.4 and 5.5, Tables 6 and 7).

Scope. The study describes what two decoded unified logs of unmanaged research iPhones contain, plus marker counts on further sysdiagnoses (Table 2). No control was switched on purpose, so the absence of a trace means that none was written in these windows, not that the control cannot leave one. Counts depend on the devices' use and on the log windows, and are not compared as rates between the releases. Section 7 states the limits.

Section 2 describes the log and positions the work, Section 3 the inventory, the classification and the markers, Section 4 the evidence, Section 5 the results, and Section 6 what they mean for reading a control's state from the log.

2 Background and Related Work

This section describes the unified log as evidence, the documentation of the controls, and the tools that read the log, and states where this work stands.

2.1 The unified log in a sysdiagnose

Apple platforms write one system-wide log. Each record carries a time, the writing process, an optional subsystem and category chosen by the developer, a level, and a message built from a format string and its arguments. Besides ordinary log records the store holds activities, signposts, and statedumps, records in which a process writes out a block of its current state. A sysdiagnose includes the log archive of the device, and decoders turn its tracev3 files back into records [23]. Dynamic arguments are private by default: unless the developer marks an argument public, the stored record holds <private> in its place, and the value cannot be recovered from the archive [16]. How far back the log reaches depends on volume and on the device; one practitioner account notes that many entries expire within hours and that a sysdiagnose mainly covers the days before it was taken [6].

2.2 Documentation of the controls

Apple's Platform Security guide [13] describes the hardware, system, data-protection, app, service, network and device-management controls of its platforms. Support articles describe single controls from the user's side, among them Lockdown Mode [10], Stolen Device Protection [11], iCloud Private Relay [9], Communication Safety [8], the App Privacy Report [7], iCloud data protection [15] and alerts about unwanted trackers [17]. The enterprise notes for iOS 27 add new status reporting, including Lockdown Mode status, and declarative VPN, DNS and relay settings [18]; Memory Integrity Enforcement is described in a security-research post [19]; and the security content of iOS 27 names components such as TCC, Sandbox, Safe Browsing, Managed Configuration and NetworkExtension [12]. None of these documents says what a control writes to the log.

2.3 Tools that read the log

The open-source decoder of Mandiant [23] converts log archives into records; its release 0.7.0 added the decompression that iOS 27 archives need [24], [1]. The Sysdiagnose Analysis Framework [21] converts the log and many other sysdiagnose files, and its analysers cover applications, processes, managed-configuration state and Wi-Fi, among others; none summarises security-control traces. MVT's sysdiagnose command records device details and leaves forensic checks to plug-in modules [25]. iLEAPP [20] imports a decoded log into a table and runs artifacts that select lines by literal markers; before the work reported here it had artifacts for, among others, biometric matches, unlock events and USB connections, and none for Lockdown Mode, VPN sessions, privacy-permission caches or capture sessions. Practitioner writing describes the log's value and its short retention [6]. Work on tool testing argues that forensic tools need validation against known data [22].

Position of this work. In the sources above we found no list of which security controls write to the log, no classification of the kind of trace, and no measurement of what redaction leaves readable for these controls. This report adds an inventory measured on two logs and markers built from the measured text. The inventory and the trace classes are new as far as we found; the redaction behaviour itself is documented by Apple [16], and what is new is where it falls for each control; the markers are engineering.

3 Method

The work has four steps: an inventory of controls from documents, a harvest of candidate records from each log, a classification of each control's trace, and markers built from the classified text (Figure 2).

3.1 Control inventory

We listed every control that the Platform Security guide [13] names in its contents and that a user, an administrator or the system can switch, enforce or report, and added controls described in the support articles, the enterprise notes and the security content of iOS 27 (Section 2.2). Two entries rest on observation only: a hardened web-content process seen in the iOS 27.0 log, and tracker-domain matching by the DNS daemon. A control mentioned only in secondary press coverage was left out. The result is 45 controls (Table 4).

3.2 Harvest and masked templates

For each control we wrote down candidate subsystems, processes and search terms, from the control's name, the daemons the documentation or the process list suggests, and the text of related records. One pass over each decoded log collected every record from 55 candidate subsystems, about 60 processes and about 80 terms: 3.9 million records from the iOS 27.0 log and 1.5 million from the iOS 26.6 log. Each message was reduced to a masked template, in which numbers, hexadecimal values, UUIDs and non-Apple reverse-DNS identifiers are replaced by tags, giving about 200,000 and 68,000 distinct templates. We read the templates per control and wrote, for each trace we kept, a predicate on process, subsystem, category and literal message text that reproduces its count.

3.3 Trace strength and trace kind

Each control received a strength and a kind. The strength is strong when the log carries the control's own state or decisions, partial when it carries only a status proxy or one aspect of the control, and none when no usable line was found in either log. The kind is the strongest of three classes seen for the control, in the order state change, enforcement, status (Table 1).

Where a template encodes a value as a digit, masking hides it; those values (for example a passcode set-state) were re-read from the raw text.

3.4 Marker-based extraction

A marker is a literal piece of message text, within a named process or subsystem, that selects one kind of line. The markers were implemented as artifacts of iLEAPP [20], which imports a decoded log into a table, copies the lines that match any marker into a second table in a collection stage, and lets each artifact filter that second table; the network artifacts read the first table directly, because their lines number over a million. Five rules govern the markers.

1. Literal text in a named source. A marker is a message prefix or phrase measured in Section 3.2, never a subsystem or process name alone.
2. Values as logged. Fields are copied as written; a <private> value stays <private>, a hash tag is not resolved, and no meaning is assigned that the line does not state.
3. Summaries for repeated lines. Where one state is restated many times, the artifact groups lines by process and masked template and gives the first and last time and the count, instead of one row per line.
4. Statedumps by their title. Statedump records carry no subsystem or category, so they are selected by the first line of the message (title: ...) and their body is parsed per entry.
5. Tests that fail when a marker is lost. Every family except the URL opens is tested through the real chain on a synthetic log show export with decoy lines under other subsystems; where a family uses the collection stage, a test fails if a marker that an artifact reads is missing from it.

Nine families of markers were built: URL opens [2]; camera and microphone capture sessions, with streaming power events and recording-indicator lines [3]; the TCC authorization cache and the location manager state, both statedumps [4]; a Lockdown Mode flag printed by Photos, passkey record loads, background shortcut actions and the VPN connectivity state [5]; and network connections with NetworkExtension session events (Artifact Availability).

3.5 Recount

For this report, every count from the two logs that appears in Section 5 was recomputed with a separate script that opens each store read-only and runs the predicates of Section 3.2 as SQL, and the network endpoint forms were recounted with the endpoint pattern of the network artifact. Counts on the other sysdiagnoses come from the recorded runs of the artifacts (Section 4).

4 Evidence and Setup

Table 2 lists the evidence. The two decoded logs come from two iPhones of different hardware generations, both unmanaged and in ordinary use, with no known compromise and no switching of controls for the study. They are the iOS 27.0 and one iOS 26.6 archive of LAB-TR-0011 [1]. The iOS 27.0 archive was decoded with the open-source decoder version 0.7.0 and the iOS 26.6 archive with version 0.6.0 [23], [24]; both runs completed with no rejected record, and the logs themselves mark 968 and 386 loss events, records dropped on the device before collection. The decoded records were held in one relational store per log and queried read-only.

Reference for the counts. The stored data are the reference. A count states how many records of a given form the log holds; it is checked by a second count made by other means (SQL against the stores, or a separate script that applies the marker conditions to the decoder's output), not by knowledge of what the user did. We did not observe the devices in use.

5 Results

Most controls leave some trace, few leave a change, and much of what would identify an actor or a target is redacted. Table 3 answers each research question; the subsections give the evidence.

5.1 Which controls leave a trace (RQ1)

Table 4 gives the inventory with the strength and kind of each trace, and Figure 3 summarises it. Twelve controls have a strong trace: biometrics, passcode change, lock state, code integrity, the sandbox, privacy permissions (TCC), software update, device management, configuration profiles, Safe Browsing, certificate revocation and VPN sessions. Nineteen have a partial trace, typically a status line or one aspect: Lockdown Mode, Stolen Device Protection availability, Activation Lock eligibility, Developer Mode, Private Relay on the telephony side. Fourteen have none in these windows, among them USB Restricted Mode, secure boot, the App Privacy Report (whose accesses are kept in files), Memory Integrity Enforcement, Background Security Improvements (only settings-interface lines, 124 in the iOS 27.0 log), Advanced Data Protection, pairing decisions, Wallet and the keychain.

5.2 What kind of trace (RQ1)

Explicit state changes are few and uneven between the logs (Figure 4). The passcode-change notification of the configuration daemon appears twice in the iOS 27.0 log, at one moment, and not in the iOS 26.6 log, which contains no passcode change; the line says neither who changed the passcode nor why. The keybag state lines (Unlocked, Locked, Locking) occur only in the iOS 27.0 log (286 lines); the lock-status line of the software-update daemon occurs in both (151 and 183). A permission change (“Update Access Record”) occurs once, with its own absolute time and the identifier of the requesting app in the message. Profile installation and removal occur only in the iOS 26.6 log, two install requests and one removal within one short interval.

Enforcement lines are plentiful. The iOS 27.0 log holds 6,099 TCC results (5,389 without error) and the iOS 26.6 log 8,825 (8,454 without error); sandbox violation reports number 62,035 and 28,804, the iOS 27.0 reports concentrated in 2.8 days; certificate-revocation enforcement (CRLite) appears 1,377 times in the iOS 27.0 log and never in the iOS 26.6 log. Status lines restate a state many times or seldom: “No MDM installation found” 3,142 and 1,058 times, “Activation lock is allowed” 48 and 37 times, “Lockdown Mode is off” 2 and one, “Developer mode enabled: NO” once and 9 times.

Several controls appear only in their negative or idle form. Lockdown Mode was always off; the passcode set-state value was always 1 (4 and 1 lines); every Safe Browsing check ended “no threat”; the TCC prompting wording known from macOS did not occur; and Stolen Device Protection appeared only as an availability check that failed because biometry was not enrolled (62 lines, iOS 27.0). For these controls the positive wording is unknown. The VPN connectivity state shows how a wider sample can close such a gap: in the three iOS 26 sysdiagnoses of Table 2 it never read Connected [5], while the iOS 27.0 log holds 1,121 such lines, 5 of them Connected (473 Disconnected, 340 Connecting, 303 Disconnecting).

5.3 What redaction withholds (RQ2)

Table 5 lists, per control, what the trace withholds and what it keeps. The redaction is plain: the hashed form that Apple's logging interface offers for correlating private values [16] occurs in none of the 42,588,594 and 25,598,286 records. A quarter of all records hold at least one <private> value (10,640,594 and 7,050,142, or 25.0 and 27.5 percent); this share is not a redaction rate, since it depends on how many records have a dynamic argument at all. The pattern is consistent across controls: the kind of event and the platform component stay readable, and the actor, the target and the payload are withheld. A permission request names its service (kTCCService plus a name) but not its requester, which is readable only in the separate attribution line and only for platform components; a URL open names the handling process but not the URL [2]; a certificate check gives its result but not the host.

The connection lines show the effect at scale. The iOS 27.0 log holds 1,561,241 lines of the network connection category, written by 112 processes, one of which wrote 92.4 percent of them. Of the 1,238,152 lines whose header names an endpoint, 1,235,369 give a tag of the form Hostname#, IPv4# or IPv6# followed by hexadecimal digits; only 2,783 give a name or a literal address. The other 323,089 lines carry no endpoint. The iOS 26.6 log holds fewer lines and fewer tags: 255,625 connection lines from 130 processes, of which 217,133 name an endpoint and 180,455 (83.1 percent) give it as a tag. No tag occurred under two processes (0 of 980 distinct tags in the iOS 27.0 log, 0 of 776 in a window of the iOS 26.6 log), so lines of different processes cannot be joined on a tag.

5.4 Marker extraction on further sysdiagnoses (RQ3)

Table 6 gives the results of the marker families on the evidence of Table 2. Every family returned the lines it was built for, and the counts equalled a count made by other means where one was made. Two results bear directly on how the lines may be read.

First, every capture session found in the iOS 26.5.2 corpus sysdiagnose belonged to the biometric daemon, and none to the Camera app or a third-party app [3]. A marker on capture sessions that ignores which process ran the session would therefore report camera use where the face-authentication hardware ran. Second, the statedumps add what the request lines lack: the TCC cache gives, per writing process, the cached verdict and its reason (user consent, system set, entitled), and the location-manager dumps say whether a process held a live location manager and whether it ran in the background. They do not name the application they describe; the only attribution is the process that wrote the dump [4].

5.5 Repetition and look-alikes (RQ3)

The VPN session lines of the iOS 27.0 log show why markers must not count lines as events (Figure 5). One always-on style tunnel produced 3,752 “On Demand start” lines, 3,851 “Received a start command” lines and 3,745 “Skip a start command” lines, while the session's status changed 306 times, 102 times to connecting and once to connected. A count of start lines would report thousands of sessions for one configuration.

Other lines match an obvious search term but record something else (Table 7). The most instructive is the remote-configuration subsystem, whose growth from 29 records in the iOS 26.6 log to 3,298 in the iOS 27.0 log was first read as a sign of device management. All 3,298 records were written by a weather widget (3,179) and the weather daemon (119), as were all 29 in the iOS 26.6 log; the four most frequent templates of the iOS 27.0 log occur 138 times each, one configuration request cycle repeated. None concerns management. A subsystem name alone is not a marker.

6 Discussion

6.1 Reading a control's state from the log

Because most traces restate a status and few record a change, what the log supports for most controls is a last known value with a validity window: the value of the last status line, valid from the first to the last line that restates it, and unknown outside the window of the log. A change can be placed only between the last line of one value and the first line of the next, unless a change line falls in that interval. The absence of a line supports a statement only for controls whose status is restated regularly; the 3,142 restatements of “No MDM installation found” support “not enrolled” across the iOS 27.0 window, while the absence of an “on” line for Lockdown Mode supports nothing on its own.

6.2 What the examiner can and cannot say

With the traces measured here an examiner can say, for example, that the passcode was changed at a given moment, that the device reported itself locked and unlocked at given times, that a permission for a named service was decided, that the sandbox denied named operations, or that a VPN session changed state. Because of redaction the examiner usually cannot say who requested a permission, which URL was opened, which host a certificate check concerned, or which server a process contacted. Where the log withholds the value, a file in the same archive may hold it: both corpus sysdiagnoses also hold the permission database, which names the requesting app [4].

6.3 Release differences

Some wording differs between the logs: the keybag state lines and the Stolen Device Protection checks occur only in the iOS 27.0 log, a Screen Time status line only in the iOS 26.6 log. With one device per release, use and release are confounded, and we do not attribute these differences to the release. A marker that is to be used on another release should be re-measured there; the markers of Section 3.4 are tested against synthetic exports, which fix their syntax, not against every build.

7 Threats to Validity

Internal validity. The trace of a control was found by searching candidate subsystems, processes and terms; a trace written under names we did not think of is missed, so the 14 controls without a trace are a statement about our search as well as about the logs. Template masking can merge distinct events and hides values written as digits; we re-read such values from raw text where they mattered. The strength and kind were assigned by one person; a second reader was not used.

Construct validity. A line is a record a process chose to write, not an observation of a user's action. Status lines are written when a daemon starts or is asked, so their frequency measures daemon activity, not the stability of the state. Several meanings, such as the weather origin of the remote-configuration records or the capture-time origin of the integrity notices, are read from the writing process and the text, not from documentation.

External validity. Two decoded logs from two unmanaged devices of different generations and use, with windows of 11.8 and 32.5 days, cannot represent iPhones in general. No device was managed and none had Lockdown Mode on, so the positive branches of most traces are unobserved. The further sysdiagnoses are iOS 26 only. The two logs were decoded with different decoder versions.

Conclusion validity. No inference beyond the counts is drawn, and no rate is compared between the releases. Counts are given per log because usage differs: the messaging application, for example, wrote 149,788 records in one log and 29 in the other.

Limitations. The Platform Security guide was used at the level of its contents. The study did not measure logs reached through a full file system extraction, the log show rendering of the marker lines (only decoded archives were read), the timing of status lines relative to the events they restate, or other tools' handling of the same lines. One control (AirDrop and Bluetooth sharing) was classified from earlier observation and not re-measured on these logs.

8 Conclusion and Future Work

Whether an iPhone's security controls can be read from its unified log had not been measured. We inventoried 45 controls from Apple's documentation, searched two decoded logs of research iPhones for their traces, and classified each trace as a change, a decision or a restated status. Thirty-one controls left a trace and 14 did not; few traces record a change, many controls were seen only in their negative form, and redaction withholds most actors, targets and payloads, including the endpoints of nearly every connection line. Markers keyed on literal text in a named process, with repeated lines summarised, collected the traces on further sysdiagnoses without counting repetition or look-alikes as events. On these logs a control's state is a last known value with a validity window; the same reading applies to any tool that reports these lines, open-source parsers included.

Future work, in order of value: (1) a protocol on test devices that switches each control at logged times on iOS 26 and iOS 27, to record the positive wordings (Lockdown Mode on, VPN connected, Stolen Device Protection on) and to measure how soon a status line follows a change; (2) the same inventory on managed devices and on more builds; (3) the marker lines as rendered by log show and in logs from full file system extractions.