与苹果CarPlay同行（第二部分）
Binary Hick
Apple, iOS, 移动设备, 虚拟助手
2025年2月19日 阅读时长约15分钟
我的初衷…
我很少有机会重新审视之前的研究。我们大多数人（即使不是所有人）都会进行研究，分享（希望如此），然后继续下一个课题。要检验的东西太多了，几乎不可能回头再看，尤其是在移动设备领域。然而，当我们真的回头时，通常是因为某些事情发生了变化，这里就是这种情况。工作中有人向我提出了一系列关于CarPlay的问题，可以总结为一个问题：取证人员能否区分用户是通过CarPlay执行操作，还是直接使用iOS设备本身？ 简短的回答是“是的，有可能。”当然，更长的答案就是这篇文章。
大约六年前，我写过一篇关于Apple CarPlay的博客，不久之后，Sarah Edwards和Heather Barnhart在2019年的SANS数字取证与事件响应（DFIR）峰会上做了一个很棒的演讲，也讨论了CarPlay和Android Auto。在数字取证领域，六年是极其漫长的，不用说，CarPlay已经发生了变化。文件系统记录方面有一些变化，而且我们对iOS统一日志（Unified Logs）的理解也取得了长足的进步。
关于CarPlay的背景知识，可以参考我之前的文章。只需知道，自那时起，不仅大多数汽车制造商在其大部分产品线中实现了CarPlay，许多还实现了无线CarPlay。本文将在适用时讨论无线连接。
变化
为了测试，我使用了iPhone 14（iOS 17.5）、14 Pro（iOS 18.2）和16 Pro（18.3.1），以及我的日产Rogue（是的，就是2019年文章里那辆——我一辆车会用很久）。不止是车子没变；我在2019年提到的那些plist文件，大部分也基本没变，除了一个。自2019年以来，CarPlay有了自己的“最近使用”文件，Chris Vance曾在此文中介绍过。作为回顾，请参见图1。
图1. com.apple.CarPlayApp.plist。
位于 /private/var/mobile/Library/Preferences/ 的 com.apple.CarPlayApp.plist 包含一个最近使用的应用程序列表，以及它们上次使用时的Unix纪元时间戳（图1中的蓝框）。列表中的每个应用程序由其包名标识，并带有各自的上次使用时间戳。我要指出的一个奇怪之处是：Apple Maps的上次更新时间总是我断开与汽车连接的时间。我怀疑这可能与CarPlay中的“今日视图”（从主屏幕向右滑动）有关，但尚未找到任何数据来证实这一点。无论如何，这个文件现在使得无需再检查同一位置的 com.apple.springboard 文件。
该文件还有一个时间戳，代表上一次CarPlay会话结束的时间。在图1中用红框突出显示。
下一个变化是 knowledgeC。虽然一些取证/调查人员感兴趣的数据已经迁移到了生物群落（biomes）（例如CarPlay连接），但还有一些残留数据也很有趣：Siri调用。知道驾驶员是通过CarPlay召唤Siri执行操作，还是用户拿起手机执行该操作，在涉嫌分心驾驶的调查中可能意义重大。在图2中，ZOBJECT表包含了与我通过方向盘按钮召唤Siri相关的记录。
图2. 召唤Siri。knowledgeC的ZOBJECT表摘录。
图2是ZOBJECT的摘录，虽然显示了多条记录，但它代表了我的一次操作：通过CarPlay使用Siri发送消息。在这里，我使用方向盘上的按钮召唤了Siri，让她发送消息，向她口述了消息，她向我朗读了消息，然后在我确认消息准确性后发送了它。在图2中从下往上阅读ZVALUESTRING列的值（红框突出显示），可以清楚地看到这一点。请求是通过方向盘按钮（com.apple.siri.steering.wheel）在CarPlay中（com.apple.siri.button.on.carplay）启动的（com.apple.siri.dictation-siri-request-started），此时她和我来回进行口述和确认消息准确性（com.apple.siri.dictation-siri-request-started）。橙色框中突出的时间进一步证实了这一系列事件。在消息发送时间附近看到 com.apple.siri.dictation-siri-request-started 可以帮助确定Siri是否确实参与了消息的发送或向驾驶员朗读消息。
还有另一个数据源，取证人员可以利用它来发现Siri调用，但稍后再详细说明。
当涉及可疑的分心驾驶时，knowledgeC中的其余数据可能也很有意思。例如，/app/usage 数据流，但它们不会告诉你这是通过CarPlay还是通过手机完成的。不过，取证人员可以得出一些合理的结论。例如，应用Threema没有CarPlay功能，如果取证人员看到 /display/isBacklit 值为1，/device/isLocked 值为0，然后是 /app/usage 出现Threema包名，接着不久后发送了一条Threema消息，所有这些事件按顺序发生，那么即使用户的手机当时连接着CarPlay，用户通过手机（而非CarPlay）发送Threema消息的可能性也很高。稍后详述在CarPlay内进行的操作。
说到CarPlay连接…
生物群落（Biomes）
自iOS 16以来，许多过去驻留在knowledgeC中的数据已迁移到生物群落，CarPlay连接就是其中之一。CarPlay连接有自己的生物群落。请注意，我说的是生物群落（复数）。第一个是 _DKEvent.Carplay.IsConnected，位于 /private/var/mobile/Library/Biome/streams/restricted/。该位置的生物群落文件包含两个关键信息：CarPlay会话开始的时间和结束的时间。参见图3。
图3. 一个CarPlay会话。
图3显示了底部的生物群落记录。右侧的红框是CarPlay会话开始的时间，蓝框是会话结束的时间。请注意，这段时间覆盖了我们在图2的knowledgeC中看到Siri调用的时间。
我在右侧的开始时间和左侧的红框之间画了一条线，是有原因的。有时，取证人员可能会观察到生物群落中写入了一条代表断开连接状态的记录，或者设备进入连接状态之前的状态（即“已断开连接”）。它可能并不总是存在，但我想提请注意它，因为我时不时会观察到它。
CarPlay连接的第二个生物群落位置是 CarPlay.Connected，它位于与 _DKEvent.Carplay.IsConnected 相同的文件系统位置。这些生物群落有两个值，其中一个表示CarPlay的连接状态。参见图4。
图4. CarPlay起始状态（已断开连接）。
如前所述，取证人员偶尔会发现指示设备进入连接状态之前状态的记录。这里，键1的值为“0”，意味着CarPlay当前已断开连接。图5中的记录左侧具有相同的时间戳，并与图3中看到的开始时间一致。请注意，键1的值现在为“1”，意味着CarPlay已连接。
图5. CarPlay会话开始。
图6显示CarPlay会话结束，因为键1的值回到了“0”，该记录的时间戳也与图3中看到的断开连接时间一致。
图6. CarPlay会话结束。
当涉及CarPlay内的实际应用使用时，生物群落可能会有所帮助。有两个感兴趣的数据流：ScreenTime.AppUsage 和 App.InFocus。两者都位于 /private/var/mobile/Library/Biome/streams/restricted/，并且各自因不同的原因而重要。图7显示了 ScreenTime.AppUsage。
图7. ScreenTime.AppUsage。
图7左侧的红框显示了CarPlay会话期间使用的第一个应用的时间，右侧的红框显示了正在使用的应用，Podcasts。如果你回想图1，CARStartApplicationBundleID 的值是 com.apple.podcasts。当我将手机插入日产汽车时，Podcast应用在CarPlay用户界面中自动打开，所以这个条目是合理的。
此外，我在蓝框中突出了键1处的值“1”。在我对CarPlay的测试中，键1处的值“1”可以表示应用在CarPlay用户界面中使用，而值“0”可以表示应用未在CarPlay用户界面中使用；然而，这是一个很大的“然而”，在手机本身上进行操作时也观察到了相同的行为。因此，虽然稍有帮助，但仍不能确认某个特定操作是在手机上还是CarPlay用户界面上发生的，取证人员需要进一步佐证他们在这里发现的值。我的另一个观察是，当两条记录具有相同的时间戳时，通常表示直接从某个应用切换到另一个应用，这可以根据键1处的值看出来。
这里还有一个额外的说明。除非先打开所选的消息应用，否则使用Siri口述或朗读消息不会出现在这里。举个例子，回想一下我召唤Siri发送iMessage（在图2的knowledgeC中可见）。参见图8中来自 ScreenTime.AppUsage 的突出显示区域。
图8. 我通过Siri口述消息时。
我在图8的红框中突出了两个时间。这两个时间界定了我通过CarPlay向Siri口述一条消息的时间段，这在图2的knowledgeC中可见。图9突出了iMessage用户界面中的消息。请注意时间戳是UTC -0500。
图9. 通过CarPlay的Siri口述消息。
应用包 com.apple.MobileSMS 在相关时间段内并未出现在 ScreenTime.AppUsage 中。稍后再详述。
另一个感兴趣的生物群落数据流是 App.InFocus。这个流很重要，不仅因为它包含的内容，也因为它不包含的内容。以上述消息传递为例，图10显示了 App.InFocus 中的相关时间。
图10. 来自App.InFocus。似乎缺少了什么。
这个CarPlay会话的第一个条目直到20:40:07才出现。那是在我将手机连接到汽车、开始播放播客、收到一条iMessage并口述回复、打开Maps、切换到CarPlay主屏幕、以及收到并回复另一条iMessage之后，所有这些操作都是通过CarPlay用户界面完成的。测试发现，通过CarPlay用户界面执行的操作不会出现在 App.InFocus 中，这是合理的，因为手机没有显示任何内容；它被锁定并面朝下放在我的杯架里。20:40:07的条目是我通过手机本身使用iMessage发送消息。图11显示了该消息。
图11. 我“分心”发送的消息。
在这个场景中，我解锁了手机以通过手机本身发送消息，然后迅速重新锁定了手机，所有这些操作都在CarPlay运行时进行。这可以在图12开始的knowledgeC中看到。
图12. knowledgeC中的解锁事件。
解锁后，我从主屏幕打开了iMessage。参见图13和图14，分别显示了这在 App.InFocus 和 ScreenTime.AppUsage 中的样子。
图13. 在App.InFocus中从主屏幕打开iMessage。
图14. 在ScreenTime.AppUsage中打开iMessage。
图14有力地说明了前面提到的关于键1处的“1”值（蓝框中突出显示）可以表示在CarPlay或手机本身中的应用使用情况。
再次，发送消息后，我锁定了手机。图15、16和17分别显示了这一操作在knowledgeC、App.InFocus 和 ScreenTime.AppUsage 中的情况。
图15. 在knowledgeC中重新锁定手机。
图16. 锁定手机后的App.InFocus。
图17. 锁定手机后的ScreenTime.AppUsage。
其他生物群落也可能有用。在上面的例子中，手机检测到我拿起了它，屏幕在我解锁之前就亮了。因此，取证人员也可以使用生物群落 Device.Display.Backlight 来进一步证明手机在相关时间段内被使用过。仅凭此生物群落中的阳性记录并不能确认我使用了手机，但它肯定加强了在其他生物群落和knowledgeC中发现的信息。另一个可用于佐证的生物群落是 Audio.Route，因为Siri的音频将通过汽车扬声器路由。参见图18。
图18. Audio.Route记录条目。
上面的记录条目是iPhone音频输出通过CarPlay路由的一个例子。此时间戳与我在CarPlay中通过Podcast应用开始播放播客的时间一致。请注意，你可以在键3处看到值“CarAudio”，在键4处看到值“CarPlay”。在键2中，我在红框中突出了字符串，这是我汽车的蓝牙MAC地址。另外的时间点20:34:02（也在图2的knowledgeC中得到证实）、20:34:32、20:39:07和20:39:32是我与Siri的交互（消息播放和口述回复消息的对话），因为她的音频是通过汽车扬声器发出的。这是在拿起手机、解锁并阅读我收到的消息之外的另一种方式。
我要说明的是，手机没有通过蓝牙与汽车配对。
如果使用了手机扬声器，其值将如图19所示。
图19. 手机扬声器正在使用。
统一日志（Unified Logs）
在过去六年里，我们对统一日志的理解取得了长足的进步，但我，以及许多其他人，认为社区仍然没有完全认识到其法证潜力。当涉及CarPlay时，统一日志携带了一些可以在文件系统中与其他记录相互验证的信息，以及一些只存在于统一日志本身的信息。从CarPlay连接开始，参见图20。
图20. CarPlay会话时间。
对于有线CarPlay连接，进程 sharingd 记录了“会话”连接和断开连接事件，这里的时间戳与在生物群落 _DKEvent.Carplay.IsConnected（图3）和 CarPlay.Connected（图4）中看到的相符。无线CarPlay会话看起来略有不同。参见图21。
图21. 一个无线CarPlay会话。
除了图20中看到的消息外，无线CarPlay会话还有一个额外的消息“Wireless CarPlay session state changed.”伴随连接和断开连接事件。和之前一样，进程 sharingd 正在记录信息。
汽车被认为是“配件”。进程 accessoryd 将记录一些关于汽车的信息，以及连接类型。有关有线连接的示例，请参见图22。
图22. 由accessoryd记录的我的汽车信息。
红框中的数据与我的日产汽车相关。日产的车机由博世制造，所以这说得通。我需要说明的是，我开的不是四门面包车。蓝框包含连接类型，在这种情况下，是通过Lightning转USB-A线连接到汽车上的USB-A端口，橙框包含的可能是手机和汽车之间的数据传输模式，再次是USB。
无线连接根据连接类型略有不同。一些连接通过Wi-Fi进行。下面的图23显示了一个示例。
图23. 无线CarPlay连接。
这是同一辆车，但连接了一个无线CarPlay适配器，我在亚马逊上买的。红框中的数据与图22相同，但 connectionType 和 transportType 值不同。我怀疑蓝框中的“IP”值是“互联网协议”，因为在测试期间，适配器似乎创建了一个临时Wi-Fi网络。这在某种程度上被 transportType 的“AirPlay”值所证实。这里还有一个额外的说明：你可以预期在生物群落 Device.Wireless.WiFi 中找到与此连接相关的条目。图24和25显示了连接（键2值为“1”）和断开连接事件（键2值为“0”）。
图24. 无线CarPlay的Wi-Fi连接事件。
图25. 无线CarPlay的Wi-Fi断开连接事件。
CarPlay也可以通过蓝牙连接运行，它们看起来完全不同，因为是由不同的进程处理的：caraccessoryd。图26由Heather & Jared Barnhart提供，他们碰巧可以使用一辆采用蓝牙进行CarPlay连接的现代Santa Fe。红框中突出显示的是蓝牙CarPlay连接的汽车信息。
图26. 通过蓝牙进行CarPlay的汽车信息。
这个例子强调了了解相关汽车及其如何实现CarPlay的重要性。
通过CarPlay的Siri调用也存在于统一日志中，并且与连接会话一样，有线和无线CarPlay连接之间存在差异。从有线和Wi-Fi无线连接开始，参见图27和图28。
图27. 通过方向盘按钮召唤Siri（按钮按下）。
图28. 通过方向盘按钮召唤Siri（按钮松开）。
我在两张图中都突出了最后的条目，因为它代表了我通过方向盘上的按钮召唤Siri的单个实例。这与图2（knowledgeC）中突出显示的事件相同。
蓝牙CarPlay连接则不那么明确。参见图29。
图29. CarPlay蓝牙连接期间召唤Siri。
caraccessoryd 是需要查找的进程，但没有伴随的“按钮”操作。再次强调，不同的汽车制造商会以不同的方式实现CarPlay功能，因此取证人员应该了解特定品牌/型号的实现方式。
促使这篇博客文章诞生的问题围绕着数据是否会显示手机正在被使用，还是用户触摸了汽车屏幕？回想一下，通过其用户界面使用CarPlay不会显示在 App.InFocus 生物群落中，只会显示在 ScreenTime.AppUsage 中。事实证明，统一日志可以某种程度上替代 App.InFocus。参见图30作为示例。
图30. 切换应用及处于焦点的应用。
上面显示了CarPlay用户界面中的两个操作：切换到Podcast应用和切换回CarPlay主屏幕。第一个日志条目代表CarPlay主屏幕在CarPlay用户界面中显示（即处于焦点）。应用包是 com.apple.CarPlay.dashboard。在红框中，我点击了CarPlay用户界面中的Podcast图标（Icon tapped: <private>），然后Podcast应用出现在屏幕上（Workspace did change to active app com.apple.podcasts）。换句话说，Podcasts应用在CarPlay用户界面中获得了焦点。蓝框是我从Podcasts应用切换回CarPlay主屏幕。日志条目“Soft home button tapped”代表我按下了CarPlay用户界面左下角的主页按钮，这导致主屏幕重新出现在屏幕上（Workspace did change to active app com.apple.CarPlay.dashboard）。换句话说，CarPlay主屏幕重新获得了焦点。App.InFocus 生物群落没有这些操作的记录（图10）。
这里有一个说明。如果用户点击手机上的图标，进程 Springboard 将记录 Icon tapped <private> 消息，然后是 Springboard 记录应用启动。图31显示了一个例子。
图31. 启动Messages应用。
这里Messages的启动时间，15:40:07（UTC -0500），与图10中在 App.InFocus 看到的时间（20:40:07 UTC – 红框突出显示）一致。
在CarPlay中，用户可以使用用户界面左侧的最近使用应用托盘在应用之间切换，类似于在手机上使用应用切换器。这个托盘在用户界面上是常驻的。当用户以这种方式切换应用时，Icon tapped 日志消息不存在。取证人员只会看到 Workspace did change 消息。图32显示了一个示例。
图32. 在CarPlay的最近使用应用托盘中切换应用。
和之前一样，App.InFocus 生物群落没有这些应用在此期间处于焦点的记录（图10）。
有时，取证人员可能会看到多个CarPlay主屏幕事件连在一起。参见图32的示例。
图33. 这里发生了什么？？？
就在红框突出显示的记录上方，我按下了CarPlay用户界面中的主屏幕按钮并过渡到主屏幕。大约两分钟后，主屏幕又有两个额外的 Workspace did change 日志条目。这是我召唤Siri并口述一条消息的时间段（在图2、27和28中可见）。当Siri在CarPlay中被召唤时，屏幕上会有一个覆盖层。参见图34和图35。
图34. 在iOS 17的CarPlay主屏幕上召唤Siri。Siri的光球位于用户界面的底部。
图35. 在iOS 18的CarPlay主屏幕上召唤Siri。屏幕边缘在发光。
在iOS 18中，当召唤Siri时，CarPlay屏幕会短暂闪烁，然后用户界面的边缘开始发光。我怀疑发生的情况是，闪烁和/或发光边缘代表Siri“接管”屏幕，然后将控制权返回给主屏幕。图36似乎支持了这个理论。
图36. Siri只是“借用”。
在蓝框中，我按下了CarPlay用户界面中的主屏幕按钮以显示主屏幕（图35）。然后我召唤了Siri，在图36的红框中可见。日志条目表明Siri“暂时借用”了屏幕，然后将其归还给 com.apple.CarPlay.dashboard。当Siri在其他应用显示在CarPlay屏幕上时被召唤，我也观察到了这种行为。无论如何，如果调用了Siri，取证人员可以预期在统一日志中会不时看到这种行为。
再次到站
自社区揭开它的引擎盖以来，CarPlay无疑已经发生了变化。虽然许多取证人员和调查人员感兴趣的数据已迁移到生物群落，但knowledgeC仍然包含一些有用的信息，而统一日志可以为那些试图确定是使用了CarPlay还是手机的取证人员提供良好的信息。
涉及分心驾驶的调查可能具有挑战性，但iOS中可用的数据可以极大地提供帮助。