Blog & News

Disclaimer: The elaboration and software project associated to this subject are results of a Bachelor’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

While car manufacturers steadily refine and advance vehicle systems, requirements of the underlying networks increase even further. Striving for smart cars, a fast-growing amount of components are interconnected within a single car. This results in specialized and often proprietary car protocols built based on standardized technology. Most of these protocols are based on bus protocols: All network nodes within such a bus network are connected using a single shared data link. This technology provides a feasible way of real time communication between several security and comfort systems. However, often no or insufficient authentication and encryption or other security mechanisms can be found in today’s car systems. As described previously, most of the interchanged data structures on a car network bus, including associated systems, are proprietary. For this reason, there’s a need for open source, extensible, easy to use and publicly available software to analyze the security state of such networks and protocols.

CAN bus

Starting from mid-1980, the CAN bus is being implemented into vehicles. Still to this day, many components and proprietary protocols rely on the CAN bus. While analyzing today’s car protocols, we focused on this technology – however, there exist multiple additional technologies like FlexRay and automotive Ethernet which will most likely gain an increased relevance and also need to be analyzed in the future.

CAN network packets are defined by the associated packet format, which looks as follows [1]:

• Arbitration ID: Describes the meaning of the data segments
• Control: Flags to manage packet transport
• Data: Payload of the packet with up to eight bytes of data
• CRC: Checksum

A general goal of analyzing car protocols is to reverse engineer the CAN matrix. This data structure maps CAN arbitration IDs and corresponding payloads to specific actions. An example for this is the identification of a CAN packet which controls the acceleration of a vehicle.

Depending on intended goals, the CAN bus can be accessed in two ways:

1. OBD-II interface: Since 2004, this diagnostic interface is mandatory for each car in the European Union. Most of the time, this port can be accessed from the driver’s seat. Inbound packets can and most likely will be filtered by the diagnostic gateway, so fuzzing from this interface can be of limited success rate.
2. Interacting with bus wires: It’s possible to directly splice analysis hardware into a CAN bus. This way, filtering can be circumvented and otherwise isolated bus segments can be analyzed.

Introducing the CANalyzat0r

This Python software project is built from scratch with new ideas for analysis mechanisms. It’s released on GitHub and bundles many features of other CAN tools in one place. Also, it’s GUI based and organized with one tab per specific analysis task:

Most of the existing open source CAN analysis software makes use of SocketCAN. This consists of a bundle of kernel modules that abstract CAN communication in such a way that CAN interfaces can be used similarly to conventional network interfaces on the Linux operating system. So does CANalyzat0r, including many additional features:

• Manage interface configuration (automatically load kernel modules, manage physical and virtual SocketCAN devices)
• Multi interface support: Sniff while sending data on a separate SocketCAN interface
• Manage your work in projects. You can also import and export them in human readable/editable JSON format and track data using a version control system.
• Transparent logging
• Graphical sniffing
• Manage findings, dumps and known packets per project:

• Easy copy and paste between CANalyzat0r modules. Also, it’s possible to paste text based SocketCAN files directly into the GUI to import existing packet dumps:

• Threaded Sending, Fuzzing and Sniffing
• Ignore packets when sniffing - Automatically filter unique packets by ID or data and ID
• Compare dumps
• Allows setting up complex setups using only one window
• Clean organization in tabs for each analysis task
• Advanced packet filtering using an interactive packet replay approach
• Search for action specific packets using background noise filtering
• SQLite support
• PDF and HTML code documentation

CANalyzat0r is modular and extensible – using the provided documentation it’s possible to implement new features which integrate into the existing GUI and work flow.

Usage Examples

Simultaneous sniffing and fuzzing

In order to analyze functionalities of proprietary car components, fuzzing mostly acts as a starting point. Using this approach, CAN nodes can be examined to uncover potential security risks. The CANalyzat0r can be used to quickly setup an efficient fuzzing environment:

1. Connect the CANalyzat0r to the CAN node via SocketCAN and the desired bit rate.
2. In the fuzzer tab, choose the desired options: For example, it’s possible to define a fuzzing mask and a desired packet length range which will be applied to all randomly generated CAN packets:

Also, CAN Arbitration IDs can be fixed while payloads remain variable. Here’s an example:

While random packets are being generated and sent over the CAN bus, it’s possible to use the sniffer tab to trace answer packets. Sniffed packet dumps can be saved, replayed or filtered in further steps.

Semi-automated packet filtering

To exploit and check for packet replay vulnerabilities, it’s often necessary to capture packet dumps while executing a certain task on a car, for example unlocking the doors using the remote control. Once such a packet dump that causes a CAN node to execute the desired task has been captured, it’s mostly desired to minimize such a set of packets. To gain the desired effect on a car’s component, it’s not required to replay thousands of packets every time. In fact, desired actions can usually be performed using only a few particular CAN packets.

For this task, the filtering tab of the CANalyzat0r can be used:

1. Capture “noise” packets: While the desired action is not being executed by the CAN component, packets that pass the bus will be captured. These packets will be useful in further analysis steps.
2. Record an arbitrary amount of packet sets while executing the task once per packet set.
3. Filtering: First, all previously captured noise packets will be removed from each packet set. After that, only packets which occur in every packet set will be shown. This resulting set of packets causes the CAN node to perform the desired task while being heavily minimized.

Packet search using a binary tree search

Large packet dumps often are the result of fuzzing attempts. To assist in filtering relevant packets, the searcher tab of the described toolkit can be used:

1. Load the desired packet dump by using either copy-and-paste mechanisms of the CANalyzat0r tabs, text based packet dumps or database queries.
2. After connecting the CANalyzat0r to the target vehicle, start the searching process.
3. The loaded packet set will be split into small chunks, which are replayed one after another. After one chunk has been replayed, the tool asks the user whether the desired action has been executed by the car. On success, the previously replayed packet set acts as the new base data set and the searching process restarts from the beginning.
4. If no chunk generates the desired output, randomization will be used. This results in shuffled packet chunks which will be used for further retries. Using this approach, actions which require multiple packets to be sent can be identified.

Database management

Once packet dumps for specific results have been identified, they can be saved to the SQLite based database with an associated description. This allows a centralized finding management. Using the JSON based database import and export functionality, database states can be version controlled. It’s also possible to work on multiple CANalyzat0r projects simultaneously by creating separate projects.

Easy setup using docker

To get started quickly, the provided docker image can be used. No dependencies have to be present on the host system and the CANalyzat0r is up and ready using only a few commands. Please refer to the docker folder within the CANalyzat0r repository for additional information.

References

• [1] CAN packet format
• CANalyzat0r GitHub Repository

~ Philipp Schmied