2026-05-20 05:30:29 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细解析了UDS诊断协议中的ECU刷写流程，将完整过程划分为环境准备、数据传输和收尾配置三个阶段。核心要点包括：必须先通过扩展会话和安全访问将ECU置于编程状态；数据传输采用0x34、0x36、0x37服务实现分块下载与校验；最后需进行网络恢复和最终配置。文章特别强调了bootsoftware的独立性和异常恢复机制的重要性。 综合评分： 86 文章分类： 车联网安全,技术标准,解决方案,应用安全

cover_image

UDS刷写流程

谈思实验室

2026年5月19日 17:17 上海

在小说阅读器读本章

去阅读

以下文章来源于车码间，作者汽车软件混子哥

车码间 .

汽车研发，合作交朋友，学习指导，欢迎交流

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

一说到 UDS 刷写，脑子里先冒出来的是三个服务：0x34、0x36、0x37。

如果只记这三个服务，其实只记住了“搬数据”这一段，还没真正抓住刷写流程。

标准里对刷写这件事，讲的是一整套编程序列。

前面要把车和 ECU 先拉进适合编程的状态，中间才是下载和写入，最后还得把网络重新拉回正常状态。如果中间做了复位，后面往往还要补一段最终配置。

整条主线

标准把非易失性存储器编程过程分成两个阶段。

第一阶段是软件下载和数据下载，这是刷写主战场。

第二阶段是可选的最终配置，用来做复位后的收尾动作，比如写 VIN、清 DTC，或者补一些只有应用跑起来之后才能做的配置。

先把整条链路压成一张总览表，再看流程会更顺畅些。

整条主线可以再压成下面这张图：

网络准备

真正开始刷写前，客户端先得把整车网络和目标 ECU 拉到适合编程的状态。标准把这一段放在 STP1，也就是第一阶段的预编程步骤。

这一步常见的动作有几类：

先把 ECU 切到扩展会话。
按需检查编程前置条件。
关闭 DTC 记录。
关闭非诊断通信，避免总线还在跑正常业务报文。
读取识别信息、准备动态地址，或者做一些 OEM 自定义准备动作。
如果网络支持，还可以先验证再切换到更高波特率，提高后面下载速度。

这一步看着像铺垫，实际特别关键。你不先把通信环境收干净，后面一边刷写、一边还有正常业务报文在网上跑，风险会直接上来。

刷写失败、超时、数据块丢失，很多时候不是 0x36 本身有问题，而是前面的网络环境没准备好。

刷写传输

STP2 才是第一阶段真正的编程步骤。这里面最常见，也最容易被拿出来单说的，就是下面这条链：

RequestDownload（34H）
TransferData(36H)
RequestTransferExit(37H)

1. 进入 programmingSession

刷写一开始，客户端先请求 ECU 进入 programmingSession(编程会话)。

ECU 收到以后，要把编程所需资源准备好。具体是不是立刻跳到 boot software 执行，标准没有一刀切，留给实现决定。

这也是为什么同样是刷写，有的 ECU 进会话后你会明显感觉它已经在 boot 里了，有的还保持在应用控制下，只是把编程资源先拉起来。

2. 安全访问

对于排放相关和安全相关系统，SecurityAccess 是强制要求。也就是说，真正正规的 ECU 刷写，不会允许你无条件往里写。

这里的过程很简单：先请求 seed，再传输 key，通过后再继续。没过这一关，后面下载链路再完整也没用。

3. 写 fingerprint

标准允许在正式下载前先写 fingerprint，用来标识是谁改了这台 ECU 的内存。这个动作通常通过 WriteDataByIdentifier（2EH）完成。

这一步的目的是追溯责任、确认版本来源、做售后诊断，很多时候都要靠这类标记。

4. 擦除和编程算法

这是很多人第一次看标准时容易糊涂的地方。

某些 ECU 本身没有把Flash驱动固化在永久存储器里，那么得先把Flash驱动下载进去。

也就是说，标准允许你先下载Flash驱动，再用Flash驱动去擦 Flash、写 Flash。

这个设计是因为不同芯片、不同平台、不同 OEM，底层编程实现差异本来就很大，没必要都做成一个死板模型。

5. 下载软件

等会话、安全、擦除准备都就绪，才进入真正的软件或数据块下载。

这一段的固定方法是：

这三步里，每一步都有自己的职责。

RequestDownload 确定数据格式、地址格式、目标地址、目标大小。ECU 还会在正响应里告诉客户端，它一帧最多能吃多大的 TransferData。

客户端不能按自己想象随便分块，得先看 ECU 给出的 maxNumberOfBlockLength。你分块分大了，后面就不是效率问题了，是ECU端直接不让传。

TransferData 才是真正搬运数据的环节。一个完整软件块，通常会拆成多个 0x36 请求分批发送。

这里最关键的字段是 blockSequenceCounter。它从 0x01 开始，后面每发一个块加一，到 0xFF 之后回卷到 0x00。这个计数器不是装饰，它是出错恢复的关键。

标准专门考虑了两类常见异常：

ECU 其实已经正确收到了某个块，也处理完了，但正响应在路上丢了。客户端超时后会重发同一个块，而且计数器不变。ECU 看到是重复块，就该直接回正响应，不能傻乎乎再写一遍。
ECU 根本没正确收到这个块，所以也没回正响应。客户端超时后同样重发。ECU 看到这个计数器时，会把它当成一个新的有效块来处理。

这套机制很朴素，但特别管用。没有 blockSequenceCounter，多块下载时一旦出现丢包、重发、响应丢失，现场就很容易乱成一锅。

RequestTransferExit 用来结束这一次数据传输。它告诉 ECU，这一轮块传输到这里结束了，后面该做收尾检查、状态切换、结果确认了。

别把它理解成一个形式化的“结束标志”。很多实现会在这个节点做真正的落盘确认，或者在这里返回一些补充状态。如果你只盯着 0x36，把 0x37 当可有可无，调试时很容易吃亏。

三个检查点

从标准给的编程步骤看，真正的软件下载中间至少有三类检查口。

第一类是算法下载后的检查。擦除例程和编程例程如果是临时下载进去的，后面可以跟一个 RoutineControl，确认例程本身是否正确。

第二类是每个软件块下载后的检查。一个连续块完成 0x34 -> 0x36 -> 0x37 之后，可以再做一次内存检查，确认这个块写进去没有问题。

第三类是全部块完成后的总校验。这里可以验证重编程依赖关系，并做校验和、签名、DTC、软硬件兼容性之类的检查。说白了，这一步才是“这次刷写到底算不算真的成功”的总闸门。

很多项目现场翻车，不是下载链路断了，而是最后这道总校验没过。包是传完了，Flash 也写了，但依赖关系不对、签名不对、版本兼容性不对，最后一样起不来。

恢复网络

第一阶段下载结束后，流程并没有自动结束，还要做 STP3，也就是第一阶段的后处理。

标准给了两种常见做法：

发送 ECUReset，让 ECU 做硬复位。
发送 DiagnosticSessionControl，让 ECU 回 defaultSession。

如果前面切过高波特率，这一步通常还承担把通信切回正常模式的职责。也就是说，STP3 不只是“礼貌性退出”，它是在把整个网络从编程状态重新拉回正常状态。

STP4 到 STP6

这部分很多资料都没展开讲，但标准其实说得很明白。

如果第一阶段里做了物理复位，或者某些收尾动作必须等应用软件真正跑起来之后才能做，那就要进入第二阶段。

第二阶段的逻辑很简单：

STP4：重新把网络和 ECU 拉进适合做最终配置的环境。
STP5：执行最终配置，比如清 DTC、写 VIN，或者做其他 OEM 规定动作。
STP6：再做一次复位或回默认会话，把整个编程事件彻底收尾。

这也是为什么量产刷写流程往往不是“下载完成就结束”。下载完成，最多只能说明第一阶段差不多了。真正要把一台 ECU 交付到可运行、可诊断、可追踪的状态，后面这些收尾动作少不了。

Boot software

标准对 boot software 的要求其实很硬。

所有支持应用刷写的可编程 ECU，都应该有独立的 boot software 和 boot memory 分区。这个分区不能因为一次失败的应用刷写就被顺手擦掉，否则 ECU 一旦中途断电、欠压、通信中断，后面连补救机会都没了。

标准明确要求，出现下面这些异常后，ECU 仍然要能恢复并重新编程：

掉电
地线丢失
数据链路中断
过压或欠压

刷写流程允许失败，但 ECU 不能因为一次失败就被刷死。真把 boot 区也一起玩坏了，后面就不是诊断刷写问题了，是返修问题。

三层逻辑

如果只想抓重点，UDS 刷写就关注三层。

第一层是环境层。先把网络和 ECU 拉进可编程状态，这对应 STP1。

第二层是下载层。真正的数据搬运靠 0x34、0x36、0x37，再叠加擦除、写入、分块、校验，这对应 STP2。

第三层是收尾层。下载完以后要复位、回默认会话，必要时再做最终配置，这对应 STP3 到 STP6。

把这三层串起来看，UDS 刷写就不再是“发几个服务把文件灌进去”这么简单了。它本质上是在控制一整次受约束的状态切换：先清场，再写入，再验收，最后把 ECU 和整车网络稳稳送回正常运行状态。

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自：

新势力车企：

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……

内资传统主流车企：

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……

全球领先一级供应商：

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……

二级供应商(500+以上)：

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……

人员占比

公司类型占比

文章

不要错过哦，这可能是汽车网络安全产业最大的专属社区！

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全：TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些？

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：谈思实验室《UDS刷写流程》