UDS 诊断协议入门：从 CAN 帧到 ISO 14229 的完整实战

CAN 抓包之后，下一步就是 UDS

如果你看过站内那篇《OBD-II 与 CAN 总线抓包分析完整指南》，大概率会有同一个困惑：抓到了一堆 0x7E0、0x7E8 的报文，看起来有规律，但完全读不懂它在说什么。

原因很简单：CAN 只负责「把字节送过去」，不规定这些字节是什么意思。真正让诊断仪能和 ECU 对话的那套「语言」，叫 UDS（Unified Diagnostic Services，ISO 14229）。

打个比方：CAN 是公路，ISO-TP 是货运规则（一车装不下怎么拆包），UDS 是包裹上的单据格式。读懂 UDS，你才算能听懂车在说什么。

本文从帧结构一路讲到能跑通的 Python 代码，全部是可以在自己车上复现的流程。

一、三层结构，先建立地图

关键认知：UDS 报文不是「一条 CAN 帧」。超过 7 字节的响应必须靠 ISO-TP 拆成多帧，这也是一堆人卡住的地方——看到 10 14 开头就懵了。

二、ISO-TP 的四种帧

CAN 一帧最多 8 字节，第一个字节被拆成「高 4 位 = 帧类型，低 4 位 = 参数」。

一条 20 字节的 VIN 响应，实际长这样：

7E8  10 14 62 F1 90 57 50 30    # 首帧：总长 20
7E0  30 00 00                    # 接收方发流控：继续发
7E8  21 41 4C 30 30 30 30 30    # 连续帧 1
7E8  22 30 30 30 30 30 30 30    # 连续帧 2

拼起来就是 62 F1 90 + 17 字节 VIN。手工拼当然可以，但代码里用 ISO-TP 库更省事。

三、诊断地址：谁在跟谁说话

OBD 口的诊断报文走固定的一组地址（11 位 ID）：

功能寻址适合「让所有 ECU 一起做某件事」（比如 3E 00 保活），物理寻址适合精确读某个 ECU 的数据。注意：功能寻址的请求不会有流控，也不支持多帧请求。

四、UDS 报文结构

一条 UDS 请求 = 服务 ID（SID）+ 子功能/参数。

• 正响应：SID + 0x40，后面跟解析后的数据。例如 10 03 → 50 03 ...
• 负响应：固定 7F 开头，格式 7F <原SID> <NRC>。例如 7F 22 31 表示「读 DID 请求超出范围」。

常见 NRC（否定响应码）

0x78 值得单独说：ECU 处理耗时操作时会先回 7F xx 78，然后过几百毫秒再回正响应。不会处理 0x78 的诊断工具会把正常流程误判成失败。成熟的库（如 udsoncan）会自动等。

五、常用服务速查

记住一个规律：读服务（0x19 / 0x22）练手安全，写服务（0x2E / 0x31 / 0x34）可能把 ECU 写坏。初学阶段只碰读。

六、一次完整会话：读 VIN

在 Linux 上用 SocketCAN，先把 500 kbps 的 can0 起起来（绝大多数乘用车诊断 CAN 是 500k）：

sudo ip link set can0 up type can bitrate 500000
candump can0

第 1 步：进入扩展会话

发送 7DF  [02] 10 03
接收 7E8  [06] 50 03 00 32 01 F4

解析：50 = 0x10 + 0x40，表示正响应；03 是当前会话；后面 4 字节是 P2/P2* 定时参数（这里 0x0032 = 50 ms，0x01F4 = 500 ms×10）。

第 2 步：读 VIN（DID = 0xF190）

发送 7E0  [03] 22 F1 90
接收 7E8  [10 14] 62 F1 90 57 50 30   # 首帧，20 字节
发送 7E0  [30 00 00]                   # 流控
接收 7E8  [21] 41 4C 30 30 30 30 30
接收 7E8  [22] 30 30 30 30 30 30 30

把 62 F1 90 后面的 17 个字节按 ASCII 拼起来，就是 VIN 码。这一步能跑通，说明你的硬件、波特率、ISO-TP 全链路都是对的。

七、用 Python 跑起来

手拼帧只适合验证，实际分析用 python-can + isotp + udsoncan 三件套。

pip install python-can isotp udsoncan

import can
import isotp
from udsoncan.connections import PythonIsoTpConnection
from udsoncan.client import Client
import udsoncan.configs

# 1) 打开 CAN
bus = can.Bus(interface="socketcan", channel="can0", bitrate=500000)

# 2) 配置 ISO-TP：物理寻址 7E0 -> 7E8
addr = isotp.Address(isotp.AddressingMode.Normal_11bits, txid=0x7E0, rxid=0x7E8)
stack = isotp.CanStack(bus=bus, address=addr, params={"blocksize": 0, "stmin": 0})

conn = PythonIsoTpConnection(stack)
conf = dict(udsoncan.configs.default_client_config)
conf["request_timeout"] = 3

with Client(conn, config=conf) as client:
    # 3) 进扩展会话
    client.change_session(0x03)
    print("会话已切换到扩展模式")

    # 4) 读 VIN
    r = client.read_data_by_identifier([0xF190])
    print("原始响应:", r.service_data)

    # 5) 读当前故障码
    dtc = client.get_dtc_by_status_mask(0xFF)
    print("DTC:", dtc.service_data)

几点实践说明：

• udsoncan 会自动处理 0x78 和 ISO-TP 流控，比自己写状态机省太多。
• 不同版本返回对象的字段名略有差异，建议先 print 出来再取。
• Windows 上没有 SocketCAN，要用 interface="slcan"、"pcan" 或 "vector"，并在 channel 里填串口名/通道号。
• ICSim 这类纯 CAN 模拟器不支持 UDS——它只会伪造车速、门锁这些原始信号。要练 UDS，得用真实 ECU、台架，或者支持 UDS 的仿真工具。

八、安全访问 0x27 是怎么回事

很多服务（写配置、执行例程）要求先解锁。流程是标准的挑战-应答：

1. 工具发 27 01（请求种子）
2. ECU 回 67 01 <seed>
3. 工具用某个算法把 seed 算成 key，发 27 02 <key>
4. ECU 回 67 02 表示解锁成功，否则 7F 27 35（密钥无效）

算法由厂商定义，没有统一标准，常见做法是查表、异或固定值、或者基于 UDS 之外的私有算法。这也是为什么「破解」不同车型时，工作量和难度差异巨大。

从防御角度看，这一点很重要：把安全算法硬编码在 ECU 固件里，本质上只是增加门槛，不是安全边界。真正的防护要靠网关隔离、诊断防火墙和访问控制。

九、几个高频坑

十、风险与边界

这一节不是套话，是真会出事的部分：

• 只读服务相对安全，写服务风险极高。0x2E 写错一个字节，可能让 ECU 进入不可用状态；0x31 执行错误例程，可能触发标定丢失。
• 不要在行驶中操作。涉及制动、转向、动力系统的 ECU，任何异常都可能直接变成事故。
• 只在自有车辆或书面授权的车辆上做。未经授权接入他人车辆诊断系统，可能触犯《网络安全法》与《刑法》第 285 条。
• 刷写（0x34/0x36/0x37）不要碰，除非你有原厂工具和恢复方案。

十一、小结

把学习路径压缩成四步：

1. 看懂帧：CAN 抓包 → 认出 0x7E0/0x7E8 → 理解 PCI 字节
2. 跑通只读：10 03 切会话 → 22 F1 90 读 VIN
3. 用库替代手拼：python-can + isotp + udsoncan
4. 再谈写入：理解 0x27 与风险之后，才碰 0x2E/0x31

延伸阅读：

• 抓包与信号逆向：《OBD-II 与 CAN 总线抓包分析完整指南》
• CAN 报文逆向：《CAN 总线消息逆向实战：ICSim + cansniffer + SavvyCAN》
• 把手机变成车载测试工具：《用 NetHunter 把你的汽车变成渗透测试工具》

免责声明：本文仅用于自有车辆的诊断学习与授权范围内的安全研究。任何未授权的车辆接入、数据写入或功能篡改，均可能违法并造成人身财产损害，后果自负。