Reading sysdiagnose files with five new modules

Summary

• Five new iLEAPP modules read text and property-list files inside a sysdiagnose: the associated-domains database, two managed-configuration event lists, the Network Extension configuration archive, two iCloud Drive state files and the process list.
• The pull request adds ten artifacts in five modules. Each reports the printed or stored values and carries notes on what the file does and does not establish.
• Row counts on three sysdiagnoses were re-counted with separate code and agree. The count of one file was corrected from 557 to 554 process blocks before merge.
• At submission, iOS 27, iOS 17 and 18 archives and several Network Extension types were unverified on real data. The Lab later ran the readers on an iOS 27.0 archive (Figure 4).

The issue

A sysdiagnose is a bundle of many small files, and most examiners read the few that a tool shows them. Several of the files in it answer questions that come up in real cases, and this pull request adds readers for them. Which apps declare a relationship with which websites? Was a managed-configuration setting or profile changed, and by which process? Is a VPN or a per-app network rule configured? Which apps have iCloud Drive containers, and when did they last sync? Which processes were running at the moment of capture?

Without a reader, an examiner opens each file as raw text or a serialised plist. com.apple.networkextension.plist is the harder case: it is a keyed archive, and its rules are not visible in a plain text view. The brctl files print identifiers in a shortened form that cannot be joined to the container list by eye. Figure 1 lists the files and the artifacts that now read them.

The failure here is not a wrong answer but a missing one. A question that the archive could answer goes unasked because reading the file takes hand work, and a hand-written count of 1,942 domain entries is not something anyone will check.

The essence

The pull request adds five modules in the style of the existing sysdiagnose readers. Each finds its file by name inside a .tar.gz or a folder and returns rows whose values are as printed or stored. Times are parsed to UTC only where the file states them in UTC, and are left as printed where the zone is not stated. The notes of each artifact say what the file does not establish.

Two design choices matter for how the rows are read. Large rule lists in the Network Extension file are grouped, because 163 rules with the same values are one fact, not 163. And a process is reported as printed, with no start time, because the tool's clock is not in the file.

Our methodology

The readers were written from the printed and serialised layouts. The pull request states that they were written from the file formats and not copied from other tools. For each file we looked at its structure first: the sections of the swcutil dump, the keys of the event dictionaries, the archive objects of the Network Extension file, the library lines of the brctl dump, the process: lines of the task list. Figure 2 shows the three reading modes.

Several details came from that look. The brctl library lines print the container identifier in shortened form, so each dump line is matched to a container by pattern; the match is reported as Yes, Ambiguous or No (Figure 3). The event files hold one event per setting field, not a sequence of changes: 431 rows shared 23 distinct times in the file read. Times in the brctl dump carry no zone, so they are shown as printed.

On the real data, the checks followed one rule: do not trust the reader's own count. Counts for the three sysdiagnoses were re-made with separate code that reads the raw members: service blocks, process: lines, event dictionaries, library lines, and an archive walk for the Network Extension rules (247 and 184 rules, in 3 and 2 groups). They agreed, with one exception. The first draft of the notes said 557 process blocks for the iOS 26.6.2 file; the file holds 554, and the notes were corrected. A pass of the repository's output checker over three reports found four uniform columns on the iOS 26.6.2 report, which are now named in the notes.

All test data is synthetic. A generator script builds the files with invented bundle identifiers (com.example.*), example.com domains and derived UUIDs, and ten test cases carry recorded baselines. On a Windows host the project's database-backed cases fail for a reason that is unrelated to this change, so the baselines hold the forward-slash form of the source path that the Linux job produces. The pull request also lists what was not verified: the Network Extension VPN, content filter and app VPN keys on a device that held them, any iOS 17 or 18 archive other than partial ones, and iOS 27. The uuid2path file was not implemented because it is absent from every iOS 26 sysdiagnose seen.

The value

For an examiner, the gain is a set of questions that a sysdiagnose can now answer from a report. Associated domains show pairings of app identifiers and websites, including system apps and App Clips. The managed-configuration lists show which process set or removed a restriction, and the profile list shows profile operations. Network Extension configurations and rule groups show what network policy the device carried. The brctl files show which iCloud Drive containers are registered and the operating system builds the daemon recorded over time. The process list shows what was running when the archive was made.

The same readers ran, unchanged, on an iOS 27.0 archive from a third device (Figure 4). Eight of the ten gave rows. Two were empty: the per-app associated-domain settings, where the section is present but prints no entries, and the profile events, where the stored list is empty. Both depend on what was configured on the device, so we do not attribute them to the release.

Every row is a lead. A domain pairing does not show that the app is installed or that anything was opened from the site. A listed process does not show that the user opened it, and an absent one may still be installed. A container is registered, not shown to hold files. A remove event is the record of a value being removed, not of a setting having been used. An empty result is not evidence that no VPN, filter or profile was ever present. Only three sysdiagnoses were counted at submission and one more later, so the counts describe those devices.

Where this sits in the Lab's research

These readers are part of the file-level evidence in LAB-TR-0011, Log Compression and Archive Structure in the iOS 27.0 Sysdiagnose: An Early Observation Tested Against Ten Archives (version 1.2, preprint, not peer reviewed; doi:10.5281/zenodo.23720069). Section 4.5 and Table 6 re-run them on one archive of each device, which is the source of Figure 4. The report is on the Lab site at LAB-TR-0011.

LAB-TR-0010, on reading these new sysdiagnose files, is in preparation and has no public page. The method above rests on the pull request.

Sources

Every number and claim above, with where it came from. PR means the pull request text, its diff or its review thread.

Related posts