Exploiting weaknesses in a car's electronic systems to gain unauthorised access or control is known as "automotive hacking." The potential attack surface for hackers expands as contemporary vehicles become more interconnected and feature cutting-edge technologies like infotainment systems and in-vehicle networks. Acquiring a solid understanding of the Controller Area Network (CAN) protocol is essential for car hacking.
In the automobile sector, the CAN protocol is a popular communication standard. It offers a uniform method for communication between different electronic control units (ECUs) inside of a vehicle. ECUs are in charge of regulating a number of processes in a car, including the brakes, airbags, engine, and infotainment systems. These ECUs can communicate and plan their activities thanks to the CAN protocol.
The following are some crucial details regarding the CAN protocol as it relates to car hacking:-
CAN messages have a frame-based structure and are composed of an identifier, data, and additional control bits. While the data carries the actual information being delivered, the identifier aids in determining the kind and priority of the message.
Physical Access Requirement:-
An attacker often needs physical access to the car's internal systems in order to take advantage of flaws in the CAN protocol. This can be done via connecting to diagnostic ports or by hacking into other entry points that have access to the CAN bus, like infotainment systems.
Impact of CAN Attacks:-
Attacks on the CAN bus that are successful can have serious repercussions. Critical ECUs, such as those in charge of brakes or steering, could be manipulated by an attacker if they acquire control of them, potentially causing accidents or allowing unauthorized access to vehicle systems.
Bus Arbitration:-
Several ECUs may attempt to transmit messages simultaneously on the CAN bus. The CAN protocol has a bit-wise arbitration technique to avoid conflicts. The first transmission is made by the ECU with the highest priority message identification.
Lack of Authentication and Encryption:-
Reliability and real-time communication, rather than security, were the main considerations in the creation of the CAN protocol. It doesn't have any internal encryption or authentication systems as a result. This leaves it open to numerous attacks, including as replay, spoofing, and message injection.
Types of CAN Messages
Different message types are supported by the Controller Area Network (CAN) protocol for communication between electronic control units (ECUs) in a vehicle. The function and behaviour of the data being transmitted over the CAN bus are specified by these message types. The most typical CAN message types are listed below:
Error Frame (CAN Error):-
An ECU sends error frames to alert the CAN bus of problems or malfunctions. These frames support network fault tolerance and error detection. An error frame is sent by an ECU to alert other ECUs of an error, such as a gearbox collision or data corruption.
Overload Frame (CAN Overload):-
Overload frames are used to signal brief instances of network overload or congestion. An ECU can broadcast an overload frame to alert other ECUs of the issue if it is overwhelmed with data or unable to process incoming messages quickly enough. As a result, other ECUs are able to temporarily lower their data transmission rate.
Data Frame (CAN Data):-
The most used communication type in the CAN system is the data frame. They transfer information and actual data between ECUs. An identifier, which controls a data frame's priority and content, and the data payload itself, which houses the information being communicated, make up a data frame. In accordance with the length of the identification, data frames can either be standard or extended.
Remote Frame (CAN Remote):-
Requesting data from another ECU on the bus is done via remote frames (CAN Remote). A remote frame contains an identifier that denotes the requested information rather than real data. An ECU replies with a corresponding data frame providing the requested data in response to a remote frame it has received.
Error Passive Frame:-
Similar to error frames, error passive frames are also utilised for error recovery. Multiple mistakes can cause an ECU to enter an error state, at which point it can emit error passive frames to show that it is recovering. Resynchronization and the restoration of regular operation are aided by these frames.
These message types enable ECUs to communicate with one another inside the network of the car, along with the IDs and data payloads that go with them. Understanding these message formats is essential for analysing CAN bus behaviour and spotting any flaws or unusual behaviour during car hacking evaluations.
On Board Diagnostics (OBD)-II Connector
The OBD-II connector, located beneath the dashboard of most vehicles, serves as a convenient access point for mechanics to connect their computers and retrieve diagnostic information from the onboard computers during repair or maintenance services.
Most contemporary automobiles have a standardised diagnostic port called the On-Board Diagnostics II (OBD-II) connector. It enables communication with various electronic control units (ECUs) installed in the car and grants access to the vehicle's internal systems. In addition to being utilised for diagnostics, the OBD-II connector is now frequently employed for car hacking and vehicle modifications.
Following are some essential details concerning the OBD-II connector:
Location:-
The OBD-II connector is normally found inside the car's passenger compartment, frequently underneath the driver's side dashboard. The precise location, nevertheless, could differ between vehicle models and manufacturers.
Physical Features:-
The OBD-II connector has an unusual design and includes 16 pins that are placed in two rows. The pins are used to connect an external equipment, such as a programming tool or diagnostic scanner, to the internal systems of the car.
Diagnostic Capabilities:-
Access to numerous diagnostic data and information from the vehicle's ECUs is made possible by the OBD-II port. This includes information about emissions as well as sensor readings, fault codes, and engine performance statistics. Technicians can retrieve and examine this data for the purpose of troubleshooting and maintenance by attaching a compatible diagnostic kit.
Standardized Protocol:-
OBD-II uses a communication protocol that is based on the CAN standard and is therefore standardized. The format and organization of the data transmitted between the vehicle and outside devices are specified by the protocol. It allows diagnostic tools to make precise information requests, watch real-time data, and carry out different control operations.
Automobile Hacking Risks:-
Because of its accessibility, the OBD-II connector has also developed into a possible target for hackers. Attackers may try to exploit holes in the vehicle's systems, send nefarious commands, or get unauthorised access to crucial ECUs by connecting to the OBD-II port. The OBD-II port's security has grown in importance for vehicle cybersecurity.
The OBD-II has 16 pins
Certainly! Here are the definitions of the 16 pins of the OBD-II connector:
J1850 Bus +: Positive line of the J1850 bus (PWM or VPW).
Chassis Ground: Ground connection for the OBD-II system.
J1850 Bus –: Negative line of the J1850 bus (PWM or VPW).
Signal Ground: Ground connection for the signal circuit.
CAN High: High-speed CAN bus communication line.
ISO 9141-2 K Line: Communication line for ISO 9141-2 protocol.
K Line of ISO 9141-2 or Keyword: Communication line for ISO 9141-2 protocol or Keyword Protocol 2000 (KWP2000) protocol.
J1850 Bus: Used for communication on the J1850 bus (PWM or VPW).
CAN Low: Low-speed CAN bus communication line.
ISO 9141-2 L Line: Communication line for ISO 9141-2 protocol.
K Line of ISO 9141-2 or Keyword: Communication line for ISO 9141-2 protocol or Keyword Protocol 2000 (KWP2000) protocol.
Battery Power: Direct battery power to supply voltage to the OBD-II connector.
Unused: This pin is not used in standard OBD-II applications.
CAN Communication: Used for CAN bus communication.
L Line of ISO 9141-2 or Keyword: Communication line for ISO 9141-2 protocol or Keyword Protocol 2000 (KWP2000) protocol.
Battery Power: Direct battery power to supply voltage to the OBD-II connector.
Please note that the functionality of some pins may vary depending on the specific vehicle and its protocols. The pins are standardized, but their functions can be different based on the vehicle manufacturer’s implementation and the communication protocols supported by the vehicle.
Layout for CAN Bus Packets
A Controller Area Network (CAN) bus packet's layout is made up of various fields that each convey a distinct piece of information. A sample CAN bus packet configuration is shown below:
A CAN bus packet consists of a start-of-frame (SOF) bit, followed by an arbitration ID, a data length code (DLC), data bytes, a CRC checksum, and an end-of-frame (EOF) bit.
Start-of-frame (SOF) bit: The SOF bit is a dominant bit that indicates the start of a CAN bus packet.
Arbitration ID: The arbitration ID is a 11-bit or 29-bit identifier that is used to uniquely identify the CAN bus packet. The arbitration ID is used to determine which node has control of the bus.
Data length code (DLC): The DLC is a 5-bit field that indicates the number of data bytes that follow the DLC. The DLC can range from 0 to 8 bytes.
Data bytes: The data bytes are the actual data that is being transmitted. The data bytes can be used to carry any type of information, such as sensor data, control signals, or messages.
CRC checksum: The CRC checksum is a 15-bit checksum that is used to verify the integrity of the CAN bus packet. The CRC checksum is calculated by using a CRC algorithm on the data bytes.
End-of-frame (EOF) bit: The EOF bit is a recessive bit that indicates the end of a CAN bus packet.
The following table shows the layout of a CAN bus packet:
| Bit | Description |
|---|---|
1 | Start-of-frame (SOF) |
11 or 29 | Arbitration ID |
5 | Data length code (DLC) |
0 to 8 | Data bytes |
15 | CRC checksum |
1 | End-of-frame (EOF) |
The CAN bus packet format is defined in the CAN 2.0 standard. The CAN 2.0 standard defines two types of CAN bus packets: standard and extended. The only difference between the two types of packets is the length of the arbitration ID. Standard CAN bus packets have a 11-bit arbitration ID, while extended CAN bus packets have a 29-bit arbitration ID.
CAN bus packets are transmitted in a single-master, multi-slave configuration. This means that there is only one master node that can transmit at a time. All other nodes on the bus must listen for transmissions from the master node. If a slave node wants to transmit, it must wait until the master node is finished transmitting.
CAN bus is a very reliable and efficient way to transmit data between nodes on a network. CAN bus is used in a wide variety of applications, including automotive, industrial, and medical.
In my second blog on this subject, we can look at specific vulnerabilities and attack scenarios outside of the CAN protocol.
0 Comments