我觉得接触车联网更重要的是要先学会CAN总线的知识，所以就从CAN（UDS方向）开始好了，为了避免浪费大家时间，先放出目录：

下面正式开始

车内CAN通信

早期的汽车控制

在很久以前车刚被造出来的时候，功能单一，只有踏板离合转向控制，其中离合器通过机械连接传递发动机的动力，而制动系统则通过简单的机械连接（比如开关）来控制制动动作。随着单片机的普及，车内功能越来越复杂，零部件越来越多，简单的机械控制已经满足不了车辆的运行，于是CAN总线（Controller Area Network）诞生了。

CAN总线

大量的ECU（Electronic Control Unit）被引入汽车，为了管理和协调这些ECU之间的通信，博世公司在1983年开发了控制器区域网络系统，也就是CAN总线。CAN的首次应用是在奔驰500E的车型上。下图为比较经典的CAN架构示例

CAN高低

车上的CAN总线通常为双绞线，两根线分别是高电平数据传输线和低电平数据传输线，也就是平常说的CAN_H（CAN_High）和CAN_L（CAN_Low）。

两根线的主要原因是为了实现差分信号传输，增强抗干扰能力和提高数据传输的稳定性，总的来说，这个设计是为了在复杂的电磁环境中实现稳定、可靠的数据传输，确保汽车电子控制系统的高效运行。

TIPS

有时候线束一大把却没有线束定义，可以参考口诀“黄高绿低”，即业内一般把黄线用作CAN高，绿线用作CAN低

CAN波特率

为了确保车内零部件之间数据传输的同步性和可靠性，CAN总线使用波特率来表示速率。CAN协议支持不同的通信速率，以满足不同的应用需求，低速CAN的通信速率范围为10~125kbps；高速CAN的通信速率范围为125kbps到1Mbps（这里的高低指的总线传输速率，不是CAN_H/CAN_L，CAN_H/CAN_L指的是连接CAN接口用来做数据交换的两根数据传输线）

CAN报文

扩展帧和标准帧

在总线中传送的报文，每帧由7部分组成。CAN协议支持两种报文格式：标准帧和扩展帧。标准格式的CANID为11位，扩展格式的CANID为29位，比如：

标准帧：ID区间是0x000-0x7FF（换算成10进制就是0-2047），7FF转换为二进制就是11111111111（11位）

扩展帧：ID区间是0x000000-0x1FFFFFFF（换算成10进制就是0-536870911），1FFFFFFF转换为二进制就是1111111111111111111111111111111（29位）

报文识别

请求

在CAN总线中，标识符用于定义报文的优先级和寻址，标识符后带的就是数据字段，按照预先设计开发的功能进行请求响应。以扩展帧18DBFFF1#0210030000000000为例，在数据部分中，报文格式可以进一步细分：

02：02 表示该帧的数据长度为 2 字节，意味着本次传输的数据实际只有 2 个字节，即1003。注意该帧需要随着请求的长度进行变化，要发送几个字节就是零几，比如发送10 03两个字节就是02 10 03，同理，发送27 02 11 22就是4个字节，用04 27 02 11 22；
1003：1003 是发送的数据内容，分为服务ID+参数。在UDS协议中，这是诊断服务的请求和参数。例如，10表示会话控制服务，03则是参数，表示具体的会话类型，1003即切换扩展模式；
0000000000：为了使数据字段达到CAN帧的标准8字节长度，填充部分设为00

响应

有请求就会有响应，CAN(UDS)的响应分为“肯定”和“否定”响应，否定响应的格式组成为数据长度帧+7F+具体响应码。以扩展帧18DBFFF1#0210030000000000为例，请求后的“肯定”响应为0250030000000000，意思是设备已切换到扩展模式；“否定”响应为037F101100000000（数据长度会随着响应内容长度变化），意思是10这个服务没有做进去；再举个例子：18DBFFF1#0227010000000000，请求后的“肯定”响应为0667011122334400，意思是请求的种子是111223344，“否定”响应为037F2711，意思是27这个服务没有做进去。下图为相关“否定”响应码的解释

观察“肯定”的响应报文我们会发现，服务ID会比发送的多40，比如发送27 01 ，响应则是67 01 ，发送1003，响应则是5003，了解这个规则有利于查找对应的响应报文，判断设备功能和通信状态

TIPS

以扩展帧的CAN通信为例，在不知道CANID的情况下，通常可以尝试先发送18DBFFF1确认通信地址，比如发送18DBFFF1，回复的是18DAF1EE，其中18DB回复对应的标识符18DA，回复的EE是通信ID，所以后续要跟EE进行通信，最终通信地址就是18DAEEF1：

18DAEEF1#0210030000000000

CAN通信

在大概了解CAN总线之后我们回归问题，车内零部件之间是怎么通过CAN通信的？

把整个架构看做是一个局域网，每个ECU当做一个节点，我们发现GW（网关）处于第一层。因为ECU处于不同CAN域以及协议不一致等原因，有些零部件需要通过GW来转发CAN报文。很多汽车中，通常还有一个VCU（整车控制器）也负责域内CAN转发。

以打开雨刮器为例：司机在方向盘或中控屏操作雨刮器开关后，首先面板会发出一段指令，这里假设是18DBFFF1#0000000000000000，指令会通过GW或VCU转发给雨刮器（看下方TIPS解释），雨刮器再做出肯定响应回复，然后开始执行动作；再举个打转向灯的例子，操作转向灯面板后，会通过GW或VCU发送18DBFFF1#0000000000000000（假设）给转向灯，转向灯回复肯定响应然后做出动作，并把状态信息通过GW或VCU转发给仪表，最终在仪表显示转向灯正在闪烁

TIPS

CAN的收发采用的是广播模式，不是单独给谁发送数据，也就是说，CAN总线上的消息是广播到所有节点的，节点会预先配置好要接收哪些ID的消息，只有当消息的ID符合节点配置的过滤器条件时，该节点才会处理这条消息。比如，假设有一个简单的CAN网络，包含三个节点A、B和C：

节点A配置为发送ID为0x100的消息。节点B配置为接收ID为0x100的消息。节点C配置为接收ID为0x200的消息。

在这种情况下：

当节点A发送ID为0x100的消息时，总线上的所有节点（包括节点B和节点C）都会接收到这条消息。
节点B会处理这条消息，因为它配置了接收ID为0x100的消息。
节点C不会处理这条消息，因为它配置了只接收ID为0x200的消息。

优先级

万一冲突了怎么办呢？在CAN总线通信中，冲突（即多个节点同时尝试发送数据）是通过一种称为“非破坏性仲裁”的机制来解决的

非破坏性仲裁机制

1、发送开始：

当一个节点开始发送消息时，它会首先发送一个起始位（Start of Frame, SOF），然后是标识符（ID）。

2、监听总线：

在发送过程中，每个节点都会监听总线上的信号。如果一个节点检测到总线上的电平与其发送的电平不一致，这意味着另一个节点也在发送消息，并且该节点发送的标识符具有更高的优先级。

3、仲裁过程：

仲裁基于标识符的值。标识符越小，优先级越高。如果两个节点同时发送消息，它们会在发送标识符的过程中进行仲裁。标识符是逐位发送的，当某个节点检测到其发送的位与总线上的位不一致时，它会立即停止发送并进入接收模式。

4、继续发送：

优先级高的节点（即标识符较小的节点）会继续发送其消息。优先级低的节点会放弃发送，并等待下一个机会重新发送。

上面整个仲裁过程是自动的，不需要人工干预，我们只要知道标识符越小，优先级越高就行

TIPS

说到这里，我们已经能发现一些问题了：节点根据优先级处理消息，那么攻击者可以通过一直高频发送高优先级的报文来占用通信通道，造成通道拥堵，最后导致业务无法正常通信、服务不可用，这类操作也俗称DOS（Denial Of Service）攻击

外部接口

OBD（On-Board Diagnostics）接口，即车载自动诊断系统接口，如果把一辆车当做是一台电脑，OBD则可以看做是一个USB接口，该接口可以用来连接车辆进行内部通信。乘用车（小轿车、9座以下小客车）通常在主驾位方向盘下方有且只有一个OBD接口。当然，也可能还存在其他暴露的连接线可以直接连接

商用车（客车、货车）则是不固定，一般位于方向盘下、副驾抽屉、副驾座椅底下等，如果是公交车，一般位于中控仪表下方。部分车可能还存在调试CAN接口，需要打开后盖查找

车载以太网通信

车内

车内以太网通信是一种在现代汽车中越来越受欢迎的技术，用于连接车辆内部的各种ECU和其他设备。与传统的车载网络（如CAN、LIN和MOST）相比，以太网提供了更高的带宽、更低的延迟以及更好的灵活性。车内以太网含有多种协议，下面以DoIP为例

DoIP

DoIP（Diagnostics over IP）是一种在以太网上进行车辆诊断的标准协议（基于TCP/IP协议栈）。其允许通过以太网接口进行车辆诊断和软件更新，具体的通信流程如下：

1、发现阶段：诊断设备发送广播请求，查询网络中的所有ECU。ECU响应请求，返回自己的逻辑地址和其他相关信息。
2、连接建立：诊断设备选择一个目标ECU，并与其建立TCP连接。通过TCP连接发送诊断请求和服务调用。
3、诊断通信：通过TCP连接进行诊断数据的交换，包括读取故障码、执行特定的诊断功能等。
4、断开连接：诊断完成后，关闭TCP连接。

TIPS

常见的还有HTTP、MQTT等等。。因为懒得打字整理的原因不一一解释了，负责的场景可能不一样，但是流程大体上差不多

车外

与车内通信不同，车外通信有多种场景，考虑人机交互，此处分为车云通信及无线遥控

车云

车云常见的有HTTP、MQTT、FTP协议，主要负责OTA升级、事件上报、远程控制等与云端交互的模块。涉及的场景一般在车机（也称IVI，In-Vehicle Infotainment车载信息娱乐系统）、APP

TIPS

车机一般不能直接上网（除了连接热点），通常依赖于TBOX（Telematics Box车载远程通信设备）的4G/5G模块。平时APP控制车辆、OTA升级都是通过TBOX来接收和处理指令的

无线射频

无线常见的技术有RF（传统的遥控钥匙（Remote Key Fob），用户按下钥匙上的按钮来解锁或锁定车辆）、NFC（Near Field Communication，如特斯拉卡片钥匙）、蓝牙（车机连接、无钥匙解锁车辆）等

TIPS

之前说的车内通信，除了CAN、LIN之外，一些零部件间也会用到无线技术，如TPMS胎压监测（Tire Pressure Monitoring System），大概流程就是类似每个轮胎内部或外部安装一个传感器，传感器测量轮胎的压力和温度，然后通过无线信号将这些数据发送到车辆的接收器

了解了车的内外通信后，我们就可以把资产划分为几部分来做信息收集，按难度等级来做进一步测试：

1、需要接触车辆的2、不需要接触车辆的

需要接触车辆

OBD接口：CAN、OBD转以太等等；IVI：热点、蓝牙、系统服务等等；USB接口：ADB等等；零部件（需要拆卸车辆）：芯片、调试接口等等；其他

不需要接触车辆：

云端：OTA平台、故障平台等等；车控：APP、无线遥控等等；其他

按照两种类型的资产划分，继续细分可以找出如下图所示的对应功能

按照功能划分，可以梳理出如下图所示不同层面的协议栈

按照我们的测试目的，下一步就可以选出需要测试的资产。比如目的是为了拿到车辆权限，则可以划分出下图所示红框标出的几个不用拆车且容易攻击的功能资产

思路

WIFI：

通过扫描WIFI IP来探测系统开了什么服务，比如SSH、Telnet、FTP或ADB等调试端口，通过这些暴露面做进一步攻击，如可以尝试未授权访问、口令爆破等手段获取Shell权限。

USB：

有些USB接口只允许充电，不识别U盘，但有的USB接口不但识别U盘，还会自动执行U盘内的可执行脚本、执行特定名称或后缀的文件，所以可以对此行为发起文件名或后缀Fuzz尝试。除此之外，有的接口还可以直接连接到车内系统

APP：

许多车控APP里都有通过VIN码、手机号绑定或分享钥匙的功能，可以尝试通过APP的文章评论或其他页面获取个人信息，然后利用越权来分享钥匙，或绑定VIN码，从而控制车辆。当然，通过其他漏洞拿下服务器再控车也没毛病，这里只是大概说一下

IVI：

隐藏按钮 - 车机一般会有几个隐藏按钮，通过连续点击特定位置就可以打开有关调试工具或工程模式；拨号暗码 - 除此之外，还可以通过拨号暗码（如*#xxxx#）来打开某些调试工具或工程模式；联网功能 - WIFI热点功能可参考上述说过的尝试。如果可以上传工具，可以上传如Tcpdump来抓取车机流量，有时候会存在很多未授权的链接可以利用；APP - 车机里的APP有许多是车企自研的，可以脱下来反编译查看有无可利用的点

OTA：

固件篡改 - 可以在闲鱼或其他渠道获取特定车辆的固件然后进行篡改，把篡改的固件重新刷入车辆固件降级 - 此方法适用于固件无法篡改时。类似WEB里的供应链攻击，在其他渠道获取固件后做分析，查看有可无利用的缺陷，有时候旧版本存在缺陷但是新版本没有，可以尝试刷入旧版本软件来利用

其他

还有一些要有复杂前提条件才能做测试的，比如需要拆卸车辆或需要得到某个东西的点：

调试接口 - 黑盒测试不会有引脚定义，可以通过查询芯片上的丝印（一般在datasheet文档）来测量引脚，找到调试接口后，如果是JTAG，则可以连接读取芯片数据，UART则可以登录内部系统（如果遇到需要密码，可以尝试修改bootargs来绕过）

固件提取 - 没有调试接口时，可以尝试把芯片吹下来使用编程器提取固件；

射频钥匙 - 拿到钥匙后可以尝试使用HackRF、bladeRF等来录制信号然后重放；

CAN - OBD接口（可能会存在OBD转以太）接入后可以测试UDS和重放等问题；

蓝牙 - 利用一些开发版实现中继（如BLE Relay）和重放

横向

前面说到IVI联网依赖于TBOX，所以一辆车里可能会存在多个网段，在拿到shell权限后可以尝试进行横向攻击（此时跟常规内网渗透无异，还需要考虑提权问题）

Tips

有时候电脑连接车机热点做横向渗透时会遇到网段隔离，可以利用反向思路通过让车机连接手机的热点来绕过隔离策略

案例

因为涉及保密，有些现实画面就不放出来了

案例一

拨号打开ADB，连接车机脱APK，在其中的一个APK中发现OBS硬编码，直接接管OBS，可以用来下发更新

翻看系统日志，找到升级日志，从日志中找到OTA下载地址

固件包解包重挂载后可以获取车机文件系统

案例二

逆向分析车控APK Frida hook 实现车辆功能控制

案例三

APK硬编码MQTT，连接可以监听到OTA升级包和所有车辆位置信息

案例四

因为保密关系，很多画面都是看到车或者零部件主板的，所以还有很多很好玩的东西（怎么解锁开车门控车什么的）就不一一分享了

列举车辆测试常用工具集合

这里只是列举了部分，实际还有很多，感兴趣的可以看下这个项目，刚转车联网安全的时候弄的基于ubuntu的集成系统，各种环境工具都在里面了，开箱即用：

https://github.com/TianWen-Lab/TranSec

转车联网安全干到现在已经有1年了，给人感觉最主要的还是需要有通信协议和二进制知识。有的名词解释因为人懒用的GPT生成的，注意辨别。车内通信除了CAN还有很多协议就不全写了，感兴趣的可以根据提到的名词去搜。文章的图不全是自己的，有的是网上+项目报告或者同事的

也是一时兴起，写到后面感觉没啥兴趣写了，也有自己菜的一部分原因，不知道写啥了，等后面越来越牛逼了再补充吧。感谢天问实验室所有的同事给予的帮助。文中有不对的地方希望您可以想方设法联系到我然后帮忙指正。别骂，不好的评论我会删

最后的最后，如果有时间会继续更新有关测试相关的东西，谢谢你的观看