新型车机,如何攻防?

一、简介

如今,大多数汽车都有车机,负责汽车座舱内的娱乐、联网、控制空调座椅等功能,也有人称之为座舱域控制器、多媒体系统等。近期,我们在研究了某品牌汽车的车机时,发现某个车机与其他车机的软硬件结构存在较大的差异。撰写本文,有两个目的,一是向读者尽可能多地介绍该车机的信息与破解过程,二是探讨这类车机应该如何进行防护。我们将分三个章节,分别介绍车机的结构、车机的破解过程和车机的防护思路。

二、车机的结构

  • 车机的一般结构

一般来说,如果车机需要上网,会有以下两种方式,一种是连接独立的TBOX零部件,他们之间使用USB接口进行网络共享,实现车机的联网功能。另一种,是不使用独立的TBOX,将TBOX内部核心的联网模组,集成到车机的主板中,车机通过USB和PCI等接口连接模组上网,如图1所示。不论是独立的TBOX,还是联网模组,他们内部都是一个Linux操作系统,负责网络基带信号的处理,以及对汽车的远程控制[1]

图1 车机与TBOX的两种连接模式

那车机的内部硬件结构可以分为那几个部分呢?我们做了一些梳理,以车机集成4G模组来上网的方式为例,具体可分为以下8个部分:

  1. 集成4G模组和eSIM,实现移动上网。
  2. 集成USBHUB,提供座舱内U盘传输音乐以及为手机充电的功能。
  3. 集成Wi-Fi、蓝牙模块,实现Wi-Fi局域网共享以及蓝牙通话的功能。
  4. 集成以太网模块,实现车内以太网通信。
  5. 集成MCU和CAN收发器,实现与车内其他ECU的通信。
  6. 集成音频模块,实现车内音响的接入。
  7. 集成视频模块,实现倒车影像等功能。
  8. 接其他外设,如按键、LCD、天线等。

具体如图2所示。

图2 车机硬件的结构

简单来看,车机内软件环境为Android、QNX、Linux等操作系统,目前比较先进的,如以SA8155P为核心的车机,使用QNX hypervisor[2]完成微内核以及虚拟化拓展功能,实现对硬件的共享,以支持上层多操作系统对硬件资源的调用,如Linux或者QNX负责仪表,Android负责娱乐系统的人机交互等等。具体如图3所示。

图3 QNX 虚拟化架构

如果车机比较低端,则一般不存在虚拟化的功能,在硬件上直接运行安卓或者Linux操作系统,提供座舱娱乐的功能,仪表等软件则由仪表硬件独立运行。

  • 新车机的不同之处

那新车机有什么不同之处呢?我们发现,新车机的软硬件的高集成度体现在与TBOX的结合方式上。我们拆解了车机,发现其内部并没有集成移动通信的模组,代替模组的,是MT8666核心处理器和MT6177射频芯片,如图  4所示。

图  4 车机硬件核心计算部分拆机图

经过查询官网描述[3],我们发现MT8666是联发科发布的车规级高性能芯片,内部集成了TBOX的解决方案,如图5所示。

图5 联发科官网对MT8666的介绍

那么他是如何替代TBOX的呢?为此,我们查询了MT6177芯片的功能,发现其内部并没有另外运行Linux的内核的MPU。也就是说,这款车机和TBOX从硬件上合二为一了,我们在类似手机的电路图中查到了以下架构,如图6所示。

图6 MT6765+MT6177架构(源于手机的电路图手册)

既然没有TBOX了,原本TBOX的功能去哪里了?从联网的过程来看,车机使用MT6177作为射频芯片进行联网,那么,在安卓系统内部,必然存在和该芯片的交互流程。我们在/dev/radio目录下发现了可以进行4G网络配置的接口,如图7所示。

图7 车机内安卓与基带的AT指令通信模式

搜索相关字符,我们发现,TBOX在其安卓内部,是以基带的形式存在的,这与手机的模式相同,如图8所示。也就是说,这款车机也是一个具备车内网通信功能的手机。

图8 查询到的基带信息

这并不让人惊奇,因为TBOX的架构本身和传统的安卓车机的架构是相似的。而且,类似的架构,在手机上也被使用过,比如华为畅享9e,使用了MT6765+MT6177为核心的方案。这款车机,可以认为是使用MT8666替代MT6765的安卓手机。以现在车内架构集成化程度越来越高的趋势来看,未来车机替代TBOX可能是大势所趋。

三、车机的破解过程

  • 调试类破解

在研究车机过程中,为了保证研究的够透彻,我们尝试查找了调试用的后门。通过搜索车型信息,找到了汽车爱好者提供的进入工程模式的方法。具体方法是在拨号键盘输入一串代码,并输入提供的密码,打开工程模式,进一步在工程模式的USB功能界面开启ADB模式。我们将车机的USB接口通过转接线与笔记本电脑相连,笔记本电脑识别了汽车的ADB服务,如图9所示。

图9 设置USB为ADB模式后PC设备管理器的识别情况

如果是调试手机,一般情况下,我们在此阶段已经可以进行ADB调试了,然而,我们发现,在运行“adb shell”命令的时候,又出现了密码认证的过程。好消息是,“adb pull”命令并不受影响,所以,我们使用“adb pull”命令将汽车/system目录导出,发现其内部verify_sh程序中存在密码认证的过程实现,逆向verify_sh后的代码如图10所示。

图10 verify_sh反编译后展现的认证细节

在输入密码后,我们使用“adb shell”命令成功进入了车机的操作系统,如图11所示。

图11 使用逆向发现的密码后成功连接

由于调试过程可能会对车机的ADB等服务造成影响,如开机不启动关键进程,工程模式打不开等情况,所以我们更改了车机内的启动脚本之一,开启了TELNET服务。一旦车机的ADB接入存在问题,我们使用TELNET服务也可以做一些拯救工作。加入启动脚本的代码如图12所示。

图12 启动脚本中加入的启动TELNET服务的代码

在重启车机后,我们发现车机的TELNET服务成功运行,运行后表现如图13所示。

图13 代码执行成功的效果

  • 应用类破解

研究到这一步,我们发现这款车机还是有一些防护能力的,只不过防护效果会比较弱。因为车机的IDPS的规则,与传统的规则并无二致。我们分析了其IDPS的控制程序,发现其解密的过程是用明文替代原加密的all.rules,我们将其控制程序调试起来后,将其断点设置为解密函数的下一个函数入口,如图14所示,重新打开all.rules即可查看其明文的规则文件。

图14 加密的IDPS规则文件以及对应的控制程序

打开后,我们却发现其规则与传统的规则并无二致,与车联网的服务也没有相关性,具体如图15所示。这是我们判断该车机防护能力较弱的主要原因。

图15 解密后的所有规则

四、车机的防护思路变化

通过分析这款新车机,我们发现,它与手机非常相似。在这类车机上,使用移动安全防护方法更加合适。可以想象,如果车机技术的趋势是向这种集成化的方向发展,那么,未来汽车安全的防护方式也会因汽车电气架构的日趋集成,而趋向移动安全防护技术的方式。

为了适配多种车机架构,越底层的防护效果,通用性越强。绿盟早在物联网安全高速发展的阶段,就提出将安全左移,实现了安全SDK,将安全固化到终端中,实现云端与终端的互联,进而实现对设备的监控,满足国家对联网设备的监管要求。

在车端,绿盟也将物联网SDK拆分为主机IDPS、网络IDPS两部分,分别对车机的运行环境和网络流量进行防护,方便模块化地进行源码和可执行文件的集成,同时,对单片机(RTOS)环境进行了兼容,可以分布式地部署在不同架构的硬件设备中,如车机、TBOX、网关、关键的ECU,以更全面地保护车内网环境以及整车零部件的安全。有兴趣的话,读者们可以联系我们,进一步在研究、研发和服务等多方面进行合作。

五、总结与展望

随着技术日趋成熟,汽车的电子电气架构日趋集成化、标准化,以满足供应商对不同厂商的汽车适配需求。然而,集成化带来的不仅是功能的集中,风险也会集中。以前,需要我们在成功攻破TBOX后才会控制车机的远程控制功能,而现在,车机集成了基带替代TBOX网络功能后,仅可以通过“AT”指令就可以配置其联网参数,使其断网、或者接入伪基站。这种情况下,车机的网络风险进一步对外暴露了。

安全防护能力也需要高度适配和集成。在软件形态方面,防护软件应该实现为底层的可执行文件,对车机进行安全防护,以适配安卓、Linux、QNX等不同的环境。在功能方面,防护软件需要覆盖对车机、TBOX、仪表、网关等多方面的防护效果,才可以克服汽车功能集成化的趋势带来的新挑战。

参考文献

[1] 一类TBOX的介绍,https://bbs.kanxue.com/thread-265243.htm

[2] QNX虚拟化,https://blackberry.qnx.com/en/products/foundation-software/qnx-hypervisor

[3] 联发科的汽车方案,https://i.mediatek.com/in/automotive-infotainment

版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司(“绿盟科技”)。作为分享技术资讯的平台,绿盟科技期待与广大用户互动交流,并欢迎在标明出处(绿盟科技-技术博客)及网址的情形下,全文转发。
上述情形之外的任何使用形式,均需提前向绿盟科技(010-68438880-5462)申请版权授权。如擅自使用,绿盟科技保留追责权利。同时,如因擅自使用博客内容引发法律纠纷,由使用者自行承担全部法律责任,与绿盟科技无关。

Spread the word. Share this post!

Meet The Author