It is not often that I get to revisit previous research. Most, if not all, of us do research, share it (hopefully), and then move on to the next thing. There is so much to examine that it is nearly impossible to revisit things, especially in the mobile device space. When we do go back, though, it is usually because something has changed, and that is what happened here. I was presented with a series of questions about CarPlay at work which can be summed up in one question: can an examiner tell the difference between when a user uses CarPlay to perform an action and when the actual iOS device is used. The short answer is “yes, it is possible.” The longer answer is, of course, this post.
Almost six years ago, I wrote a blog about Apple CarPlay, and, shortly thereafter, Sarah Edwards and Heather Barnhart gave a great presentation at the 2019 SANS DFIR Summit that also discussed CarPlay & Android Auto. Six years is an eternity in digital forensics, and, needless to say, things have changed with CarPlay. There have been a few changes in the file system artifacts, and our understanding of iOS Unified Logs has come a long way, too.
For background on CarPlay, see my previous article. Just know that since that time not only have most vehicle manufactures implemented it in a majority of their product lines, but many have also implemented wireless CarPlay. This post will address wireless when applicable.
Changes
For testing I used an iPhone 14 (iOS 17.5), 14 Pro (iOS 18.2), and a 16 Pro (18.3.1), and my Nissan Rogue (yep, the same one from the 2019 article – I hang on to cars for a while). The car wasn’t the only that has not changed; the plist files that I mentioned back in 2019, for the most part, have not changed, either, save one. Since 2019 CarPlay has gotten its own “recently used” file, which was covered by Chris Vance here. As a recap, see Figure 1.
Located in /private/var/mobile/Library/Preferences/, com.apple.CarPlayApp.plist contains a list of recently used apps, along with a Unix Epoch timestamp for when they were last used (blue boxes in Figure 1). Each app in the list is identified by the bundle name with their respective last used timestamp. One oddity that I will note: Apple Maps always had a last update of when I disconnected from the car. I suspect this is likely due to the Today View in CarPlay (swiping left to right from the home screen), but have not been able to find any data to confirm this. Regardless, this file now negates the need to examine com.apple.springboard in the same location.
The file also has a timestamp that represents the time the last CarPlay session ended. That is highlighted in the red box in Figure 1.
The next change is knowledgeC. While some data examiners/investigators would be interested in has migrated to biomes (i.e., CarPlay connections), there is some residual data that is also interesting: Siri invocations. Knowing that a driver summoned Siri to perform an action via CarPlay versus the user picking up the phone and performing that action could go a very long way in a suspected distracted driving investigation. In Figure 2, the ZOBJECT table contains records that relate to my summoning Siri via a button on my steering wheel.
Figure 2 is an excerpt of ZOBJECT, and while there are multiple records shown, it represents one action by me: using Siri to send a message via CarPlay. Here, I used a button on my steering wheel to summon Siri, asked her to send a message, dictated the message to her, she read it back to me, and then sent it after I confirmed the message’s accuracy. Reading the ZVALUESTRING column values from the bottom up in Figure 2 (highlighted in the red box), that is clearly seen. The request was started (com.apple.siri.dictation-siri-request-started) via the steering wheel button (com.apple.siri.steering.wheel) in CarPlay (com.apple.siri.button.on.carplay) at which time she and I went back and forth dictating and confirming the message accuracy (com.apple.siri.dictation-siri-request-started). The times, highlighted in the orange box, further confirm the series of events. Seeing com.apple.siri.dictation-siri-request-started around the time a message was sent can help with determining if Siri was, in fact, involved in sending a message or reading a message back to a driver.
There is another data source that an examiner can leverage to discover Siri invocations, but more on that later.
When it comes to suspected distracted driving, the rest of the data in knowledgeC could be interesting. For example, /app/usage streams, but they don’t tell you if this was done via CarPlay or via the phone. An examiner could form some logical conclusions, though. For example, the app Threema does not have CarPlay functionality, and if an examiner saw /display/isBacklit with a value of 1, /device/isLocked with a value of 0, then /app/usage with the Threema bundle name, and then a Threema message was sent shortly thereafter, all in that order, then there is a high likelihood that the user sent the Threema message via the phone and not CarPlay, even if those events occurred while the phone was connected to CarPlay. More on actions taken within CarPlay later.
Speaking of CarPlay connections…
Biomes
Many things that used to reside in knowledgeC have migrated to biomes as of iOS 16, and CarPlay connections is one such thing that has made the trip. CarPlay connections have their own biomes. Notice I said biomes, plural. The first is is _DKEvent.Carplay.IsConnected, and it is found in /private/var/mobile/Library/Biome/streams/restricted/. The biome files in this location have two key pieces of information: when the CarPlay session started, and when it ended. See Figure 3.
Figure 3 shows the bottom biome record. The red box on the right is when the CarPlay session started, and the blue box is when the session ended. Note that this period of time covers the time at which we see the Siri invocation in knowledgeC (Figure 2).
I have drawn a line between the start time on the right and the red box to the left for a reason. At times, examiners may observe that there is a record written to the biome that represents a disconnection state, or, the state from which the device is coming to the connected state (i.e., “disconnected”). It may not always be present, but I wanted to draw attention to it as I have observed it from time to time.
The second biome location for CarPlay connections is CarPlay.Connected, and it is found in the same file system location as _DKEvent.Carplay.IsConnected. These biomes have two values, one of which indicates the connection state of CarPlay. See Figure 4.
As previously mentioned, occasionally examiners will find records that are indicative of the state from which the device is coming to the connected state. Here, the value at key 1 is “0,” meaning CarPlay is currently disconnected. The record in Figure 5 has the same timestamp in the left, and aligns with the start time seen in Figure 3. Note that the value at key 1 is now “1,” meaning the CarPlay is connected.
Figure 6 shows the CarPlay session ending as the value at key 1 returned to “0,” and the timestamp for that record also aligns with the disconnection time see in Figure 3.
When it comes to actual app usage within CarPlay biomes may help. There are two streams of interest: ScreenTime.AppUsage and App.InFocus. Both are located in /private/var/mobile/Library/Biome/streams/restricted/, and each is important for separate reasons. Figure 7 shows ScreenTime.AppUsage.
The red box to the left in Figure 7 shows the time the first app used during the CarPlay session, and the red box to the right shows the app being used, Podcasts. If you recall from Figure 1, the value CARStartApplicationBundleID was com.apple.podcasts. When I plugged the phone in to the Nissan, the Podcast app opened automatically in the CarPlay UI, so this entry makes sense.
Additionally, I have highlighted the value “1” at key 1 in the blue box. In my testing of CarPlay, values of “1” at key 1 can indicate the app was in use in the CarPlay UI, and values of “0” can indicate the app was not in use in the CarPlay UI; however, and this is a big however, this same behavior was also observed when doing things on the phone itself, so, while slightly helpful, it still is not confirmatory that a particular action happened on the phone versus the CarPlay UI, and examiners will need to further corroborate the values they find here. Another observation I had is that when two records have the same timestamp, it is typically indicative of switching from one app directly into another, which you can see based on the values at key 1.
One additional note here. Using Siri to dictate or read messages will not appear here unless the messaging app of choice is opened first. As an example, recall that I summoned Siri to send an iMessage (seen in knowledgeC from Figure 2.). See the highlighted areas from ScreenTime.AppUsage in Figure 8.
I have two times highlighted in the red box in Figure 8. These times bookend the period of time in which I dictated a message to Siri via CarPlay, which was seen in knowledgeC in Figure 2. Figure 9 highlights the message in the iMessage UI. Note the timestamp is in UTC -0500.
The app bundle com.apple.MobileSMS does not appear in ScreenTime.AppUsage during the time in question. More on this shortly.
The other biome stream of interest is App.InFocus. This stream is important not only for what it contains, but also what it does not contain. Taking the messaging example from above, Figure 10 shows the applicable time in App.lnFocus.
The first entry for this CarPlay session does not appear until 20:40:07. That was after I had connected the phone to the car, started a podcast , receive an iMessage and dictated a reply, opened Maps, switched to the CarPlay home screen, and received and replied to another iMessage, all via the CarPlay UI. Testing found that actions taken via the CarPlay UI do not appear in App.InFocus, and this makes sense as the phone was displaying nothing; it was locked and facing away from me while it was in my cupholder. The entry at 20:40:07 is my use of iMessage via the phone itself to send a message. Figure 11 shows the message.
In this scenario, I unlocked the phone to send a message via the phone itself and then quickly locked the phone back, all while CarPlay was running. This can be seen in knowledgeC starting in Figure 12.
Once unlocked, I opened iMessage from the home screen. See Figures 13 and 14 for how this looks in App.InFocus and ScreenTime.AppUsage, respectively.
Figure 14 drives home what was mentioned earlier about how the “1” values at key 1 (highlighted in the blue box) can represent app usage in both CarPlay or the phone itself.
Again, after sending the message, I locked the phone. Figures 15, 16, and 17 show this action in knowledgeC, App.InFocus, and ScreenTime.AppUsage, respectively.
Other biomes may also be useful. In the above example the phone detected that I had picked it up and the screen came on before I unlocked it. So, examiners can also use the biome Device.Display.Backlight to further bolster the fact that the phone was in use during the time in question. Positive records in this biome alone do not confirm I was using the phone, but it certainly strengthens what is found in the other biomes and knowledgeC. Another biome that could be useful in corroboration is Audio.Route, as Siri audio would be routed through the car speakers. See Figure 18.
The record entry above is an example of when audio output of the iPhone is routed through CarPlay. This timestamp aligns with when I started a podcast via the Podcase app in CarPlay. Note that you can see a value of “CarAudio” at key 3 and a value of “CarPlay” at key 4. In key 2, I have highlighted the string that is the Bluetooth MAC address of my car in the red box. The additional times at 20:34:02 (also confirmed by knowledgeC in Figure 2), 20:34:32, 20:39:07, and 20:39:32 were my interactions with Siri (message playback and dialogue for dictating a return message) since her audio was coming through the car speakers. This was in lieu of picking up the phone, unlocking it, and reading the message I had received.
I will note that the phone had not been paired with the car via Bluetooth.
If the phone speakers were used, the value would appear as it does in Figure 19.
Unified Logs
Our understanding of Unified Logs has come a long way in the last six years, but I, and many others, feel the community still hasn’t realized their full forensic potential. When it comes to CarPlay, the Unified Logs carry some information that can be verified with other artifacts in the file system, and some information that is exclusive to the Unified Logs themselves. Starting with CarPlay connections, see Figure 20.
For wired CarPlay connections, the process sharingd documents the “session” connection and disconnection events, and the timestamps here align with what was seen in the biomes _DKEvent.Carplay.IsConnected (Figure 3) and CarPlay.Connected (Figure 4). Wireless CarPlay sessions look a little different. See Figure 21.
In addition to the messages seen in Figure 20, Wireless CarPlay sessions have an extra message “Wireless CarPlay session state changed.” that accompany the connection and disconnection events. As before, the process sharingd is logging the information.
Cars are considered “accessories.” The process accessoryd will log some information about the car, along with the type of connection. For an example of a wired connection ,see Figure 22.
The data in the red box relates to my Nissan. Nissan’s head units are manufactured by Bosch, so this makes sense. I will note that I do not drive a 4-door van. 🙂 The blue box contains the connection type, which, in this case, was a Lightning to USB-A connector to the USB-A port in my car, and the orange box contains what is likely the mode of data transport between the phone and the car, which is, again, USB.
Wireless connections look slightly different depending on the type of connection. Some connections happen over Wi-Fi. Figure 23 below shows an example.
This the same vehicle, but with a wireless CarPlay dongle attached to it, which I picked up on Amazon. The data in the red box is the same as Figure 22, but the connectionType and transportType values are different. I suspect “IP” value in the blue box is “Internet Protocol” as it appeared, during testing, that the dongle created an ad hoc Wi-Fi network. This is somewhat confirmed by the transportType value of “AirPlay.” One additional note here: you can expect to find entries related to this connection in the biome Device.Wireless.WiFi. Figures 24 and 25 show the connection (key 2 with a value of “1”) and disconnection events (key 2 with a value of “0”).
CarPlay can operate over Bluetooth connections, too, and they look completely different because a different process handles them: caraccessoryd. Figure 26 comes courtesy of Heather & Jared Barnhart, who happened to have access to a Hyundai Santa Fe that utilized Bluetooth for CarPlay. Highlighted in the red boxes is the car information for a Bluetooth CarPlay connection.
This example stresses the importance of knowing the car in question, and how it implements CarPlay.
Siri invocations via CarPlay are also present in the Unified Logs, and, just like the connection sessions, there are differences between wired and wireless CarPlay connections. Starting with wired and Wi-Fi wireless connections, see Figures 27 and 28.
I have highlighted the last entries in both figures as it represents a single instance of Siri being summoned by a button on my steering wheel. It is the same event that is highlighted in Figure 2 (knowledgeC).
Bluetooth CarPlay connections are less explicit. See Figure 29.
caraccessoryd is the process to look for, but there is no accompanying “button” action. Again, different auto manufacturers will implement CarPlay functionality differently so examiners should understand the particular make/model’s implementation.
The question that willed this blog post into existence revolved around whether data will show if a phone is being used versus the user touching the screen on the car? Recall earlier that using CarPlay through its UI will not show up in the App.InFocus biome, just ScreenTime.AppUsage. As it turns out Unified Logs can act as a replacement, of sorts, for App.InFocus. See Figure 30 as an example.
Two actions in the CarPlay UI are represented above: switching to the Podcast app and switching back to the CarPlay home screen. The first log entry represents the CarPlay home screen being displayed in the CarPlay UI (i.e., it is in focus). The app bundle is com.apple.CarPlay.dashboard. In the red box, I tapped the Podcast icon in the CarPlay UI (Icon tapped: <private>) and the Podcast app came on the screen (Workspace did change to active app com.apple.podcasts). In other words, the Podcasts app came into focus in the CarPlay UI. The blue box is my changing back to the CarPlay home screen from the Podcasts app. The log entry “Soft home button tapped” represents my pushing the home button in the bottom left of the CarPlay UI, which caused the home screen to come back on the screen (Workspace did change to active app com.apple.CarPlay.dashboard). In other words, the CarPlay home screen came back into focus. The App.InFocus biome has no record of these actions (Figure 10).
One note here. If a user taps an icon on the phone, the process Springboard will log the Icon tapped <private> message, followed by Springboard logging the app launch. Figure 31 shows an example.
The launch time for Messages here, 15:40:07 (UTC -0500), aligns with the time seen in App.InFocus seen in Figure 10 (20:40:07 UTC – highlighted in the red box).
In CarPlay, users have the ability to switch between apps using the recently used app tray on the left of the UI, similar to using the app switcher on the phone. This tray is persistent across the UI. When a user switches between apps in the manner, the Icon tapped log messages are not present. Examiners will simply seen the Workspace did change messages. Figure 32 shows an example.
As before, the App.InFocus biome has no record of these apps being in focus during this time (Figure 10).
Occasionally, examiners may see multiple CarPlay home screen events together. See Figure 32 for an example.
Just above the records highlighted in the red box, the I pressed the CarPlay home button in the UI and transitioned to the home screen. Approximately two minutes later, there are two additional Workspace did change log entries for the home screen. This is the time period when I summoned Siri and dictated a message (seen in Figures 2, 27, and 28). When Siri is summoned in CarPlay, there is an overlay on the screen. See Figures 34 and 35.
In iOS 18 when Siri is summoned the CarPlay screen flashes momentarily before the edges of the UI start glowing. I suspect what is happening is the flash and/or the glowing edges represent Siri “seizing” the screen and then returning control the home screen. Figure 36 seems to lend creditability to that theory.
In the blue box I pressed the home button in the CarPlay UI in order to present the home screen (Figure 35). I then summoned Siri, seen in the red box in Figure 36. The log entry indicates Siri “borrows” the screen momentarily before returning it to com.apple.CarPlay.dashboard. I have also observed this behavior when Siri is summoned while other apps are on the CarPlay screen. Regardless, examiners can expect to see this behavior in the Unified Logs from time to time if Siri is invoked.
End of the road. Again.
CarPlay has certainly changed in the years since the community popped the hood. While many things examiners and investigators are interested have moved to biomes, knowledgeC still contains some useful information, and the Unified Logs can provide good information to examiners who are trying to determine whether CarPlay or the phone was used.
Investigations where distracted driving can be challenging, but the data available in iOS can help immensely.
One thought on “Ridin’ With Apple CarPlay 2”