作者：lxonz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.找错了串口

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

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

GND：保证两设备共地，有统一的参考平面

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

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

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

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

对车机进行拆解分析：

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

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

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

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

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

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

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

WiFi→FTP/TFTP→PC

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

Uart→Xmodem/Ymodem/Zmodem→PC

简单介绍一下这三个协议

Xmodem:异步文件传输协议。分为标准Xmodem和1k-Xmodem两种，前者以128字节块的形式传输数据，后者字节块为1k即1024字节，并且每个块都使用一个校验和过程来进行错误检测。在校验过程中如果接收方关于一个块的校验和与它在发送方的校验和相同时，接收方就向发送方发送一个确认字节(ACK)。由于Xmodem需要对每个块都进行认可，这将导致性能有所下降，特别是延时比较长的场合，这种协议显得效率更低。

Xmodem协议控制字符

SOH：0x01 (Modem数据头)

STX：0x02(1K-Xmodem数据头)

EOT：0x04 (发送结束)

ACK：0x06 (应答)

NAK：0x15 (重发)

CAN：0x18 (取消发送)

CTRLZ：0x1A（填充）

标准的Xmodem数据包

一个完整的数据帧一共132字节，其中包含128字节数据，数据帧以固定3字节帧头开始，第一个是控制字符SOH（0x01），第二个是数据帧序号，第三个是数据帧序号反码，第四个是数据帧固定长度为128，不足128为使用CTRLZ（0X1A）进行补齐，第五个是校验和。

Xmodem传输过程：

启动传输：Xmodem协议的传输由接收方启动，接受方发送"C"或者NAK，其中接收方发送NAK信号表示接收方打算用累加和校验；发送字符"C"则表示接收方打算使用CRC校验。

传输过程：当接收方发送的第一个"C"或者NAK到达发送方，传输启动。发送方将数据以每128字节的数据加上包头，包号，包号补码，校验和打包成帧格式传送，发送方发完后，等待接收方发送ACK（0x06），发送方收到ACK，证明数据传输成功，接收方会要求发送方发送下一个数据包。如果接收方发送NAK给发送方，证明文件需要重传，发送方会将上一组数据重发。如果接收方发送CAN（0x18），发送方会停止发送。

结束传输：如果数据传输正常，需要结束传输，会发送方发送EOT（0x04），接收方会发送ACK（0x06）确认。

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.发送端传输文件过程

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！