车机硬件分析与固件提取

  • A+
所属分类:IoT

本篇文章由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

简单介绍一下这三个协议

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

    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

end


招新小广告

ChaMd5 Venom 招收大佬入圈

新成立组IOT+工控+样本分析+AI 长期招新

欢迎联系[email protected]



车机硬件分析与固件提取

本文始发于微信公众号(ChaMd5安全团队):车机硬件分析与固件提取

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: