前言

后面想开源一个智能汽车安全的学习项目，用 Qt 整车模拟(这个有点难)或者汽车零部件模拟(大概率做这个)，即使需要用到硬件也不会非常贵，以便降低车联网安全学习门槛，帮助后来者学习。本篇讲一些入门知识，了解一下车联网安全的整体架构。本文带大家整体入门车联网安全，后续每个分支会做详细的研究。

基础篇

网联汽车

联网的车(Connected Car):又称网联汽车，即这些车具有网络连接功能，通常还具有Wi-Fi热点功能用于和其他设备分享车载网络连接。具有网络连接功能的汽车通常还会扩展出其他功能来充分利用网络连接带来的优势，例如车祸自动报警求救、远程控制、远程升级[Over the Air(OTA)Update]、安全预警等。车联网表示车辆接入网络，这个网络不仅包含传统的互联网，还拓展了新的领域——**V2X(Vehicle To Anything)**。V2X是无人驾驶的关键技术，行驶中的车辆通过V2X技术与外界不间断地进行通信，感知周边环境的变化，对不同的行车环境作出响应，以保障行车的舒适度与安全性。

车联网包含智能化和网联化两大技术路径，协同实现“信息感知”和“决策控制”功能。

（1）智能化：依赖高级辅助驾驶系统ADAS，采用车载传感器与汽车自动控制系统相结合的方法实现汽车的自动巡航（ACC）、自动泊车（APS）及自动紧急刹车（AEB）等一系列功能。目前，新上市的车辆大多具有自动紧急刹车系统（AEB）和车道保持辅助系统（LKA），并能实现人车互联。

（2）网联化：依靠搭载车联网V2X通信系统，进一步实现车-人、车-车、车-路、车-云的信息交换，实现汽车行驶的安全性、提高道路通向效率等，并最终实现无人驾驶。

现阶段处于车联网阶段的早期，V2X在特殊场景中得到应用，现在提到更多的是智能网联汽车。智能网联汽车还不具备完整的车路协同能力，属于单车智能。智能网联汽车具有丰富的信息娱乐系统，支持远程控制车辆等功能。智能网联汽车的明显特征是支持OTA（Over The Air，空中下载技术）。汽车通过OTA拥有了更多的可能性，通过OTA可以给车辆添加新功能、修复软件中存在的缺陷等。但随着汽车智能化的程度不断加深，信息安全问题也日益凸显。车联网广义上仍然可以按照物联网设备划分为“云-管-端”架构。

（1）“云”指的是车联网后端服务，由车企或内容服务商为车载终端提供服务的云端合集。云端提供的服务包括OTA、远程终端、信息娱乐、导航等。车联网云端的安全与其他领域的云端安全并无太大差异。云端依旧存在信息泄露、远程命令执行、SQL注入等威胁。

（2）“管”指的是云端与终端之间数据传输的管道，在车联网中专有网络与公共网络并存。敏感性较低的数据采用公共网络传输，敏感程度较高的数据（如车辆控制）采用专有网络传输。数据传输格式部分采用专有标准协议，如电动汽车与管理系统之间的通信协议采用GB/T 32960.3—2016《电动汽车远程服务与管理系统技术规范第3部分：通讯协议及数据格式》中的通信协议及数据格式、道路运输车辆采用JT/T 808—2019《道路运输车辆卫星定位系统终端通讯协议及数据格式》，与云端通信。此外，在车联网行业中广泛存在自定义的协议。在管道中，主要研究对象是通信协议，通信协议需要保障数据机密性，防止数据泄露或被篡改。

（3）“端”指的是车联网靠近消费者的终端设备，不仅仅是车辆本身，还有充电桩、车载单元(On Board Unit, OBU)、路测单元(Road Side Unit, RSU)等终端。

V2X通信

V2X(Vehicle to X)通信：表示车与X通信，X可以是车(Vehicle)、路(Road)或者其他相关基础设施，相应地也就有了V2V(Vehicle to Vehicle,车与车通信)、V2I(Vehicle to Infrastructure,车与基础设施如道路、服务器等通信)、V2P(Vehicleto Pedestrian,汽车与行人通信)等概念。V2X的典型应用有左转辅助、紧急刹车提示、闯红灯警告、过弯速度警告、施工路段提醒、实时天气信息提醒等。

高级辅助驾驶系统（ADAS）

高级辅助驾驶系统(ADAS,Advanced Driver Assistance System):ADAS是在驾驶过程中辅助驾驶员的系统，它的功能包括安全告警功能、自适应控制功能、信息提示功能等，可在通过传感器检测到可能的危险时对驾驶员发出告警或者接管汽车某些控制功能（比如紧急刹车功能），以及根据环境自动对汽车的某些功能进行控制，比如根据环境亮度自动调节车灯亮度、自适应巡航控制、盲点警告、自动变道等。
ADAS技术通常依赖于各种传感器和通信技术，例如依赖雷达或者摄像头检测与前车的距离，依赖V2V获取附近车辆信息，依赖摄像头检测车道等。根据《道路车辆先进驾驶辅助系统（ADAS）术语及定义要求》，ADAS可以分为信息辅助与控制辅助两大类别。

TBOX

TBOX是智能网联汽车上用于联网的重要模块，又名T盒、车载无线终端等，国外一般称之为TCU（Telematics Control Unit，远程信息控制单元）。上端与TSP(Telematics Service Provider)服务器相连，下端通过CAN总线等与汽车其他模块相连。国内的TBOX需要满足GB/T 32960—2016系列标准对新能源汽车的监控要求，并提供远程控制、车辆故障诊断、OTA升级、网络共享、蓝牙钥匙、载荷分析等功能。

TBOX通常是一个黑色的盒子，由于需要和其他部件相连，因此对外的接口较多，大体上可以分为3种：天线、通信接口以及电源。天线有蜂窝网络天线、Wi-Fi天线、GNSS天线、FM广播天线、蓝牙天线等。接口有USB、Ethernet、CAN、UART等。对外的接口有一定的外观特征，如天线一般采用FAKRA连接器，USB一般使用HSD连接器。

FAKRA连接器用于射频模拟/数字信号的同轴连接系统，支持高达6 GHz数据传输频率。2000年，以德国车厂为首的车厂，共同推出了一种汽车专用的音响与天线规格接头，后来推广至具有射频特性传输信号的功能，如视频、导航、蜂窝网络、Wi-Fi、摄像头、V2X等。FAKRA一般采用同轴电缆，单线单芯。不同颜色的连接器外形存在差异，使用场景也有所不同，例如蓝色用于GNSS、紫色用于蜂窝网络等。通过这种特性，人们能够根据颜色和外观的差异快速判断接口用途。

高速数据(High-Speed Data, HSD)接口专为汽车市场设计，支持高达6GHz的数据传输频率，支持USB、LVDS、Ethernet等协议的传输，适用于信息娱乐模块和显示装置等应用。HSD连接器型号较多，单腔HSD一般采用4芯。HSD连接器通常与Fakra、Mini-Fakra配合使用。

拆开TBOX会发现，里面使用的芯片并不多，结构相对简单。一般采用两种方案，区别在于通信模组是否具备SoC的功能。第一种是SoC与通信模组分离的方案，SoC本身不具备通信功能，需要通过通信模组与外部通信。这种方案以前使用得较多，现在更多的是采用集成方案。第二种是集成方案，将SoC和通信模组的功能封装到一起。采用这种方式的芯片有移远通信的EC20、慧翰微电子的FLC-MCM630、华为的巴龙MH 5000等。

在SIM卡方面，大部分TBOX采用eSIM卡，也有部分使用普通可插拔的SIM卡。除此之外，一般TBOX上还有一个MCU模块，MCU的功能比较单一，主要负责与CAN总线进行通信。

T-BOX的使用

对TBOX的基本认识是从盒子上的标签开始的，从标签可以得到供应商、硬件版本、CMIIT ID（无线电发射设备型号核准代码）、FCC ID、IMEI、ICCID、进网许可证等信息。还可以根据CMIIT ID/FCC ID查询更多的信息。从这些信息中可以形成对TBOX的初步认识，为后续分析奠定基础。标签的样式各不相同，提供的信息也有多有少。

图中有两个标签，左边的是TBOX的基本信息，右边的是进网许可证。从这两个标签中可以看出，这是奔驰汽车上的一个TBOX，制造商为Harman，型号为HERMES 1.5 CN。通信方面，这个TBOX支持蓝牙、Wi-Fi、蜂窝网络。标签中有蓝牙标志意味着支持蓝牙通信。标签中给出了WLAN-MAC：746FF7091E2E。这意味着支持Wi-Fi，根据MAC地址通过组织唯一标识符查询到模块的供应商为启基科技股份有限公司。另外，如果Wi-Fi隐藏了SSID，可以通过标签上的MAC地址找到对应的SSID。根据右边的进网许可证也能获取一些设备信息，作为左侧标签的补充。在中华人民共和国工业和信息化部网站中，查询进网许可证编号“17-B884-171643”。

车机

车机一般采用分离式结构，显示屏与主机分离。采用分离式结构有利于拓展显示，顺应当下汽车智能化的浪潮，越来越多的车企为新推车型配备更大更多的屏幕。有的车型甚至会用到3块及以上的屏幕，通过视觉冲击满足消费者对智能汽车的追求。车机上的多屏幕显示与电脑多屏幕显示有所差异，大多不是简单的分屏显示，每一个屏幕都是通过虚拟技术生成的，使用较多的车载虚拟化方案有QNX Hypervisor、COQOS Hypervisor、ACRN等。

主机方面一般采用SoC（System on Chip，片上系统）与MCU搭配使用，SoC负责提供信息娱乐，而与车身总线的交互一般由MCU实现。MCU具备一路或多路CAN总线，车机对空调、车窗的控制通过MCU传递给CAN总线，对应的部件执行相应的操作。接口一般有USB接口、收音机天线接口、导航定位天线接口、多组CAN接口、扬声器接口、A2B车载音频接口、调试串口等。

车机中SoC一般采用虚拟化技术将系统分割为多个独立的子系统，底层一般使用AGL(Automotive Grade Linux)或QNX系统。AGL是Linux基金会维护的开源车载操作系统，采用Linux内核，通过开源技术栈加快汽车制造商、供应商以及科技公司的开发进程。AGL划分为应用层、应用框架层、服务层以及操作系统层。AGL通过对服务进行抽象，提供便捷易用的接口。QNX是由Blackberry公司推出的分布式实时操作系统，与AGL的开源方式不同，QNX采用闭源方式，使用前需要得到Blackberry公司的授权。蔚来汽车ES8搭载的NIO OS便是基于QNX开发的。

车机是一个相对封闭的系统，用户的自由度相对较低，默认状态下不能任意安装第三方应用。车机底层操作系统负责与MCU之间的通信，通过MCU间接接入车身总线。底层操作系统还为人机交互的信息娱乐系统提供运行环境，通过虚拟化技术运行Android操作系统。由于Android系统生态完整、应用丰富，国内多数车机采用Android作为人机交互系统。车企通过深度定制车机操作系统建立自己的生态，如吉利汽车的GKUI、比亚迪的DiLink等。

充电桩

充电桩结构

充电桩按充电方式可以分为直流充电桩、交流充电桩。直流充电桩是固定安装在电动汽车外，与交流电网相连，为电动汽车动力电池提供直流电源的供电装置。交流充电桩是固定在电动汽车外，为电动汽车供能的装置，但不具备充电功能，需要连接车载充电机才能为电动汽车充电。直流充电桩的充电效率比交流充电桩的充电效率高，使用更加广泛，下文提到的充电桩均表示直流充电桩。不同充电桩的外形和结构有差异，下面以国家电网的“A型一体充电机”为例，讲解充电桩的结构。

充电桩由TCU（Tariff and Control Unit，计费控制单元）、充电主控模块、功率控制模块、开关电源、散热系统、充电枪、液晶显示屏等部分组成。TCU如图11-31所示，外围接口丰富，集成串口、CAN、工业以太网、SIM卡槽、音频、LVDS等接口，并支持北斗定位、蜂窝通信等功能，可实现充电桩人机交互、计费计量、支付、数据加解密、控制充电设备、与车联网平台通信等功能。

TCU是充电桩的核心，也是我们研究的主要对象。从图11-32中可以了解TCU的数据外围交互。TCU配备两个外插式标准SIM卡槽，充电桩主要通过蜂窝网络与车联网平台相连。

人机交互方面，TCU通过LVDS或并口连接支持触屏操作的液晶显示器，用户通过显示屏与充电桩交互完成充电过程，同时也可以通过显示器配置和维护充电桩。可选的充电付费方式很多，包括扫描二维码、刷卡、输入个人账号等。读卡器与TCU采用RS232通信。在电量计费时，使用多功能电表进行电量测算，TCU通过RS485与电表通信并读取消耗的电量值。TCU与充电设备控制器通过CAN总线进行通信，通信协议为BMS。调试接口方面，TCU提供了丰富的调试接口，如RS232、RJ45、UART等。

了解TCU的组成结构之后，还需要知道充电插头的定义。

充电桩与电动汽车之间采用CAN总线通信，CAN_H位于充电插头的S+，CAN_L位于充电插头的S-。

充电协议

电动汽车充电机与电池管理系统(Battery Management System, BMS)之间的通信基于CAN协议，通信数率为250kbit/s，使用29bit标识符的CAN拓展帧，通信地址固定，任何手段都不能改变，充电机地址为86(56H)，BMS地址为244(F4)。每个CAN数据帧包含一个单一的协议数据单元(Protocol Data Unit, PDU)。协议数据单元由七部分组成，分别是优先权、保留位、数据页、PDU格式、PDU特定格式、源地址和数据域。

第一行表示数据位，第二行表示数据说明，第三行表示位数，数据格式说明如下。

P为优先权，从最高0到最低7。
R为保留位，留作今后开发使用，本标准中为0。
DP为数据页，用来选择参数组描述的辅助页，本标准中为0。
PF为PDU格式，用来确定PDU的格式，以及数据域对应的参数组编号。
PS为PDU特定格式，PS的值取决于PDU格式，在本标准中PS的值为目标地址。
SA为源地址，发送此报文的源地址。
DATA为数据域，若给定参数组数据长度≤8字节，按单帧传输。若给定参数组数据长度为9～1785字节，数据传输需多个CAN数据帧,通过传输协议功能的连接管理能力来建立和关闭多包参数组的通信。

整个充电过程包括6个阶段：物理连接、低压辅助上电、充电握手阶段、充电参数配置阶段、充电阶段和充电结束阶段。更多内容详见GB/T 27930—2015《电动汽车非车载传导式充电机与电池管理系统之间的通信协议》。

IVI

参考链接

IVI（In-Vehicle Infotainment）是指安装在汽车中的信息娱乐系统。它是集成了多种功能和服务的电子设备，旨在提供丰富的娱乐、信息和通信体验。其实对于这个除了IVI之外还有很多名字，比如

Head Unit (HU): Head Unit是指车辆中心控制单元，它是车机系统的主要组成部分。Head Unit通常位于车辆的仪表板上，集成了多媒体功能、导航系统和控制界面。
Infotainment System: Infotainment系统是指整合了信息和娱乐功能的车载系统。它提供了音频、视频、导航、通信等功能，旨在为驾驶员和乘客提供全面的娱乐和信息体验。
中控屏
……

ECU

参考链接

汽车互联互通的快速发展为新功能和创新的商业模式提供了许多机会。与此同时，汽车网络受到黑客攻击的可能性也在增加。此类攻击威胁到车辆的功能安全(Safety)，并可能造成经济损失。AutoSAR标准为运行在ECU上的软件定义了基本的软件功能和接口，确保车辆在出厂时就具备必要的安全防护和检测能力。现代车辆E/E架构不断发展,但总体来看，无论E/E架构如何发展，ECU还是可以简单的划分为两大类型：

CP(Classic Platform):计算能力、存储空间大小、网络带宽等都通常十分有限，而实时性要求又很高，这类ECU通常要求部署轻量级的安全措施，重点解决运行在ECU上的软件和网络报文的完整性和真实性。
AP(Adaptive Platform):各类资源相对丰富。可以提供更多的资源给Security，因此可以部署一些入侵检测特性以及整车安全管理类的特性。未来E/E架构越来越走向融合的道路，整车的核心功能会集中在少量的高性能计算芯片中，有的文献中成为汽车计算机(Vehicle Computer),我们仍然归类为AP类。

CAN

参考链接

CAN是车辆网络通信中最常用的协议之一。然而，原始的CAN协议没有内置的安全机制，因此现代车辆通常使用CAN协议的安全扩展，如CAN-FD (CAN with Flexible Data-Rate) 和CAN-XCP (CAN with Extended Calibration Protocol) 来增加安全性。

CAN协议的特点包括：

可靠性：CAN使用冗余机制和错误检测与纠正技术，确保通信的可靠性。它具有错误检测和错误响应机制，可以检测和处理通信中的错误。

实时性：CAN协议设计用于实时控制应用，具有高效的消息传输机制和低延迟特性。

简单性：CAN协议相对简单，易于实现和部署。它使用广播通信和基于标识符的消息过滤机制。

然而，原始的CAN协议存在一些安全性挑战，如缺乏身份验证和加密机制，容易受到欺骗和中间人攻击。为了提高CAN协议的安全性，现代车辆通常使用CAN的安全扩展协议，如CAN-FD（CAN with Flexible Data-Rate）和CAN-XCP（CAN with Extended Calibration Protocol）。这些扩展协议提供了额外的安全特性，如消息认证、数据完整性保护和加密。

安全风险：

CAN总线攻击：黑客可能通过篡改或伪造CAN消息来影响车辆的正常运行，如操纵刹车系统或引擎控制。
数据注入：黑客可能注入虚假的CAN消息，导致车辆系统做出错误的决策或操作。

实际案例：

Jeep漏洞（2015年）：黑客成功利用CAN总线上的漏洞，远程控制了一辆Jeep车辆，包括刹车和方向盘等功能。
Tesla Model S攻击（2016年）：黑客通过CAN总线入侵了特斯拉Model S，实现了远程控制车辆的各种功能。

LIN

LIN 总线协议用于车辆中低速数据传输，如门控、照明和仪表板等。LIN本身并没有提供强大的安全性，因此在需要更高安全级别的应用中，可以结合其他安全通信协议使用。

LIN协议的特点包括：

成本效益：由于LIN协议的较低速率和简单性，它在成本上更具有竞争力。它适用于车辆中的简单控制和监测任务。

简单性：LIN协议相对简单，易于实现和部署。它使用主-从架构，其中一个主节点控制多个从节点。

然而，与CAN相比，LIN协议在安全性方面的功能有限。它没有内置的加密和身份验证机制，因此在需要更高安全级别的应用中，可以结合其他安全通信协议使用，如CAN-FD和LIN的安全扩展。

综上所述，CAN和LIN是车辆通信中常见的协议。CAN主要用于高速、实时控制的通信，而LIN主要用于低速、简单控制的通信。为了提高安全性，现代车辆通常采用CAN和LIN的安全扩展协议，以增加安全特性和保护通信免受攻击。

安全风险：

欺骗攻击：黑客可能冒充合法的LIN设备，与车辆中的LIN网络进行通信并执行恶意操作。
窃听攻击：黑客可能窃听车辆中的LIN通信，获取敏感信息，如车辆控制指令或传感器数据。

实际案例：

BMW i3攻击（2018年）：黑客通过LIN总线入侵了一辆BMW i3电动汽车，成功控制了车辆的门锁和车窗等功能。
福特Focus攻击（2019年）：黑客通过LIN总线攻击了福特Focus车辆的车窗控制系统，成功实现了远程开启和关闭车窗。

MOST

MOST (Media Oriented System Transport) 面向媒体的系统传输总线，MOST 是汽车业合作的成果，而不具备正式的标准。它是一种专门针对车内使用而开发的、服务于多媒体应用的数据总线技术。MOST 表示“多媒体传输系统”。

MOST总线工作原理

MOST 总线利用光脉冲传输数据，采用环形结构，在环形总线内只能朝着一个方向传输数据。MOST 总线的传输技术近似于公众交换式电话网络（ Public Switched Telephone Network；PSTN），有着数据信道（Data Channel）与控制信道（Control Channel）的设计定义，控制信道即用来设定如何使用与收发数据信道。一旦设定完成，资料就会持续地从发送处流向接收处，过程中不用再有进一步的封包处理程序，将运作机制如此设计，最适合用于实时性音讯、视讯串流传输。MOST在制订上完全合乎ISO/OSI的7层数据通讯协议参考模型，而在网线连接上MOST采用环状拓朴，不过在更具严苛要求的传控应用上， MOST也允许改采星状（亦称放射状）或双环状的连接组态，此外每套MOST传控网络允许最多达64个的装置（节点）连接。

基于MOST总线的车载音频娱乐系统原理图MOST总线专门用于满足要求严格的车载环境。这种新的基于光纤的网络能够支持24.8Mbps的数据速率，与以前的铜缆相比具有减轻重量和减小电磁干扰(EMI)的优势。同时，MOST也支持随插随用机制。

FlexRay

FlexRay是一种高速车辆网络通信协议，用于高带宽和实时性要求较高的系统，如刹车、转向和悬挂控制。FlexRay提供了一些安全机制，例如消息认证和数据完整性保护。

FlexRay协议的特点包括：

高带宽和灵活性：FlexRay支持高达10 Mbps的通信速率，能够满足车辆系统中对大量数据传输的需求。它还提供了灵活的网络配置选项，允许多种通信拓扑结构。

实时性：FlexRay使用时间分隔多路访问 (Time Division Multiple Access, TDMA) 技术，通过将通信周期划分为固定的时间槽，实现严格的实时通信。这对于需要高精度和可靠性的车辆控制系统至关重要。

安全性：FlexRay提供了消息认证和数据完整性保护的机制，以保护通信数据的安全性。它使用消息认证码 (MAC) 和数据签名等技术来验证消息的真实性和完整性。

安全风险：

消息干扰：黑客可能干扰FlexRay消息传输，导致通信错误或消息丢失，影响车辆的实时性和可靠性。
信息窃取：黑客可能窃取FlexRay通信中的敏感信息，如自动驾驶系统的指令或传感器数据。

实际案例：

福特Escape漏洞（2013年）：黑客通过FlexRay总线入侵了福特Escape车辆，成功控制了车辆的刹车和加速等功能。
捷豹路虎漏洞（2016年）：黑客利用FlexRay总线的漏洞入侵了捷豹路虎车辆，成功控制了车辆的转向和刹车等功能。

Ethernet：

以太网在车辆领域的应用越来越普遍，特别是用于高带宽的数据传输和车辆内部的通信。为了增强安全性，车辆中使用的以太网通常采用了安全扩展，如Ethernet AVB (Audio Video Bridging) 和 TSN (Time-Sensitive Networking)。

Ethernet协议的特点包括：

Ethernet AVB (Audio Video Bridging)：Ethernet AVB是一组用于音频和视频传输的标准，旨在提供严格的实时性和同步性。它具有流量调度和时钟同步机制，以确保高质量的音视频传输，并为车载娱乐和车载通信系统提供更好的用户体验。

TSN (Time-Sensitive Networking)：TSN是一组扩展以太网标准，旨在满足对实时性和可靠性要求较高的应用的需求。它提供了严格的时间同步和流量调度机制，支持车辆中对高实时性通信的要求，如自动驾驶和高级驾驶辅助系统。

安全风险：

网络入侵：黑客可能通过网络入侵车辆的以太网系统，获取未经授权的访问权限，并对车辆进行恶意操作或数据窃取。
远程攻击：黑客可能通过远程连接到车辆的以太网系统，利用系统漏洞或弱点来入侵车辆并控制其功能。

实际案例：

远程攻击特斯拉（2016年）：黑客通过特斯拉车辆的以太网接口入侵了车辆，成功控制了车辆的门锁、仪表盘和行驶系统等功能。
远程攻击大众汽车（2019年）：黑客通过大众汽车的以太网接口入侵了车辆，成功控制了车辆的中央控制单元和仪表盘等功能。

ASec

ASec是一套在汽车以太网中实施安全性的标准和协议。它包括对消息认证、数据完整性、访问控制和安全密钥管理的支持。

Auto motive Ethernet Security （ASec）协议的特点包括：

消息认证和完整性保护：ASec提供了对消息的认证和数据完整性保护的机制。它使用加密算法和数字签名来确保消息的真实性和完整性，防止消息被篡改或伪造。

访问控制：ASec定义了访问控制机制，以确保只有经过授权的设备和实体可以访问车辆的以太网系统。它可以基于身份验证、访问权限和角色分配等策略进行访问控制。

安全密钥管理：ASec提供了安全密钥的生成、分发和管理机制，以确保密钥的机密性和安全性。密钥管理是实施安全通信的重要组成部分，用于加密和解密通信数据。

安全风险：

密钥破解：黑客可能尝试破解ASec协议中使用的加密密钥，以获取对车辆通信的未经授权的访问权限。
信息篡改：黑客可能篡改ASec协议中的安全认证和完整性保护机制，以修改或伪造车辆通信中的消息。

实际案例：

车辆远程入侵攻击（2019年）：黑客通过ASec协议的漏洞，成功远程入侵了车辆的以太网系统，获取了车辆的敏感信息和控制权。

GW

参考链接

汽车网关(Automotive Gateway) 可以简单形象地理解为翻译官，作为整车网络的数据交互枢纽，是整车电子电气构架中的核心部件，使数据在车辆内部的多个网络(CAN、LIN、MOST、FlexRay等) 中安全可靠得进行传输是其核心功能。网关作为汽车网络系统的核心控制装置，负责协调不同结构特征的CAN总线网络和其他数据网络之间的协议转换、数据交换、故障诊断等工作。整车电子电气构架可以基于网关而更加优化，网关也可以提高整车拓扑结构的可扩展性和整车的安全性，整车网络数据的保密性也可以得到加强。

BMS

参考链接

BMS电池管理系统（BATTERY MANAGEMENT SYSTEM）俗称电池保姆或电池管家，主要就是为了智能化管理及维护各个电池单元，防止电池出现过充电和过放电，延长电池的使用寿命，监控电池的状态。

BMS电池管理系统单元包括BMS电池管理系统、控制模组、显示模组、无线通信模组、电气设备、用于为电气设备供电的电池组以及用于采集电池组的电池信息的采集模组，BMS电池管理系统通过通信接口分别与无线通信模组及显示模组连接，所述采集模组的输出端与BMS电池管理系统的输入端连接，所述BMS电池管理系统的输出端与控制模组的输入端连接，所述控制模组分别与电池组及电气设备连接，BMS电池管理系统通过无线通信模块与Server服务器端连接。

车联网攻击面

车联网合规要求

车联网安全面检测

竞赛篇

线上赛

车联网竞赛的赛制和内容也在不断发生着变化，常见的分项赛有云平台夺旗赛、车载信息娱乐系统漏洞挖掘、总线逆向破解等。车联网安全竞赛相对于当下应接不暇的CTF赛事还是比较少的，也有一些赛事连续举办多年，如世界智能驾驶挑战赛、汽车安全与召回技术论坛上举办的车联网安全攻防挑战赛等。

随着汽车电气系统日趋复杂，传统电气系统的点对点通信方式已无法满足通信需要，汽车总线便应运而生。在现代的汽车构造中有多种总线，不同的总线对应不同的使用场景。

LIN

**LIN（Local Interconnect Network，局域互连网络)**是一种低成本的串行通信网络，是对汽车多路网络的补充。LIN总线的最高传输速率为20kbit/s，主要用于对速度不敏感、对带宽要求不太高的子系统，如车窗、灯光、电动座椅等。
CAN

CAN（Controller Area Network，控制器局域网络）是一种应用于实时环境的串行通信网络，是汽车中使用最为广泛的总线网络，主要用于车身控制，提供电子控制单元与启停系统、驻车辅助系统与电子驻车制动器传感器之间的通信等。CAN总线的最高传输速率为1Mbit/s，协议本身能够保障数据的完整性与实时性。由于标准CAN总线携带的数据量较少，随着汽车网络传输的数据量不断攀升，在CAN的基础上衍生出了CAN-FD(CAN with Flexible Data rate)。CAN-FD与CAN相比，数据传输速率更大、有效数据场更长。车载以太网是一种基于以太网的专门用于汽车领域的通信技术，主要用于故障诊断、车载信息娱乐系统和高带宽传感器的连接。
车载以太网

车载以太网是一种基于以太网的专门用于汽车领域的通信技术，主要用于故障诊断、车载信息娱乐系统和高带宽传感器的连接。
FlexRay

由于CAN总线通信方式不能满足新兴的驾驶辅助功能，如ABS防抱死系统、ASR驱动防滑系统、ESP电子稳定系统等涉及汽车主动，被动领域的高要求辅助功能，需要更多的交互节点，更高的传输带宽，对汽车通信系统的可靠性、安全性、实时性提出更高的要求；
MOST

MOST（Media Oriented Systems Transport），是一种面向多媒体数据传输的总线。上个世纪 90 年代，MOST 是由 ABB 等一众著名整车厂共同研制而成用来传输车载多媒体数据的总线，并制定了相关的标准和协议，现由 Mircochip 维护管理。根据 MOST 总线的来源可以看出，MOST 总线生来就是为车载多媒体数据服务的，而以太网则不同，以太网则是先制定相关的传输协议，不针对特定应用。

另外，从技术上来讲，以太网的终端设备基本都是非同期的，发送也是自由的；而 MOST 是时钟完全同期的，都是主设备过来的，发送时月票式的，带宽有保证。而同样作为汽车四大总线之二的 CAN 和 LIN 由于传输带宽的原因，也不便用于多媒体数据的传输。

所以，综合背景下，MOST 就诞生了并广泛应用于车载多媒体数据的传输。
A2B

Analog Devices Inc. A2B®（汽车音频总线）是一款高带宽、双向、数字音频总线，为音频设计提供更简单、更方便的解决方案。A2B能够用一条双线UTP（非屏蔽双绞线 Unshielded Twisted Pair）电缆传输I2S/TDM/PDM数据和I2C控制信息以及时钟和电源，节点间距离最长15米，整个菊花链最长40米。A2B可用作其自己的网络，具有嵌入式子网络，或者搭配其他较长距离协议用作端点传输总线。单个A2B网络中所有节点上的时钟均同步。系统中每个节点同时接收麦克风和串行音频数据。

CAN总线协议 1 讲

CAN协议的国际标准为ISO 11898，通信速率为5kbit/s～1Mbit/s。CAN报文由帧起始、仲裁段、控制段、数据、CRC校验段、帧结束组成，CAN ID位于仲裁段，标准帧的ID长度为11bit，拓展帧的ID长度为29bit，无论在标准帧还是在拓展帧中，数据的长度都是8字节。

CAN协议有两种帧结构——标准帧和拓展帧。ID长度为11bit的是标准帧，ID长度为29bit的是拓展帧。在比赛中以标准帧为主，拓展帧使用得相对较少。如果是刚接触总线协议分析的人，只需要知道CAN数据帧由ID、DLC（Data Length Code，数据长度）、数据域三部分组成。ID表示报文的优先级；DLC表示数据的有效长度，取值范围是1～8；数据域表示所需传输的数据。其他部分由CAN协议的电气层负责，不需要我们关注。

CAN ID的值越小，消息的优先级别越高。CAN报文按照ID的范围划分为应用报文、网络管理报文、开发报文、诊断报文。

ISO-TP协议 1 讲

了解CAN报文的结构后，先来看一段CAN报文。下面是一道汽车总线分析的题目，使用candump获取CAN报文，我们需要从中找到隐藏的flag。

这是一道比较基础的CAN报文分析题。报文的结构依次为接口名称、CAN ID、DLC以及数据。报文内容较短，从整体上看，CAN ID有131、08F、0A5、0D9、0F3、098、19A、16A、09A、0EF、113、199，不难发现ID为19A的消息最多。我们提取ID为19A的报文。

仔细观察数据的第一个字节分别是10、21、22、23、24，看起来似乎有一定的规律。其实，这是ISO 15765标准第二部分（通常称之为ISO-TP协议）网络层服务中定义的协议数据单元。ISO-TP协议中定义了4种数据帧：单帧、首帧、连续帧以及流控帧。

单帧：数据域第一个字节的高四位的十六进制值为0时，代表这是单帧数据。第一个字节的低四位代表数据长度。
首帧：在多帧传输中，数据域第一个字节的高四位的十六进制值为1时，代表这是多帧数据传输的第一帧，数据域第一个字节的低四位与第二个字节代表数据帧的长度。
连续帧：用于传输多帧传输中拆分的CAN消息，作为首帧的后序帧。数据域第一个字节的高四位的值为2，第一个字节的低四位为连续帧的编号。编号从1开始，达到15时，在下一个连续帧中重置为0。
流控帧：用于调节连续帧发送的速率。流控帧数据域第一个字节的高四位为3。

再来看CAN ID为19A的报文。第一条报文，数据域第一个字节的高四位为1，表明这是多帧数据传输的首帧。再看数据长度为0x01A(26)字节。接着往后看，后面4条报文数据域的高四位都是2，说明这些是多帧数据传输中的连续帧。通过分析CAN报文可知，CAN ID 19A在传输多帧数据，现在我们把数据提取出来，得到如下的数据。

将其转化为ASC II字符可以得到flag——“flag{welcome_and_have_fun}”。

SAE J1979协议 1 讲

通过上面的题目我们了解了CAN的上层协议ISO-TP，下面再来看涉及更高层协议的题目，如读取车架号、车速等车辆的基本信息，这类题考查的是对SAE J1979协议的掌握程度。

SAE J1979《汽车诊断技术规范》属于应用层协议，网络层和传输层采用ISO-TP。SAE J1979对应的国际标准为ISO 15031-5。SAE J1979标准中定义了10种模式，汽车制造商并不需要支持所有的模式，每个制造商也可以自行定义模式，这10种模式如下。

模式01：请求动力系诊断数据

识别动力系统信息并在诊断设备上显示车辆数据、车辆状态等信息，如发动机转速、温度、车速、档位、电池电压、油量、油耗、总里程、本次里程等。
模式02：请求冻结帧数据

和模式01中的数据相同，冻结帧数据是在故障发生和故障码被定义时存储的，用于反映故障发生时的环境信息，便于分析故障并处理。
模式03：请求排放相关的诊断故障码

获取与排放相关的故障码，故障码定义见ISO 15031-6。通过请求当前的故障码，了解车辆发生的故障，再根据产生的原因进行维修。
模式04：清除/复位与排放相关的诊断信息

车辆发生故障后产生故障码，维修后需要清除故障码和冻结帧数据。
模式05：请求氧传感器检测结果

该模式显示氧传感器检测页面和收集到的关于氧传感器的测试结果。
模式06：请求指定检测系统的测试结果
除氧传感器外还需要检测其他系统，如催化剂系统、蒸发系统等。车辆制造商通过自定义参数获取指定的监控系统的测试结果。
模式07：请求排放相关的未决故障码

一次驾驶循环后，需要连续监测系统的未决故障码以判断是否需要维修。维修技术人员以此来确认是否已经正确维修且清除了故障码。
模式08：请求组件/系统的控制操作

这个模式用于外部设备控制车载组件、系统，具体功能由车辆制造商指定。
模式09：请求车辆信息

获取车辆信息，该信息包括存储在车辆发动机控制单元中的车辆的标定信息，如车厂、型号、品牌、车架号、发动机号等。
模式0A：请求排放相关的永久故障码

获取与排放相关的故障码，这类故障码一旦产生就不能清除或改写。

硬件连接方面，读取车辆基本信息的入口是 **OBD-II(On Board Diagnostics-Ⅱ)**接口。部分比赛使用模拟器模拟OBD-Ⅱ接口的CAN总线，向接口发送指定的数据获取需要的数据。在整车上，按法规要求需要预留OBD-Ⅱ接口。OBD-Ⅱ接口用于故障诊断，接口一般位于方向盘下方。诊断故障的方式很多，如CAN总线诊断、K线诊断等。当前主流的诊断方式是CAN总线诊断。CAN总线使用差分信号，需要用到两根线缆CAN_H和CAN_L。CAN_H位于OBD-Ⅱ的第6个接口，CAN_L位于OBD-Ⅱ的第14个接口。

车辆OBD接口，连接车辆ECU行车电脑的接口,检修车辆时把设备解码仪插在此接口，进行扫描车辆是否有故障及故障代码，以后的车联网都是基于此口加以研发的。

什么是OBD

OBD全称：On Board Diagnostics，翻译成中文是：车载自动诊断系统“OBD Ⅱ”是“on Board Diagnositics Ⅱ”。为使汽车排放和驱动性相关故障的诊断标准化，从1996年开始，凡在美国销售的全部新车，其诊断仪器、故障编码和检修步骤必须相似，即符合OBD Ⅱ程序规定。作为驱动性和排放诊断基础，OBD Ⅱ系统将得到越来越广泛的实施。

OBDII的作用

OBD Ⅱ程序使得汽车故障诊断简单而统一，维修人员不需专门学习每一个厂家的新系统。

【1】随时检测零部件和系统的故障，保证汽车在使用寿命中的排放不超过OBD法规的要求

【2】检测到相关排放故障时，OBD系统可以用仪表板上的MIL灯进行报警。

【3】故障车辆能够得到及时修理，减少车辆排放。

【4】OBD系统有助于技师迅速诊断，对症修理，降低维修成本。

【1】、【3】、【8】、【11】、【12】、【13】厂家自定义

【2】SAE J1850 总线+ 【10】SAE J1850 总线﹣

【4】车身地【5】信号地

【6】CAN-H 【14】CAN-L

【7】K-Line 【15】L-Line

【16】常电源

故障码标准

SAE J2010规定了一个5位标准故障代码，第1位是字母，后面4位是数字。

首位字母表示设置故障码的系统。当前分配的字母有4个：“P”代表动力系统，“B”代表车身，“C”代表底盘，“u”代表未定义的系统。

第2位字符是0、1、2或3，意义如下：0-SAE(美国汽车工程师协会)定义的通用故障码：1-汽车厂家定义的扩展故障码；2或3-随系统字符(P，B，C或U)的不同而不同。动力系统故障码(P)的2或3由SAE留作将来使用；车身或底盘故障码的2为厂家保留，车身或底盘故障码的3由SAE保留。

第3位字符表示出故障的系统：1-燃油或空气计量故障；2-燃油或空气计量故障；3-点火故障或发动机缺火；4-辅助排放控制系统故障；5-汽车或怠速控制系统故障；6-电脑或输出电路故障。7-变速器控制系统；8-变速器控制系统。

最后两位字符表示触发故障码的条件。不同的传感器、执行器和电路分配了不同区段的数字，区段中较小的数字表示通用故障，即通用故障码；较大的数字表示扩展码，提供了更具体的信息，如电压低或高，响应慢，或信号超出范围。

常见的CAN通信速率有两种，一种是速度为500kbit/s的高速CAN，用于控制ECU、ABS等；另一种是速度为125kbit/s的低速CAN，用于控制仪表、防盗等。OBD-Ⅱ上诊断CAN的速率一般为500kbit/s。

与OBD-Ⅱ上的CAN总线进行通信需要使用CAN总线分析仪（通常简称为CAN卡）。电脑连接CAN卡之后，可以接收和发送CAN报文。现在我们获取车辆的VIN码（Vehicle Identification Number，车架号）。获取车架号属于请求车辆信息，消息的长度为0x02，所属模式为09。在模式09中，获取车架号的信息类型编号为02。数据的长度没有超过0x07，使用单帧传输即可。使用SocketCAN发送以下消息获取车架号。

车架号的长度为17个字符，采用多帧传输，返回的数据如下。

首先解析多帧传输的数据，数据的长度为0x014。0x49表示对模式0x09的肯定响应，0x02表示后面的数据是车架号，接下来的31 47 31 4A 43 35 34 34 34 52 3732 35 32 33 36 37是车架号，转换为ASC II码后得到了17位的车架号1G1JC5444R7252367。

UDS协议 1 讲

UDS（Unified Diagnostic Services，统一诊断服务）是诊断服务的规范化标准，位于OSI模型的应用层，它可以在多种总线（如CAN、LIN、以太网）上实现。在CAN总线实现的UDS诊断被称为UDSonCAN。

UDS中定义了一系列服务，包含六大类，一共26种。每种服务采用SID（Service IDentifier，服务标识符）进行标识。

UDS是一种交互式协议，采用请求应答模式。如果是肯定的响应，**回复[SID+0x40]；如果是否定的响应，回复7F SID以及一个字节的错误码(NRC)**。

赛题：WDB_2020_Teslaaaaa

总览

有了ISO-TP和的UDS的基础知识后，我们再来看2020年网鼎杯的一道题目。此题出自青龙组，划归在MISC类别下，题目名称为Teslaaaaa，提示参考ISO 15765-2标准和ISO 14229-1标准。

下载附件后，解压得到一个名为ecu_can_log.asc的文件。ASC（ASCII Log File，文本日志文件）是Vector定义的用于记录总线日志的文件格式。ASC文件以文本形式记录汽车总线的数据流量，具备一定的可读性。可以使用开源工具Savvy CAN解析日志文件。

除了日志文件外，还有一张提示图片，从图片上可以看到正在使用电脑对ECU（Electronic Control Unit，电子控制单元）刷写固件，ECU芯片上标有ARM，表明处理器的架构为ARM。

现在来看一下日志中的报文信息，从帧过滤中可以看到，日志文件中的CAN ID一共有3个，分别0x730、0x7B0以及0x7DF。分析报文信息，发现日志记录了ECU固件的刷写过程。下面详细分析日志中记录的刷写过程，把标记为“UDS Tester”的CAN卡简称为Tester。

过程分析

第一步，10 02诊断会话控制，请求进入编程会话。Tester发送请求进入编程会话，得到ECU的肯定应答。

0x10 -> 诊断会话控制

0x50 -> 0x10(SID) + 0x40 -> 肯定应答。

第二步，27 05安全访问，请求种子。27服务是UDS的安全访问服务，05子功能表示请求安全校验种子。ECU收到请求种子的消息，返回种子0x1122334。

第三步，27 06安全访问，发送密钥。使用第二步拿到种子 0x11223344，经过双方约定的算法计算得到密钥 EE DD CC BB，并通过27服务的06子功能发送密钥给ECU。ECU收到后与自己计算的密钥进行对比，如果相同则通过验证。从ECU的肯定应答中通过安全校验。

第四步，31例程控制，请求擦除Flash。Tester给ECU发送了多帧数据 31 01 FF 00 44 08 00 00 00 00 00 20 00，0x44表示后面的地址和地址字宽都是4字节，后续表示Flash擦除的起始地址为0x08000000，大小为0x00002000字节。这两个地址在逆向分析时会用到。

第五步，34 例程控制，请求下载。多帧数据 34 00 44 08 00 00 00 00 00 20 00 表示请求下载ECU固件到地址0x08000000处，大小为0x00002000字节。ECU回复肯定应答接收了下载请求。

第六步，36 数据传输。传输数据的长度为0x00002000，每次多帧传输的数据量为0x80(0x82-0x02)，整个下载过程需要传输0x40(0x2000÷0x80)次。

第七步，37 01请求退出传输。Tester发送37服务，表示数据传输完成。

第八步，31 01 DF FF例程控制，厂商自定义功能。UDS标准中从0x0200到0xDFFF区间的RID（Routine IDentifier，例程标识符）保留给车企自定义使用。当前消息的RID为0xDFFF，属于车企定义功能，虽然不清楚具体用途，但也不影响解出此题。

第九步，31 01 FF 01例程控制，检查编程依赖。

第十步，11 01 ECU复位，请求重启ECU。ECU刷写完成之后，重启ECU，使新固件生效。

对整个通信过程进行分析后，发现可以划分为5个阶段。

Tester向ECU请求进入编程会话。
进行安全验证，验证Tester的合法性。
请求数据下载，并传输固件所需的刷写参数。
Tester传输长度为0x2000的数据到ECU中，并刷写到地址0x08000000～0x08002000中。
重启ECU，刷入的新固件后生效。

数据提取

import re

frame_len = 0
frame_data = ""
handled_len = 0

with open("ecu_can_log.asc") as file:
    for line in file.readlines():
        data = re.findall(r"730             Tx   d 8 10 (..) 36 .. (.. .. .. ..)", line)
        if len(data):
            # print(data)
            frame_len = int(data[0][0], 16)
            handled_len = 6
            frame_data += data[0][1] + " "
            continue

        data = re.findall(r"730             Tx   d 8 2(.) (.. .. .. .. .. .. ..)", line)
        if len(data) and frame_data:
            # print(data)
            left_len = frame_len - handled_len
            if left_len > 7:
                frame_data += data[0][1] + " "
                handled_len += 7
            else:
                frame_data += data[0][1][0:left_len*-1] + " "

with open("output.bin", "wb+") as file:
    file.write(bytes.fromhex(frame_data.replace(" ", "")))

逆向分析

使用 IDA 加载文件，架构选择ARM小端序，通过符号引用找到关键函数。

void __noreturn sub_8000290()
{
  int v0; // r0
  _BYTE v1[48]; // [sp+0h] [bp-30h] BYREF

  v0 = sub_800123E(v1, 48);
  sub_800033C(v0);
  sub_8000430(1073821696, "Welcome challenger!\r\n");
  sub_8000430(1073821696, "The flag is:\r\n");
  sub_8000168(v1);
  sub_8000430(1073821696, v1);
  sub_8000430(1073821696, "\r\n");
  while ( 1 )
    ;
}
int __fastcall sub_8000168(_BYTE *a1)
{
  int result; // r0
  char v3[52]; // [sp+4h] [bp-34h] BYREF

  sub_800120C(v3, "flag{canoecr7-zd9h-1emi-or8m-f8vm2od81nfk}", 44);
  sub_8001256(a1, v3);
  a1 += 5;
  a1[2] -= 0xD;
  a1[11] -= 5;
  a1[15] -= 0x2C;
  a1[3] -= 0xB;
  a1[5] -= 0x30;
  a1[7] += 0x2B;
  a1[28] += 0x32;
  a1[31] += 0x2E;
  a1[19] -= 0xD;
  a1[20] -= 0x42;
  a1[1] += 3;
  a1[29] -= 0x37;
  a1[24] -= 0x33;
  a1[9] -= 0x17;
  a1[25] -= 6;
  a1[27] -= 0x3C;
  a1[4] -= 0x34;
  a1[6] -= 0xE;
  a1[30] -= 0x34;
  a1[22] -= 0x3A;
  a1[12] -= 0x30;
  a1[16] -= 0x38;
  a1[34] -= 0x35;
  *a1 -= 0x30;
  a1[14] += 3;
  a1[17] -= 5;
  a1[33] -= 0x37;
  a1[35] -= 0x38;
  a1[10] -= 2;
  a1[26] -= 0x43;
  result = (unsigned __int8)a1[21] - 6;
  a1[21] = result;
  return result;
}

这个函数给出了flag，对原始flag进行了简单的加密。

temp="canoecr7-zd9h-1emi-or8m-f8vm2od81nfk"
v1=[]
j=0
for i in temp:
    v1.append(ord(i))
    j+=1
v1[2] -= 13
v1[11] -= 5
v1[15] -= 44
v1[3] -= 11
v1[5] -= 48
v1[7] += 43
v1[28] += 50
v1[31] += 46
v1[19] -= 13
v1[20] -= 66
v1[1] += 3
v1[29] -= 55
v1[24] -= 51
v1[9] -= 23
v1[25] -= 6
v1[27] -= 60
v1[4] -= 52
v1[6] -= 14
v1[30] -= 52
v1[22] -= 58
v1[12] -= 48
v1[16] -= 56
v1[34] -= 53
v1[0]-= 48
v1[14] += 3
v1[17] -= 5
v1[33] -= 55
v1[35] -= 56
v1[10] -= 2
v1[26] -= 67
flag="flag{"
for i in v1:
    flag+=chr(i)
flag+='}'
print flag

CAN总线协议 2 讲

CAN 总线仲裁

以CVVD首届车联网漏洞挖掘大赛一道题为例。

题目：汽车某一CAN网段上有3个ECU，分别是ECU1、ECU2、ECU3，各个ECU发出去的报文ID如上图所示，如果这3个ECU同时发出报文，请写出此时CAN网段上的报文ID，用十六进制表示。

CAN 总线仲裁原理

首先要了解CAN总线仲裁的原理，即CAN报文的优先级是通过对ID的仲裁来确定的。根据CAN协议的物理层我们知道，如果总线上同时出现显性电平和隐性电平，总线的状态会被置为显性电平，CAN正是利用这个特性进行仲裁的。对于CAN来说，0为显性，1为隐性。对不同的ID进行仲裁时，ID数值越小，优先级越高。

图中可以看到3个ECU发出去的报文ID，首先将ECU发出的信号转化为便于理解的ID。CAN ID的长度为11字节，属于标准帧的ID。ECU1发出的ID为1011000 1111(0x58F)，ECU2发出的ID为101 0011 0111(0x537)，ECU3发出的ID为101 0101 0011(0x553)。然后依据CAN总线仲裁机制（ID越小，优先级越高）得到CAN网段上的报文ID。3个CAN ID中，0x537最小，于是得到结果flag{0x537}

ECU 回复响应码

此题也来自CVVD首届车联网漏洞挖掘大赛，主要考查对UDS协议的理解。

题目：ECU不支持27服务的响应代码是多少？

27服务是UDS中定义的安全访问服务(Security Access)，通过种子与密钥的方式为ECU提供保护机制。本题考查第一阶段，对27服务请求访问的否定响应应答。通过查询UDS标准，在否定响应码定义和数值表中找到了服务不支持的值0x11，即得到flag{0x11}

ISO/SAE 21434

题目：对于ISO/SAE 21434中的工作产出、集成和验证报告，是下列哪一节的产出内容？

A.验证阶段 B.运维阶段 C.生产阶段 D.产品开发阶段

ISO/SAE 21434《道路车辆-网络安全工程》标准是基于SAE J3061《信息物理汽车系统网络安全指南》制定的针对车辆生命周期的标准，主要从风险评估管理、产品开发、运行/维护、流程审核等4个方面保障汽车信息安全工程工作，目标是使设计、生产、测试的产品具备一定的信息安全防护能力。

ISO/SAE 21434标准基于V模型的总体思路，覆盖了汽车电子研发和制造相关领域的核心开发活动过程，主要涵盖安全管理、基于项目的网络安全管理、持续的网络安全活动、相关风险评估方法以及道路车辆概念验证阶段、产品开发阶段和开发完成后阶段的网络安全。

ISO/SAE 21434中产品开发阶段包括系统、硬件和软件开发，集成与验证位于该标准的10.4.2节，此节属于产品开发阶段，于是得到flag{D}。

WP29 R155和R156

题目：WP29颁布法规中对未授权用户能够获取车辆系统权限给出的应对措施的编号是什么？

WP29的全称为联合国世界车辆法规协调论坛，2020年6月，WP29通过了R155法规和R156法规。R155主要分为网络安全管理体系认证（CSMS认证）和车辆型式审批两部分。CSMS认证主要审查原始设备制造商是否建立了涵盖汽车全生命周期的网络安全相关体系，以确保汽车全生命周期都有对应的流程和措施。车辆型式审批则是确保原始设备制造商开发的汽车网络安全架构及防护方案在进行审查认证时满足基本要求。R156主要从流程体系与技术需求上对软件更新提出要求。流程体系方面的要求是建立软件更新管理体系(SUMS)，主要由软件更新一般流程要求、软件更新记录存储要求及软件更新的安全流程要求三部分构成。技术需求包括通用软件更新要求及OTA附加要求。R155和R156法规于2021年1月起生效。

我国也在积极推进车联网法律法规的建设。2020年11月，国家市场监督管理总局发出了《关于进一步加强汽车远程升级(OTA)技术召回监管的通知》，首次提出了OTA召回的概念，要求车企在实施OTA召回计划时，向国家市场监督管理总局备案。

根据WP29 R155标准中的附录表格，可知对未授权用户能够获取车辆系统权限给出的应对措施的编号是M9，那么flag就是flag{M9}。

线下实车漏洞挖掘

在车联网安全竞赛的线下决赛中，一般会有对实车的漏洞挖掘。时间较短，只有短短的数小时时间，若没有指定车型漏洞的积累，短时间内很难挖掘到优质漏洞。实车漏洞挖掘主要集中于CAN总线（OBD-Ⅱ接口）、车机以及TBOX等。

CAN总线漏洞挖掘

比赛中CAN总线的接口一般为OBD-Ⅱ。需要提前准备OBD-Ⅱ公头开口线、一分二转接线延长线、CAN通信卡以及汽车诊断仪等。

常见的题目包括信息读取、功能指令逆向等。信息读取指的是向CAN总线发送诊断报文，获取ECU的特定信息，如确定车内ECU的数量，并列出ECU的诊断响应ID。发送诊断报文开始拓展会话诊断控制，如图所示。ECU收到之后回复肯定响应(50 03)，回应的CAN ID就是此题需要的诊断响应ID。

功能指令逆向指的是对鸣嗽叭、车门、车窗等功能的CAN报文逆向。在没有进行CAN网络隔离的车辆中，由于CAN报文广播的特征，在OBD-Ⅱ接口处可以监听所有的CAN报文。以对鸣喇叭指令的逆向为例，首先使用CAN通信卡监听OBD-Ⅱ接口的CAN消息，然后按下汽车喇叭的控制开关使汽车鸣喇叭，接着分析这段CAN报文，找出其中的鸣喇叭报文。接收到的报文往往比较多，可以通过一些技巧来缩小分析范围。首先统计相同报文出现的次数，去掉重复的报文。然后按照功能操作（如按喇叭）的频次过滤出可能的报文。最后通过折半查找等方法重放报文，找到可以让车辆鸣喇叭的报文。

车机漏洞挖掘

由于时间限制，现场实车的车机漏洞挖掘测试往往不会太深入。在参赛之前，需要做好收集情报工作。例如，预测比赛使用的汽车品牌及车型，比赛一般使用国产电动汽车，车型一般是最近推出的，下面介绍如何确定参赛用车的品牌。

站在主办方的角度，测试某车企的车辆需要拿到相应的授权，一般为了方便沟通，通常会与本地的车企合作。例如：比赛在重庆举办，使用长安汽车的概率就比较高；在北京比赛，使用北汽旗下的车辆的可能性就比较高。除此之外，还可以根据赛事的合作伙伴来推测，赛事合作伙伴中的车企极有可能是参赛用车的提供方。

知道汽车品牌后，需要分析车型，某些赛事在参赛之前会用车衣遮挡车辆，并用赛事标签遮挡车辆Logo。这也难不倒善于信息收集的安全研究员，首先观察车的外形轮廓，确定车辆是轿车还是SUV，然后再通过其他信息判断具体车型。

知道车型后，需要在互联网上搜索工程模式、任意应用安装等信息，从中找到接入车机的入口，包括ADB调试接口、USB任意应用安装等。ADB调试接口一般使用USB TYPE-A双公头线，线材需要赛前提前准备。此外U盘、Wi-Fi网卡、SDR设备也是必备的。

收集到情报后，在比赛现场的实车上实践。根据掌握到的信息，扩大影响范围，找到更多的漏洞。以下是一些常见的漏洞点。

(1)工程模式

工程模式是厂商隐藏的高级功能，用于调试维护车机。部分车型可从工程模式中打开调试接口、导出日志等。如果工程模式没有使用密码等保护机制，我们很容易进入工程模式，那么这也是一个具有较高威胁系数的安全威胁。在工程模式中导出日志到U盘中，分析导出的日志中是否包含敏感信息，如用户通讯录、进程信息、TSP平台信息等。

(2)流量分析

首先搭建Wi-Fi热点让车机连接，然后使用Wireshark抓包，最后分析明文传输的流量信息，从中寻找敏感信息和漏洞。依据流量信息，向上分析发现TSP平台的漏洞，如管理后台弱口令、MQTT未授权访问等；向下分析发现车机端的漏洞，如任意应用安装等。

接入车辆提供的Wi-Fi热点，扫描端口挖掘服务漏洞。多数车型的热点是由车机共享的，但也有少部分是由TBOX发出的。通过技巧可以区分热点是由车机还是TBOX发出的，扫描53(DNS)端口，如果DNS端口开放，那么此热点极有可能是TBOX发出的。

(3)系统漏洞挖掘

拿到车机的权限后需要进行进一步的漏洞挖掘。可以测试的点包括命令注入、敏感信息检索（如私钥、云存储token等）、用户权限提升、分析车辆控制逻辑实现远程控制效果等。实车自由漏洞挖掘比拼的是相同时间内发现的漏洞数量和质量。比赛中团队的协作很重要，合理搭配队伍并提前分工，各自发挥特长，分别挖掘车联网中存在的漏洞。

一般而言，精通CTF竞赛的选手对车联网安全不太了解，无法解答与车联网高度相关的题目；对于车联网安全研究员来说，一般从事于车联网漏洞挖掘、安全合规测试等工作，参与的CTF比赛较少。通过合理搭配CTF选手和车联网安全研究员，往往能够获得更好的成绩。

实战篇

通过竞赛了解一定的基础概念以后再来看实战篇。

CAN通信总线安全

CAN总线协议 3 讲

CAN 是控制器局域网络（Controller Area Network）的简称，是实现汽车所有或部分部件之间通信的中枢神经系统，由以研发和生产汽车电子产品著称的德国 BOSCH 公司开发并最终成为国际标准（ISO 11898），是国际上应用最广泛的现场总线之一。在使用 CAN 作为车内通信系统之前，汽车制造商使用的是点对点布线系统，当汽车内部电子单元越来越多时，这种布线系统会显得特别庞大且维护成本太高，后来通过使用 CAN 代替来解决这个问题。

简单来说，CAN 可以让汽车上的各个电子单元相互通信、共享数据，提出 CAN 的主要原因是它允许多个 ECU（Electronic Control Unit，电子控制单元）共用一根导线进行通信。在一辆现代汽车中存在多达 70 个 ECU，例如：发动机控制单元、安全气囊、变速箱、齿轮单元、防抱死制动系统（ABS）、信息娱乐系统、气候控制系统、车窗、车门等部件，为了让这些单元之间能够相互通信，点对点布线会显得特别庞大。试想一下，每一个组件都连接到其它全部组件，对于后期故障诊断和排除来说是相当糟糕的，但是有了 CAN 就可以用单线代替，每个元件之间的通信就简单了许多。CAN总线通常采用屏蔽或非屏蔽的双绞线，总线接口能在极其恶劣的环境下工作。根据ISO 11898的标准建议，即使双绞线中有一根断路，总线都必须能继续工作。

CAN 总线可以被认为是一个嘈杂、拥挤、慢速版的以太网局域网，只是流量是 UDP 而不是 TCP。值得注意的是，并不是所有的汽车控制系统都使用 CAN，而且 CAN 不仅仅是汽车系统中使用的通信协议，还可能有其它协议，如蓝牙、GSM/LTE 蜂窝网络、卫星无线电、LIN（Local Interconnect Network）等。在实际场景中，CAN 并不是唯一的攻击面，可能还存在很多其它的攻击面。

CAN总线特性

安全性：CAN是低级协议，不支持任何内在的安全功能。在标准的CAN中也没有加密，使得网络数据能被截取。在大多数应用中，应用程序需要部署自己的安全机制，例如认证传入命令或网络上某些设备的存在。若不执行适当的安全措施，其他人可能设法在总线上插入消息。尽管一些安全关键功能（如修改固件，编程键或控制防抱死制动）存在密码，但这些系统并未普遍实施，并且密钥对的数量有限。

通信机制：多主机，即每个节点都有接入总线的能力
寻址机制：消息区别，不设节点的地址，通过消息的标志符来区别消息。
帧类型：数据帧、远程帧、错误帧、超载帧、帧间隔
攻击方式：应用报文模糊攻击、DOS攻击测试、重放攻击

由于CAN总线上的数据包没有进行过任何的加密处理，因此这些数据包是能够被截取窃听。由于车载网络使用CAN协议进行通信，所以我们可以联想到车联功能也是通过CAN网络进行数据发送和交换。

CAN总线的工作

一辆汽车可以有多个节点，能够发送或接收报文，这个报文基本上由一个 ID 组成，它的优先级，也可以包含 CAN 报文，一次可以是 8 个字节或更少。如果两个或两个以上的节点同时开始发送报文，那么以主导 ID 发送的报文将覆盖依次主导 ID 发送的报文，这就是所谓的基于优先级的总线仲裁。ID 数值越小的报文优先级越高，这就是节点判断报文传输先后的依据。来自制动器的报文比来自音频播放器的报文具有更高的优先级。

CAN运行在两条线路上：CAN高电平（CANHI）和CAN低电平（CANLO）。
CAN bus 有四种帧类型。

帧类型	用途
数据帧（Data Frame）	包含要传输的节点数据的帧
远程帧（Remote Frame）	请求传输特定标识符的帧
错误帧（Remote Frame）	任何检测到错误的节点发送的帧
重载帧（Overload Frame）	在数据或远程帧之间插入延迟的帧

CAN有两种类型的消息(帧)格式：标准（基础）帧格式和扩展帧格式。标准（基础）帧有11位标识符，扩展帧格式有29位标识符。CAN标准帧格式和CAN扩展帧格式之间的区别是通过使用IDE位进行的，IDE位在11位帧的情况下以显性方式传输，而在29位帧的情况下以隐性方式进行传输。支持扩展帧格式消息的CAN控制器也能够以CAN基本帧格式发送和接收消息。CAN 总线由两根不同的导线组成，由于它是总线，因此这些导线可以连接到多个设备。

标准帧格式

说一下主要的4个元素，其他的大家感兴趣可自行去了解：

仲裁ID（Arbitration ID）：仲裁ID是一种广播消息，用来识别正视图通信的设备的ID，其实也代表发送消息的地址。任何的设备都可以发送多个仲裁ID。在总线中同时发送的消息，低仲裁ID的消息拥有优先权。
标识符扩展（IDE）：标准帧格式该位始终是0。
数据长度码（DLC）：表示数据的大小，番位是0字节到8字节。
数据（Data）：总线传输数据本身。一个标准的数据帧可携带最大尺寸为8字节。有些系统中会强制要求8字节，不满8字节则填充为8字节。

下面来看看 CAN 数据帧的结构：

扩展帧格式

扩展帧格式与标准帧格式类似，扩展帧格式可以连接在一起，形成更长的ID。拓展帧格式可包含标准帧格式。拓展帧格式的标识符扩展IDE被设置为1。扩展帧有一个18位的标识符，是标准的11位标识符的第二部分。

实车上访问 CAN 总线

为了访问汽车的 CAN 总线，需要先访问车载自诊断端口，也就是 OBD。虽然可能存在数以百计的其它诊断标准或者端口，但基本上现在所有汽车都使用的 OBD-Ⅱ，这也正是修车修理工用来识别汽车故障的途径，OBD 是最直接访问 CAN 的，找到 OBD-Ⅱ 的方法非常简单，它通常位于乘客座椅或者驾驶员座椅附近，且不用使用螺丝刀就能访问。

这就是 OBD 的具体样子：

如果您想知道 OBD 的引脚，下面是 OBD 端口的引脚：

通过 OBD 访问 CAN 所需的硬件和软件

因为电脑不能直接与 CAN 连接，为了与 CAN 总线交互，需要类似 USB 转 CAN 的工具，通过 USB 连接到 OBD-II 端口，这样就可以发送或接收 CAN 数据包。同时在软件上需要一些能够读取或写入 CAN 数据包以及编码或解码 CAN 数据包的工具。

硬件

连接 OBD-II 所需的硬件可以很容易地在市场上找到，有昂贵以及廉价的硬件设备。高端设备包括 Kvaser 和 EMS，这些设备价格昂贵且矫枉过正，性价比很高的组合是 USB2CAN 和原生的 Linux 系统。

另外，很多时候会遇到 ELM327，它是一个基于蓝牙的设备，但对于黑客来说是非常糟糕的，原因是它的数据速率比较慢，最后会丢失很多数据包。

Macchina M2 是一个开源的汽车接口，可以通过 OBD-II 与 CAN 总线通信。Macchina M2 最大的优点是它是模块化的，也就是说可以在 Macchina M2 的基础上增加 WiFi、GSM、LTE、BLE 模块。Macchina M2 有 2 个 CAN 通道。Macchina M2 还具有 LIN，可以通过访问链接获取更多关于 Macchina M2 的信息。

另一个低成本的选择是 CSS 电子公司的 CLX000，它可以记录和流式传输 CAN 数据，数据可以在免费的开源软件 Wireshark 中可视化，一个插件便可以实现逆向功能，CLX000 是可视化和远程信息处理的理想选择。

可以通过访问链接获取更多关于 CLX000 的信息，在一些博客中也有一些关于 CAN 的文章。

软件

在软件方面，Linux 内核中内置了 SocketCAN、can-utils、vcan，它们的作用是发送和接收 CAN 数据包，对数据进行编码或解码，也可以通过 Wireshark 分析 CAN 数据包。

如果想了解更多关于 CAN 操作的知识，而又不想破坏自己的汽车，ICSim 将会是首选工具。

CAN模拟环境搭建

安装ICSim

安装依赖

# 安装依赖
sudo apt install libsdl2-dev libsdl2-image-dev can-utils maven autoconf -y
# 下载ICSim
git clone https://github.com/zombieCraig/ICSim.git
# 编译安装
cd ICSim/
sudo make

安装socketcand

# 下载socketcand
git clone https://github.com/linux-can/socketcand.git
cd socketcand
# First run to create the 'configure' script.
./autogen.sh
# Then run the created script with
./configure
# install
make
sudo make install

安装Kayak

可选，原作者已于2020年起放弃维护

# 下载
git clone https://github.com/dschanoeh/Kayak.git
# 安装jdk
sudo apt-get install openjdk-8-jdk
# 安装
cd Kayak
mvn clean package

开始模拟

准备虚拟 CAN 网络

进入 ICSim 目录，执行有一个名为 setup_vcan.sh 的 shell 脚本：

└─# cat setup_vcan.sh 
# 加载 CAN 的内核模块以及虚拟 CAN 的内核模块：
sudo modprobe can
sudo modprobe vcan
# 接下来设置虚拟接口：
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

modprobe 命令是用来加载内核模块，比如 can 和 vcan 模块，最后两行将创建一个 vcan0 接口以便模拟汽车网络。

└─# ifconfig vcan0
vcan0: flags=193<UP,RUNNING,NOARP>  mtu 72
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

运行 ICSim

运行 ICSim 至少需要两个组件，一个仪表盘和一个控制器，用来模拟加速、刹车、控制车门、转向灯等，需要至少 3 个终端窗口或标签来运行仪表盘、控制器和 can-utils。

运行仪表盘和控制器

# 为了运行仪表盘，需要运行一个名为 icsim 的文件，参数为 vcan0，也就是之前创建的接口。
./icsim vcan0
# 此时仪表盘无法正常工作，这是因为接口 vcn0 上没有流量，为了模拟接口 vcan0 上的流量，这里需要启动控制器。
./controls vcan0

控制器操作仪表盘

vcan0 是一个虚拟的 CAN 接口，ICSim 将通过它来发送和接收 CAN 帧，当启动控制面板时，可以观察到车速表有一些波动，这是因为控制面板模拟了噪声，启动控制面板后，便可以使用键盘来模拟流量。

行为	快捷键
加速	↑
左右转向	←/→
解锁前左右车门	Right-Shift + A/B
解锁后左右车门	Right-Shift + X/Y
锁定全部车门	Right-Shift + Left-Shift
解锁全部车门	Left-Shift + Right-Shift

Savvycan

下载链接

Savvycan 也可以用来分析can帧，使用起来也是很简单方便。

1	Connection->Open Connection Window->Add New Device Connection

然后便可以看到 CAN 流量。

CAN总线操作

虚拟 CAN 接口设置成功后就可以在这个接口中发送或接收 CAN 数据包了，接下来使用 can-utils 中的一个叫做 cangen 的工具来生成虚拟的 CAN 数据包。cangen 可以生成用于测试的 CAN 帧，要使用 cangen 需要指定要生成 CAN 帧的接口，这里 vcan0 是创建的虚拟 CAN 接口：

1	└─# cangen vcan0

wireshark

生成 CAN 帧后，有很多工具可以查看 CAN 帧的内容，这里以 Wireshark 举例。

can-utils

另外，可以选择使用 can-utils 提供的工具，比如 cansniffer 和 candump，它们的功能和 Wireshark 差不多。

可以使用 candump 转储或记录 CAN 帧：

└─# candump vcan0                             
  vcan0  183   [8]  00 00 00 06 00 00 10 32
  vcan0  143   [4]  6B 6B 00 FF
  vcan0  095   [8]  80 00 07 F4 00 00 00 26
  vcan0  166   [4]  D0 32 00 36
  vcan0  158   [8]  00 00 00 00 00 00 00 37
  vcan0  161   [8]  00 00 05 50 01 08 00 3A
  vcan0  191   [7]  01 00 10 A1 41 00 29
  vcan0  164   [8]  00 00 C0 1A A8 00 00 22
  vcan0  133   [5]  00 00 00 00 89
  vcan0  136   [8]  00 02 00 00 00 00 00 0C
  vcan0  13A   [8]  00 00 00 00 00 00 00 0A
  vcan0  13F   [8]  00 00 00 05 00 00 00 00
  vcan0  17C   [8]  00 00 00 00 10 00 00 03
  vcan0  18E   [3]  00 00 4D
  vcan0  1CF   [6]  80 05 00 00 00 2D
  vcan0  1DC   [4]  02 00 00 2A
  vcan0  183   [8]  00 00 00 0C 00 00 10 0F
...

上面正在运行的 cangen 生成 CAN 帧，上面的终端正在运行 candump 记录 CAN 帧，记录的 CAN 帧可以分为四列，第一列是 CAN 接口，第二列是仲裁 ID，第三列是 CAN 数据的大小，第四列是数据本身。

CAN总线威胁

根据CAN总线的特性，我们则可以了解CAN面临的威胁：

CAN总线通信是广播的方式，所以数据是可以被监听和获取的。
CAN总线协议中ID代表报文优先级，协议中没有原始地址信息。也就是说任何人都可以伪造和发送虚假或恶意的报文。

另外拒绝服务攻击在CAN总线协议中也是存在的。但是我们主要是分析和逆向CAN总线。

重放攻击

candump

candump 可以转储 CAN 帧，如果想进行重放攻击，需要先转储 CAN 帧，然后使用 canplayer 对转储的 CAN 帧进行重放，CAN 帧的转储可以使用 -l 参数启动：

1
2
3

└─# candump -l vcan0
Disabled standard output while logging.
Enabling Logfile 'candump-2024-03-21_155205.log'

使用 candump 转储 CAN 帧时，会创建一个以 candump 为前缀和日期命令的文件，如果想查看转储文件的内容，可以在 Linux 中使用 cat 命令查看：

└─# cat candump-2024-03-21_155205.log
(1711007525.799440) vcan0 1CF#80050000003C
(1711007525.799476) vcan0 244#00000001A8
(1711007525.799479) vcan0 1DC#02000039
(1711007525.799481) vcan0 320#000030
(1711007525.799483) vcan0 324#7465000000000E38
(1711007525.799485) vcan0 183#0000000900001020
(1711007525.799487) vcan0 37C#FD00FD00097F0038
(1711007525.799489) vcan0 039#002A
(1711007525.799491) vcan0 40C#0000000004000013
(1711007525.799492) vcan0 454#23EF18
(1711007525.799494) vcan0 143#6B6B00E0
(1711007525.799496) vcan0 095#800007F800000013
(1711007525.800548) vcan0 1A4#0000000800000010
(1711007525.800566) vcan0 1AA#7FFF000000006810
(1711007525.800570) vcan0 1B0#000F0000000157
(1711007525.800573) vcan0 1D0#000000000000000A
(1711007525.802955) vcan0 166#D0320027

括号内的是时间戳，vcan0为我们的虚拟can接口。后面的是ID和数据，ID和数据以#号分割。

candump是监听并记录原始数据，会有很多对我们无用的数据。can-utils工具包中还有一款可以根据仲裁ID进行分组显示，并对变化的数据以红色显示，它就是cansniffer。cansniffer 是用于嗅探 CAN 数据包的工具。cansniffer 的 -c 参数可以通过颜色高亮突出变化的字节，当需要判断执行某些操作是否会导致 CAN 数据变化时使用。

└─# cansniffer -c vcan0
00|ms | ID  | data ...     < vcan0 # l=20 h=100 t=500 slots=1 >
99999 | 039 | 00 0C                   ..
01|ms | ID  | data ...     < vcan0 # l=20 h=100 t=500 slots=33 >
00019 | 039 | 00 1B                   ..
00011 | 095 | 80 00 07 F4 00 00 00 17 ........
00010 | 133 | 00 00 00 00 B6          .....
00009 | 136 | 00 02 00 00 00 00 00 39 .......9
00009 | 13A | 00 00 00 00 00 00 00 37 .......7
00010 | 13F | 00 00 00 05 00 00 00 3D .......=
00011 | 143 | 6B 6B 00 E0             kk..
00010 | 158 | 00 00 00 00 00 00 00 28 .......(
00010 | 161 | 00 00 05 50 01 08 00 2B ...P...+
00010 | 164 | 00 00 C0 1A A9 00 00 12 ........
00010 | 166 | D0 32 00 27             .2.'
00010 | 17C | 00 00 00 00 10 00 00 30 .......0
00010 | 183 | 00 00 00 13 00 00 10 34 .......4
...

cansniffer

cansniffer 可以通过仲裁 ID 进行过滤，当需要只显示某一个特定仲裁 ID 的帧时，只需在嗅探的过程中，按减号（-）然后输入 000000，再按 Enter 键清除所有的帧，按加号（+）然后输入仲裁 ID，再按 Enter 键便只显示特定仲裁 ID 的帧。

1
2
3

-000000
+133
+244

canplayer

顾名思义，canplayer 是用来重放 CAN 帧的工具。理想情况下，当必须进行重放攻击时，首先需要转储或记录 CAN 帧，然后使用 canplayer 对 CAN 帧进行重放。在进行重放攻击前需要打开 ICSim，这个时候会在 cansnifer 工具中看到 CAN 帧的变化，在使用candump -l vcan0转储 CAN 帧的同时在控制器对仪表盘进行操作，例如：加速、转向，然后停止转储，将会看到创建了一个 candump-XXXXX.log 命名的文件，接下来使用canplayer -I candump-XXXXX.log对转储的 CAN 帧进行重放，将会在仪表盘中看到转储时进行的操作。

想象一个场景，希望对转速表进行欺骗，但是却不知道转速表的读数在哪个仲裁 ID 上工作，这种情况需要先用 candump 的 -l 参数转储 CAN 帧数，然后用 canplayer 重放转储的 CAN 帧，使用 canplayer 重放 CAN 帧时需要通过 -I 参数来接受输入文件：

1	canplayer -I candump-2024-03-21_160543.log

canplayer 还有一些其它非常好用的参数，可以通过man canplayer获取。

转储 CAN 帧分析

在真实的汽车中，CAN 总线的噪音可能会大很多，且 CAN 帧出现速度也会快很多，所以如何识别出关键的仲裁 ID 是一个难题，这里列出三种方法：二分法，统计法，观察法，推荐使用统计法。

二分法

将转储的 CAN 帧文件一分为二，然后分别重放观察哪一个文件包含了关键的仲裁 ID，然后对相应的文件再进行操作，依次循环。

首先通过candump监听数据。
1
candump -l vcan0
回到控制器界面，进行开门锁操作，然后在关闭车门锁。
停止监听数据。数据保存到执行mv candump-2020-06-22_140718.log source (文件名根据实际情况修改)
关车门锁操作，执行canplayer -I source 重放数据。确认车门锁是否开启。如果没有，请重复上面的步骤。
输入 wc -l source 命令查看文件行数。笔者这里结果为11407行。
输入 split -l 6000 source c1 将source文件分成两个文件。
使用canplayer重放两个分割后的文件，查看重放的哪个文件打开来车门锁。每次重放前都要执行 canplayer -I source。主要是保证每次重放分割的文件前车门锁是关闭的。
根据第6和7的步骤对包含重放命令的文件进行。这里要注意每次split命令分割的行数减少1倍。例如第二次执行的名为 split -l 3000 c1aa c2 。重放命令为 canplayer -I c2aa和canplayer -I c2ab。这样一直重复知道发现最终的数据包。

经过上面的重复，在13ab的文件中定位到来了ID值和发送的数据。使用 cansend vcan0 19B#00000E000000 进行验证。打开车门锁成功。

统计法

以仲裁 ID 或仲裁 ID 和 CAN 数据为依据，统计出 CAN 帧文件各仲裁 ID 或仲裁 ID 和 CAN 数据出现的次数，根据出现的此处进行判断。对于一些只有在进行操作时才会产生的动作，可以通过选择特定的次数，对其发送的次数进行筛选。

使用 candump -l vcan0 捕获数据包。
在控制器界面中操作5次车门锁操作。
停止 candump。获得保存文件，这里为candump-2020-06-22_151059.log。
通过编写好的脚本，运行 python3 can.py candump-2020-06-22_151059.log获得结果

#!/usr/bin/python3
# -*- coding: UTF-8 -*- 
can_log_file = input("file name:")

class can_info:
    ID = ""
    count = 0

can_list = []
data_dict = {}
with open(str(can_log_file), 'r') as file: 
    content = file.readlines()
    for item in content:
        idx = item.find('#')
        can_ID = item[idx-3:idx]
        can_data = item[idx+1:]
        
        flag = True
        for elem in can_list:
            if elem.ID == can_ID:
                elem.count = elem.count + 1
                data_dict[can_ID].append(can_data)
                flag = False
                break
        
        if flag:
            ci = can_info()
            ci.ID = can_ID
            ci.count = ci.count + 1
            data_dict[can_ID] = []
            data_dict[can_ID].append(can_data)
            can_list.append(ci)

    for item in can_list:
        print(item.ID + " : " + str(item.count))

    can_id = str(input("can_id:"))
    for item in can_list:
        if item.ID == can_id:
            for elem in data_dict[can_id]:
                print(elem, end="")

运行一下：

└─# python3 can_wc.py                          
file name:candump-2024-03-21_165147.log
244 : 1046
095 : 1333
166 : 1332
158 : 1332
161 : 1332
191 : 1332
133 : 1332
136 : 1332
13A : 1332
13F : 1332
164 : 1332
17C : 1332
18E : 1332
1CF : 666
039 : 880
1DC : 666
320 : 136
324 : 136
37C : 136
40C : 46
183 : 1332
454 : 46
143 : 1332
1A4 : 666
1AA : 661
1B0 : 661
1D0 : 661
294 : 331
21E : 331
305 : 127
309 : 135
428 : 45
405 : 45
333 : 130
188 : 26
5A1 : 12
19B : 10
can_id:19B
00000B000000
00000F000000
00000B000000
00000F000000
00000B000000
00000F000000
00000B000000
00000F000000
00000B000000
00000F000000

观察发现19B，较为可能是开门和关门的can数据帧。找到19B相关的数据帧。

└─# cat candump-2024-03-21_165147.log | grep 19B#        
(1711011109.292333) vcan0 19B#00000B000000
(1711011110.165507) vcan0 19B#00000F000000
(1711011111.107797) vcan0 19B#00000B000000
(1711011111.878506) vcan0 19B#00000F000000
(1711011112.849585) vcan0 19B#00000B000000
(1711011113.615873) vcan0 19B#00000F000000
(1711011114.435582) vcan0 19B#00000B000000
(1711011115.148119) vcan0 19B#00000F000000
(1711011116.077156) vcan0 19B#00000B000000
(1711011116.881887) vcan0 19B#00000F000000
└─# cat candump-2024-03-21_165147.log | grep 19B# > 1.log
└─# canplayer -I 1.log

成功开关车门。

观察法

在控制器界面按下左键，模拟器界面左转向灯闪了一下，观察cansniffer界面数据变化，在左转向灯闪时（也就是按下左键时），看哪一个值变了又变会原值，并保持原值。最终定位ID值为188。现在在进行另外一个例子，在汽车加速过程中，转速表是一直在上升。这就可以通过观察哪一个值是在持续上升的。这里通过控制器界面，按住上方向键，观察哪一个值是在持续增加的。最终定位ID值为244。可以通过 cansend 来进行验证，是否成功。

Savvycan的使用

有时间再细研究。

重放攻击

使用 SavvyCAN 执行重放攻击要容易得多，在 Send Frames 中选择 Playback，可以从文件加载数据或直接从捕获的数据加载数据，还可以从 ID 筛选菜单中选择要重播的 ID。

识别仲裁 ID

SavvyCAN 提供了许多逆向工具，其中经常使用的是 Sniffer，它能够弹出非活动字节，通过二分法过滤仲裁 ID 便可以快速识别出关键的仲裁 ID。

发送自定义帧

SavvyCAN 还有一个非常实用的功能，在 Send Frames 中选择 Custom，它能够发送自定义的帧并可以实时修改。

Fuzzing

SavvyCAN 还有一个非常酷的功能，在 Send Frames 中选择 Fuzzing，它能够非常容易的对 CAN 帧进行 fuzzing。

建议阅读

zh1chu 师傅写的几篇文章。

[zh1chu] 汽车CAN总线-01 介绍

[zh1chu] 汽车CAN总线-02 共计

[zh1chu] 汽车CAN总线-03 测试方法演示

TBOX 安全

TBOX 安全威胁

TBOX承担着与外部通信的重要工作，其重要性不言而喻。TBOX往往也是攻击者的首先目标，以下是TBOX面临的一些威胁系数较高的安全威胁。

硬件调试接口威胁

TBOX一般会预留调试接口，若调试接口缺乏健壮的授权访问认证，攻击者就能通过调试接口获取系统的访问控制权，进一步挖掘系统中存在的安全隐患。

固件提取威胁

固件是安全研究极其重要的内容，固件提取也显得尤为重要。IoT设备通常可以通过多种方式获取固件，如官方网站下载、网络升级捕获、调试接口获取、编程器读取等。由于TBOX相对比较封闭，因此很多常规的方法都无法使用。最直接的方法是从硬件设备上提取，将存储芯片拆卸下来，从提取出的固件中，可以获得私钥、硬编码口令等敏感信息，并发现其中的安全问题。

车联网服务平台威胁

TBOX中的车联网服务多采用双向认证机制，若TBOX被攻破，攻击者可以伪装成TBOX向云端发起攻击。TBOX多接入专用的APN网络，同网络中的网络设备往往比较脆弱。控制TBOX并接入APN后，会给车企内部网络带来不确定的安全威胁。

公网暴露

部分TBOX暴露在公网中，存在较高的安全威胁。特别是开放了Telnet等服务的TBOX，如C4MAX-3GNA。使用Shodan搜索C4MAX-3GNA。C4MAX-3GNA开启了Telnet服务，任何人都可以连接且无须认证。连接后，可以修改TBOX的运行参数、追踪车辆行驶路径。

CAN总线

TBOX是车辆CAN总线网络中重要的节点，用于实现远程诊断、远程控制等功能。移动应用程序对车辆的控制（如空调调节、车门开关等）通过TBOX的CAN接口下发给指定的ECU处理。若TBOX的CAN接口被非法控制，甚至会影响到车辆行驶安全。特别是在FOTA(Firmware Over-The-Air)应用场景中，对ECU升级流程进行逆向分析之后，通过替换网关或其他ECU的固件可以实现控制整车ECU。

协议安全

TBOX中除了常见的HTTP、FTP等协议外，还有一些专有协议，如GB/T 32960.3、JT/T 808等。按照国家监管要求，电动汽车的数据首先上传到企业平台，然后逐级转发到新能源国家检测平台。通信数据格式采用GB/T 32960.3标准。JT/T 808标准规定了道路运输车辆卫星定位系统车载终端与监管/监控平台之间的通信协议与数据格式。在使用GB/T 32960.3、JT/T 808或其他私有协议时，若未正确使用，可能造成用户隐私泄露，还会将企业资产暴露在安全威胁之下。

车机安全

车载信息娱乐系统(In-Vehicle Infotainment, IVI)又称车机、中控屏、导航屏，用于实现人与车之间的信息交互。车机从早期功能简单的CD、DVD、导航发展至今，信息化、智能化程度越来越高。车机是整车当中人机交互接口最多的部件，因而攻击点最多，安全威胁风险系数较高。

车机安全威胁

不安全的外部接口

利用外部接口攻击车机，如USB接口、串口、CAN总线等。硬件方面，主板上可能预留有调试接口、UART串口等。通过调试接口进入车机的操作系统做进一步的分析，可以寻找潜在的安全威胁。预留给用户使用的接口通常只有USB接口，采用Android系统的车机的USB接口也常作为调试接口使用。在某车机中多次点击系统版本号可以进入工程模式。在工程模式中开启USB调试，ADB连接之后，发现系统以Root权限运行，可见该车机缺乏基本防护。

不恰当的工程模式

部分车机的隐藏菜单——工程模式存在三方面问题。第一，多数车机的工程模式入口未应用严格的访问授权机制，未授权用户很容易进入车机的工程模式。第二，工程模式中预制功能的权限过大（如开启ADB调试等），可能将车机暴露在攻击者的视野之下。第三，大部分车机可以在工程模式下导出日志，日志中可能含有敏感信息，如进程信息、车机与服务端通信异常信息等。

隐私问题

某些车型工程模式中导出的日志包含个人通讯录。导出用户个人通讯录明显不符合《汽车数据安全管理若干规定（试行）》的要求，用户的个人隐私应得到充分的保护和尊重，企业在收集数据时应做到合理合规。

通过通信信道对车辆数据或代码进行篡改、删除等

Wi-Fi、蓝牙等无线协议存在缺陷，成功利用后可实现任意代码执行，如腾讯科恩实验室发现Tesla Model S使用的Marvell无线芯片驱动存在堆溢出漏洞。另外，如果通信信道中重要数据的传输未进行加密，也容易被监听或遭受中间人攻击。

控制第三方软件

车机上有着为数不少的第三方软件，如导航软件、音乐软件等。第三方应用程序的安全也会影响车机系统的安全。利用信息娱乐应用攻击车辆系统，可导致供应链级别的攻击风险。

滥用或损害软件更新过程

在OTA更新过程中引入恶意软件，可以实现对系统的非法接入。

充电桩安全

随着新能源汽车的高速发展，作为新能源汽车网络重要组成部分的充电桩也得到了快速的发展。各大公共充电基础设施运营商纷纷加快建站抢占市场，各家的安全防范能力参差不齐，而电力作为新能源汽车的主要动力来源，直接关系到大众的出行安全。在研究充电桩安全之前，我们首先了解充电桩的结构，然后分析充电桩存在的安全隐患。

充电桩安全威胁

充电桩安全风险主要体现在以下几方面：一是硬件调试接口保护不到位，降低了攻击者的分析难度；二是厂商开发对各种服务没有进行严格的保护，可能被攻击者利用作为攻击的入口；三是软件开发部署时缺乏安全方面的考虑，容易被攻击者利用，对充电设置、主站以及运营平台构成安全威胁。充电桩体本身潜在的攻击漏洞如下。

针对充电桩调试接口的攻击漏洞：暴露调试接口、易于提取固件、篡改存储介质、获取普通用户权限、权限提升等。
针对开放服务的攻击漏洞：FTP（File Transfer Protocol，文件传输协议）未授权访问、FTP弱口令、SSH（Secure SHell，安全外壳协议）弱口令等。
针对固件的攻击漏洞：获取敏感数据、获取硬编码密码、逆向加密算法、获取敏感API接口、固件降级植入后门等。
针对内存的攻击漏洞：获取内存中的敏感数据（如用户名、密码）、加密Key等。
针对CPU卡的攻击漏洞：通过监听串口数据，获取用户卡片加密密码等。
针对BMS通信协议的攻击漏洞：发送伪造的充电报文，伪装其他用户充电等。
针对通信协议的攻击漏洞：如充电桩与主站之间采用MQTT物联网通信协议，MQTT拥有相对的安全认证体系，但在使用时可能存在配置不当的情况。使用MQTT可能存在的安全威胁有未授权访问、中间人攻击等。

OTA 安全

参考链接

近年来，汽车远程服务、在线升级（OTA）平台、车辆调度平台等业务服务快速发展，用户的规模逐步扩大，日渐成为网络攻击的重要目标。由于车端用户可通过车联网平台进行信息交互、远程操作，一旦遭受网络攻击控制，可被利用实施对车辆的远程操控，造成严重后果。

当前，联网车辆数量和通信需求不断增长。在“车-云”通信场景下，网络隔离不到位、通信协议存在漏洞隐患、访问接入缺乏安全认证等问题突出。“车-设备”通信场景下，受限于设备性能等因素，通信安全认证机制尚不完善，存在拒绝服务攻击等漏洞隐患，可导致 WiFi、蓝牙、智能钥匙失效。

在 OTA 功能实现过程中，云端、车端、通信链路、升级包等关键环节均存在被攻击和篡改等安全隐患。

数据风险

汽车 OTA 带来对已售车型大量应用服务的数据井喷，还面临在保证用户个人信息安全的前提下，企业如何实施数据利用共享，OTA 相关数据如何跨境流通等问题。这些安全风险都对企业的合规管理与创新发展提出新的要求。

用户隐私信息泄漏风险

汽车远程升级整个过程中涉及到云端服务器安全、车端安全、车云通信安全，也关系到生产者、用户及汽车软件供应商等其他主体之间的数据收集、数据传输等多个处理环节。在这些过程之中如果存在网络攻击风险，可能导致 OTA 系统遭受破坏，不法分子可以通过 OTA 系统窥探到用户的隐私信息，如车辆位置、行车路线等行为习惯。同时，第三方应用平台可能存在非法获取其他应用和车载端数据的风险。

数据出境合规风险

随着系列政策文件均提出汽车产生的个人信息和重要数据出境管理要求，智能网联汽车作为重点监管对象，产生的大量数据为数据跨境管理带来新的风险。对跨国企业而言，涉及技术研发的数据免不了出境或远程跨国访问，若分布于各国的数据只能本地存储而无法出境交互，将动摇跨国车企一直以来采取的开发、维护、集中化管理模式，导致车企需重新对一国市场进行单独资源调配，建立和总部一致的技术团队，成本不可估量[18]。因此在车辆售出后，面对远程升级需要的软件版本号、升级包名称、升级时间等决定功能实现的数据如何合法地出境流动仍然存在管理规定不明晰带来的风险。

功能风险

当涉及车辆核心功能如动力、制动和电池管理系统等模块的远程升级时，可能对车辆的功能安全带来新的挑战，升级后的系统将车辆与驾驶人暴露在未知的危险中。OTA 功能安全风险可举例为：

车端升级条件判断不当导致的安全风险

车辆远程升级是一个比较长的过程，而且升级过程中车辆大部分功能可能无法正常使用，所以一般都要求车辆在P档、电池电量充足等一定条件下才能进行。如果车辆对于升级条件的判断存在问题，可能导致在非预想的情况下触发升级事件，对车辆和车内人员人身安全造成威胁。

车端升级失败导致的车辆功能不可用

在车辆升级过程中可能出现断电等异常情况导致升级失败的情况，如果没有对升级失败的情况进行妥善的容灾处理，可能导致车辆无法启动，甚至零部件损坏等严重事件。

OTA 升级软件自身缺陷导致的风险

软件更新后未进行充分验证和测试就直接部署到车辆上，软件自身的缺陷可能会使软件运行出现意外行为，导致系统崩溃、触发车辆失控等安全事故。

软件不兼容风险

在车辆升级过程中，升级软件可能引入新的功能和接口，如果车辆硬件不支
持或不兼容，可能导致升级后系统无法正常工作，造成行车安全隐患。

为应对上述 OTA 安全风险，总体来说，在云平台端可采用证书，签名和加密机制，负责为 OTA 服务平台提供安全服务，包括密钥证书管理服务，数据加密服务，数字签名服务等，保证升级包不会随意被制作和发布，升级包的内容不会被恶意获取。在通信链路端，可通过可靠的物理链路和安全传输协议来保证网络传输安全。在车端，可通过汽车的功能域隔离，划分不同 ASIL 等级，通过冗余设计保证整车的功能可靠性；车辆终端 OTA 组件对升级包进行合法性验证，适配安全升级流程，通过安全启动来保证可信的软件在 ECU 上加载启动运行。

车联网安全专题

前言

基础篇

网联汽车

V2X通信

高级辅助驾驶系统（ADAS）

TBOX

车机

充电桩

IVI

ECU

CAN

LIN

MOST

FlexRay

Ethernet：

ASec

GW

BMS

车联网攻击面

车联网合规要求

车联网安全面检测

竞赛篇

线上赛

CAN总线协议 1 讲

ISO-TP协议 1 讲

SAE J1979协议 1 讲

UDS协议 1 讲

赛题：WDB_2020_Teslaaaaa

总览

过程分析

数据提取

逆向分析

CAN总线协议 2 讲

CAN 总线仲裁

ECU 回复响应码

ISO/SAE 21434

WP29 R155和R156

线下实车漏洞挖掘

CAN总线漏洞挖掘

车机漏洞挖掘

实战篇

CAN通信总线安全

CAN总线协议 3 讲

CAN总线特性

CAN总线的工作

标准帧格式

扩展帧格式

实车上访问 CAN 总线

CAN模拟环境搭建

安装ICSim

安装socketcand

安装Kayak

开始模拟

Savvycan

CAN总线操作

CAN总线威胁

重放攻击

转储 CAN 帧分析

Savvycan的使用

重放攻击

识别仲裁 ID

发送自定义帧

Fuzzing

建议阅读

TBOX 安全

TBOX 安全威胁

硬件调试接口威胁

固件提取威胁

车联网服务平台威胁

公网暴露

CAN总线

协议安全

车机安全

车机安全威胁

不安全的外部接口

不恰当的工程模式

隐私问题

通过通信信道对车辆数据或代码进行篡改、删除等

控制第三方软件