作者: Eric Evenchick 翻译:看雪论坛『智能设备应用』版主:gjden
原文链接: CAN HACKING
一、介绍
我们介绍一个新的系列,那就是CAN和汽车hacking,首先我们介绍CAN协议并讨论汽车网络的工作原理。
1986年,Bosch引入了控制局域网协议(the Controller AreaNetwork protocol),这是专门为汽车内部各汽车ECUs之间的网络通信而设计的。CAN在汽车行业,工业,机器人应用的网络控制方向,成为一种非常受欢迎的选择。从2008开始,美国所有的出售的汽车都必须使用CAN协议。
现代汽车是一种分布式控制系统,它包含一些列被设计来处理专门任务的ECUs。比如,车门控制模块管理门锁和门窗。CAN支持这些ECUs进行通信,通过链接到汽车内部网络,CAN也允许外部系统去执行诊断任务。
汽车中CAN通信的一些例子:
-
发动机控制模块发送当前发动机转速给仪表盘,仪表盘会显示当前的车速。
-
车门ECUs发送一个消息给另外一个车门ECUs来打开车窗。
-
通过诊断工具发送一个固件更新信息给ECUs来更新固件。
CAN的使用通常很少被保证或者没有做安全保障,除了就让其隐没通信外。我们能够使用CAN转USB接口来监听通信数据,然后对其进行解码。我们也可以使用这些工具发送伪造的信息,或者执行诊断动作。不信的是,大部分处理CAN的工具都是专用的,并且非常昂贵。虽然诊断协议是标准的,但是却不是开放的,必须从国际化标准组件进行购买。
下一节,我们会解析CAN帧的结构以及讲解如何对CAN数据进行解码。
二、汽车内部网络
前一节,我们讨论了汽车内部网络如何通过CAN来进行工作的,现在我们深入到协议中并且讲解CAN是如何被使用到汽车行业中。
1. 总线
从硬件的角度来看,有两种类型的CAN:高速CAN(差分)和低速CAN(单线)。高速CAN使用两根线,速度可达1Mbps。低速CAN使用一条线,速度相对低一些,但是实现起来更加廉价。高速CAN用于更为关键的应用,比如发动机控制。单线用于相对次要的事情,比如空调系统和车窗。
在多主机配置中,许多ECUs连接到同一个总线。所有的消息通过总线被广播到每一个ECUs。
一个简化的汽车网络
CAN消息结构
从软件的角度来看,CAN消息包含三部分:ID,数据长度码(DLC)和最多8个字节的数据。ID被用于指定是什么消息,由谁发送。典型的,标准ID有11bits,但也有29bits的扩展ID.ID定义了优先级,ID越小,消息的优先级越高。
DLC是4bits,指定消息中数据的长度。在某些应用中,值为8的DLC一直被使用,没有使用的data字节用0填充。
最后8字节的data包含实际的信息。这段信息的含义可以从ID和DLC来确定。
2. 协议解析与database
为了搞清楚8字节data的含义,ECUs会将data解码成类似于发动机转速,油量,或者制动踏板位置的信号。每一个信号都有开始位和结束位,它们用于从8字节中选择正确的比特位。
不是任何信号和消息都能够通过总线进行传输,所有的ECUs必须事先约定好消息和信号的格式。下图是一个信号表格和一个消息格式图。
Atable of CAN signals that make up a message
Asample CAN message layout
为了帮助程序控制器处理CAN消息和信号,引入了CAN database。这个database包含了所有消息和信号的定义,其中最流行的格式是DBC,DBC是使用向量的方式来描述消息和信号的专有格式(也是基于ASCII数据流)。目前功能比较完善的DBC编辑工具是CANDB++,这是一款免费的可视化的编辑工具(遵循beer协议),其可以支持:
DBC文件的创建
在已存在的DBC数据库中加入消息和信号
传输和接收关系的定义
为CANoe仿真定义环境变量
添加专门的消息进行测试
添加消息来修正ECUs
CANDB++
有了DBC文件,你可以很容易将嗅探到的CAN总线数据进行解码。比如,我们可以嗅探方向盘按钮按下时的总线消息,你也可以通过发送伪造的数据给总线来伪装成ECUs。比如你能够发送一个假发动机转速消息给仪表。
No,this car wasn’t actually doing 8000 RPM.
通过解码数据库可以解决大部分一般性的通信消息,但是在汽车诊断的应用中,另外使用了一个专用的协议。下一节,我们来看看这种协议是如何工作的,以及他们一起有什么好玩的东西可以玩。
三、CAN协议
OBD-II接口
下次,当你坐在司机位时,看看你左膝盖周围,你会找到类似于上图的接口,这就是OBD-II接口。
OBD-II协议不单指CAN协议,它是通过UART,PWM,CAN接口共同实现的。1991年,加州空气资源委员会(California Air ResourcesBoard)需要一个诊断协议用于所有在加州出售的汽车,这时汽车行业有了OBD-II协议。在新型汽车中,该协议一直都是通过CAN协议来实现,所以OBD-II满足你访问多种类型汽车的需要。
ODB-II接口常常被用于读取汽车参数和错误码。通过使用OBD-II访问模块,你可以读取参数ID(PID),其包含了汽车的状态信息。维基百科有一篇很好的文章来介绍OBD-II模块和PIDs.
链接里提供大量OBD-II相关的知识和信息,你可以花20美元购买一个工具来读取错误码并清除发动机检测灯。这里我们不谈论OBD-II的细节(请看维基百科的详细说明),我们讨论一下它的大哥UDS.
1.统一诊断服务(UNIFIED DIAGNOSTIC SERVICES)
虽然许多汽车爱好者对OBD-II都非常熟悉,但是很多却并没有听说过统一诊断服务(UDS)。这是让人遗憾的,因为OBD-II只是UDS的一个子集。OBD-II只允许了一些有限的服务,而UDS却是厂商和技术人员所使用的协议,它提供了所有的服务,包含诊断、校准、固件更新。
UDS有各种不同的服务,比如ReadDataByIdentifier 和 TransferData,这两个服务定义了一个字节的服务ID(SID).从0-0x0f的SID保留给OBD-II使用,剩下由UDS标准定义,部分由厂商自己进行定义。下表是标准定义的UDS服务以及他们的SID(HEX)
UDS服务 |
SID |
DiagnosticSessionControl |
10 |
ECUReset |
11 |
SecurityAccess |
27 |
CommunicationControl |
28 |
TesterPresent |
3E |
AccessTimingParameter |
83 |
SecuredDataTransmission |
84 |
ControlDTCSetting |
85 |
ResponseOnEvent |
86 |
LinkControl |
87 |
ReadDataByIdentifier |
22 |
ReadMemoryByAddress |
23 |
ReadScalingDataByIdentifier |
24 |
ReadDataByPeriodicIdentifier |
2A |
DynamicallyDefineDataIdentifier |
2C |
WriteDataByIdentifier |
2E |
WriteMemoryByAddress |
3D |
ClearDiagnosticInformation |
14 |
ReadDTCInformation |
19 |
InputOutputControlByIdentifier |
2F |
RoutineControl |
31 |
RequestDownload |
34 |
RequestUpload |
35 |
TransferData |
36 |
RequestTransferExit |
37 |
UDS通过使用一个帧结构的发送把数据发送给ECUs。单帧(SF)通常被用于短消息的发送,单帧的所有数据都以6字节长度来存放。如果数据太长,就通过第一个帧(FirstFrame =FF)来开启数据发送,然后通过连续帧(Consecutive Frames (CF))来发送数据内容。帧结构如下图:
The structure of SF, FF, and CF messages
OBD-II只使用SF帧结构,但其他帧结构(FF,CF)也被用于长数据传输,比如固件下载.为了弄清楚这些服务是如何工作的,你需要一个ISO 14229文档,但不信的是,它需要花250美元来购买其PDF文档。与UDS通信的工具也是非常昂贵的。但是,利用一些基本知识,你就能够理解总线的工作原理。
OPENXC
由于UDS是一个封闭的协议,福特的研究员以及创建一个可以和汽车进行通信的开源平台。这个平台就是OpenXC平台。OpenXC提供了一个可以通过CAN从福特汽车上读取数据的协议。
为了使用这个开源平台,你需要一个汽车接口。chipKIT可以和福特开源固件一起使用,此外,你也可以选择购买一个预先构建的解决方案—CrossChasm.一旦汽车接口启动并运行,你就可以通过Android和PPython APIs来访问数据。我们过去已经在hackaday上谈及过OpenXC的话题。
很开心看到汽车厂商拥抱开源项目,并希望福特继续致力于这个开源平台的工作。但是OpenXC协议只可进行只读操作,并且限于小消息的通信。
现在,我们知道了所有关于协议的事情,是该建立一个CAN硬件的时候了,下一篇,我们将会了解,你到底需要一个什么样的硬件在你自己的项目中来使用CAN。
四、组建硬件
1.接线
不幸的是,没有一个标准来进行CAN链接。最通用的高速CAN连接器是DE-9,其中有7个针用于高速CAN,2针用于低速CAN。但是连线方式却是不同的,许多都是不兼容的。
CAN需要一个终端电阻,最好是在总线的末端链接一个120欧姆的电阻。
终端电阻作用:
在通信电缆中的信号反射。在通信过程中,有两种信号因素导致信号反射:阻抗不连续和阻抗不匹配。阻抗不连续(就像高低不平的路),信号在传输线末端突然遇到电缆阻抗很小甚至没有,信号在这个地方就会引起反射。消除这种反射的方法,一般在电缆的末端跨接一个与电缆的特性阻抗同样大小的终端电阻,使电缆的阻抗连续。由于信号在电缆上的传输是双向的,因此,在通讯电缆的另一端可跨接一个同样大小的终端电阻。从理论上分析,在传输电缆的末端只要跨接了与电缆特性阻抗相匹配的终端电阻,就能大大的减少信号反射现象(当然不可能完全消除,世界上有绝对的东西吗?在实际应用中,由于传输电缆的特性阻抗与通讯波特率等应用环境有关,特性阻抗不可能与终端电阻完全相等,因此或多或少的信号反射还会存在)。引起信号反射的另个原因是数据收发器与传输电缆之间的阻抗不匹配。这种原因引起的反射,主要表现在通讯线路处在空闲方式时,整个网络数据混乱。信号反射对数据传输的影响,归根结底是因为反射信号触发了接收器输入端的比较器,使接收器收到了错误的信号,导致CRC校验错误或整个数据帧错误。要减弱反射信号对通讯线路的影响,通常采用噪声抑制和加偏置电阻的方法。在实际应用中,对于比较小的反射信号,为简单方便,经常采用加偏置电阻的方法。
作为练习,你可以把一个120欧姆的电阻并联到CAN总线上就可以了。
工具:
一个比较好的CAN工具可以让你收发CAN消息,使用CAN数据库来解释实时数据,并且可以和CAN协议进行会话。带有这种功能的CAN工具一般都是专用的,并且非常昂贵,但是一些友好的黑客提供了一些廉价的选择。
GoodThopter
基于(Travis Goodspeed)GoodFET的GoodThopter使用MicrochipMCP2515 CAN转SPI控制器来访问CAN总线。该开源硬件工具让你可以使用Python脚本来收发消息。
CAN Bus Triple
CAN Bus Triple设备提供提供一个接口来访问三种类型的CAN总线(低,中,高),并且可以在类似于Arduino的环境下进行编程,其提供的开源代码可以让你测试第二代的马斯达汽车,但可惜的是该硬件并没有开源。
Saleae Logic
Saleae Logic也不是开源的,但它却是非常方便而且便宜的CAN总线嗅探工具。它可以捕包,解码和显示CAN数据包,这对于想要组建你自己的CAN硬件来说,是最有用的。
2. DIY
1)需要的部件
如果你想设计自己的CAN工具,你需要两个东西:CAN控制器和CAN收发器。
CAN控制器产生并且解释CAN消息,市场上有很多微控制器可以作为CAN控制器,比如Atmel ATmega32M1、FreescaleS08D和TITiva C Series。在构建CAN控制器是,你必须使用外部振荡器,内部振荡器并不能满足高速CAN的精度要求。如果你想要把CAN功能加入到已有的微控制器上,那么MCP2515是一个选择,他是一个标准的CAN控制器,他可以通过SPI来与主机进行通信。
CAN收发器可以在控制器和CAN总线之间传输信号,需要两个收发器来分别处理高速CAN和低速CAN,NXPTJA1050可以处理高速总线,ON Semi NCV7356可以处理低速总线和单线总线。
2)电路板
有大量的开发导出板满足CAN控制器的要求。Arduino Due的SAM3处理器就有该类型的控制器,但是板上不带有收发器。你可以选择CAN bus shield,使用Due CAN Library就可以开始工作。
Arduino Due
ChipKITMax32
ChipKITMax32比较类似于Due,它有两个CAN控制器,但是你需要提供外部收发器来和总线交互。还好ChipKIT是OpenXC平台官方支持的项目,你可以获取他们的固件。
看雪众测:http://ce.kanxue.com
—–微信ID:ikanxue—–
看雪学院,致力于安全研究16年!
原文始发于微信公众号(看雪学院):汽车CAN协议hacking