与Apple CarPlay同行 2
Binary Hick
苹果, iOS, 移动设备, 虚拟助手
2025-02-19 15分钟阅读
我所有的愿望… 我很少有机会重访之前的研究。我们大多数人（即便不是所有人）进行研究、分享（但愿如此），然后就会转向下一个目标。有太多东西需要检查，几乎不可能回头再看，尤其是在移动设备领域。然而，当我们真的回头时，通常是因为某些事情发生了变化，这里的情况正是如此。我在工作中遇到了一系列关于CarPlay的问题，可以归结为一个问题：取证人员能否区分用户是使用CarPlay执行操作，还是直接使用iOS设备本身？ 简短的回答是：“是的，有可能。” 更详细的答案，当然就是这篇文章了。
大约六年前，我写过一篇关于Apple CarPlay的博客，不久之后，Sarah Edwards和Heather Barnhart在2019年SANS数字取证与事件响应峰会上做了一个很棒的演讲，也讨论了CarPlay和Android Auto。六年时间在数字取证领域是极其漫长的，不用说，CarPlay也发生了变化。文件系统取证信息发生了一些变化，我们对iOS统一日志的理解也取得了长足的进步。
关于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中的蓝色方框）。列表中的每个应用都通过捆绑包名称及其各自最后使用的时间戳来标识。我要指出一个奇怪之处：苹果地图的最后更新时间总是我断开与汽车连接的时间。我怀疑这可能是因为CarPlay中的“今日视图”（从主屏幕向右滑动），但尚未找到任何数据来证实这一点。无论如何，这个文件现在使得检查同一位置的 com.apple.springboard 变得不再必要。
该文件还有一个时间戳，表示上一次CarPlay会话结束的时间。图1中的红色方框对此进行了高亮显示。
下一个变化是 knowledgeC。虽然一些取证人员/调查人员感兴趣的数据已迁移到Biome流（例如，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，然后是带有Threema捆绑包名称的 /app/usage，接着不久后发送了一条Threema消息，所有这些事件按此顺序发生，那么即使用户的手机连接着CarPlay，用户也很有可能是通过手机而不是CarPlay发送的Threema消息。稍后将详细介绍在CarPlay内采取的操作。
说到CarPlay连接…
Biome流
自iOS 16起，许多过去存放在 knowledgeC 中的数据已迁移到Biome流，CarPlay连接就是其中之一。CarPlay连接有它们自己的Biome流。注意我说的是复数形式的Biome流。第一个是 _DKEvent.Carplay.IsConnected，位于 /private/var/mobile/Library/Biome/streams/restricted/。此位置的Biome文件包含两个关键信息：CarPlay会话的开始时间和结束时间。参见图3。
图3. 一个CarPlay会话。
图3显示了底部的Biome记录。右侧的红色方框是CarPlay会话开始的时间，蓝色方框是会话结束的时间。请注意，此时间段覆盖了我们在knowledgeC（图2）中看到Siri调用的时间。
我有意将右侧的开始时间与左侧的红色方框之间画了一条线。有时，取证人员可能会观察到有一条记录被写入Biome，代表断开连接状态，或者设备从哪个状态转换到连接状态（即“已断开”）。它可能不总是出现，但我想提请注意，因为我时不时观察到它。
CarPlay连接的第二个Biome位置是 CarPlay.Connected，它与 _DKEvent.Carplay.IsConnected 位于相同的文件系统位置。这些Biome有两个值，其中一个指示CarPlay的连接状态。参见图4。
图4. CarPlay起始状态（已断开）。
如前所述，取证人员偶尔会发现指示设备从哪个状态转换到连接状态的记录。这里，键1处的值为“0”，意味着CarPlay当前已断开。图5中的记录左侧具有相同的时间戳，并与图3中看到的开始时间一致。注意，键1处的值现在是“1”，意味着CarPlay已连接。
图5. CarPlay会话开始。
图6显示CarPlay会话结束，键1处的值恢复为“0”，该记录的时间戳也与图3中看到的断开连接时间一致。
图6. CarPlay会话结束。
当涉及CarPlay内的实际应用使用时，Biome流可能会有所帮助。有两个相关的流：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 中。稍后再谈这个问题。
另一个相关的Biome流是 App.InFocus。这个流的重要性不仅在于它包含的内容，还在于它不包含的内容。以上面的消息示例为例，图10显示了 App.InFocus 中的相关时间。
图10. 来自 App.InFocus。似乎缺少了什么。
这次CarPlay会话的第一个条目直到20:40:07才出现。那是在我将手机连接到汽车、启动播客、接收一条iMessage并口述回复、打开地图、切换到CarPlay主屏幕、以及接收并回复另一条iMessage之后，所有操作都是通过CarPlay用户界面完成的。测试发现，通过CarPlay用户界面采取的操作不会出现在 App.InFocus 中，这是合理的，因为手机没有显示任何内容；它被锁定并面朝下放在我的杯架里。20:40:07的条目是我通过手机本身使用iMessage发送消息。图11显示了这条消息。
图11. 我“分心”发送的消息。
在这个场景中，我解锁手机通过手机本身发送了一条消息，然后迅速重新锁定手机，所有这些操作都在CarPlay运行期间进行。这可以在knowledgeC中看到，从图12开始。
图12. knowledgeC中的解锁事件。
解锁后，我从主屏幕打开了iMessage。关于这在 App.InFocus 和 ScreenTime.AppUsage 中的显示方式，请分别参见图13和图14。
图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。
其他Biome流也可能有用。在上面的例子中，手机检测到我拿起了它，屏幕在我解锁前就亮起了。因此，取证人员还可以使用Biome流 Device.Display.Backlight 来进一步证实手机在相关时间段内被使用过。仅凭此Biome流中的肯定记录并不能确认我正在使用手机，但它肯定加强了在其他Biome流和knowledgeC中的发现。另一个可用于佐证的Biome流是 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. 手机扬声器正在使用。
统一日志
在过去六年中，我们对统一日志的理解取得了长足进步，但我和许多其他人认为，社区仍未完全认识到它们在取证方面的全部潜力。就CarPlay而言，统一日志包含一些可以在文件系统中通过其他取证信息验证的信息，以及一些统一日志本身独有的信息。从CarPlay连接开始，参见图20。
图20. CarPlay会话时间。
对于有线CarPlay连接，进程 sharingd 记录了“会话”连接和断开连接事件，这里的时间戳与在Biome流 _DKEvent.Carplay.IsConnected（图3）和 CarPlay.Connected（图4）中看到的一致。无线CarPlay会话看起来略有不同。参见图21。
图21. 无线CarPlay会话。
除了图20中看到的消息外，无线CarPlay会话在连接和断开连接事件时还伴随有一条额外的消息“Wireless CarPlay session state changed.”。和之前一样，进程 sharingd 在记录信息。
汽车被认为是“配件”。进程 accessoryd 将记录一些关于汽车的信息，以及连接类型。有关有线连接的示例，参见图22。
图22. accessoryd 记录的关于我的汽车的信息。
红色方框中的数据与我的日产汽车相关。日产的音响主机由博世制造，所以这很合理。我要指出我开的不是4门货车。蓝色方框包含连接类型，在这个例子中，是通过Lightning转USB-A连接线连接到汽车上的USB-A端口，橙色方框包含的可能是手机和汽车之间的数据传输模式，同样是USB。
无线连接根据连接类型看起来略有不同。一些连接通过Wi-Fi发生。图23显示了一个示例。
图23. 无线CarPlay连接。
这是同一辆车，但连接了一个无线CarPlay适配器，我从亚马逊上购买的。红色方框中的数据与图22相同，但 connectionType 和 transportType 的值不同。我怀疑蓝色方框中的“IP”值是“Internet Protocol”，因为在测试期间，适配器似乎创建了一个临时Wi-Fi网络。这在一定程度上由 transportType 值“AirPlay”所证实。这里还有一个额外的说明：你可以预期在Biome流 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用户界面使用CarPlay不会出现在 App.InFocus Biome流中，只会出现在 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 Biome流没有这些操作的记录（图10）。
这里有一个说明。如果用户点击手机上的图标，进程 Springboard 将记录 Icon tapped <private> 消息，随后是 Springboard 记录的应用启动。图31显示了一个示例。
图31. 消息应用启动。
这里的消息应用启动时间，15:40:07（UTC -0500），与图10中看到的 App.InFocus 时间（20:40:07 UTC – 红色方框高亮显示）一致。
在CarPlay中，用户可以使用用户界面左侧的最近使用应用托盘在应用之间切换，类似于在手机上使用应用切换器。这个托盘在用户界面中始终存在。当用户以这种方式切换应用时，不会出现 Icon tapped 日志消息。取证人员只会看到 Workspace did change 消息。图32显示了一个示例。
图32. 在CarPlay的最近使用应用托盘中切换应用。
和之前一样，App.InFocus Biome流没有这些应用在此期间处于焦点状态的记录（图10）。
有时，取证人员可能会看到多个CarPlay主屏幕事件聚集在一起。参见图33的示例。
图33. 这里发生了什么？？？
在红色方框高亮显示的记录上方，我按下了CarPlay用户界面中的主页按钮并切换到了主屏幕。大约两分钟后，又有两个针对主屏幕的 Workspace did change 日志条目。这个时间段是我召唤Siri并口述消息的时间（见图2、27和28）。当在CarPlay中召唤Siri时，屏幕上会有一个覆盖层。参见图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。当在其他应用显示在CarPlay屏幕上时召唤Siri，我也观察到了这种行为。无论如何，如果调用了Siri，取证人员可以预期偶尔会在统一日志中看到这种行为。
路的尽头。又一次。
自从社区“打开引擎盖”检查以来，CarPlay在几年间确实发生了变化。虽然许多取证人员和调查人员感兴趣的内容已转移到Biome流，但 knowledgeC 仍然包含一些有用的信息，统一日志可以为试图确定是使用了CarPlay还是手机本身的取证人员提供良好的信息。
涉及分心驾驶的调查可能具有挑战性，但iOS中可用的数据可以提供巨大的帮助。