Exploring Car Hacking and CAN Bus Systems with Matthew Kinich

Matthew Kinich holds a Bachelor's of Science in cyber security engineering with a focus on automotive and vehicle security. He is a camp bus and vehicle integration specialist who created the open-source tool called the Can Commander.

Matthew Kinich delved deeper into the field of car hacking after creating the Can Commander tool. He decided to make his own device for car hacking and will demonstrate it with videos during the presentation.

Matthew Kinich has engaged with car manufacturers to discuss specific vulnerabilities and solutions. He also consulted independent mechanics to understand their needs for a car hacking device that is more affordable than manufacturer tools.

Car hacking involves manipulating a vehicle's electronic systems by exploiting vulnerabilities in communication networks. It can also involve attacking onboard computers or infotainment systems to gain access or control.

Car hacking allows individuals to understand their vehicle systems, improve security by identifying and mitigating vulnerabilities, and enhance performance by tuning and optimizing the vehicle.

Matthew Kinich emphasizes the dangers of car hacking and warns participants to be cautious as it can cause harm, financial loss, and legal issues if not done responsibly. He stresses the importance of safety and following proper procedures.

The presentation will cover attack vectors in car hacking, providing insights into different methods and techniques used in manipulating vehicle electronic systems.

Car security vulnerabilities include issues with the key and ignition system, such as a vulnerability in the Kia ignition system that allowed jump-starting. Most cars now have immobilizer systems to prevent hot wiring, reducing the risk of theft.

The OBD2 port provides open access to car data, with some manufacturers adding security gateways. However, accessing the OBD2 port and CAN data is still possible, making it a potential attack vector for hackers.

RF side vulnerabilities, such as those related to key fobs, pose security risks. Understanding RF communications is crucial to safeguard against potential attacks on car systems.

Car manufacturers' proprietary infotainment systems may have vulnerabilities that hackers can exploit. Some users can flash their own ROMs, potentially compromising the security of the system.

The learning objectives include understanding CAN communications, the CAN protocol, DBC files for decoding information, reverse engineering CAN packets, and creating payloads for injecting packets into the system.

Participants will learn how to create payloads for injecting packets into car systems, potentially enabling denial of service attacks. Additionally, they will explore man-in-the-middle attacks and adding features to cars, like activating disabled components.

Car hacking involves understanding the Controller Area Network bus (CAN bus) in vehicles, which allows for customization and adding sensors to the car. It is crucial to secure the car against common attacks and understand the significance of car hacking.

To perform car hacking, essential tools include a multimeter, a laptop, and a CAN Commander. The CAN Commander can be obtained with the Flipper Zero module or built using a microcontroller. The development of the CAN Commander involved collaboration with Rabbit Labs, spanning almost a year of effort and significant investment.

The Controller Area Network bus (CAN bus) is a standard for wired connections in vehicles, ensuring data accuracy and integrity. It uses two wires, CAN high and CAN low, for communication between sensors and the car's Electronic Control Unit (ECU). The CAN bus protocol, introduced by Bosch, became federally required in the United States after 2007, guaranteeing its presence in modern cars.

The speaker has a background in working with Bosch and the CAN bus system, which was standardized in 1993. They mention the separation of the data link and physical layer in the CAN system, explaining the classification of data ranges. New technologies like CAN FD (2015) and CAN XL (under development since 2018) have increased data transmission capabilities significantly.

CAN FD, introduced in 2015, allows for transmitting up to 64 bytes compared to the traditional 8 bytes, enhancing security applications. CAN XL, still in development, aims to increase data throughput significantly, potentially up to 256 or 112 bytes. The focus remains on the traditional CAN standard found in most vehicles, with support for CAN FD in some systems.

The OBD2 port provides easy access to a car's communication system without the need for dismantling the vehicle. Located under most steering wheels, it serves as a convenient entry point. Every sensor and device in the car uses the same two wires (CAN high and CAN low), allowing tapping into them for diagnostics and modifications.

Differential signaling is used in CAN bus wires, with CAN high and CAN low maintaining a set voltage of 2.5 volts when idle. When a packet is transmitted, CAN high rises to 3.5 volts while CAN low drops to 1.5 volts. Using a multimeter, technicians can easily identify these wires by measuring the voltage difference.

It is advised not to poke around in wiring systems with the battery connected. However, with the OBD2 port, there is a defined pinout making it safer. Always refer to the car's wiring diagram to locate wires, especially the can high and can low wires which are twisted pairs.

When testing for can wires, connect the positive probe to the can wire suspected to be can high, and the negative probe to a ground like the car chassis. Measure the voltage to identify the can high wire accurately.

The CAN protocol involves an arbitration ID (CAN ID) to signify signals, a DLC (Data Length Code) indicating the number of data bytes, and a data frame containing the actual data. The 11-bit identifier includes the CAN ID, DLC, and data field, simplifying the understanding of the protocol.

Using a CAN controller like the mcp2515, one can extract individual CAN frames efficiently. The controller handles end of frame, start of frame, stuff bits, and CRC, leaving the user with the essential task of extracting and interpreting the CAN data.

The mCP 2515 Can Controller is discussed, which is a bundle of components including the Canas interface with screw terminals for Can high and Can low wires, an 8 MHz Crystal for clock driving, a Can transceiver, a Can controller, and termination resistors for signal stability.

The importance of termination resistors in ensuring signal stability is highlighted, with a mention of 60 Ohms resistance on each Can line. It is emphasized that without these resistors, strange readings and data transmission issues may occur.

The OBD2 connector, featuring 16 pins with standardized functions for diagnostic purposes, is described. The connector allows querying of diagnostic data, but limitations exist in terms of injecting packets for hacking purposes.

The presence of a 12-volt battery line on pin 16 of the OBD2 connector, which remains active even when the car is off, is noted. Additionally, the use of grounds in the connector for device powering and the need for voltage step-down for microcontrollers are discussed.

The significance of Can high and Can low lines, specifically on pins 14 and 6 of the OBD2 connector, is emphasized. These lines are crucial for Can bus communication and can be located under the steering wheel for verification.

OBD2 pigtails found on Amazon contain wires for each pin, but caution is advised as the pin diagrams may not always be accurate. It is recommended to use a multimeter in continuity mode to verify connections and mark wires to prevent accidental voltage mishaps.

When using a 12V connector wire, it is advisable to cut it short to prevent accidental contact with other components. Similar precautions can be taken with ground wires to ensure safety while working with electronic connections.

One method to power a microcontroller is by terminating a 12V wire into an RJ45 ethernet cable and creating a breakout. This approach allows for the utilization of 12V power, but caution must be exercised to avoid potential risks.

Successfully connecting an Arduino Nano to an mCP 2515 breakout board involves wiring the SPI connections, including CAN high and CAN low wires. Power can be supplied from a Flipper Zero device, with data read through a laptop via USB for serial data analysis.

Raw data from the connected devices may not be immediately usable. To decode this data effectively, a DBC file (Database Conversion File) is essential. DBC files provide instructions on how to interpret raw CAN data, enabling easier analysis of vehicle communication.

DBC files are database files that aid in decoding raw CAN data, specific to car manufacturers. While proprietary, some DBC files can be found online, with open DBC being a notable resource. These files follow a standardized format, simplifying the parsing of CAN data without extensive reverse engineering.

The format of the CAN ID for a signal typically contains multiple signals within a single frame or ID. It's not limited to one for the entire eight bytes to avoid wasteful data transmission. Each signal includes information such as signal name, bit start, length, endianness, scale, offset, minimum and maximum values, and unit.

Each signal in the CAN ID specifies details like the signal name (e.g., engine speed), bit start position (e.g., bit 24), length of the signal, endianness (little or big endian), scale (multiplier for value), offset (value added to result), minimum and maximum values, and unit of measurement (e.g., rotations per minute). These details are crucial for interpreting the data accurately.

To illustrate data processing, consider an example where a hex value of 6813 (little endian) corresponds to 1368. By applying a scale of 0.125, the resulting value is 621, matching the expected value. Understanding the scaling, offset, and endianness is essential for correctly interpreting and converting data from hexadecimal to decimal.

Can Commander can parse ABC files, process data from SD cards, and compute raw values from CAN bus data, providing a comprehensive view beyond PID or diagnostic tools.

Reverse engineering signals allows for creating custom DBC files, which can be contributed to the open DBC repository on GitHub, enhancing the availability of vehicle-specific data for others.

DBC files can be found on the Can Commander GitHub page under the 'resources' section, providing detailed information on various car models and their CAN bus signals.

DBC files contain information such as CAN ID, signal names, start bit, length, endianness, scaler, offset, minimum and maximum values, enabling access to a wide range of vehicle data beyond OBD2 readers.

Reverse engineering DBC files is crucial for understanding and utilizing advanced vehicle data like radar sensors, sonar sensors, lane assist, and other critical information not available through standard OBD2 readers.

Extracting necessary information from DBC files allows for writing scripts to parse data effectively, enabling the interpretation of CAN bus signals for various applications like RPM monitoring.

Correctly setting up hardware components like the chip select pin for SPI communication with devices like the mCP2515 is essential for ensuring accurate data processing and device functionality.

Using extracted data from DBC files, it is possible to create functional applications like a tachometer or speedometer by converting analog readings to digital values, showcasing the practicality and versatility of data processing techniques.

The speaker demonstrated reverse engineering an LCD display by tapping into the LCD wires to extract raw data related to RPM and speed. They mentioned adding a progress bar for RPM or speed on the LCD display.

The speaker pointed out the yellow check engine light on the display, indicating a problem with the vehicle. They discussed using a tool to turn off the check engine light and identify the specific issue triggering it.

The speaker described the process of disassembling parts of the car to access a cable for testing. They mentioned removing panels and bolts to reach the connector for the cable.

The speaker explained the reverse engineering process by converting raw data logs into ASCII characters to decipher information displayed on the LCD. They isolated usable data and cross-referenced it to determine the bite position for modification.

After deciphering the communication systems, the speaker mentioned creating a DBC file to upload for others to modify their LCD displays. This process involved reverse engineering the data and making it accessible for customization.

With the obtained information, the speaker planned to write a script for modifying the LCD display. They intended to integrate the reverse engineered data for speed and RPM into the script for further customization.

The speaker modified their car by adding a digital speedometer to the LCD display. The speedometer is fast and accurate as it reads data directly from the raw canas data, not from diagnostics.

The speaker demonstrated the use of the Can Commander module by injecting a message and showing it on the screen. They highlighted the ability to hack the LCD with the module and wire connections using solid copper wire for screw terminals.

The speaker mentioned creating a custom OBD2 to connector for the Can Commander module, allowing direct plug-in to the device. They used solid copper wire for connections and a screw terminal connection for the connector.

The speaker discussed additional features of the Can Commander module, including a custom rabbit lab cc1101 radio transceiver for key fob data matching with can data. They also mentioned a GPS for logging coordinates and the ability to unlock a car without a key using the module.

The speaker showcased real-time data feed on The Flipper zero, demonstrating accelerator readings as they pressed the accelerator. They highlighted the slow response time initially, which improved once the data synced up.

The speaker developed an Android app to interface with the Can Commander module, providing an alternative to using the flipper zero. The app is available on GitHub for download and is written in react native, with plans for porting to iOS.

The speaker implemented a full filtering solution in the Can Commander module, allowing users to filter specific data based on Can ID and export logs. This feature streamlines data analysis for reverse engineering purposes.

A denial of service attack floods the system with garbage data to prevent actual data from being processed. Manipulating the rules of CAN arbitration by using low CAN IDs with higher priority can disrupt the system's functionality.

A man-in-the-middle attack involves intercepting and modifying data exchanged between two parties without their knowledge. By tapping into the CAN bus, attackers can alter sensor data, impacting privacy and potentially misleading systems like insurance trackers.

The speaker demonstrates setting up a CAN Commander using Arduino IDEs with MCP2515 CAN controllers. This setup allows for practical implementation of attacks like denial of service and man-in-the-middle on the CAN bus.

To set up Can Commander, open a web browser and visit the GitHub page or cancommander.com. Download the code from the Arduino environment folder and the Can Commander library. Paste the code into the Arduino IDE, ensure the correct Arduino board is selected, install the library, and upload the code to the device.

One option in Can Commander is to read all traffic on the CAN bus, displaying IDs in HEX and data byte lengths. Users can stop the output by typing 'S'. This function provides insight into the messages being sent and received.

Can Commander offers a speed test feature to measure the message rate, useful for understanding the traffic flow. Users can see the messages per second being sent, aiding in determining the appropriate rate for operations like denial of service attacks.

In Can Commander, initiating a denial of service attack involves entering the 'right' mode, selecting an ID, specifying data byte lengths, setting the payload data, and choosing a transmission speed. By overwhelming the bus with messages at a higher rate, users can disrupt communication and gain priority due to lower IDs and higher data rates.

The speaker demonstrates a denial of service attack by entering an ID of 01 and sending ffs for all eight bytes, causing messages to cover up everything else. This attack can shut down a car by preventing sensors from functioning properly.

The attack message being printed includes both sent and received messages, but on the actual canvas, only the attack message is visible, completely taking over. This attack can disrupt the car's systems, potentially causing the check engine light to turn on and preventing proper system startup.

The speaker emphasizes the simplicity of the attack, requiring a low arbitration ID like one. This attack is potent and can wreak havoc without the need for complex reverse engineering.

The speaker mentions the man-in-the-middle attack, which involves receiving, modifying, and sending data. This attack is similar to the denial of service attack but requires another device for demonstration.

The speaker transitions to discussing features of the Can Commander software for reverse engineering raw CAN data. Features include filtering, tracking values, and automatic ASCII conversion for deciphering data like displays.

To filter traffic, users can enter a mask and a filter in heex. A mask allows filtering a wider range of values, with 7FF representing allowing all bits in the mask. This feature is useful for extracting logs efficiently, such as filtering out unnecessary data streams like Volume Plus 511.

The hardware filtering feature utilizes filter buffers inside the mCP 2515, designed for efficient data filtering. This method reduces the need for post-filtering in higher-level languages like Python, making it easier to analyze and process data streams directly within the controller.

Value tracking allows monitoring changes in data values, such as detecting increments or decrements in specific bytes. By setting filters and masks, users can track and analyze data changes effectively, providing valuable insights for identifying unusual responses or behaviors.

The Diagnostics and PID Manager feature enables users to perform various tasks related to car diagnostics, including checking and clearing error codes, viewing car statistics like speed and RPM, and managing the check engine light. This tool operates using the standard diagnostic query-response protocol through the OBD Port, offering comprehensive diagnostic capabilities beyond basic OBD2 readers available online.

The speaker mentions that in their repository, they have included a variety of resources for accessing car diagnostic information. These resources include a list of available diagnostic PIDs (Parameter IDs) such as oxygen sensors, tank level, and ambient air temperature. The speaker highlights that even though not all cars may support all PIDs, there is a PID that indicates which ones are supported by a specific car.

The speaker explains that the provided resources also include a DBC file that contains information such as bit start, bit length, scale, offset, min-max values, and measurement units for interpreting the diagnostic data. This allows users to understand and interpret the data obtained from their vehicles effectively.

The speaker introduces the functionality of '0x00' that enables users to view all the PIDs supported by their cars. By sending a query, users can retrieve information from the car's system. The speaker clarifies that receiving a response depends on the car's compatibility with the requested PID.

The speaker delves into the programming aspect of sending PID requests. They explain the process of entering a PID request, sending it through a function called 'send PID request,' forming the request payload, and receiving the actual PID response. The speaker emphasizes the importance of understanding the format and structure of PID requests for effective communication with the car's system.

The speaker provides insights into interpreting diagnostic values, such as coolant temperature and engine RPM. While some values like coolant temperature are straightforward, others like engine RPM require scaling and conversion formulas. The speaker demonstrates how to scale and convert values, making it easier for users to interpret and utilize diagnostic information effectively.

The speaker underscores the versatility of the diagnostic tool, mentioning its capability to serve as a basic diagnostic tool and a Commander tool for advanced functionalities. They encourage users to explore the tool's potential beyond basic diagnostics, highlighting its broader applications in automotive maintenance and troubleshooting.

The speaker briefly touches on the advanced functionalities of the diagnostic tool, hinting at its potential for secret extraction and deeper analysis. They suggest that the tool can offer more than just basic diagnostic capabilities, indicating a broader scope for exploration and utilization in automotive diagnostics.