Disclaimer: This article assumes that you are in possession of a Logs archive (.logarchive file). The information and analyses presented in this article are the result of personal research and testing. They are provided for informational and educational purposes only. Any commercial use of the contents of this article without prior written permission from the author is strictly prohibited. Users are not authorized to copy, reproduce, transmit, or distribute the contents of this article without permission. The author disclaims any responsibility for the consequences of using the information contained in this article. For permission requests, please contact the author directly.
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.
iOS Unified Logs - Opening an Application
The easiest way to open an application is, obviously, to click on its icon. This action will generate some unified logs that you should investigate:
Timestamp | Event |
2023-10-03 20:00:04 | SpringBoard: Icon tapped: <private> |
2023-10-29 20:00:05 | SpringBoard: Initiating launch from icon view: <private> |
The two logs above can already help you show that the phone has been tampered with, but they don't tell us which application has been opened.
To have this information, take a look at the following logs:
Timestamp | Event |
2023-10-29 17:48:23 | SpringBoard: Bootstrapping application<net.whatsapp.WhatsApp> with intent foreground-interactive |
2023-10-29 17:48:23 | WhatsApp: Initializing connection |
The first two logs are very telling, especially as the first one mentions ‘foreground’, but these logs are only recorded when the application wasn't already running in the background. If you find these logs, then the application was completely closed before the user clicked on it.
I should also point out that the Bootstrapping log has changed a little bit on iOS 17, and now looks something like this:
Process | Event |
SpringBoard | Bootstrapping app<com.apple.tips(0A2313B5-6BE7-47CF-9D48-3B09767A3C42)> with intent foreground-interactive |
The ‘Initializing connection’ log, recorded by the open application process, has not changed.
Here are a few more examples:
Event | Application |
SpringBoard: Bootstrapping app<com.apple.mobilesafari(0A2313B5-6BE7-47CF-9D48-3B09767A3C42)> with intent foreground-interactive | Safari |
MobileSafari: Initializing connection | Safari |
SpringBoard: Bootstrapping app<com.apple.tips(0A2313B5-6BE7-47CF-9D48-3B09767A3C42)> with intent foreground-interactive | Tips |
Tips: Initializing connection | Tips |
These unified logs can therefore help you find out which application has been opened by the user.
However, the logs presented above are not enough. What can you do if the application you opened was already running in the background?
In general, here is a set of unified logs that you can use to find out which application has been ‘in Focus’:
Event | Application |
SpringBoard: [app<com.apple.tips((null))>:794] Setting process visibility to: Foreground | Tips |
Symptomsd: changedForegroundState to 1 for com.apple.tips | Tips |
Symptomsd: com.apple.tips: Foreground: true | Tips |
Symptomsd: Report state change to foreground for com.apple.tips | Tips |
mediaserverd: <<<< FigCaptureDisplayLayoutMonitor >>>> -[FigCaptureDisplayLayoutMonitor _updateObserversWithLayout:]: <FigCaptureDisplayLayoutMonitor: 0x686850050 Main Display> <FigCaptureDisplayLayout: 0x6880d3cc0 08-27-2024 13:12:16, Main Display, foreground:[com.apple.tips]> | Tips |
SpringBoard: Application process state changed for com.apple.tips: <SBApplicationProcessState: 0x3029c25e0; pid: 843; taskState: Suspended; visibility: Foreground> | Tips |
SpringBoard: [app<com.apple.tips(0A2313B5-6BE7-47CF-9D48-3B09767A3C42)>:843] Setting process visibility to: Foreground | Tips |
SpringBoard: [0x3014675a0:(FBSceneManager):sceneID:com.apple.tips-default] Scene assertion state did change: ForegroundFocal. | Tips |
SpringBoard: [0x3014675a0:(FBSceneManager):sceneID:com.apple.tips-default] Scene lifecycle state did change: Foreground | Tips |
backboardd: new scene host settings: contextID:5ACA9995 <sceneID:com.apple.tips-default> unspecified -> foreground | Tips |
In the table above, you can see that the common term between all these logs is ‘Foreground’, which means that the application is active and open. It is therefore this application that is currently in front of the user.
We can also investigate the logs using the term ‘Focus’. Here are a few logs:
The second log is particularly interesting, as it tells you which application was in focus before the one the user has just opened! The fourth log is also worth noting, as it seems that all this is also recorded in Biome. I haven't had a chance to make any comparisons yet, but it would be worth it!
Here's another example of this second log:
Event | Application |
SpringBoard: elementWithFocusBundleID changed. old: com.apple.tips; new: com.apple.mobileslideshow; | Photos |
I'm well aware that all this represents a lot of logs, but you don't need to find them all during your investigations. A few will suffice to show which application was open at the time.
iOS Unified Logs - Leaving an Application
In the same way, here are some unified logs recorded when the user exits an application:
Event | Application |
SpringBoard: didRemoveExternalForegroundApplicationSceneHandle pid:843 scene:@com.apple.frontboard.systemappservices/FBSceneManager:sceneID%3Acom.apple.tips-default now:<empty> | Leaving Tips to Home Screen |
SpringBoard: rules: target changed from:<pid=843 token=@com.apple.frontboard.systemappservices/FBSceneManager:sceneID%3Acom.apple.tips-default> to (null) | Leaving Tips to Home Screen |
SpringBoard: Focused scene identity did change to: (null) | Leaving Tips to Home Screen |
contextstored: Setting value for /device/app/inFocus: | Leaving Tips to Home Screen |
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 iPhone 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 offence.
Finally, we have seen that launching an application, or putting it ‘in Focus’ so that you can use it, also generates a large quantity of unified logs.
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.
Enjoy your Digital Investigations!
Lionel Notari
Comentários