本篇文章由ChaMd5安全团IOT小组投稿

0x00 简介

在对车联网车机端进行漏洞挖掘与安全研究时，需对车机端固件进行提取。本文分享一次对车机端硬件分析与固件提取记录。

在以往的车联网安全研究工作过程中，我们曾通过以下方式获取到车机端固件：

1. 官网提供升级固件
2. 硬件调试接口JTAG获取固件
3. 读取Flash芯片获取固件
4. 通过串口获取车机系统Shell权限，进而对固件进行打包
5. 利用车机固件更新API，从云端获取更新固件
6. 云端信息泄露，如FTP弱口令或未授权接口获取车机固件

在本次分析记录中，我们使用方法4，通过串口的方式对车机固件进行提取。

0x01 车联网系统

车联网系统一般包含四部分：信息娱乐系统(IVI)、车载网关(T-BOX)、手机APP以及云平台系统(TSP)

不同厂商的车联网实现架构不同，但总体架构可分为4部分：

1. 信息娱乐系统(IVI)
2. 车载网关(TBOX)
3. 手机端车联网应用(APP)
4. 车联网云平台服务(TSP)

IVI：车载信息娱乐系统(In-Vehicle Infotainment)。早期以CD机的形式进行音频播放，在车联网功能推广后，目前的车载娱乐系统可以通过蜂窝网络接入互联网，并提供以下常见功能：实时导航，网页浏览，视频播放，手机投屏，语音控车等。车载信息娱乐系统通常具备一部分CAN总线操控能力，因此车载信息娱乐系统"功能外溢"现象产生的攻击面很可能会导致控车漏洞的产生。

T-BOX：车载网关(Telematics BOX)。负责车机内部的以太网通信，同时提供联网能力，实现车端与云平台(TSP)的远程长连接。T-BOX具备一定CAN总线的能力，也是数字钥匙(手机控车)的实现载体。通过数字钥匙，用户可以通过手机对车辆进行远程操控(云钥匙)或者近场操控(蓝牙钥匙，NFC钥匙)。其中云钥匙的实现架构如下图所示：

APP：手机端车联网应用程序。多数车联网汽车厂商会向车主提供车联网应用程序，此类APP通常具备以下功能: 车主服务，应用商城，远程控车等。

TSP：车载信息服务提供商(TelematicsServiceProvider)。在车联网系统中以云的形式向用户侧与车辆侧提供以下服务：用户信息维护，车辆定位，状态监控等。

0x02 UART协议

在分析硬件之前，先简单介绍一下要如何获取shell

一般来讲，硬件都会有调试接口，就是Uart。

Uart:通用异步收发传输器，是一种串行异步收发协议，应用十分广泛。Uart工作原理是将数据的二进制位一位一位的进行传输。在UART通讯协议中信号线上的状态位高电平代表’1’低电平代表’0’。当然两个设备使用UART串口通讯时，必须先约定好传输速率，也就是波特率。

典型的波特率有这些：300，1200，2400，9600，19200，38400，115200。（上述波特率并不全）

如果试过每一个波特率还是无法接收到可见字符，说明两个问题：

1.找错了串口

2.可能它本身传输的数据是不可见字符

连接Uart需要三根线，分别是：

• TX：发送数据端，要接对面设备的RX
• RX：接收数据端，要接对面设备的TX
• GND：保证两设备共地，有统一的参考平面

接下来我们看一下uart的数据包

• 起始位：发送方要先发出一个低电平’0’来表示传输字符的开始
• 数据位：包含正在传输的实际数据。如果使用奇偶校验位，它可以是5 位到8位长。如果未使用奇偶校验位，则数据帧的长度可以是9位。在大多数情况下，数据首先以最低有效位发送。
• 奇偶校验位：这位是可能有也可能没有，串口会设置校验位（数据位后面的一位），用一个值确保传输的数据有偶个或者奇个逻辑高位，例如数据是011，对于偶校验，校验位为0，保证逻辑高的位数是偶数个，如果是奇校验，校验位为1，这样就有三个逻辑高位。
• 停止位：表示数据包的结束

0x03 硬件分析

本次分析的车机，是通过闲鱼购买，总共有以下配件

• 液晶显示屏
• 车机
• 车机与屏幕的连接线

在分析之前，需要先给车机通电，车机上会标注出一些信息供我们判断如何接正负极

7号BAT接正极，8号GND接负极，4号ACC_IN接正极，效果图如下：

对车机进行拆解分析：

不同车联网厂商实现模式不同，部分厂商会将车载网关(T-Box)与信息娱乐系统(IVI)集成到同一Linux系统中，一些厂商则会将二者分开实现。在本次分析目标中，车载网关(T-Box)与信息娱乐系统(IVI)位于同一块电路板中的两个芯片内，其分布如下图：

这是下层的板子，MCU和它的串口都在这上面，一般单片机的MCU都没有shell，所以不必关注这里的串口。

通过串口连接IVI的效果如图：

通过串口连接4G模块（tbox）效果如图：

小结：找串口重点是耐心，其次是猜，有的板子不会标出rx tx，需要根据经验猜测一些地方是否是串口。这块板子标注出了rx tx，因此不需要使用万用表找串口了。

0x04 文件传输协议与固件提取

提取固件，一般会根据硬件能提供的功能来具体分析，大致思路是这样：

1. 车机有wifi功能，通过工程模式开启wifi热点

   WiFi→FTP/TFTP→PC

2. 通过串口文件传输协议，直接提取固件

   Uart→Xmodem/Ymodem/Zmodem→PC

简单介绍一下这三个协议

• Ymodem:Xmodem改良版，它可以一次传输1024字节的信息块，同时还支持传输多个文件。

  这里只对改进的地方进行解释说明，协议控制符与Xmodem相同，传输流程也相同，差别在数据帧，Ymodem有三组数据帧。

  1.起始帧：SOH + 00 + FF + filename + filesize + NULL + CRCH + CRCL

  SOH：数据头

  00：数据帧序号，依次向下排

  FF：数据帧序号反码

  filename：传输的文件名

  filesize：传输的大小

  NULL：数据部分的128字节减去filename和filesize，剩下的用00填充

  CRCH：CRC高8位

  CRCL：CRC低8位

  2.数据帧格式：STX/SOH + [编号] + 编号的反码 + data[0] + data[1] + data[n] + CRCH + CRCL

  3.结束帧格式：SOH + 00 + FF + NULL + NULL + … + NULL + CRCH + CRCL

  数据帧和结束帧与Xmodem相同。

• **Zmodem:**采用串流传输方式，传输速度最快。

  Zmodem数据帧：ZPAD + ZDLE + A + frame-type ZF3 ZF2 ZF1 ZF0 CRC-1 CRC-2

  ZPAD+ZDLE：帧头

  A：报头的数据是二进制格式

  frame-type：帧类型

  ZF3 ZF2 ZF1 ZF0：4个字节信息

  Zmodem协议工作流程：

  1.发送端建立连接

  2.接收端建立连接

  3.发送端传输文件过程

  4.接收端接收文件过程

  5.接收端ZDATA帧的处理过程

  6.对ZEOF帧的处理过程

  7.发送端终止发送

  8.接收端终止发送

支持这三种协议的工具分别是minicom和SecureCRT。

通过使用SecureCRT可以直接下载或上传文件，如果芯片系统里存在lrzsz，可以直接用Zmodem进行传输。

输入命令 sz filename即可下载

0x05 参考资料

1.https://blog.csdn.net/wangguchao/article/details/108483276

2.https://www.circuitbasics.com/basics-uart-communication/

3.https://www.embedded.com/understanding-the-uart/

4.https://zhuanlan.zhihu.com/p/39782973

5.https://shatang.github.io/2020/08/12/Xmodem协议/

6.https://www.cnblogs.com/iriczhao/p/12052676.html

7.https://blog.csdn.net/weixin_38165614/article/details/112303713?utm_medium=distribute.pc_relevant.none-task-blog-2~default~BlogCommendFromMachineLearnPai2~default-4.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~BlogCommendFromMachineLearnPai2~default-4.control