引言
GB 44496-2024《汽车软件升级通用技术要求》
GB 44496专注于规范软件升级的整个过程，其检测同样分为管理体系审查和车辆技术测试两部分。
第一部分：软件升级管理体系（SUMS）审查
此部分同样是文件审查和人员访谈，审查车厂是否建立了覆盖软件升级全生命周期的管理体系。内容包括：
- 流程制度：是否有书面化的升级管理流程，覆盖从需求、开发、测试到发布的各环节。
- 版本控制：是否能唯一标识所有软件版本。
- 风险评估：是否有流程评估升级对型式批准、车辆安全等的影响。
- 记录留存：是否有流程确保所有升级活动的信息被记录并安全存储（至少保存至车型停产后10年）。
- 应急管理：是否有处理升级突发事件的应急机制。
第二部分：车辆要求测试（VTA实车验证）
此部分在实车上进行，分为8项通用测试（所有支持软件升级的车辆）和6项在线升级（OTA）附加测试。
8项通用测试（所有升级功能都需测试）
- 升级包真实性与完整性验证：用篡改工具修改升级包，验证系统能否识别并拒绝。这是安全底线。
- 软件识别码（SWIN）读取：通过OBD接口读取ECU的软件识别码，验证是否与申报信息一致。
- 用户告知：核对升级前车机屏幕展示的升级信息（目的、时长、风险等）是否完整准确。
- 用户确认机制：验证升级必须在用户明确确认后执行，不能自动进行；断电重启后不能自动续刷。
- 电量保障：模拟不同电量，验证低电量时系统能否正确拦截升级，且拦截阈值必须保证有足够电量完成升级和回滚。
- 行驶中升级安全：验证车辆在行驶状态下能否被禁止启动OTA升级。
- 兼容性验证：推送不匹配的升级包，验证系统能否识别并拒绝。
- 升级记录可追溯性：升级完成后，检查是否有完整记录（时间、版本变化、结果）。
6项在线升级（OTA）附加测试（仅支持OTA的车辆需测试）
- 多通道用户告知一致性：比对车机、手机APP、短信等不同渠道的升级信息是否完全一致。
- 前置条件检查：验证系统升级前的自检机制是否覆盖了所有强制条件。
- 车门防锁止：这是关键测试项。在升级中模拟多种故障（如断电），验证车内机械解锁能否正常打开车门。
- 升级失败处理与回滚：测试升级中断电、断网等极端情况后，系统能否完整回滚到旧版本或进入安全状态。
- 断点续传：验证升级包下载中断后，能否从断点处恢复，而非重新下载。
- 安全相关功能不受影响：验证在升级过程中及升级后，车辆的安全相关功能是否正常工作。
总结下来：496面向的软件升级，其中牵扯到的东西包括切不仅限于ECU、OTA、软件PIN码识别、软件升级包的真实性、完整性测试；升级结果测试……本博客旨在记录用到的工具和相关的案例（均已做隐私处理）以做后续的参考。
针对升级包需要做以下的测试：
- 真实性
- 完整性
- 在线升级
- 离线升级
真实性
指官方升级包的签名值和篡改后的升级包位数一致，只是其中部分细节有出入。例如：
Base64
官方包：MIIEpAIBAAKCAQEAu1SU1LfVLPHCYZM6s8LqE2j8rDqHnZxQyW3...
篡改后：MIIEpAIBAAKCAQEAu1SU1LfVLABCDM6s8LqE2j8rDqHnZxQyW3...完整性
指篡改后的升级包部分签名值丢失，常常出现在文件损坏、人为恶意破坏等场景。例如：
Base64
官方包：MIIEpAIBAAKCAQEAu1SU1LfVLPHCYZM6s8LqE2j8rDqHnZxQyW3...
篡改后：MIIEpAIBAAKCAQEAu1SU1LfVLM6s8LqE2j8rDqHnZxQyW3...每一个用例都应该有两方面的截图：
- 官方包的升级成功案例
- 官方包的升级过程
- 篡改包的升级失败案例
- 篡改包的升级过程
Winhex
Winhex是经典的二进制编辑工具，在这里主要作用篡改软件升级包的签名值。修改完之后需要和未修改前的升级结果作对比。如果上传篡改包，系统升级失败，证明该条例成功。
例如，针对某品牌车辆的软件升级包，可以通过winhex修改里面的参数，随机篡改（真实性）或添加删除（完整性）
真实性
完整性
后续将该升级包以OTA方式下载或通过车内物理连接传输至车辆，执行升级；检查记录升级结果即可。
针对不同的ECU的后续结果可能都会不同，但显示的“成功/失败”的结果都可以用作测试报告
