Disclaimer: 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.
In digital forensics, the investigation and interpretation of unified logs from iOS devices are necessary for discovering relevant traces. These logs give complete information into device activity, user behavior, and specific events such as changes in device orientation or screen backlighting as we will see in this article. The ability to extract and analyze these logs is required for forensic investigators and others involved in digital investigations.
This article focuses specifically on unified logs related to the orientation and backlighting of iPhones. By examining these logs, investigators can add elements to the reconstruction of the events and have a detailed understanding of device usage from the beginning of the "problematic° action to the end. Such detailed analysis can help in various scenarios and my "favourite" one is always in road traffic accident.
We will have a look to the different types of orientation logs, how they record the device's position, and their relevance in forensic investigations. Additionally, we will delve into backlight logs, explaining how they capture screen activation events triggered by various actions such as receiving notifications or interacting with Siri.
The most recent articles focused on the analysis of WiFi logs and motion states have been really long, this is why this one is a bit shorter . This one will go straight to the point without much embellishment, providing a clear and concise overview of these unified logs.
iOS Unified Logs - Orientation
First of all, here are the different possible orientations for your phone. The backboardd process defines them very well, and to ensure that we are on the same page, I have displayed next to the unified logs the Apple pictograms detailing the different possible orientations:
Event | Orientation |
backboardd: Effective device orientation changed to: portrait (1) |  |
backboardd: Effective device orientation changed to: portraitUpsideDown (2) |  |
backboardd: Effective device orientation changed to: landscapeLeft (3) |  |
backboardd: Effective device orientation changed to: landscapeRight (4) |  |
backboardd: Effective device orientation changed to: faceUp (5) |  |
backboardd: Effective device orientation changed to: faceDown (6) |  |
A very important note: I have been studying the iOS Unified Logs for several years now, and those recorded by the backboardd process have existed for a very long time. In other words, you should always be able to find them during your investigations. Please also note that the faceUp orientation, whose pictogram may not be the clearest, illustrates a phone lying horizontally with the screen facing up. FaceDown is, of course, the opposite.
Finally, it is not always easy to remember the difference between "landscapeLeft" and "landscapeRight" orientations. To avoid confusion, look at where the lightning port (or USB-C) of your phone is located. If it is on the right side of the screen, then the orientation is "landscapeRight."
Now that we have described the basic orientations of the phone, we can study some logs that will provide you with additional information. The backboardd process, once again, records a unified log mentioning the previous position of the device and the new one, as shown in the unified logs below:
Event | Orientation |
backboardd: Received orientation. (Portrait to FaceUp) | |
backboardd: Received orientation. (LandscapeRight to PortraitUpsideDown) | |
backboardd: Received orientation. (FaceUp to FaceDown) | |
This can be very interesting in certain cases, and as always, I can only recommend that you look for different concordant unified logs.
Finally, the SpringBoard process also records several unified logs each time the user changes the phone's orientation. Here is a list:
Event | Orientation |
SpringBoard: [SwitcherOrientation] outSwitcherOrientation: landscapeLeft (4), outElementsOrientations: { "sceneID:net.whatsapp.WhatsApp-default" = 4; } |  |
SpringBoard: Active interface orientation changing from portrait (1) to landscapeLeft (4) | |
SpringBoard: Received active interface orientation did change from portrait (1) to landscapeLeft (4) with duration 0.3 | |
SpringBoard: Broadcasting active interface orientation (landscapeLeft (4)) change to registered clients with sequence #: 8. | |
Many logs point in the same direction, specifically a "landscapeLeft" orientation. During your investigations, I recommend cross-referencing these logs, recorded by the SpringBoard process, with those I previously presented, recorded by the backboardd process.
The most interesting unified log in the table above is obviously the one that allows you to know which application the user was in when they changed the orientation of their phone. Here are some additional examples of this log:
Event | Application |
SpringBoard: [SwitcherOrientation] outSwitcherOrientation: portrait (1), outElementsOrientations: { "sceneID:ph.telegra.Telegraph-default" = 1; } | Telegram |
SpringBoard:[SwitcherOrientation] outSwitcherOrientation: portrait (1), outElementsOrientations: { "sceneID:com.apple.Fitness-default" = 1; } | Fitness |
SpringBoard: [SwitcherOrientation] outSwitcherOrientation: portrait (1), outElementsOrientations: { "sceneID:com.waze.iphone-default" = 1; } | Waze |
SpringBoard: [SwitcherOrientation] outSwitcherOrientation: portrait (1), outElementsOrientations: { "sceneID:com.apple.camera-default" = 1; } | Camera |
Most of the time, if not always, you will also have a log from the application's process that records this orientation change. This can only help you confirm which application the user was in when they turned their phone. Here are some examples:
Event | Application |
Telegram: <UIWindowScene: 0x10360dea0> (9B21ACB0-A0AB-4FD8-A217-4C3D5DCCE227) Scene will change interface orientation: portrait (1) | Telegram |
MobileSafari: <UIWindowScene: 0x10316cf00> (95672E30-7CC7-4A8E-BFD4-6964973D4F1E) Scene will change interface orientation: landscapeRight (3) | MobileSafari |
WhatsApp: <UIWindowScene: 0x10a30c7f0> (D4B31AE4-4F7D-4A05-BA2F-4C9CDE6049B8) Scene will change interface orientation: landscapeRight (3) | |
Camera: <UIWindowScene: 0xe5ce08180> (0C904BC2-19AA-4ACC-8547-5474D07EB809) Scene will change interface orientation: landscapeRight (3) | Camera |
By the way, I will soon write a detailed article about the "Camera" application because it is very interesting and records numerous logs that can be pertinent to consider in certain investigations.
iOS Unified Logs - Backlight
The concept of backlight is simply a term illustrating the illumination (backlighting to be precise) of the screen. The most concrete example is a notification that we receive which automatically lights up our phone screen (unless we have set a different setting, of course). There are many reasons that can cause the screen to light up automatically:
Event |
SpringBoard: Animating backlight to factor 1.00 with duration 0.18 source:2 (home button) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.18 source:3 (lock button) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.00 source:12 (notification) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.00 source:13 (prox) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.00 source:14 (Siri) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.00 source:15 (boot) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.00 source:20 (lift to wake) |
SpringBoard: Animating backlight to factor 1.00 with duration 0.00 source:26 (transient overlay) |
In the table above, several events can turn on the screen, pressing the home button or receiving a notification for example. We can also note that activating Siri by saying "Siri" is clearly recorded. One of the most interesting logs is perhaps the one indicating "lift to wake," which is generated when the phone is taken by the user, causing the screen to turn on automatically. Finally, a clarification must be done regarding the transient overlay element, which is recorded during an incoming call.
However, the most recent versions of iOS record the above logs in a slightly different manner. As usual, I can only recommend verifying what you can observe (or not) during your investigations. Here are some examples:
Event |
SpringBoard: Animating backlight to state active on animated:YES source:2 (home button) |
SpringBoard: Animating backlight to state active on animated:YES source:3 (lock button) |
Finally, when we turn off the screen (I am not referring to turning off the phone here), logs similar to those previously presented are also recorded:
Event | iOS Version |
SpringBoard: Animating backlight to factor 0.00 with duration 0.18 source:3 (lock button) | Before iOS 16 |
SpringBoard: Animating backlight to factor 0.00 with duration 0.18 source:8 (idle timer) | Before iOS 16 |
SpringBoard: Animating backlight to state inactive animated:YES source:3 (lock button) | iOS 16 and after |
SpringBoard: Animating backlight to state inactive animated:YES source:8 (idle timer) | iOS 16 and after |
The differences between iOS versions being minimal, the best I can recommend is to start your investigation with a broad search, for example, by simply typing "Animating backlight to".
Conclusion
The unified logs presented in this article, combined with those analyzed in previous articles, increasingly aids digital investigators in reconstructing actions that may have led, for example, to a collision. For instance, backlight logs reveal when the screen lit up due to a notification, while orientation logs show how the phone was held and rotated. Unlock logs indicate when the phone was ... unlocked (obvious I know) and WhatsApp logs could show an active use of the messaging app. By analyzing these logs together, investigators can determine if the driver was distracted by their phone at the time of the impact.
By investigating all these unified logs together, investigators can create a timeline of events, possibly showing that the user was distracted by their phone just before the accident. This can provide solid "evidence" (in "" because we will have to confirm them with other sources) in road accident cases or other situations needing a close look at phone use.
Enjoy your Digital Investigations !
Lionel Notari
Comments