车联网安全基础知识之UDS刷写前置基础知识

车联网安全
2023-05-02 15:52
127773

有段时间没写文章了,之前计划要写的车联网安全基础知识系列要写的已经新建了好多好多文件了。年初到最近都忙于项目和一些生活上的事情,所以没有更新文章。最近有不少伙伴来催更,也欢迎其他小伙伴来催更和"提需求"。最近在给公司做SOA架构下的安全测试中,发现27算法在一些新场景下的用途以及存在的安全问题。回头翻资料的时候发现讲27服务(安全访问)的文章倒是不少,而讲述完整的UDS刷写过程的文章相当少,且很少与安全相结合。今天和大家分享一下27安全访问的安全性以及我对UDS刷写流程的一些认识。
写的文章篇幅比较长,于是拆成了三篇。后续文章将在不久后发出。

本文不会详细讲解UDS的基础知识,后续会出专题讲解 UDSonCAN、UDSonIP ,到时会站在安全研究的角度详细UDS协议。本篇主要讲解UDS刷写中了涉及的重要的基础概念。

服务ID:后续UDS刷写中用到的服务ID

会话定义:刷写中会话切换,不同阶段在不同的会话。

27服务认证流程:刷写解锁,安全访问的基本流程。

诊断连接方式:不同的连接方式,直接和通过网关连接。

固件格式:刷写中使用到的固件的常见的格式以及简单的分析。

服务ID汇总

首先总体看一下刷写涉及的服务ID以及在刷写过程的用途。

诊断服务标识Service ID诊断服务 Diagnostic Service在刷写过程中的用途
0x10诊断会话控制 DiagnosticSessionControl切换到拓展会话检查刷写条件、停止一些功能切换到编程会话执行刷写
0x11ECU复位 ECUReset用于刷写完成后重启服务,使新固件生效
0x27安全访问 SecurityAccess校验刷写者身份,采用seed-key
0x28通信控制 CommunicationControl关闭和启用一般通讯报文
0x29认证服务 Authentication Service基于PKI的身份认证
0x31例程控制 RoutineControl指定特定的例程,前置条件检查、检查编程依赖等
0x34请求下载 RequestDownload设置下载的参数(起始地址、长度)
0x36数据传输 TransferData固件传输
0x37请求结束传输 RequestTransferExit终止数据传输
0x3E测试设备在线 TesterPresent用于将会话保持在当前会话中
0x85控制故障码设置 ControlDTCSetting设置启停故障码存储功能

会话

诊断会话关联了一系列的诊断服务或诊断功能。只有当前激活的诊断会话支持的诊断服务才能被响应。ECU通常有两个以上的诊断会话,包括:一个默认会话(Default Session)和若干非默认会话(Non Default Session)。其中非默认会话又包括编程会话和扩展会话等。其他非默认会话由厂商自行定义。常见的ECU诊断会话定义如下:

诊断会话会话ID描述
默认会话0x01ECU启动后默认进入此会话。只提供基本的诊断服务。
编程会话0x02ECU更新应用程序或标定数据时进入此会话。支持与程序更新相关的诊断服务。如0x34、0x36、0x37等。
扩展会话0x03除支持默认会话下的诊断服务和功能外,还支持额外的诊断服务。
.........

诊断会话控制服务(0x10)是用于激活控制器各种不同的会话模式 。在固件刷写中会使用0x10服务在默认会话、编程会话、拓展会话来回切换。

会话保持(3E 00)

此服务用于向单(或多)个服务端指示客户端仍然与车辆连接,并且维持先前已激活的某些诊断服务和/或通信将保持活动状态。此服务用于将一个或多个服务端保留在默认会话之外的诊断会话中,通过周期性的发送 3E 实现。

整个刷写过程中, 刷写工具要周期性的发送链路保持请求, ECU 不需要响应请求信息。如果没有开启会话保持,几秒后ECU就会切回默认会话。

刷写前需要保持在拓展会话下。

刷写中需要保持在编程模式下。

27 服务-安全访问认证流程

安全访问服务的目的是为保密和排放、安全相关的一些服务和数据提供访问权限来保护数据。2E(通过DID写入数据)、2F(通过DID进行输入输出控制)、31服务(例程控制)、34服务(请求下载)、36服务(请求上传)、37服务(数据传输)等服务需要经过身份认证。身份认证利用了种子和密钥之间的关系。 服务的示例如下图所示:

c35d127585abeb5ca2a35e9c59bab0f3.png

1.Request Seed:Tester 使用27服务,并携带需要解锁的安全等级 0X 发送给特定的 ECU。

2.Request Seed Reply : 对应的ECU收到之后,生成4个字节的随机数 Seed,返回给 Teseter。

3.Send Key: Tester 拿到Seed后,使用自定义实现的 Seed2Key 算法计算出Key,发送给ECU。Send Key 中的安全访问级别 0Y 是Request Seed的 2倍。例如当请求种子为 27 01 时,发送秘钥则为 27 02(01*2)。

4.Send Key Reply : ECU 将收到的 Key 和 自己拿 Seed 作为输入的 Seed2Key 计算出结果进行对比,然后返回验证的结果。

Seed2Key 算法

安全访问中最重要的就是Seed2Key算法,算法通常是一些比较简单的移位算法,例如下列的算法。

 #defineSECURITYCONSTANT   0x464c4147
 
 WORD seedToKey (WORD wSeed, DWORD constData)
 {
 DWORD wLastSeed ;
 WORD wLastKey;
 wLastSeed= wSeed;
 wLastSeed = (wLastSeed>>5) | (wLastSeed<<23);
 wLastSeed *= 7;
 wLastSeed ^= SECURITYCONSTANT;
 wLastKey = (WORD)wLastSeed;
 return wLastKey;
 }

seed2key 接受2个输入参数 种子 和 安全常量,种子由 ECU 随机产生;安全常量内置在ECU和诊断仪中,在某种意义上来说安全常量就是密码。采用同一算法的不同用途的 ECU,通常使用不相同的安全常量。

诊断连接方式

诊断设备与ECU连接有两种方式,如下图。

1.诊断设备连接网关,由网关将消息转发给ECU;

2.诊断设备与ECU直连。

fed4234913e8d4cd849e1c2365979fd1.png

固件格式

S-record、Intel Hex、BIN、VBF 是汽车中MCU固件常用的格式,下面简单介绍一下这几种格式。了解数据格式有助于固件分析、刷写安全测试等。

S-record

S-record 是摩托罗拉设计的一种常于MCU内存、EPROM、EEPROM 写入的文档格式,S-record 将二进制数据以ASCII字符表示。常用文件后缀名有 SRECORD、SREC、S19、mot。文件格式如下图。

7554f7137d9fe2b673b29affb0e57f30.png

Header Record 文件头信息,其中记录有模块名称、版本号等;

Data Record 数据记录,有 S1、S2、S3 三种类型;

Count Record(可选) 包含了先前传输的S1、S2、S3记录的计数;

Termination Record,结束记录,有 S7、S8、S9 三种类型。

79caaf39e78d2d4e3b722de905ad878b.png

S0 Record(头记录):记录类型是“S0”。地址场没有被用,用零(0x0000)填充。数据场中的信息使用HEX转换成字符串是:JKE_X1_APP_SOC.s19。此行表示程序的开始,不需烧入内存,用来表述文件的相关信息,可能包含文件名、版本号等。

S3 Record(数据记录):记录类型是“S3” 。地址场由4个字节地址,数据场由可载入的数据组成。

S7 Record(结束记录):记录类型是“S7”。地址场由4字节的地址,包含了开始执行地址。没有数据场。此行表示程序的结束,不需烧入内存。

注: S-Record 中记录有固件的起始地址,逆向分析时直接从中获取,然后设置为起始地址即可。

Intel HEX

在嵌入式MCU程序开发中,经常编译链接后生成的 HEX 就是采用的 Intel Hex 格式。也是一种将二进制文件转换成了ASCII码形式存储的文本文件。

705a994991db0db5cde5319675d7fe9b.png

BIN

二进制文件,只有固件数据,没有起始地址、描述信息等。

73aa2f0c750ed970dcc4965f9ad5c22e.png

自定义格式

车企自定义格式如,VBF(Volvo Binary File)。VBF 使用在 volvo、mazda、Ford、吉利等品牌的汽车中。

文件头记录有文件的VBF版本号、软件版本信息、ECU物理地址、数据起始地址等。

57b94d83aed0f71f5b16d27099ee98da.png

分析工具

srecord

命令行工具 srecord

sudo apt-get install srecord

查看S-record文件信息

fans@fans:~$ srec_info JKE_X1_APP_SOC.s19
 Format: Motorola S-Record
 Header: "JKE_X1_APP_SOC.s19"
 Execution Start Address: 00FC0000
 Data:   01000000 - 01089C5F
         01180000 - 011800FF
        0127FB80 - 0127FBDF
        0127FF80 - 0127FFFF

文件转换

S-record 转 hex

srec_cat JKE_X1_APP_SOC.s19 -Motorola -o JKE_X1_APP_SOC.hex -Intel

Intel hex 转 S-record

srec_cat JKE_X1_APP_SOC.hex -Intel -o JKE_X1_APP_SOC.s19 -Motorola

S-record 转 bin

srec_cat JKE_X1_APP_SOC.s19 -Motorola -o JKE_X1_APP_SOC.bin -bin

HexView

S-record、Intel Hex、BIN 文件之间的转换可以采用 Vector 的图形化文件编辑软件 HexView。

c3b47e3a900d66ee8f6079a9637b5183.png

专用工具

主机厂或供应商自己开发的专用软件,如VBF文件查看工具 VBF Tool.

08d5f0c1f132bae38ac739f951ecf50a.png

脚本

根据文件格式定义,编写脚本解析、提供固件,部分可以在 Github 上找。

# wget https://raw.githubusercontent.com/consp/vbfdecode/master/vbfdecode.py
 # python vbfdecode.py -b firmware.vbf
 Offset: 0x359, Location: 0x18000, Size: 0xB256C, Data Offset: 0x361
 VBF v2.1
 Description: Software part: 1234 type: APP
 Network: 0x00000000
 Data Format Identifier: 0x00000000
 ECU address: 0x000007C6
 Frame_format:
 Erase frames:
 Data blobs:
 0x00018000     0x000B256C       e301
 
 Saving:
    18000.bin

参与评论

0 / 200

全部评论 0

暂无人评论
投稿
签到
联系我们
关于我们