图解基于UDS的Flash BootLoader

admin 2023年9月21日10:57:01评论8 views字数 2923阅读9分44秒阅读模式

点击上方蓝字谈思实验室

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


图解基于UDS的Flash BootLoader
图解基于UDS的Flash BootLoader


图解基于UDS的Flash BootLoader

bootloader程序架构


图解基于UDS的Flash BootLoader

略有简化的bootloader图


这张图和恒润教程中的BootLoader流程大体是一致的。


疑问点


Q:图中的烧写顺序是34-36-34-36-34-36-37,但另一些材料中的顺序是34-36-36-36-37。


A:这个问题这样理解,34-36-36-36-37的前提是你要下载的数据是连续的数据,每个36所使用的地址信息,都是34中包含的地址信息再加上一定的偏移量。


如果需要下载不连续的数据,就需要重新进行34服务或31(擦除)-34服务。



图解基于UDS的Flash BootLoader


为什么要搞Bootloader?


为什么要基于UDS搞Bootloader


假如你的控制器有外壳,却没有设计bootloader的话,每次更新ECU的程序,你都需要把外壳拆开,用烧写器来更新程序。有了bootloader,你就可以通过CAN线来更新程序了。更方便些的话,甚至可以通过OTA进行远程升级。


那为什么使用UDS呢?主要是为了规范bootloader的全过程。比如烧写小明牌ECU时,我们肯定希望其他牌子的ECU处于一个静默的状态,都歇一歇,这就需要一个大家共同执行的标准来进行规范,什么时候停发数据,什么时候不能再储存DTC了等等。


又比如在调试时,大家肯定希望你的控制器经由CAN烧写的过程是大家都能看得懂的,是满足于某种规范的。由此,UDS在设计时考虑了bootloader的需求,专门为bootloader设计了几个服务,供大家使用。主机厂在发需求时自然就要求大家要在UDS规范的基础上完成bootloader功能了。



图解基于UDS的Flash BootLoader


Bootloader应支持的UDS服务


显然bootloader不需要支持19/14等故障类服务。


在boot程序中,10/27/11/3E这样的基础诊断服务需要支持,22/2E读写DID的服务需要支持,31/34/36/37这4个bootloader主打服务需要支持,共10个。


在app段程序中,85和28服务需要支持,保证暂停CAN正常通信,暂停记录DTC,让被升级设备专心升级。


图解基于UDS的Flash BootLoader

10种boot段服务+2种app段服务



图解基于UDS的Flash BootLoader


Bootloader——三段式


(1)预编程阶段


1. 3E TP报文。


2. 10服务切换到03扩展模式。


3. 85服务和28服务,关DTC和非诊断报文。使整个CAN网络处于安静的状态。这是对整车网络进行操作的,一般都是以功能寻址的方式来发送。注意先用85服务关闭DTC,再使用28服务关报文。


图解基于UDS的Flash BootLoader

(2)主编程阶段


1. 10服务切换到编程模式,这里要注意,正确的方式是App段程序回复0x78 NRC,接下来跳转到boot段程序,最后由Boot段程序来回复10 02的肯定响应。错误的方式是由App段回复10 02的肯定响应,再进行跳转。


2. 读取一个DID,tester要判断一下返回值。返回值里面可能包含密钥的一部分信息。


3. 27服务,解锁,通过安全验证。


图解基于UDS的Flash BootLoader

注意10 02服务不应直接进行肯定响应,存在风险


图解基于UDS的Flash BootLoader


4. 写DID指纹,标记写软件人的身份,ECU回复写指纹成功。(根据OEM要求来执行)


5. 31服务-擦除Flash。ECU肯定响应,擦除成功。


6. 34服务,请求数据下载,ECU回复确认最大块大小。


7. 36服务,开始传输数据。每个块传输完成后,ECU肯定响应。判断是否还有更多块需要下载。最多可以支持255个块。


8. 37服务,请求退出传输。ECU肯定响应。


9. 31服务-校验APP段程序,检查编程一致性/完整性。ECU肯定响应。校验成功。


10. 若有更多块需要下载,重新执行31(擦除Flash区域)-34-36-37-31(校验)服务。若无,往下执行。


11. 11服务,ECU复位。之后应直接跳转到新下载的APP段程序中。


图解基于UDS的Flash BootLoader

31(擦Flash)-34-36


图解基于UDS的Flash BootLoader

36-37-31(校验)


(3)后编程状态


1. 10服务切换到03扩展会话。


2. 执行28服务和85服务,使能非诊断报文和DTC。这是对整车网络进行操作的,一般都是以功能寻址的方式来发送。注意先执行28,后执行85,避免DTC误报。


图解基于UDS的Flash BootLoader

3. 27服务,安全校验,准备写入数据。


4. 2E服务,将编程信息写入到ECU中。


5. 10服务,退回01默认会话。结束。


图解基于UDS的Flash BootLoader



图解基于UDS的Flash BootLoader


BootLoader的启动顺序与转换流程


以下流程仅作为参考,有很多不规范之处。欢迎大家留言探讨。


1. ECU上电或复位后,先进入Boot段。从Flash/EEPROM中读取 App有效标志,运行boot标志 。


2.判断 运行boot标志 ,若为1,则进入Boot段的编程会话(安全等级为上锁),之后写Flash/EEPROM(不安全操作), 运行boot标志 清零。若S3定时器超时则退回Boot段默认会话。


3. 经过安全访问进入Level2解锁状态,开始执行App内存擦除,擦除后 App有效标志 清零(不安全操作)。


4. 开始烧写。烧写成功后 运行boot标志 写0,App有效标志 写1。


2*. 判断 运行boot标志 ,若为0,则进入Boot段的默认会话。


3*. 50ms后判断 App有效标志 ,若为1,则 跳转到 App段默认会话。实现时使用汇编指令执行APP段程序;若为0,退回Boot段默认会话,且不再判断 App有效标志,不会再尝试进入App段。


4*. App段程序若收到了编程会话请求, 运行boot标志写1 ,随即执行ECU复位,这样会重新进入boot段程序。


注:从BOOT跳入APP前需要判断APP的数据完整性,例如进行CRC校验。



图解基于UDS的Flash BootLoader


问题点


Q:假如烧进去了不良App段程序,无法返回boot段程序怎么办?


A:参照电脑的开机方式,在ECU开机之后,预留很短的一段时间维持在boot状态,在这段时间内,若收到指定报文(比如,电脑是按住F8),那么就不跳转到App段了。


Q:运行boot标志和App有效标志为了安全起见,应该保存到哪里?


A:运行boot标志可以放置在RAM中,由Boot和App共用。


Q:上文图中的CAN数据实例,为什么出现了两次CRC的校验?CRC校验是对哪些数据的校验?


A:OEM不希望ECU中保存有可以擦写Flash的代码,所以BootLoader需要在烧录App之前,先把擦写Flash的代码通过UDS烧写到RAM中,烧完了之后进行一下31服务下的CRC校验。之后烧录ECU的App程序,App可能会因为地址不连续而分为很多段下载。下载完毕后需要进行总的CRC校验。不管哪次校验,CRC所校验的数据是代码的数据段,即36服务中传输的有效数据。


来源:汽车ECU开发

更多文章

智能网联汽车信息安全综述

华为蔡建永:智能网联汽车的数字安全和功能安全挑战与思考

汽车数据合规要点

车载以太网技术发展与测试方法

车载以太网防火墙设计

SOA:整车架构下一代的升级方向

软件如何「吞噬」汽车?

汽车信息安全 TARA 分析方法实例简介

汽车FOTA信息安全规范及方法研究

联合国WP.29车辆网络安全法规正式发布

滴滴下架,我却看到数据安全的曙光

从特斯拉被约谈到车辆远程升级(OTA)技术的合规

如何通过CAN破解汽

会员权益: (点击可进入)谈思实验室VIP会员


图解基于UDS的Flash BootLoader


图解基于UDS的Flash BootLoader

原文始发于微信公众号(谈思实验室):图解基于UDS的Flash BootLoader

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年9月21日10:57:01
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   图解基于UDS的Flash BootLoaderhttp://cn-sec.com/archives/2053246.html

发表评论

匿名网友 填写信息