新型车机，如何攻防？

汽车安全 2年前 (2023) admin

714 0 0

一、简介

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

二、车机的结构

车机的一般结构

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

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

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

集成4G模组和eSIM，实现移动上网。
集成USBHUB，提供座舱内U盘传输音乐以及为手机充电的功能。
集成Wi-Fi、蓝牙模块，实现Wi-Fi局域网共享以及蓝牙通话的功能。
集成以太网模块，实现车内以太网通信。
集成MCU和CAN收发器，实现与车内其他ECU的通信。
集成音频模块，实现车内音响的接入。
集成视频模块，实现倒车影像等功能。
接其他外设，如按键、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、仪表、网关等多方面的防护效果，才可以克服汽车功能集成化的趋势带来的新挑战。