Disclaimer: This article assumes that you are in possession of a Logs archive (.logarchive file).
An invaluable source of information.
Established during the year 2016, one of the primary objectives of Unified Logs iOS is to record as much information as possible regarding the device's activity. Given this premise, it can be highly intriguing for us, digital investigators, to shed light on what they could offer us during our digital investigations. Could they provide us with more details concerning a specific action performed by the user? Through the few examples discussed below, I aim to demonstrate that these traces should not be overlooked in your investigations!
Before delving into the heart of the matter, I would like to emphasize that Unified Logs have a limited duration (generally not exceeding 30 days), as illustrated by the following statistics:
During a forensic investigation of an Apple phone, have you ever found yourself asking one of the following questions:
When was the phone last powered on/powered off ?
Was the phone unlocked using fingerprint authentication or by entering the passcode ?
At the moment the phone is unlocked/locked, is it possible to determine how long it had been in that state before the action ?
Can I accurately demonstrate that the user scrolled horizontally between his/her applications ?
All of these questions can be of extreme importance in certain types of investigations, particularly in cases like road traffic accidents for example. How can you be certain whether the person behind the wheel was or was not using their phone at the time of the impact? If you answered "Yes" to any of the questions above, then you are in the right place.
Good news, investigating these traces precisely allows you to answer these questions and much more! I've had the opportunity, in my numerous research endeavors, to conduct tests on different iPhone models running iOS 16 and find these answers. However, it cannot be ruled out that these logs may vary somewhat from one phone to another.
iOS Unified Logs - Power on / Power off the device
As is the case with every action performed on the device, a multitude of logs is generated when the user starts his/her phone. One of those logs that bears witness to this action is the following:
Timestamp | Event |
2023-10-02 10:49:36 | kernel: downloaded firmware ("0x0290.bin") in 163ms |
Similarly, when the user turns off his/her phone, the following logs are recorded:
Timestamp | Event |
2023-10-01 21:39:52 | SpringBoard: Deferring device orientation updates for reason: shutdown |
2023-10-01 21:39:53 | locationd: {"msg":"locationd shutting down", "event":"activity", "force":1, "killerPid":1} |
Through these two examples, digital investigators will be able to determine with relative ease when a phone was initialized or when the user decided to turn it off. If the user never turns off his/her phone, these logs will obviously not be found. However, it can also be important for an investigator to demonstrate that the phone was not turned off at the time of the alleged events.
iOS Unified Logs - Unlock / lock the device
Determining when the phone was unlocked or, conversely, when it was locked can provide valuable information since certain actions cannot be performed when the phone is not accessible.
At present, there are two methods to unlock one's device:
By using the previously established passcode.
By using a fingerprint or Face ID, which is grouped together under what is known as biometric authentication.
The investigation of Unified Logs allows digital investigators to determine by which method the user accessed his/her phone:
Timestamp | Event |
2023-10-01 20:21:50 | SpringBoard: Processed authentication request (success=YES): <SBFAuthenticationRequest: 0x2802e5c80; type: 1; hasPasscode: YES> |
2023-10-01 20:23:24 | SpringBoard: Processed authentication request (success=YES): <SBFAuthenticationRequest: 0x2802097a0; type: 2; hasPasscode: NO> |
The first recorded log indicates that the device was unlocked using the passcode. The unlocking process was successful ("success=YES"), and the mention "hasPasscode: YES" confirms that the correct passcode was entered. The second log records an unlock using either the fingerprint or Face ID (type: 2; hasPasscode: NO), with both methods referenced in the same log.
However, it is essential to be cautious and not draw conclusions too quickly. Indeed, the first log, mentioning "success=YES" and "type:1; hasPasscode: YES," is also recorded when the user enters the wrong code on the unlock screen!
Therefore, it is necessary not to rely solely on these logs and to use others to confirm the unlocking of the phone. For this purpose, I recommend the following log, as it is very easy to understand:
Process | Event |
SpringBoard | Unlock attempt succeeded: yes |
SpringBoard | Unlock attempt succeeded: no |
The second log in the table above will obviously be recorded when the user enters the wrong code on their phone's screen.
We can now compare the logs recorded when the unlock procedure is successful or unsuccessful:
Activity Identifier | Process | Event |
5092 | SpringBoard | Processed authentication request (success=YES): <SBFAuthenticationRequest: 0x281d11830; type: 1; source: 0; handler: "<__NSMallocBlock__: 0x280a2efc0>"; hasPasscode: YES> |
5092 | SpringBoard | Unlock attempt succeeded: yes |
143016 | SpringBoard | Processed authentication request (success=YES): <SBFAuthenticationRequest: 0x281d2c6c0; type: 1; source: 0; handler: "<__NSMallocBlock__: 0x2805e48c0>"; hasPasscode: YES> |
143016 | SpringBoard | Unlock attempt succeeded: no |
Just a heads up: Don't be surprised if the logs are recorded twice (two instances of "Processed authentication request" followed by two instances of "Unlock attempt succeeded") within milliseconds. This doesn't mean that the person unlocked their phone multiple times at lightning speed (you'll also notice that all these logs have the same Activity Identifier).
In general, paying attention to the Activity Identifier of iOS Unified Logs during your investigations is an excellent practice! It can greatly help in grouping logs related to the same action performed by the user.
Lastly, the "Unlock attempt succeeded" log is also recorded when the device is unlocked biometrical.
iOS Unified Logs - A bit more about biometric unlock
Biometric unlocking can vary significantly from one iPhone to another, so it's essential to keep this in mind as I haven't tested these different logs on all models. Nevertheless, here are some logs you can investigate to shed light on fingerprint unlocking (once again, if you don't have them, it may be due to the model or the OS version):
Process | Event |
SpringBoard | Base unlock behavior received biometric event: finger on |
SpringBoard | Base unlock behavior received biometric event: bio unlocked |
SpringBoard | Base unlock behavior received biometric event: finger off |
SpringBoard | Base unlock behavior received biometric event: identity match failed |
In the case of an unrecognized fingerprint, the second log (recorded during a successful one) will be replaced by the last one.
The following log, which is generated with each unlock, is also important because it allows investigators to determine how long the phone was locked, providing them with an idea of the device's last "usage."
Timestamp | Event |
2023-10-01 20:23:24 | apsd: Screen did unlock (Was locked for 1.245383 seconds) |
Locking one's phone can also be done in various ways, such as pressing the Lock Button or asking Siri to "Lock my phone." An important point to mention is that the log below, generated by the SpringBoard process, is recorded in both cases! Therefore, this log alone is not sufficient to prove that the user pressed the specific button:
Timestamp | Event |
2023-10-04 20:23:24 | SpringBoard: performSleep: Locking the device with lock button source and animating fade-out |
2023-10-04 20:23:24 | apsd: Screen did lock (Was unlocked for 305.244956 seconds) |
As was the case before, the process "apsd" records, in seconds, the duration for which the phone was accessible. Highlighting this information can be extremely valuable if a driver claims not to have touched his/her phone while driving, for example.
iOS Unified Logs - Horizontal Scrolling
Once the phone is unlocked, the user can horizontally scroll through his/her various downloaded applications before clicking on the one they choose. In this scenario, three potentially interesting logs can be found:
Timestamp | Event |
2023-10-03 19:12:33 | SpringBoard: SBRootFolderView beginning user-initiated scroll |
2023-10-03 19:12:33 | SpringBoard: SBRootFolderView ending user-initiated scroll - willDecelerate: YES |
2023-10-03 19:12:33 | SpringBoard: SBRootFolderView ending deceleration of user-initiated scroll |
In my research, I have observed that the first log is generated when the user begins scrolling between his/her applications, and the two last logs occur once the user lifts his/her finger from the screen. If they do not lift their finger and perform a "partial" scroll (keeping their finger on the screen for a few seconds, for example), the two final logs will be recorded with several additional seconds compared to the first one.
Conclusion
Reconstructing with precision the actions taken on a phone can sometimes be challenging. However, as demonstrated by these brief examples, investigating the Unified Logs recorded by iPhones can be highly valuable for digital investigators. We have only scratched the surface here by showing how a phone was unlocked and for how long, for instance. Such information can be crucial in certain investigations where a phone is involved, particularly in cases related to traffic accident investigations when it is necessary to prove that a driver was using their smartphone at the time of the offense.
In the following articles, we will delve into other logs, especially those generated by third-party applications, to explore in greater detail the benefits of considering them.