Learn all about car hacking by Blackhat Pakistan. Automotive security is really exciting and is an interesting topic of study for many security researchers. Automotive and hardware, for the most part, have always been off the radar. These hacks are always more difficult to pull off and at the same time, they are potentially more devastating. With the arrival of Self Driving cars like Tesla, Automotive security will only become more important.
When you are driving a car today, you are driving a hugely powerful computer that happens to have wheels and steering.
Today, when you drive a car, there’s nothing that is not mediated by a computer. And at the core of all this is the Controller Area Network or simply called CAN or sometimes CAN Bus, a central nervous system of a car responsible for intravehicular communication. This tutorial is going to be a guide for car hacking as safely as possible on reverse engineering CAN packets.
Latest post: How to hack wifi 2022 updated method 100% working
To practice CAN-Bus exploitation we will be using an ICSim package from Craig Smith. ICSim includes a dashboard with speedometer, door lock indicators, turn signal indicators and a control panel. The control panel allows the user to interact with the simulated automobile network, applying acceleration, brakes, controlling the door locks and turn signals.
Also read: Blackhat Hacking Course in Hindi/Urdu
Part 1: Setting Up the Virtual Lab
The goal of this tutorial
The primary goal of this tutorial is to help you get started with Automotive security. Entry barrier to Car Hacking is much higher compared to any other security fields. I hope this tutorial can play an important role in helping you clear the entry barrier.
While Car Hacking and Automotive Security is a much broader field, this tutorial only focuses on Controller Area Network(CAN) and limited to Sniffing CAN traffic, analyzing them, reverse engineer and perform replay attacks on automotive.
While it is true that we will be performing this attack/tutorial on an Instrument Cluster Simulator, this can very well be transitioned to a real car with additional hardware. I will talk about the extra hardware needed towards the end of this article.
The goal of this article is to help you get started in automotive security and/or car hacking easily without spending a lot of money on hardware.
This is NOT a “Zero to Hero in Car hacking to make you expert in X minutes” article, instead, this article just aims to help you just get started with car hacking in a simulator.
This article will help you learn
- functioning of CAN
- Gaining access to CAN via OBD-II
- Sniffing the CAN Traffic
- Analyzing and reverse-engineering the CAN Traffic
- Replay Attack
- Denial of Service in CAN Network [Part 3 TODO]
- Playing with your CAN packets using Python [Part 3 TODO]😉
If you decide to practice this tutorial, you would need:
- Any Linux distributions (I will be using Ubuntu)
- ICSim (ICSim is an opensource Instrumentation Cluster Simulator)
Can be downloaded from https://github.com/zombieCraig/ICSim
Introduction to CAN
Controller Area Network aka CAN is the central nervous system that enables communication between all/some parts of the car. Before CAN was originally developed by BOSCH in 1985 as an intra-vehicular communication system, automotive manufacturers used point-to-point wiring systems. As we started having more and more electronic components in the cars, this only became bulky and too expensive to maintain. This problem was then fixed by replacing it with CAN.
Also read: Cashapp Carding 2022 Method With working Bin
In simple terms, CAN allows various Electronic units in cars to communicate and share data with each other. The main motive of proposing CAN was that it allowed multiple ECU to be communicated with only a single wire. A modern car can have as much as 70 ECUs. In a car, you can have components like Engine Control Unit, Airbags, Transmission, Gear Unit, Anti-lock braking system or simply ABS, infotainment systems, climate control, Windows, doors, etc. In order for all these units to communicate with each other, point-to-point wiring would have been so bulky. Imagine, every component connected to every other component, this would have been a real mess to diagnose for any troubleshooting. But with CAN, this can be replaced with single wire and communication between each unit is much simpler.
The CAN-Bus could be thought of as a noisy, crowded, slower version of Ethernet LAN except that the traffic is UDP rather than TCP.
It is worth noting that not all automobile control systems use CAN and also CAN is not only the communication protocol used in an automobile system. There could be other protocols such as Bluetooth, GSM/LTE cellular networks, satellite radios, LIN, etc. You should know that CAN is not the only attack surface, there could be many.
Working of CAN
A car can have multiple nodes that are able to send and/or receive messages. This message consists of essentially an ID, which is a priority of the message and also it can contain CAN message that can be of eight bytes or less at a time.
If two or more node begins sending messages at the same time, the messages sent with the dominant ID will overwrite with that of less dominant. This is called priority-based bus arbitration. Messages with numerically smaller value IDs are a higher priority and are always transmitted first. This is how a node detects that higher priority messages are being placed on a bus.
Message from Brakes has a higher priority than a message from the audio player.
Note down that, Lowest ID = Highest Priority.
If two or more node begins sending messages at the same time, the messages sent with the dominant ID will overwrite with that of less dominant.
CAN bus consists of two different wires. As it is a bus, multiple devices can be connected to these wires. A CAN frame has 3 major parts:
- Arbitration Identifier
- Data Length Code
- Data field
Let’s have a look at the CAN data frame:
What if CAN was never invented?
This is a legit question that must be going through your head, as there are many other buses that can be easily implemented but why CAN? Before the CAN bus was invented, automotive manufactures used to do point to point wiring systems, if you have three components in the car, all three components were connected to each other with a point to point wiring system.
Consider these three components are steering system, gear unit, and ABS. Now on a typical point to point wiring system, you need a steering system to be directly connected to a gear unit and to the ABS as well with wires. Also, your gear unit needs to be connected to the ABS and Steering System, with a bunch of wires. This is perfectly fine with cars with fewer components. Can you imagine this in a modern car that has as much as 100 different ECU and other components? This is going to be messy and bulky! Also impossible to identify faults in the wiring system, (if any), the diagnosis would have been a real nightmare, and very much expensive to maintain.
This is when automotive manufacturers came up with the idea of CAN.
The point to point wiring problem can be replaced with two wires, 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 being used in pretty much every car, this is mandated by law so CAN is not going anywhere soon. Also, CAN bus was not developed keeping modern security in mind.
Okay, How do I access CAN Bus in a real Car?
In order for you to access the CAN bus in your car, you need to have access to the onboard diagnostic port, aka OBD. While there may be hundreds of other diagnostic standards and ports, basically all the cars these days use OBD-II. This is exactly what your car mechanics usees to identify the faults in your car. OBD is the most direct access to CAN. Locating OBD-II is pretty easy. This is located somewhere near the passenger’s seat or driver’s seat. And this should be accessible without the need of a screwdriver.
This is how exactly an OBD looks like.
If you are wondering about the pinouts of the OBD, here’s the pinout for the OBD port.
If you look carefully, pin 6 and pin 14 are the same CANH and CANL that I had mentioned earlier.
Hardware and Software Needed to access CAN via OBD
In order for you to interact with the CAN bus, since now you already know you need an OBD port, you need something like USB to CAN because your computer can’t talk to CAN directly. You need something that connects to the OBD-II port via USB so that you can send/receive the CAN packets. Also on the software, you need something that can read and/or write CAN packets as well as encode and/or decode the CAN packets. With a little bit of hardware and software, you definitely can hop into the CAN.
The hardware needed for you to connect to the OBD-II can be easily found in the market. There are expensive as well as inexpensive hardware devices. High-end devices include Kvaser and EMS, which are expensive and overkill.
You have USB2CAN, a native can interface for Linux that offers great value for money.
Also, many times you will come across this ELM327, Bluetooth based devices, they are terrible for hacking for a reason that they have slower data rates and you will end up losing so many packets.
Macchina M2 is my personal favorite one. Macchina M2 is an opensource automotive interface that allows you to communicate to the CAN bus via OBD-II. The best part about Macchina M2 is that it is modular, meaning you can add WiFi, GSM, LTE, BLE modules on top of M2. M2 has 2 CAN channels. M2 also has LIN 😉 You can find more about Macchina M2 here.
I have used USB2CAN and Macchina M2, they provide great value for money and does the job.
Another low-cost option is the CLX000 from CSS Electronics, which lets you log and stream CAN data for e.g. car hacking purposes. Data can be visualized in the free open-source Wireshark software and a plugin enables useful reverse engineering functionality.
CLX000 is great for visualisation and telematics.
You can find more information about CLX000 here, they’ve some great articles on CAN as well.
I would recommend going through their blogs: https://www.csselectronics.com/screen/page/reverse-engineering-can-bus-messages-with-wireshark/language/en
On the software side, you have SocketCAN, can-utils, vcan built into the Linux kernel. They serve the purpose of sending and receiving the CAN packets, encode and/or decode them.
You also have Wireshark that can analyze CAN packets.
If you want to learn more about CAN exploitation without worrying to harm your Car, ICSim is the tool to go for!
Setting up the virtual Environment
The best and inexpensive way to practice car hacking is by running an instrumentation cluster simulator. Thanks to Craig Smith and his open-source repo called ICSim. Using ICSim, it’s pretty easy to set up and inexpensive to learn CAN-Bus exploitation.
Let’s do the setup.
Instrument Cluster Simulator requires SDL libraries
SDL is a cross-platform development library for computer graphics and audio. Since ISCim draws and animates a virtual dashboard, this is required. This can be installed via apt-get.
sudo apt-get install libsdl2-dev libsdl2-image-dev -y
Installing CAN Utils
In order for us to send, receive and analyze CAN packets, we need CAN utils. can-utils is a Linux specific set of utilities that enables Linux to communicate with the CAN network on the vehicle. The canutils consist of 5 main tools that we use very frequently:
- cansniffer for sniffing the packets
- cansend for writing a packet
- candump dump all received packets
- canplayer to replay CAN packets
- cangen to generate random CAN packets
can-utils can be installed via apt-get
sudo apt-get install can-utils -y
Download the Instrumentation Cluster Simulator
Instrumentation Cluster Simulator is used to generate the simulated CAN traffic.
This can be downloaded by cloning the project via a git repository.
git clone https://github.com/zombieCraig/ICSim
If everything goes well, you should see this
Preparing the Virtual CAN Network
Once you navigate inside the ICSim directory, there’s a shell script called setup_vcan.sh
The modprobe command here is used to load kernel modules like can and vcan modules. 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 can interface
To verify vcan0 interface, ifconfig vcan0 will show
Running the Simulator
Now it’s time to run the simulator. Running the ICSim simulator at least requires two components. A dashboard and a controller to simulate the acceleration, brakes, controlling the doors, turn lights, etc. You would require at least 3 terminal windows/tabs for these to run. We would require these terminals to run dashboard, controller and another for running can-utils.
Running the dashboard
In order to run the dashboard, you could run a file called icsim with an argument vcan0, the interface we created earlier.
At this point in time, the dashboard won’t be functioning including speedometer, turn lights, brakes or doors. It is because there is no traffic on the interface vcn0. In order to simulate traffic on interface vcan0, we need to start the controller.
Control Panel can be started by
The vcan0 is the virtual CAN interface through which our ICSim will send and receive CAN frames. As soon as you start the control panel, you can observe speedometer making some fluctuations. This is because of the noise simulated by the control panel.
Once the control panel has been started, you can use keyboard keys in order to simulate traffic.
Using the key combinations below, you can make changes in the ICSim Dashboard.
Once I press the up arrow key and left arrow key, this is what you can observe.
That’s all for the setup. If you have followed everything, you must be good to go. In Part 2, I will be talking about ways to exploit CAN traffic.
In this part, we will dive deep into sniffing, replaying and attacking CAN Traffic.
How does a CAN message look like?
This is how exactly your CAN messages look like when they are captured via can-utils. If I break down the columns, the first one is the interface, the second one is the arbitration ID, third is the size of the CAN message, this can’t be more then 8. If you look at the CAN frame, you will understand better why this can not be more than 8. The fourth is the CAN data itself.
Making sense of CAN message
In this example, this is an 8-byte frame. The message is being sent by an arbitration ID 0x111. Once the instrument cluster sees this message, this will first make sure, if it was intended for instrument cluster or not. If it is, then it reads the message which has 0x0BB8, which translated to 3000 in decimals. Now your instrument cluster moves the needle in the tachometer to 3000.
Once you have the understanding of how CAN message makes sense, we can further inject fake/modified packets via ODB-II on the CAN bus to spoof tachometer or anything else.
Before we run into the demo of ICSim, let’s look at how other mini utilities of can-utils work. To do this, let’s first set up the virtual can interface.
Setting up the virtual CAN interface
sudo modprobe can
This will load the kernel module for CAN. Also, we need to load the kernel module for virtual can as well.
sudo modprobe vcan
If you wish to verify if the required kernel modules are loaded or not, you can use
lsmod | grep can
This will display if CAN and VCAN have been loaded or not.
Let’s now set up the virtual interface
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
You can verify if virtual CAN interface is set up or not using
Once the virtual CAN interface is set up, you are now ready to send/receive the CAN packet in this interface. Let’s now use one of the mini utilities from can-utils called cangen to generate the dummy CAN packets.
cangen generates the CAN frames for testing purposes. To use cangen, you need to specify the interface in which the CAN frame is to be generated.
vcan0 is the virtual CAN interface we recently created.
Since you have already generated CAN frames, there must be a way to look into the frames! There are many utilities available, one among many available is Wireshark. Launch the Wireshark after generating the CAN frames.
You may see many interfaces available depending on how many interfaces are up, vcan0 is the interface where your CAN frames are being generated.
Once you click on the interface you wish to look the packets into, this is how the CAN frame looks like.
More detailed information about the CAN frame can also be viewed.
Also, there are other utilities inside vcan0 like cansniffer and candump which does more or less the same stuff Wireshark does. You can use any tools or utility, whichever you feel more comfortable with.
To dump or log the frames using candump, you can use
This will be the output from the candump.
In one of the terminals, the lower one is generating the CAN packets, whereas the terminal on the top is running candump. If I have to break down the columns for you, the first one you see is the CAN interface. The second is the arbitration ID, the third one is the size of CAN message, and the fourth is the message itself.
candump can also log the can frame for you. If you wish to perform a replay attack, you can first log the frames and then use mini utility like canplayer to replay the frames. Logging of CAN frames can be enabled using -l flag.
candump -l vcan0
When you log the CAN frames, a file will be created prefixed by candump followed by the date.
If you wish to see the contents of the dump file, you can always use cat command in Linux to see the contents.
The frames we captured using candump can be replayed using a utility like canplayer.
As the name suggests, the canplayer will replay the can frames. Ideally, this is useful when you have to do the replay attack. You would first dump/log the CAN frames and then playback the CAN frame using the canplayer.
Imagine a scenario where you wish to spoof the tachometer, and you have no idea on which arbitration ID the tachometer reading works, you have no idea what’s in the CAN message. So ideally you would first dump and log the frames using candump with -l flag, and then use can player to replay the frames that were logged.
canplayer requires -I option to accept the input file.
canplayer -I canfile.log
canplayer has several other really useful options, you can find out them using man canplayer.
CAN sniffer is used to see the change in CAN traffic. This is very useful to see a change in a particular byte. cansniffer has an option -c very useful for seeing the byte change in a colorful way. What this does is, it will compare the earlier byte and the current byte, if there’s a difference then it is indicated by the change in the color of the byte. This is very useful when you wish to know if there was a change when you had performed a certain operations in a car.
cansniffer -c vcan0
I find cansniffer very helpful because the cansniffer allows filter by IDs as well. So if you wish to see the frames only from a particular ID, say 0x011, you can do that as well.
This can be done once you start sniffing, press — and then 000000. This will first clear all the frames. Now, you can start adding the IDs using + and then the ID you want to display and hit Enter. This way you can filter the frames of individual IDs.
cansend is used to send the CAN frames to a specific CAN interface. It’s usage is
cansend interface frame
We will use all of these utilities with ICSim.
Installation and Introduction to the ICSim are already discussed in the earlier post. Please follow this article to learn how to install ICSim.
Let’s launch the ICSim and sniff the CAN frames.
./icsim vcan0./controls vcan0
If you have followed every step discussed in the earlier post, you should be able to see this. Also, you can notice that the speedometer needle is moving back and forth, which is expected behavior because of the noise present.
Sniffing the CAN frames generated by ICSim
We will use cansniffer, a utility provided by can-utils, to sniff the packets. You can open up a new terminal and start cansniffer by
cansniffer -c vcan0
The -c option is used to indicate the change in bytes of the frame.
You can see very quick changes in the CAN frames, difficult to keep up with the rate at which communication is happening. In a real car, this communication would happen fast. To keep up with it, you can use arbitration ID filtering. If you only wish to see the frames from ID 40C, you can always press — and then 000000 followed by Enter key. This will clear all the IDs from cansniffer and you can then press + followed by ID to filter out and then press Enter key.
Here I have filtered the ID 40c only using the same steps mentioned above. You can try pressing the Up arrow key to increase the throttle and then notice how quickly CAN frames are being changed. The change is again indicated by the coloring. You can always play around with this and see how things are working under the hood.https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2Fad-GkTZAWck%3Ffeature%3Doembed&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dad-GkTZAWck&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2Fad-GkTZAWck%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube
Making sense of this huge data is going to be a difficult task. Also, finding the arbitration ID in which you have to inject the frames is an impossible task to do from this big data.
So you would start sniffing the packets, then perform some action like turning on the turn signal indicators or pushing the throttle, once it is logged, then divide the packets into two halves, perform the replay attack on the first half and see if it works. If it doesn’t, move on to the other half. This other half chunk of frames must work. Again this other half is still going to be huge, go ahead and divide the frames into two halves again, repeat this until you are left out with a single frame.
Now to perform Replay attack with ICSim, you must have already started ICSim, you should be able to see the frames using cansniffer. Now we will use candump with -l option to log and save the frames, in the meanwhile we will increase the throttle, press <left> and <right> arrow keys to turn on the turn signal indicator.
candump -l vcan0
Now we will stop candump and you will see a file as candump-XXXXX.log being created.
Replaying the CAN frames
To replay those packets we will be using canplayer. Since we will be using a file as input for canplayer, we need -I option to be enabled.
canplayer -I candump-2019XXXXXX.log
You can see that a replay attack has been performed, the turn signals, speedometer should be working as you had done earlier.https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FfhqAKmihl2E%3Ffeature%3Doembed&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DfhqAKmihl2E&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FfhqAKmihl2E%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube
Creative Packet Analysis
In a real car, CAN bus can be a lot noisier and CAN frames can appear a lot faster, so identifying the arbitration ID could be a difficult task. So to easily identify arbitration ID, you can follow this
Dividing the CAN frames and performing Replay
If you wanted to divide the CAN frames into two half and perform the replay on each of them, the best way to do is capture the CAN frames using candump and use wc utility to count the number of CAN frames, then use split to divide the log into two half equally.
Now, you can use the canplayer to replay these CAN frame independently.
Identify the arbitration ID for Throttle, Doors and turn signals!
[This image below has been put up intentionally so that you spend time finding the arbitration IDs 😆]
At this point in time, I assume you have already found the arbitration ID for doors, tachometer and turn signals.
How about unlocking the door?
You would have noticed that in 0x19B, whenever you unlock/lock the doors, you must have seen the changes in CAN frames. How about unlocking them using cansend? (ICSim has 4 doors)https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FzGlzmpiY5fY%3Ffeature%3Doembed&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DzGlzmpiY5fY&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FzGlzmpiY5fY%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube
Playing around with RPM, Tachometer
Playing around with Turn Signals
Can I try this on a real car?
Yes, here is a short clip from GreHack, France 2019, I had conducted a workshop on a Car Hacking and CAN bus exploitation.https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FXWuegmWgpYM%3Ffeature%3Doembed&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DXWuegmWgpYM&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FXWuegmWgpYM%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube
This one is from the Hyundai i10.https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F7nHtuBCqfyU%3Ffeature%3Doembed&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D7nHtuBCqfyU&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F7nHtuBCqfyU%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube
You can always try this on a real car. But! Use your common sense and be safe while doing in a real car!
By now, you must have learned how CAN bus works, how does a CAN frame looks like and of course using canutils you must have learned to sniff the CAN frames, send and fuzz the CAN frames.
Using ICSim is rather simple, on a real car, this could be slightly difficult for a few reasons:
- You may have difficulty locating an OBD-II port that gives you direct access to CAN Bus.
- CAN communication in a real car is very fast compared to the rate at which it happens in ICSim.
- In a real car, you may find a lot more arbitration identifiers than in an ICSim.
- CAN is not the only network present in a car. If you can’t find the message you are looking for, this probably is in a different network.
- Car Hacker’s Handbook — Must read
- More on can-utils & SocketCAN, SavvyCAN
- Charlie Miller & Chris Valasek researches
- Most importantly: https://github.com/P1kachu/awesome-vehicle-security
I definitely plan to release a few more articles on this series, hopefully within the next few weeks, especially on SavvyCAN, one of my favorite tools for fuzzing on the CAN bus. I plan to write another article on doing this in a real car using Macchina M2 and SavvyCAN.
We will now look into what SavvyCAN is and using it with ICSIM. After that, we will look into how to perform fuzzing and scripting with SavvyCAN.
There are various software’s out there that will help you monitor and filter the CAN communication. You’ve got costly and proprietary tools, as well as free and open-source tools. The purpose of this article/blog is to help you get started with car hacking on cheap, so the expensive tools do not fit on our list. I have already written in detail about the cheap and free alternative for these expensive CAN communication tools. Tools like can-utils, Wireshark works as expected. can-util works great! but SavvyCAN provides a lot more extra features. For beginners, it offers a nice GUI, which helps you easily navigate, filter the packets and arbitration IDs, etc. For those who are already into Car hacking, SavvyCAN offers really great features. My personal favorite features include the ability to perform scripting on CAN frames, Fuzzing and several RE tools bundled together to make SavvyCAN really great.
Let’s look at the definition of SavvyCAN from their website.
“SavvyCAN is a cross platform QT based C++ program. It is a CAN bus reverse engineering and capture tool. It was originally written to utilize EVTV hardware such as the EVTVDue and CANDue hardware. It has since expanded to be able to use any socketCAN compatible device as well as the Macchina M2 and Teensy 3.x boards. It can capture and send to multiple buses and CAN capture devices at once.”
I find it really easy using SavvyCAN rather than can-utils. Again, let’s not start the debate between which tool is better and which is not, as long as it serves your purpose, you should be good to go. Most importantly, there must be other really great tools, which I might have never explored, feel free to comment down if you are aware of any other tools.
SavvyCAN installation is a really easy and straightforward process. You can download the prebuilt binaries for Linux, Mac, and windows from https://www.savvycan.com
Installation and running in Ubuntu
Installation is not required as you are downloading the app image binaries, make it executable and run it!
chmod 744 SavvyCAN-305dafd-x86_64.AppImage# and ./SavvyCAN-305dafd-x86_64.AppImage
You should be able to run SavvyCAN
You can play around with the SavvyCAN interface for a while. If you want to use SavvyCAN with Macchina M2 or any other compatible hardware, you don’t need any extra installation.
We intend to use SavvyCAN with ICSim, so we need to install qtserialbus.
Once you open the SavvyCAN window, If you navigate to Connection -> Open Connection Window -> Add New Connection, you can observe that the qtserialbus is disabled.
Let’s begin with the installation of qtserialbus so that we can use this with ICSim.
$ wget https://download.qt.io/official_releases/qt/5.14/5.14.4/qt-opensource-linux-x64-5.14.2.run
Once you have successfully downloaded qt5, we need to install/execute
$ chmod a+x ./qt-opensource-linux-x64-5.14.2.run$ sudo ./qt-opensource-linux-x64-5.14.2.run
Please note down the pathname, you will need this later.
Once qt5 is installed, you need to install qtserialbus, as this is not included in the official apt repository of Ubuntu. So we need to build this ourselves.
$ sudo apt install qtdeclarative5-dev qttools5-dev g++$ git clone https://github.com/qt/qtserialbus$ cd qtserialbus$ /home/y0g3sh/Qt5.14.2/5.14.2/gcc_64/bin/qmake .$ make$ sudo make install
In order to use qtserialbus, the SavvyCAN’s AppImage file that we downloaded earlier will not work. SavvyCAN has to be built with qmake.
$ git clone https://github.com/collin80/SavvyCAN
$ cd SavvyCAN
$ /home/y0g3sh/Qt5.14.2/5.14.2/gcc_64/bin/qmake CONFIG+=debug
This will take some time to build.
Once everything is installed, start the ICSim simulator, start everything except can-utils. Instead of using can-utils to capture CAN communication, we will use SocketCAN.
Starting the SavvyCAN
Please launch the SavvyCAN binary we just built rather than the appimage we downloaded earlier. Remember, if you want to perform this on a real car and not use it with qtserialbus, you can continue to use those appimage binaries and need not go through all this hassle of building SavvyCAN yourself.
$ cd SavvyCAN
Now you can open the connection window and observe that the QT SerialBus has been enabled.
Adding vcan0 to SocketCAN
To make a new connection in SavvyCAN,
- Open the SavvyCAN
- Goto Connection menu -> Open Connection Window -> Add New Device Connection
- Choose the connection with the following setting
Connection Type as QT SerialBus Devices
SerialBus Device Type as socketcan
Port as vcan0
Then, create a new connection.
As soon as the connection is done, you can see the CAN frames flying around in the SavvyCAN window, which is a good sign that everything is working well and good.
In order to understand the SavvyCAN better, let’s do the same things we did earlier using can-utils, but this time with SavvyCAN.
SavvyCAN provides nice and intuitive interface to filter the frames by ID. You can uncheck the IDs that you don’t require, from the right pane. This way you can quickly identify the ID associated. Another really cool feature is ”Overwrite mode”. If this option is enabled, the frames will overwrite on the same row.
Performing a replay attack using SavvyCAN is much easier. You can open the Playback options under Send Frames menu. You can either load data from file or load directly from the captured data. You can also choose which ID to replay from ID filtering menu.
Identifying the arbitration ID
I get asked this question a lot, on how to identify which ID does what on a car. Finding arbitration ID can sometimes be very tricky. SavvyCAN provides many RE tools. One of which I use frequently is “Sniffer”. This allows me to fade the inactive bytes and identify the IDs quickly. For example, let’s try to identify the ID for Tachometer. To identify the tachometer ID, I will open the Sniffer and Fade the inactive bytes. The way I identify is, let’s assume if there are 20 IDs available. I disable at least one third of them — perform the action on car/ICSim— observe the change in frames. I do this until I am left out with single ID.
Let’s see Sniffer, one of the RE tools of SavvyCAN in action.
Here I did not find any change in the bytes that corresponds to my action. So I will move for another half of IDs.
Looks like 0x244 is what we are looking for. You can observe the pattern in the change bytes when throttle is hit. As the speed increases, the tachometer displays the change in 3rd and 4th byte (counting from Zeroth Byte)
You can do this for all the actions available in ICSim.
Sending Custom frames
SavvyCAN also has another cool feature where you can modify the packets on the fly while sending custom frames. To be able to do this, You need to open Frame Sender from inside the Send Frames menu. Let’s spoof the tachometer. From the above example when we sniffed the packets, you would have observed how tachometer works. The 3rd and 4th Bytes increases with increase in throttle. So what we will do is, send the custom frame, modify the bytes on the fly to observe the change in tachometer.
The data column will consist of hex values, the ID should be in the format of 0x123, trigger must be the value in ms, the delay between each frames, and modification should consist of modification on bytes.
Example what I would like to do is, I want to send on Bus 0, ID 0x244 (tachometer), data as 0x00 0x00 0x00 0x00 0x00 and increase the 3rd byte by 2 everytime, so on modification you could easily write d3=d3+2. Once done, make sure to check on Enable (EN) checkbox.
The another really cool feature about SavvyCAN is that, how easy is it to fuzz around CAN frames.
I made a quick video as it was easy explaining on video on how to fuzz.
I hope you enjoyed these articles. Thank you!