Reverse Engineering of Automotive CAN networks

1. Objectives

Automotive networks are challenging for security research and training because although the protocols of the automotive networks are standardized, the implementation details by each automotive manufacturer are not standardized.

In this lab, students will learn how to monitor the CAN bus, replay selected packets, and identify CAN packets that are responsible for door control, headlights control, and speedometer display.

2. Pre-lab Reading

There are two excellent articles on security of automotive CAN networks. “Experimental Security Analysis of a Modern Automobile” by Kosher et al. [1] experimentally evaluates security issues on a modern automobile and demonstrates the fragility of the underling system structure. The authors demonstrate that an attacker can infiltrate virtually any Electronic Control Unit (ECU) and completely circumvent a broad array of safety-critical systems.

In the paper “Adventures in Automotive Networks and Control Units” [3], Miller and Valasek demonstrate how an attacker is able to control the steering, braking, acceleration and display on two different vehicles. The paper describes all technical information needed to reproduce such attacks. Some of the examples in this lab are derived from this paper.

3. Background

2.1 CAN (Controller Area Network):

The modern automobile may have hundreds of electronic control units (ECU) for various sub-systems and the total amount of wires inside an automobile may be more than 5 miles long. Besides, communication among subsystems becomes more frequent and more environmental data should be shared by multiple devices. All complexity, heavy weight and frequent communication result in the development of Controller Area Network (CAN) Bus.

Figure 1 Automotive CAN Networks

CAN is a central networking system that connects all modules working throughout the vehicle so that they can work together to run effectively and efficiently as automobiles have become more technologically advanced and intelligent. For example, the engine reports the vehicle’s speed to the transmission, which in turn must tell other modules when to shift gears. Connecting all these individual modules to each other became too complex, so a central networking system became necessary to efficiently run the vehicle. The CAN bus is one of these central networking protocol used in vehicles without a host computer.

A vehicle typically has two CAN buses, a high speed CAN bus operating at up to 1Mbps and a low speed CAN bus operating at up to 125 Kbps, see Figure 1. Powertrain system, including engine control, transmission control, gear control etc., is usually connected by the high speed bus. The body control system, including door control, seat control, light control, etc. which deal with passenger comfort and convenience, is usually connected by the low speed bus. The dashboard and OBD II bridge two networks.

For the physical layer, a twisted pair multidrop cable is specified with a length ranging from 1,000m at 40Kbps to 40m at 1Mbps. The maximum payload of a message is 8 bytes, and all messages carry a cyclic redundancy code (CRC). Each message has an identifier, which can be interpreted differently depending on the application or higher-level protocols used. All nodes on the network receive each message and then decide whether that identifier value is of interest.

For protocol layer, CAN is a carrier-sense, multiple-access protocol with collision detection and arbitration on message priority (CSMA/CD+AMP). CSMA means that each node on a bus must wait for a prescribed period of inactivity before attempting to send a message. And CD-AMP means that collisions are resolved through a bit-wise arbitration, based on a preprogrammed priority of each message in the identifier field of a message. The higher priority identifier always wins bus access. That is, the last logic-high in the identifier keeps on transmitting because it is the highest priority. Since every node on a bus takes part in writing every bit "as it is being written," an arbitrating node knows if it placed the logic-high bit on the bus.

The bus access in CAN is event-driven and takes place randomly. If two nodes try to occupy the bus simultaneously, access is implemented with a nondestructive, bit-wise arbitration. Nondestructive means that the node winning arbitration just continues on with the message, without the message being destroyed or corrupted by another node. The allocation of priority to messages in the identifier is a feature of CAN that makes it particularly attractive for use within a real-time control environment. The lower the binary message identifier number, the higher its priority. An identifier consisting entirely of zeros is the highest priority message on a network because it holds the bus dominant the longest. Therefore, if two nodes begin to transmit simultaneously, the node that sends a last identifier bit as a zero (dominant) while the other nodes send a one (recessive) retains control of the CAN bus and goes on to complete its message. A dominant bit always overwrites a recessive bit on a CAN bus. The allocation of message priority is up to a system designer, but industry groups mutually agree on the significance of certain messages. For example, a manufacturer of motor drives may specify that message 0010 is a winding current feedback signal from a motor on a CAN network and that 0011 is the tachometer speed. Because 0010 has the lower binary identifier, messages relating to current values always have a higher priority on the bus than those concerned with tachometer readings.

Figure 2. Standard CAN: 11-Bit Identifier

There are totally four message frames that can be transmitted on a CAN bus:

1. Data frame. It is the most common message type, and comprises the arbitration field, the data field, the CRC field, and the acknowledgment field. The arbitration field contains an 11-bit identifier and the RTR bit, which is dominant for data frames. Next is the data field which contains 0 to 8 bytes of data, and the CRC field which contains the 16-bit checksum used for error detection. Last is the acknowledgment field. (Shown as Figure 2)

2. Remote frame. The intended purpose of the remote frame is to solicit the transmission of data from another node. The remote frame is similar to the data frame, with two important differences. First, this type of message is explicitly marked as a remote frame by a recessive RTR bit in the arbitration field, and secondly, there is no data.

3. Error frame. It is a special message that violates the formatting rules of a CAN message. It is transmitted when a node detects an error in a message, and causes all other nodes in the network to send an error frame as well. The original transmitter then automatically retransmits the message. An elaborate system of error counters in the CAN controller ensures that a node cannot tie up a bus by repeatedly transmitting error frames.

4. Overload frame. This frame is similar to error frame in format and is transmitted by a node which becomes too busy. The primary use of this frame is to provide for an extra delay between messages.

By the definition of CAN and basic frames of CAN message above, it is easy to find where the problem of CAN is. The messages on CAN bus are transmitted to all nodes and each node would accept the message by identifier it is interested or drop it. No one consider where the packet comes from. That is, no authentication is applied during CAN network. It is fine in the past because the network is isolated before and authentication free helps reduces circuit delay. However, the network nowadays supplies more accesses for device to join in which breaks down the isolation. Once one device is hacked, for example media player, the data stream read from CD consisting code-injected messages would moves into network and jeopardize the system deeply because each device would trust every message as long as it has appropriate identifier the device is interested. By the development of wireless communication like Bluetooth and telematics units, the attack would happen covertly. Although on the opposite, no clue where the message comes from makes it hard to understand how network works when sniffing the CAN network without prior knowledge and this does protect whole system to some extent, some previous research has shown that outsiders are getting more and more knowledge of CAN and would fully understand it in the future. It’s just matter of time.

4. Testbed

The automotive network testbed consists of a software package and a hardware platform that can be used for testing and reverse engineering of automotive networks. It provides a packet monitor and a customized packet transmitter that enables students to verify the packet functionalities by injecting the monitored packets to network.

4.1 Software - OCTANE (Open Car Testbed and Network Experiments)

OCTANE can be downloaded directly from OCTANE website at octane.gmu.edu. The download file is an archive of an exe file and a msi file. You can use either of them. When the file is downloaded, double click on it to start the installation process, see reference [4] for detailed installation instruction and software manual.

OCTANE is a software tool which brings cyber-physical security research to researchers and students. It reduces the barrier of entry into the security research and teaching of automotive networks by providing a software package and a hardware framework for the reverse engineering and testing of automotive networks. It provides a platform for security research and teaching by replicating the interactions between the hardware components and control software of the systems so that the user can focus on the security aspects of the automotive network instead of the tool configuration and setup.

Figure 3. OCTANE: Transmit Packet

Figure 4. OCTANE: Bus Monitor

OCTANE is composed of both a software package and hardware framework. The package supports monitoring (shown as Figure 3) and transmitting (shown as Figure 4) CAN protocols and includes many features to enable researchers to reverse-engineer protocols more easily and use shareable XML files that encode these protocols. In the hardware configuration part, OCTANE enables the users to test interactions between automobile devices in reality and test proposed operations in a real automobile environment as well.

4.2 Hardware Platform

For safety reason, we strongly recommend to set up the hardware platform with a stationary car. One way is to elevate the car on jack stands, so that the car cannot move forward or backward but the throttle can be applied to bring the wheel to certain speed.

You can connect a laptop to the car’s standard On-Board Disgnostics II (ODB-II) port (see Figure 4) with a CAN-to-USB interface cable (see Figure 5) to interact with the car’s CAN network.

Figure 4. The OBD II port of a car

Alternatively, the instructors can buy some parts and cable and set up an experimental lab network, see reference [2] for detailed instructions.

Figure 5 A typical simple USB-CAN Interface cable

5. Experiments

The automotive CAN network is broadcast in nature. Each CAN packet has an ID associated with it. Each ECU independently determines whether it is interested in a message based on the ID. In addition, there is no information about which ECU sent the message. Thus, without prior knowledge, it is very challenging to figure out the source or intended receivers of any of the messages.

To figure out what different CAN messages do, we can monitor the CAN bus and capture what new messages are being transmitted when we take certain actions (e.g. open and close the doors, turn on and off lights), and then replay them to see if the car will respond.

However, it is very demanding to reverse engineer the whole protocols. OCTANE reduces the barrier to reverse engineering and testing of automotive CAN networks. It enables us to replicate the interactions between hardware components and control software of the systems. In addition, OCTANE has the ability to replay and fuzz test different automotive network protocols.

In this lab, students will learn how to monitor the CAN bus, replay selected packets, and identify CAN packets that are responsible for door control, headlights control, and speedometer display.

5.1 Monitoring

Figure 6 shows the CAN bus monitor interface with OCTANE. The CAN bus monitor interface outputs the received packets and allows for transmission of packets back to a network.

Figure 6: Screenshot of the bus monitor interface of OCTANE

To capture the CAN packets, you will need to activate the sniffing feature by selecting BM from the menu and click on Monitor Bus as showed in Figure 6. If the software is connected to the car, as soon as the Monitor Bus button is clicked, packets show up in the monitor bus table.

It can be stopped by stop monitor button. Clear interface will clear all the packets that are received or sent from the monitor bus.

Furthermore, if you want to keep track of the changes in messages of a certain ID, you can add an ID filter by clicking the Receive Filter tap, input the CAN ID, and then click on Apply Filter button. Figure 7 shows the output after the ID filter “750” is applied. This will be very useful in understanding and reverse engineering the meaning of packets.

Figure 7. Add an ID filter

5.2 Identify the packets that display doors are ajar or closed

Turn on the Monitor Bus, open and close the driver’s side door several times and check packets captured.

A lot of packets will be captured. However, with careful analysis and several trials, you should be able to identify the packets that show doors are ajar or closed.

Every car is different. The exact packets for the car you use will most likely be different. The following are examples on the CAN bus of some Ford vehicles.

When all doors are closed, the following packets will be transmitted every two seconds:

ID: 3B1, Length: 8, Data: 00 00 00 00 00 00 00 00

When the driver’s side door is ajar, the following packet will be transmitted:

ID: 3B1, Length: 8, Data: 80 00 00 00 00 00 00 00

5.2.1 Replay the packet

To verify, we can replay the packet and see if the car will respond. You can select the identified packets on the Monitor Bus and send the exact packet using Transmit Selected Packet button, see Figure 6.

When all doors are closed, transmit Door Ajar packets and see if the dashboard will show that door is ajar. When a door is ajar, transmit Door Closed packets and see if the dashboard will display all doors are closed. If the car does not respond, continue to try other captured packets, until they are verified.

5.2.2 Name the packets

Once a packet is identified, you can give it a name and add it to an XML filter file. This could be very useful to work collaboratively to identify the packets and share it with other users.

Figure 8. Identify a Packet

To name a packet, you can take the following steps, see Figure 8:

1. Choose the identified packet from the monitor bus

2. Click on edit -> Identify Packet to bring up the Identify Packet window

3. Choose the Car Type that you want to add the packet to

4. Give it a Name

5. Add

5.3 Turn on and off the headlights with CAN messages

This exercise is very similar to the previous one. We will identify the packets that turn on and off the headlights.

Turn on the Monitoring Bus, turn on and off the headlights several times and check packets captured.

Replay some of the captured packets, when the headlights switch is in the AUTO state. After several trials, you should be able to identify the packets that can turn and off headlights.

For some Toyota cars, the following packets can be used to turn on and off headlights, when the switch is in the AUTO state.

#Turn headlights ON

ID: 750, Length: 8, Data: 40 05 30 15 00 40 00 00

#Turn headlights OFF

ID: 750, Length: 8, Data: 40 05 30 15 00 00 00 00

5.4 Display falsified speeds on the speedometer

In this exercise, students will learn how to manipulate the speedometer to display a falsified speed.

When a car is moving, packets responsible for displaying the speed on the speedometer will be continuously generated. Those packets are relatively easy to identify, since they all have the same ID, but data portions are constantly changing.

Again, every car is different. Packets that are responsible for displaying the speed on the speedometer in some Toyota cars are as follows:

#When idle

ID: 0B4, Length: 8, Data: 00 00 00 00 00 00 00 BC

#When moving about 10 miles per hour:

ID: 0B4, Length: 8, Data: 00 00 00 00 8D 06 66 B5

5.4.1 Display arbitrary speed on the speedometer

Once packet ID is identified, we can change the data portion and display arbitrary speed on the speedometer, even when the car is idle.

Figure 9. Transmit Modified Speedometer Packets

When the car is idle, try the following step:

1. Select the identified speedometer packet

2. Click on Transmit Modified Packet button. Once we do that, the transmit packet window is going to pop up with the packet values in it, see Figure 9.

3. Modify the data portion of the packets, don’t change the ID.

4. Click on Transmit packets.

5. Repeat the above steps several times, identify the packets that make the speedometer display various different values, such as 10 mph, 30 mph, 50 mph, 70 mph.

References

[1] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage, “Experimental Security Analysis of a Modern Automobile,” IEEE Symposium on Security and Privacy, Oakland, CA, May 16–19, 2010. 

[2] P. Borazjani, C. Everett, and D. McCoy. "OCTANE: An Extensible Open Source Car Security Testbed." Proceedings of the Embedded Security in Cars Conference. 2014.

[3] Charlie Miller and Chris Valasek, “Adventures in Automotive Networks and Control Units,” DefCon 21, July, 2013, Las Vegas, NV, USA. http://illmatics.com/car_hacking.pdf

[4] http://octane.gmu.edu/help/octane-quick-guide.pdf, “OCTANE Quick Start Guide,”