Car Hacking: The Ultimate Guide! – Part I by Anastasis Vasileiadis
Car safety is really exciting and is an interesting topic of study for many safety researchers. With the arrival of Self Driving cars like Tesla, car safety will only become more important. When you drive a car today, you are driving an extremely powerful computer that happens to have wheels and a steering wheel.
At the core of all this is the Controller Area Network or simply CAN (also referred to as the CAN Bus), a central nervous system of a car responsible for communication. Today’s article is about hacking a car with CAN reverse engineering packages.
The ICSim package by Craig Smith will be used for the practical use of the CAN-Bus. ICSim includes a dashboard with speedometer, door lock indicators, turn signals and control panel. The control panel allows the user to interact with the simulated car network, applying acceleration, brakes, controlling door locks and turn signals.
Table of Contents
- Part 1: Setting up the virtual car
- Prerequisites
- Introduction to CAN
- CAN operation
- Note that, Lower ID = Higher priority.
- What if CAN was never invented?
- Why should you care about CAN?
- Hardware and software required to access CAN via OBD
- Utensils, accessories
- Macchina M2
- CLX000
- Software
- Setting up the virtual environment
- The instrument simulator requires SDL libraries
- CAN Utils installation
- Download the instrument simulator
- Preparing the virtual CAN network
- Run the Simulator
Part 1: Setting up the virtual car
The primary purpose of this guide is to help you begin to understand car insurance. The difficulty in Car Hacking is much higher compared to other security fields.
While Car Hacking and Automotive Security is a much broader field, this guide focuses only on the Controller Area Network (CAN) and is limited to Sniffing CAN traffic, analyzing it, doing reverse engineering and performing replay attacks on cars.
Car safety is really exciting and is an interesting topic of study for many safety researchers. With the arrival of Self Driving cars like Tesla, car safety will become more important.
When you drive a car today, you are driving an extremely powerful computer that happens to have wheels and a steering wheel.
While it is true that we will perform this attack / seminar on an instrument cluster simulator, this could very well be done on a real car with extra hardware. I will talk about the extra material required at the end of this article.
The purpose of this article is to help you get started learning car safety or car breakdown easily, without spending a lot of money on hardware. The article simply aims to help you get started with hacking a car into a simulator.
In this article you will learn
- CAN operation
- Gaining access to CAN via OBD-II
- Sniffing CAN Traffic
- Analyzing and reverse-engineering CAN Traffic
- Replay Attack
- Denial of Service in CAN [Part 3 TODO]
- Playing with CAN packages using Python
Prerequisites
In this tutorial, you will need:
- Any Linux distributions (I will use Ubuntu)
- Can-utils
- ICSim (ICSim is an open source car simulator)
and you can download it from the address https://github.com/zombieCraig/ICSim
Introduction to CAN
The Controller Area Network aka CAN is the central nervous system that allows communication between all / certain parts of the car.
Before CAN was first developed by BOSCH in 1985, as an in-vehicle communication system, car manufacturers used point-to-point cabling systems. As we started to have more and more electronic components in cars, this became bulky and very expensive to maintain. This problem was later corrected by replacing it with CAN.
Simply put, CAN allows different electronic modules in cars to communicate and share data with each other. The main motivation of the CAN proposal was that it allowed communication of multiple ECUs (ECU = Engine Control Unit = Car Control Unit) with only one cable. A modern car can have up to 70 ECU.
In a car, you can have accessories such as engine control unit, airbags, gearbox, gear unit, anti-lock braking system or just ABS, infotainment systems, air conditioning, windows, doors, etc. To communicate between all these units their point-to-point wiring would be quite bulky. Imagine, every element connected to every other element, this would be a real mess for diagnosis and troubleshooting. But with CAN, this can be replaced with a single cable and communication between each unit is much simpler.
CAN-Bus could be considered as a slower version of Ethernet LAN except that the traffic is UDP and not TCP.
It is worth noting that not all car control systems use CAN and also CAN is not the only communication protocol used in a car system.
There could be other protocols such as Bluetooth, GSM / LTE networks, satellite radios, LIN etc. Be aware that CAN is not the only program that can be attacked. There are many more.
CAN operation
A car can have multiple nodes that are able to send and / or receive messages. Each message essentially consists of an ID, which is a priority of the message and can also contain a CAN message that can be eight bytes or less.
If two or more nodes start sending messages at the same time, the messages sent with lower ID will replace that of the higher ID. This is called priority-based bus arbitration. Messages with numerically lower identifiers (IDs) are a higher priority and are always sent first. This is how a node locates and places the highest priority messages on a channel.
Message from the brakes takes precedence over a message from the audio player.
Note that, Lower ID = Higher priority.
If two or more nodes start sending messages at the same time, the messages sent with the dominant ID will override those of the less dominant one.
The CAN bus consists of two different cables. As it is a bus, many devices can be connected to these cables. A CAN framework has 3 main parts:
- Arbitration Identifier
- Data Length Code
- Data field
Let’s take a look at the CAN data framework:
What if CAN was never invented?
A logical question that may cross your mind is why the CAN system, while there are many other ways that can be easily implemented? Before the invention of the Can-bus, automakers used point-to-point cabling systems. So if you have three parts in the car, all three parts were connected to each other with a triangular wiring system from point to point.
Consider these three elements are the steering, the gearbox and the ABS. Now in a standard point-to-point wiring system, you need the steering system to be wired with the gearbox and ABS so that everything is connected. Also, the gearbox should be connected to the ABS and the steering system, with a bunch of cables.
This is perfect for cars with fewer components. Can you imagine it in a modern car that has up to 100 different ECUs and other components? As well as being a chore, it would also be impossible to detect faults in the wiring system, (if any), the diagnosis would be a real nightmare and very costly.
That’s when carmakers came up with the idea of CAN.
The point-to-point wiring problem can be replaced with two cables, i.e. CANH and CANL, CAN HIGH and CAN LOW respectively. Now, this way communication is much faster, simpler and very easy to diagnose.
Why should you care about CAN?
It is because CAN is used in almost every car, this is required by law, so CAN will not stop being used soon. Also, the CAN bus was not developed with modern security in mind.
To access your car’s CAN bus, you must have access to the cab diagnostic port, also known as the OBD. While there may be hundreds of other diagnostic standards and ports, basically all cars these days use the OBD-II. This is exactly what your car mechanics use to diagnose damage to your car.
OBD is the most direct access to CAN. Locating OBD-II is fairly easy. This is somewhere near the front passenger or driver’s seat. And it should be accessible without the need for a screwdriver.
This is exactly what an OBD looks like.
If you are wondering about OBD pinouts, see in the picture below what all these OBD port pins are.
If you look closely, pin 6 and pin 14 are the same CANH and CANL I mentioned earlier.
Hardware and software required to access CAN via OBD
To interact with the CAN bus, since you already know that you need an OBD port, you need something like a “USB to CAN” adapter, because your computer can not “talk” directly to the CAN.
You need something, that is, to connect to the OBD-II port and on the other hand to a USB port, so that you can send / receive CAN packages. Also as software, you need something that can read and / or write CAN packets as well as encode and / or decode CAN packets. With a little hardware and software, you can definitely get into CAN.
Utensils, accessories
The hardware required to connect to the OBD-II can easily be found on the market. There are expensive as well as cheap devices. High-end devices include Kvaser and EMS, which are expensive and overpriced.
You can get a USB2CAN, which is an interface for Linux that offers great value for money. Value 60 euros.
You will also often come across these devices based on ELM327 and Bluetooth. They are very bad for hacking because they have slower data rates and you will end up losing too many packages. But their value is about 10 euros.
Macchina M2
The Macchina M2 is my personal favorite (worth 85 euros). The Macchina M2 is an open source car interface that allows you to communicate with the CAN bus via OBD-II. The best part about the Macchina M2 is that it is modular, which means you can add WiFi, GSM, LTE, BLE drives over the M2. The M2 has 2 CAN channels. The M2 also has a LIN You can find out more about it Macchina M2 here.
I have used USB2CAN and Macchina M2, where they provide great quality and do their job.
CLX000
Another low cost option is the CLX000 from CSS Electronics, which allows you to record and transmit CAN data for e.g. for car breach purposes. The data can be displayed in the free Wireshark open source software and an add-on allows useful reverse engineering functions.
The CLX000 is ideal for visualization and telematics.
You can find more information about the CLX000 here, they also have some great articles on the CAN. I would recommend you visit their blogs: https://www.csselectronics.com/screen/page/reverse-engineering-can-bus-messages-with-wireshark/language/en
Software
In terms of software, you have SocketCAN, can-utils, vcan embedded in the Linux kernel. They serve the purpose of sending and receiving CAN packages, their encoding and / or decoding.
You also have Wireshark which can analyze CAN packages.
If you want to learn more about CAN operation without worrying about damaging your car, ICSim is the tool you must use!
Setting up the virtual environment
The best and cheapest way to practice car hacking is to run an instrument simulator. Thanks to Craig Smith and the open source repo called ICSim. Using ICSim, it is quite easy to set up and learn how to operate the CAN-Bus.
Let’s make the adjustment.
The instrument simulator requires SDL libraries
SDL is a multi-platform development library for computer graphics and audio. Since ISCim designs and animates a virtual control panel, SDL is required. It can be installed via apt-get.
sudo apt-get install libsdl2-dev libsdl2-image-dev -y
CAN Utils installation
To send, receive and analyze CAN packages, we need CAN tools. Can-utils is a set of Linux utilities that allow Linux to communicate with the in-vehicle CAN network. Can-utils consist of 5 main tools that we use very often:
- cansniffer For the sniff of packages
- cansend to write a package
- candump dump all downloaded packages
- canplayer to repeat CAN packages
- cangen to create random CAN packages
Can-utils can be installed via apt-get
sudo apt-get install can-utils -y
Download the instrument simulator
The instrument cluster simulator is used to generate the simulated motion of the CAN.
You can download it through the git repository: https://github.com/zombieCraig/ICSim
If all goes well, you should see it
Preparing the virtual CAN network
Once you browse through the ICSim directory, there is a shell script called setup_vcan.sh
he modprobe command here is used to load kernel units, such as can and vcan. The last two lines will create a vcan0 interface in order to simulate the car network.
You can run the following commands to set up a virtual interface
./setup_vcan.sh
To verify the vcan0 interface, ifconfig vcan0 will be displayed
Run the Simulator
Now it’s time to run the simulator. Running the ICSim simulator requires at least two components. A dashboard and a controller to simulate acceleration, brakes, door control, turn signals etc. At least 3 terminal windows will be needed to operate. Have these terminals have a dashboard, controller and another to execute other commands.
Execution of the control panel
To run the control panel, you must run a file called icsim with an argument vcan0, (the interface we created earlier).
./icsim vcan0
At this point, the instrument panel will not operate, including the speedometer, lights, brakes or doors. This is because there is no movement in the vcan0 interface, in order to simulate it we have to start the controller.
The Control Panel can start with the following command
./controls vcan0
Vcan0 is the virtual CAN interface through which ICSim will send and receive CAN frames. Once you start the control panel, you may notice that the speedometer fluctuates somewhat. This is due to the noise simulated by the control panel.
Once the control panel starts, you can use the keyboard keys to simulate motion.
Using the following key combinations, you can make changes to the ICSim Control Panel.
Once I press the up arrow and the left arrow key, you will see below what will happen
This is all about setting up the program. If you have followed everything as I described it to you, you must have gained complete control of the car. In Part 2, I will talk about ways to exploit traffic or otherwise car exploitation.
Originally posted at: https://en.iguru.gr/car-hacking-apolytos-odigos-part/
About the Author
Anastasis Vasileiadis
PC Technician, Penetration Tester, Ethical Hacker, Cyber Security Expert, Malware Analyst, Information Security Researcher, Reverse engineering.