UDS刷写基础基础概念解读

本篇主要讲解UDS刷写中了涉及的重要的基础概念。

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

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

(相关资料图)

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

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

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

服务ID汇总

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

会话

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

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

会话保持(3E 00)

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

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

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

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

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

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

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

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

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

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

Seed2Key 算法

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

#defineSECURITYCONSTANT  0x464c4147WORDseedToKey(WORDwSeed,DWORDconstData){DWORDwLastSeed;WORDwLastKey;wLastSeed=wSeed;wLastSeed=(wLastSeed>>5)|(wLastSeed<<23);wLastSeed*=7;wLastSeed^=SECURITYCONSTANT;wLastKey=(WORD)wLastSeed;returnwLastKey;}

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

诊断连接方式

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

诊断设备连接网关，由网关将消息转发给ECU；

诊断设备与ECU直连。

固件格式

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

S-record

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

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

Data Record 数据记录，有 S1、S2、S3 三种类型；

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

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

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码形式存储的文本文件。

BIN

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

自定义格式

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

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

分析工具

srecord

命令行工具 srecord

sudoapt-get install srecord

查看S-record文件信息

fans@fans:~$ srec_infoJKE_X1_APP_SOC.s19Format: Motorola S-RecordHeader:"JKE_X1_APP_SOC.s19"Execution Start Address: 00FC0000Data: 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。

专用工具

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

脚本

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

# wget https://raw.githubusercontent.com/consp/vbfdecode/master/vbfdecode.py# python vbfdecode.py -b firmware.vbfOffset: 0x359, Location: 0x18000, Size: 0xB256C, Data Offset: 0x361VBF v2.1Description: Software part:1234type: APPNetwork: 0x00000000Data Format Identifier: 0x00000000ECU address: 0x000007C6Frame_format:Erase frames:Data blobs:0x00018000   0x000B256C    e301Saving:18000.bin

—END—

关键词：