还记得上周的“攻防博弈”吗?你刚用安全访问算法骗过了ECU的门禁,拿到了那3次宝贵的“信任票”。
但别高兴太早——门开了,车还没动呢。接下来你要面对的是UDS协议栈里最“暴力”也最讲究技巧的领域:数据刷写。
上个月,我在帮某Tier1调试OTA刷写流程时,遇到了一个诡异的问题:刷写成功率只有70%。每次都在传输中途ECU突然回复0x7F 0x36 0x31(请求超出范围),或者干脆超时无响应。
查了三天,发现是分包策略和流量控制参数没匹配——就像在限速60的高速公路上猛踩油门,车不翻才怪。
今天,我们就来手撕0x34(请求下载)和0x36(传输数据)这对“刷写双雄”。我会用真实刷写Bootloader的案例,带你破解分包传输的流量控制算法,并手写一个支持断点续传的刷写工具。
痛点拆解:为什么你的刷写总失败?
很多新手写刷写工具时,会直接这样写:
# 反例:暴力刷写,不考虑ECU处理能力
def flash_bootloader_naive(data):