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 previous articles, we've examined user behavior through the investigation of unified logs (such as phone unlock events, touchscreen interactions, and the use of the voice recorder, for example), logs that can be of great importance when it comes to demonstrating that a driver, for instance, manipulated their phone to make a call or to write a message.
Today, I would like to share with you, a few logs that would be very interesting to investigate in cases of road accidents. Why? Because the logs presented in this article can help you determine when the phone user started their car and when they stopped it before leaving.
It is essential to clarify that in the article presented here, the phone was not connected via Bluetooth to the vehicle, the "Driving Focus" feature was not activated, and finally, the phone was not linked via CarPlay to the vehicle. These different connections will be explored in future articles. Therefore, this is almost the worst-case scenario possible (except for a completely turned off or discharged phone, for example). Nevertheless, we will see that even in this unfavorable situation for digital investigators, some interesting logs can be analyzed.
However, caution should be exercised regarding their interpretation and accuracy. If the unified logs I presented in my previous articles were very accurate, these are much less so! However, it's also crucial to introduce logs that shouldn't be blindly trusted as they could lead to false conclusions.
These will only be indications, and I can only recommend confirming them with other evidence.
iOS Unified Logs - Walking
Before being able to take the wheel, it's not uncommon to have to take a few steps to reach one's vehicle. With the nice weather slowly arriving (at least in Switzerland), we could imagine a user enjoying a coffee on a terrace. While seated at the table of their favorite restaurant, their status, according to their iPhone, is marked as "stationary." In other words, the phone registers no movement.
When the user starts moving, their status will transition from stationary to walking, as recorded by the following log:
Timestamp | Event |
2024-04-21 14:07:12 | symptomsd: Motion State Transition: Stationary->Walking (stationary:1->0 moving:0->1) |
For example, if 30 minutes prior, you have the opposite log, that is:
Timestamp | Event |
2024-04-21 13:33:03 | symptomsd: Motion State Transition: Walking->Stationary (stationary:0->1 moving:1->0) |
It becomes increasingly interesting to trace the "journey" of the phone user. We can determine when they were in motion and when they were stationary, allowing us to formulate hypotheses.
Finally, if you're dealing with an athlete, you might see the term "running" instead of "walking":
Timestamp | Event |
2024-04-22 19:14:53 | symptomsd: Motion State Transition: Stationary->Running (stationary:1->0 moving:0->1) |
However, it is very important for me to emphasize that the unified log "Motion State Transition: Walking" is not as precise as it may seem (that would have been too good...), so interpretation must be approached with caution and it is really important to know it !
Indeed, during my tests, I discovered that it could also register when the phone is taken out of a pocket or picked up from a table, for example. Moving the phone can make it think that it is in motion. Therefore, I strongly advise against blindly relying on these logs; they should serve as indications, especially when state transitions last only a few seconds. If there appear to be many logs indicating "Stationary->Walking" and "Walking->Stationary" over a short period, it's possible that the user was simply checking their phone occasionally (for replying to messages, for example).
On the other hand, convincing the phone of a "running" movement is more challenging because it requires much more vigorous manipulation of the device.
iOS Unified Logs - Start Driving
The user eventually reaches their vehicle, opens it, and sits down. They have once again transitioned from a "Walking" state to a "Stationary" state. Indeed, before actually starting to drive, one can imagine that the user takes the time to fasten their seatbelt and place their belongings (phone, keys, wallet, etc.) in the central console. These few seconds are enough for the phone to register a stationary state. However, don't be surprised if the state transitions directly from walking to "vehicular". Acting more quickly during my tests, there were instances where the stationary state was not recorded between Walking and Vehicular states (see the logs in the table below).
It is crucial for me to clarify that the described logs below were observed when the iPhone was in the central console of the vehicle. Keeping my phone in the pocket of my phone during driving, the logs presented below were not recorded.
At the moment when the user is seated in the car, we have the following log:
Timestamp | Event |
2024-04-21 16:21:32 | symptomsd: Motion State Transition: Walking->Stationary (stationary:0->1 moving:1->0) |
I want to mention that the log format might be slightly different depending on the iOS version of the investigated iPhone. For example, with iOS 15, this log is recorded as follows:
Timestamp | Event |
2024-04-21 16:21:32 | symptomsd: Transition to state:Stationary (current:Walking), stationary:0->1 moving:1->0 |
Therefore, don't be overly restrictive in your predicate commands when investigating unified logs.
iOS Unified Logs - Let's make a comparison !
To facilitate the comparison, here's a summary of my journey recorded by Google Maps, starting at 3:08 PM and ending at 3:35 PM on 21st of April (however, GPS was not active during the journey):
Once ready, it's now time to start the car and set it in motion. When this occurs, a multitude of logs are recorded by the iPhone, assisting digital investigators in forming a hypothesis about the individual's departure. Now, imagine someone leaving the scene of their misdeed in a motor vehicle; it could be very interesting to investigate these various logs in detail to form a hypothesis. However, I would remain cautious regarding the accuracy of recording these logs. I wouldn't be surprised if they are recorded with a delay of a few seconds or even minutes in some cases. Nevertheless, it's still valuable to know that they exist. Therefore, don't take them as absolute truth but rather as an indication that you'll need to confirm.
Timestamp | Event |
2024-04-21 15:08:36 | locationd: VEHICULAR: vehicularStartTime, <private>, seq, <private> |
2024-04-21 15:08:36 | wifid: -[WiFiManagerMotionServices startMonitoringMotionState]_block_invoke [MOTION] MotionState: Driving - (CMMotionActivity @ 55764.292634,<startDate,2024-04-21 13:08:36 +0000,confidence,2,unknown,0,stationary,0,walking,0,running,0,automotive,1,cycling,0>) |
2024-04-21 15:08:36 | symptomsd: Motion State Transition: Stationary->Vehicular (stationary:1->0 moving:0->1) |
2024-04-21 15:08:36 | carkitd: Handling com.apple.vehiclePolicy.DNDMode notification |
2024-04-21 15:08:36 | carkitd: [com.apple.carkitd.assertion-service:83607030-DE6C-4E31-B589-81418FF295AD] Get mode configuration, identifier=com.apple.donotdisturb.mode.driving |
2024-04-21 15:08:36 | carkitd: Engaging Driving. |
2024-04-21 15:08:37 | contextstored: ATXModeDrivingFeaturizer: received new DNDWD event |
2024-04-21 15:08:37 | contextstored: ATXModeDrivingFeaturizer: Driving mode activated by Do Not Disturb While Driving |
The first occurrence of all these logs is a very effective way to highlight the moment when the user started driving their vehicle. Indeed, several of these logs (those recorded by processes like wifid or carkitd, for example) will also be recorded during the actual driving. A quick way to determine when the vehicle started moving is to look for the first Unified Log from the table above: "locationd: VEHICULAR: vehicularStartTime, <private>, seq, <private>", and then search for the others, presented in the table above, to strengthen your hypothesis.
My phone running on iOS 15 also recorded some logs at that time, albeit with a few seconds of delay. Since this phone wasn't connected to the internet, that might explain it:
Timestamp | Event |
2024-04-21 15:08:09 | locationd: VEHICULAR: vehicularStartTime, <private>, seq, <private> |
2024-04-21 15:08:09 | wifid: -[WiFiManagerMotionServices startMonitoringMotionState]_block_invoke [MOTION] MotionState: Driving - (CMMotionActivity @ 728.311369,<startDate,2024-04-21 13:08:09 +0000,confidence,2,unknown,0,stationary,0,walking,0,running,0,automotive,1,cycling,0>) |
2024-04-21 15:08:09 | symptomsd: Transition to state:Vehicular (current:Stationary), stationary:1->0 moving:0->1 |
I find it particularly interesting that the time of recording of these various logs corresponds to the departure time I can see on the Google Maps application. However, as we will see later in this article, I would remain cautious regarding the interpretation of these logs because they may not always be as precise.
iOS Unified Logs - Stop the Car
Similarly to what we've highlighted for the departure of the vehicle at 3:08 PM, can we also pinpoint its stop? Let's explore which logs we could investigate.
The first observation I can mention is that I couldn't find a log "Motion State Transition: Vehicular>Stationary (stationary:0->1 moving:1->0)" at that time. However, I did find the following two logs that seem interesting:
Timestamp | Event |
2024-04-21 15:35:20 | wifid: -[WiFiManagerMotionServices startMonitoringMotionState]_block_invoke [MOTION] MotionState: Driving Stopped - (CMMotionActivity @ 57367.657798,<startDate,2024-04-21 13:35:20 +0000,confidence,2,unknown,0,stationary,1,walking,0,running,0,automotive,1,cycling,0>) |
2024-04-21 15:35:20 | sharingd: Stationary: no -> yes |
These two logs are recorded several times during my journey in the vehicle. Although they are recorded in pairs (with the same activity identifier), it seems risky to assume that they identify all the stops of the vehicle (such as at a red light, for example). However, search for their last occurrences can help us determine when the vehicle stopped for the last time. Stopping doesn't leave much precise trace, I admit, but that's the way it is.
In the first log above, we can also notice the mentions "stationary, 1" and "automotive, 1," which were perfectly correct in my case.
iOS Unified Logs - Motion state transition
The question you're probably wondering is why I don't have the log from the "symptomsd" process that we saw earlier. My hypothesis is as follows: As explained for walking (Motion state walking), this log seems to be partially linked to the user's manipulation of the phone. To clarify my point, here are some situations that illustrate it (some testing I made on 27th April):
While keeping my phone in my pocket throughout my journey in the vehicle, the log "Motion State Transition: Walking->Vehicular" (and the other mentioned previously) was not recorded.
While keeping my phone in my pocket during the first part of the journey (approximately 5 minutes, I started my journey around 15:27 on the 27th April), the log "motion state vehicular" was not recorded. I then stopped in a parking spot (to simulate stopping at a red light) and took my phone out of my pocket to write a message. I observed the following logs:
Timestamp | Event |
2024-04-27 15:33:04 | symptomsd: Motion State Transition: Walking->Vehicular (stationary:0->0 moving:1->1) |
2024-04-27 15:33:05 | SpringBoard: Processed authentication request (success=YES): <SBFAuthenticationRequest: 0x2830f34b0; type: 2; source: 0; handler: "<__NSMallocBlock__: 0x282566a00>"; hasPasscode: NO> |
It seems that taking the phone out of my pocket acted as a kind of "update" regarding its status and thus triggered the recording of the "Motion State Transition" log. At the same time, I also have all the logs described earlier that indicate the departure of the car, including:
Timestamp | Event |
locationd: VEHICULAR: vehicularStartTime, <private>, seq, <private> |
These observations could perfectly explain why I don't have the "Motion State Transition: Vehicular>Stationary" log at 3:35 PM on April 21, which is when I definitively stopped my car (see Google Maps screenshot):
Since this iPhone is a test iPhone, I don't use it for communication, for example. In other words, when I stopped my car, I took a few minutes to check the various notifications I had on my everyday phone (an Android...) without touching my iPhone! And as I mentioned earlier, it seems that "No manipulation = No log". My car was indeed stopped, but since I didn't touch my phone, it didn't perform the "update". Once my quick check was done, I picked up my iPhone and got out of my car, at which point we can see the log being recorded:
Timestamp | Event |
2024-04-21 15:37:36 | carkitd: Evaluating transition to Non-vehicular state. |
2024-04-21 15:37:37 | symptomsd: Motion State Transition: Vehicular->Walking (stationary:0->0 moving:1->1) |
2024-04-21 15:37:47 | routined: <private>, received motion alarm, PedestrianAfterDriving, location, <private>, error, (null) |
Once again, these hypotheses are simply the result of my observations and tests. After realizing this, I also tested picking up my phone when I stopped my car, and the "Motion State Transition" log was indeed recorded at that moment. Ultimately, while the "Motion State Transition" log seems to be recorded somewhat automatically when the user manipulates their phone, it can be an indicator of phone use during driving (though, in my opinion, there are logs that are much more interesting for demonstrating this).
Although recorded with a delay of a few seconds, the log generated by the "routined" process mentioning "PedestrianAfterDriving" seems particularly interesting to me!
iOS Unified Logs - Get the phone out of my pocket
There are many proximity logs (iOS Unified Log Category = ProximitySensor) that attempt to determine if the phone is in a pocket or not. For example, I can mention these:
Process | Event |
SpringBoard | pocketStateManager:didUpdateState:0 |
SpringBoard | -[SASSiriPocketStateManager _updateForPocketState:] #SiriPocketStateManager: PocketState changed to CMPocketStateTypeOutOfPocket |
SpringBoard | pocketStateManager:didUpdateState:1 |
SpringBoard | -[SASSiriPocketStateManager _updateForPocketState:] #SiriPocketStateManager: PocketState changed to CMPocketStateTypeInPocket |
SpringBoard | pocketStateManager:didUpdateState:2 |
SpringBoard | -[SASSiriPocketStateManager _updateForPocketState:] #SiriPocketStateManager: PocketState changed to CMPocketStateTypeFaceDown |
SpringBoard | pocketStateManager:didUpdateState:3 |
SpringBoard | -[SASSiriPocketStateManager _updateForPocketState:] #SiriPocketStateManager: PocketState changed to CMPocketStateTypeFaceDownOnTable |
Unfortunately, all these logs are very imprecise! They are recorded at any time, and I often obtained "didUpdateState:0" and "CMPocketStateTypeOutOfPocket" even when the phone was in my pocket, for example. Due to their significant number, I do not recommend relying on them. I hold the same opinion regarding this log:
Process | Event |
SpringBoard | Ambient presentation allowed = YES [ enabled:YES ; lockedButNotBlocked:YES ; ignoreLockState:NO ; unlockedSinceBoot:YES ; carplay:NO ; screenOccludingAccessory:NO ; hostingApp:NO ; isInSetupMode:NO ; isOutOfPocket:YES ; isViewObstructed:NO ; listInteraction:NO ; pullDownCoverSheet:NO ; spotlight:NO ; todayView:NO ] |
Another log referencing pockets is recorded by SpringBoard, but it's just as imprecise as the previous ones. However, while the mention of "isOutOfPocket" should not be considered due to its imprecision, I must inform you that I haven't evaluated the other mentions that can be found in this log.
iOS Unified Logs - Let's walk again !
Once the car is stopped, the user exits and starts walking to their desired destination. We can observe the logs we already discussed previously:
Timestamp | Event |
2024-04-27 16:23:45 | symptomsd: Motion State Transition: Stationary->Walking (stationary:1->0 moving:0->1) |
2024-04-27 16:23:51 | routined: <private>, received motion alarm, PedestrianAfterDriving, location, <private>, error, (null) |
Once again, the second log, explicitly mentioning "PedestrianAfterDriving," seemed particularly interesting to me.
As explained earlier, if the user quickly exits their vehicle, don't be surprised to see the following log:
Timestamp | Event |
2024-04-27 16:47:21 | symptomsd: Motion State Transition: Vehicular->Walking (stationary:0->0 moving:1->1) |
Conclusion
The unified logs presented in this article must be investigated with caution! As mentioned several times, they may not be as precise as they appear. However, it is important to be aware of them, not to blindly believe them, to pay attention to them, and then to confirm them with other evidence or logs, for example.
Although investigating these unified logs can be complicated and sometimes seem imprecise, I believe it remains very interesting to know about them. In this first part, we observed that a multitude of logs is still recorded even when the phone is not connected to the car via CarPlay and Bluetooth! While observations/hypotheses resulting from the investigation of these different logs will need to be confirmed with other evidence (as always...), knowing that they exist is still very interesting. Personally, I always drive with my phone somewhere in the car, and in this situation, the precision of the logs seemed rather accurate regarding the departure of the vehicle and its final stop. I don't think I'm wrong in assuming that few of us keep our phones in our pockets while driving and that these logs should not be dismissed so quickly.
In future articles, we will try to compare these logs with those obtained when the phone is connected to CarPlay or Bluetooth in the car to see if the precision is only better. We will also analyze the use of the "Driving Focus" option and see how it could help us in our investigations.
Through this article, it is important to remember that the absence of logs mentioning terms like "vehicular" or "driving," for example, does not mean that the person in question was not driving. Likewise, having them does not prove that the person was behind the wheel (they may have been a passenger), hence the need, once again, to confirm all this with other evidence. However, I remain convinced that it can be interesting to take a look at them when you don't know when an accident occurred... the person probably got out of their vehicle with their phone to take some photos or make a call, for example, thus giving an idea (which will need to be confirmed later, once again) of the time of impact.
Enjoy your Digital Investigations !
Lionel Notari
Want to know more about me? Take a look at my presentation page or my photography website. www.lionelnotari.com
Comments