D~DIDI~DIDIDI!!!!

0%

UDS诊断协议基础

Posted on Edited on In

UDS（Unified Diagnostic Services，统一诊断服务）是汽车电子控制单元（ECU）环境中最核心的诊断通信协议，基于ISO 14229标准，在汽车行业中具有极高的通用性和重要性。

无论是车辆的故障排查、固件升级（OTA），还是高阶的汽车网络安全研究，掌握UDS协议都是必不可少的基础。

1. UDS协议概述

UDS协议（ISO 14229）通常基于CAN总线（ISO 15765-2 DoCAN）运行，但也可在FlexRay、以太网（DoIP）等多种网络协议上运行。它定义了诊断仪（Tester/Client）与ECU（Server）之间的交互机制。

1.1 服务与类别

UDS标准共定义了6大类、26种类型的诊断服务。每种服务都分配了唯一的SID（Service Identifier，服务标识符），范围在 0x00-0xFF 之间。

类别 描述 代表性SID（举例）
Diagnostic and Communications Management 诊断与通信管理。控制诊断会话、安全访问、通信及控制链路。 0x10 (DiagnosticSessionControl)
0x27 (SecurityAccess)
Data Transmission 数据传输。用于读取或写入ECU的数据（如配置参数、VIN码等）。 0x22 (ReadDataByIdentifier)
0x2E (WriteDataByIdentifier)
Stored Data Transmission 存储数据传输。用于操作故障读取（DTC）。 0x14 (ClearDiagnosticInformation)
0x19 (ReadDTCInformation)
Input/Output Control 输入/输出控制。允许诊断仪临时接管或控制ECU的输入输出接口。 0x2F (InputOutputControlByIdentifier)
Routine 例程控制。用于启动、停止或获取ECU内部的自检/特定例程的结果。 0x31 (RoutineControl)
Upload/Download 上传与下载。用于固件刷写（Flash），通常与Bootloader配合使用。 0x34 (RequestDownload)
0x36 (TransferData)

2. UDS通信机制

UDS本质上是基于“请求-响应”架构的问答式通信机制。

2.1 寻址方式

客户端发送诊断请求时，支持两种寻址机制：

  1. 物理寻址（Physical Addressing）：点对点（1对1）通信。测试仪针对网络上的某一个特定的ECU发送请求，目标ECU必须回复。常用于读取数据、写入数据、安全访问等。
  2. 功能寻址（Functional Addressing）：广播通信（1对多）。测试仪向网络上所有的ECU广播请求，所有支持该特定功能的ECU都会给出响应。常用于唤醒网络、查询多节点状态等。

2.2 请求帧格式 (Request)

诊断仪发起的请求帧格式通常如下：

1
[SID] + [Sub-function (可选)] + [Data Parameter (可选)]
  • SID：请求的服务ID（1个字节，如 0x10）。
  • Sub-function：子功能（1个字节）。用于进一步具体化服务（如 0x10 0x01 表示进入默认会话）。
    • 最高位（Bit 7）通常是 suppressPosRspMsgIndicationBit（抑制正响应位，SPRM）。如果设为1，ECU执行成功后将不会发送正响应帧，以减少总线负载。
  • Data Parameter：具体的操作数据段（长度不定）。

2.3 响应帧格式 (Response)

ECU收到请求后，如果不是被抑制响应，会返回处理结果。响应分为正响应和负响应。

正响应 (Positive Response)

当ECU成功接收并执行了请求，返回正响应：

1
[Response SID] + [Sub-function (如果有)] + [Data Result]
  • Response SID = Request SID + 0x40
  • 例如：请求 0x10（诊断会话控制），正响应的SID必然是 0x50。

负响应 (Negative Response)

当ECU因为权限不足、条件不满足或格式错误无法执行请求时，会返回固定格式的负响应：

1
[0x7F] + [Request SID] + [NRC]
  • 0x7F：负响应固定标识符。
  • Request SID：被拒绝的请求的原始SID。
  • NRC (Negative Response Code)：负响应码（1个字节），详细说明失败原因。

常见的NRC代码包括：

  • 0x11：服务不支持 (ServiceNotSupported)
  • 0x12：子功能不支持 (SubFunctionNotSupported)
  • 0x13：消息长度或格式错误 (IncorrectMessageLengthOrInvalidFormat)
  • 0x22：条件不满足 (ConditionsNotCorrect)
  • 0x31：请求超出范围 (RequestOutOfRange)
  • 0x33：安全访问被拒绝 (SecurityAccessDenied)
  • 0x35：无效密钥 (InvalidKey)
  • 0x36：超出尝试次数 (ExceededNumberOfAttempts)
  • 0x78：请求正确，但响应挂起 (RequestCorrectlyReceived-ResponsePending)

3. 安全研究视角下的 UDS 协议

在车联网渗透测试中，UDS协议是最常被攻击者利用的面之一，主要安全威胁包括：

  1. UDS 爆破扫描 (Discovery & Fuzzing)
    • 发送各种无效或极端的边界SID和载荷，观察ECU在异常输入下的反应，发现未公开或特定厂商的内部诊断接口（如绕过安全限制即可读写内存）。
  2. Security Access 暴力破解 (NRC 0x33/0x35 绕过)
    • 0x27为安全访问服务。许多ECU使用简单的Seed-Key算法，如果Seed长度不够或重试控制/惩罚机制（如NRC 0x36 延时）实现存在缺陷，可能会被穷举破解，获取特权（如进入编程会话 0x10 0x02）。
  3. 恶意固件刷写 (Upload/Download)
    • 如果成功绕过身份认证，可以通过由 0x34、0x36、0x37组成的刷写流程上传修改过（如植入后门代码）的固件。
  4. 通过 I/O 控件恶意接管车辆部件
    • 使用 0x2F 控制服务非法接管刹车控制、转向电机、车门解锁等核心动作。
  5. 拒绝服务 (DoS)
    • 频繁发送特定的测试框架（例如：DiagnosticSessionControl 0x10），或引起大量功能广播错误，致使目标ECU消耗计算资源处理UDS甚至进入总线挂起（Bus Off）状态。