Key finding
– One Unified Log hit proves little. Hits from different processes, run in one marker window, can support a conclusion.
– On iOS 18.2.1 a Face ID unlock leaves three lines from three processes within 33 milliseconds. Each records a different step.
– Every set comes with a second column: what it cannot show.
– The companion sheet holds twelve sets, in the same layout as the search term sheet.
Part of the Anchored Log Reconstruction series. Part 2 of 2, after A hit is not a trace: search terms that mislead (Part 1 of 2) – Thesis Friday #31.
Last week was about hits that mislead. A hit that holds up still needs company. The companion cheatsheet groups twelve search term sets, each built around one question.
One question, several processes
A set is a handful of terms from different processes, run in the same marker window. This is the set for “which unlock method?” on an iPhone:
| Level | Search term | Process / subsystem |
|---|---|---|
| Biometric | inBioUnlock matchResult MATCH | biometrickitd, kernel |
| Face ID hardware | isFaceDetected=1 getFaceDetectInfo PearlCamFrameReceived | kernel, AppleH13CameraInterface |
| Touch ID hardware | kAppleBiometricFingerOnEvent kAppleBiometricFingerOffEvent | kernel, AppleMesaSEPDriver |
| Passcode | SBUIPasscodeTextField Suppress Scanning State | SpringBoard, UIKit:KeyboardSceneDelegate |
No row answers the question alone. Each one says that a process wrote a string. The question gets answered when the rows that apply to your device agree.
Example: a Face ID unlock on iOS 18.2.1
These three lines come from my thesis reference data: an iPhone 12 mini with iOS 18.2.1, recorded on 9 March 2025 (UTC+1). #1 describes the first one.
| Timestamp | Process / subsystem | Message | After line 1 |
|---|---|---|---|
| 14:50:43.337360 | kernel / AppleH13CameraInterface | PearlCamFrameReceived - isFaceDetected=1 … hasAttention=1 … | 0 |
| 14:50:43.368613 | WidgetRenderer_Default / ChronoServices | [com.apple.chrono:keybag] Transition: locking -> unlocked | 31.3 ms |
| 14:50:43.369979 | biometrickitd / BiometricSupport | identities:withClient: | 32.6 ms |
The lines record three different steps. The kernel line says the camera captured a frame with a face in it and that the user was looking at the screen. The keybag line records a change of state. The biometrickitd line shows that biometric identities were requested for a client. The message is cut off in my reference line, so that is as far as I read it.
The search term sheet says Transition: locked -> unlocked is absent on a biometric unlock. On this build the biometric chain carries locking -> unlocked instead, which is another reason to name the build and search on the exact string.
Together the three lines support a Face ID unlock on this device and build. The support comes from three processes each recording a different step. The 33 milliseconds between them do not carry the argument, because proximity is not causality (#25).
What the set cannot show
Each set on the companion sheet has a column for what it cannot show. For the unlock-method set it says that a Face ID frame on its own is not a match, and that FD Distance 0 means no detection. It says that success=YES is not evidence of a passcode entry. It also says that the lines rejecting an attempt fire on a wrong passcode and on a failed Face ID, so the surrounding cluster decides which.
This is #22 in practice. The column stops a strong-looking hit from carrying more than the line can bear. The example above does not show whose face it was, and it does not show that another build behaves the same way. It shows a sequence on one device.
Combining sets
A case rarely needs one set. An unlock, the touch before it and the button press before that each have their own. Put the results in one timeline and keep the window of each set visible. Name the level at which you counted, and write down every zero.
The two sheets work as a pair. The search term sheet says what a line is. The sets sheet says what to put next to it. A single term cannot support a reconstruction, but hits from different processes, counted at a named level and checked on your own reference device, can.
Limits and version notice
The example comes from one device and one build, acquired through a sysdiagnose, which holds less than a direct collection (#7). The sets are lists of search terms with notes, not interpretations of a whole event. They were measured on the builds named in the footer of the sheet, unless a note says otherwise.
Apple changes what it logs between versions of iOS, iPadOS, macOS and watchOS, including in minor updates and betas. A term can change, move to another process or subsystem, or stop being written at all. Do not carry a set over to another version without a new reference action. Record the device, the build and the acquisition method for every search you run.
Send me an artifact
Is a term missing from a set, or does a set no longer work on a newer version? Send it to tim@thesisfriday.com. Include the device model, the OS version and build, the exact action you performed with the time and the clock you read it from, the raw log lines, and how you acquired the log. Do not send case data. Contributions are checked against a reference action before they are added, and accepted ones are credited by name unless you ask otherwise.
© 2026 Tim Korver — Thesis Friday. Licensed under CC BY-NC-ND 4.0. Method: Anchored Log Reconstruction (ALR). Commercial or training use requires written permission. See Copyright and Use.