In the near future, self-driving vehicles will likely be the norm. Cars today are essentially just computers with wheels, and they’re becoming increasingly interconnected. This, of course, provides opportunities to make our lives easier, but it can also increase the digital attack surface and potential risks if manufacturers leave proper vehicle cybersecurity measures unaddressed or incomplete.

Whether or not you’re into car hacks, I invite you to continue reading. I’ll share some insights into what I believe to be the future of connected cars and the potential security challenges this represents to customers and manufacturers — and also explain how I was able to hack my own vehicle.

Car Electronics 101

First, if you’re new to car electronics, it’s important to understand a few basic concepts. A few years back, before I started getting into car hacks, I remember friends saying their car computers had an issue and needed to be replaced. I used to imagine there was only one computer in a car that controlled all electronics, but I couldn’t have been more wrong.

Modern vehicles have several computers, each designed for very specific tasks, and they’re interconnected by an internal network. Modern vehicles also have sensors that measure everything from temperature to oil pressure, wheel speed, tire inflation, and more, all of which are controlled by specific modules that are, in essence, very specialized computers.

Below is a list of the most commonly found car electronics. Note that this isn’t an exhaustive list, and different car manufacturers may name these systems differently:

1. Engine control module (ECM)
2. Transmission control unit (TCU)
3. Body control module (BCM)
4. Electronic brake control module (EBCM)
5. Climate control unit
6. Supplemental restraint system (SRS) control module

Vehicles of all types nowadays implement what’s known as a Controller Area Network (CAN bus), so the different modules/computers inside a vehicle can share information. For example, the ECM may need to inform you about a problem with the engine by sending an error code to be displayed on the dashboard, or the EBCM may need to send a signal to the ECM to reduce engine torque if the current driving terrain is too slippery. Such messages are sent via the CAN bus, which acts like a central system that carries messaging between all the different ECUs, in place of the previous way those messages had to move through cumbersome wiring inside the vehicle.

With modern vehicles, where dozens of ECUs can work simultaneously, the internal vehicle network is constantly loaded with hundreds of messages being sent every minute from all different sensors and computers – it’s easy to liken the CAN bus to a network, and networks can be attacked.

Vehicles can be vulnerable in different ways because their internal network can lack security controls. Just like the early days of the internet, where all computers were expected to be “good,” the computers inside your car will receive and execute any instruction because it’s expected that everything they receive comes from a trusted source. But that’s not always so.

Additionally, every car manufacturer uses different codes or messages in their CAN bus — for example, an instruction taken from the CAN bus that contains “665 F0 16 00 00” may instruct the car to turn on the headlights for one manufacturer, but it may turn up the radio volume for another, or simply do nothing. This represents a challenge for security researchers as these instructions are often not publicly available and must be reverse engineered.

While shuffling commands in this manner can add a level of difficulty for someone that may want to hack your car by adding, for example, a module to control your car remotely using a cellular network, it certainly doesn’t make the task impossible, and additional controls must be devised and put into place to keep hackers out.

Emerging Challenges Related to Connected Cars

Technologies like vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications are on the rise, and I’m sure they’ll provide many benefits to consumers, manufacturers and even public infrastructure management. In the future, it will likely be very common for vehicles to receive updates over the air (OTA) just like your smartphone does today. This may help improve existing features and performance or even add new features to your vehicle.

However, it is of the utmost importance that proper security controls are taken into consideration from the very early stages, given that every new technology represents a potential new attack vector. For example, attacks that involve cloning of wireless key fobs are becoming more common, and until car manufacturers addresses these security weaknesses, we may want to store our wireless key fobs in a bag that blocks RFID signals.

How I Was Able to Hack My Vehicle

To demonstrate that it is possible to add new modules/ECUs that a vehicle will trust without performing any checks, I’ll share with you some of the details of how I was able to add a set of new features to my own vehicle. Although the module I added is from the same manufacturer, someone with enough knowledge and time can create their own module and add it to a car.

The feature I wanted to add to my car combines traction and stability control and can also be useful for specific off-road situations. I set out to get a copy of the workshop manual for the car, which contains detailed wiring diagrams of all components. While reading through the manual, it became evident that the feature I was after was controlled by the EBCM, so I knew I had two options: try to modify the firmware of my unit or get a different model of EBCM. Reverse engineering a firmware from scratch takes a lot of work and skills, so at that point, the most reasonable option was to get a different model of EBCM that already had the specific feature I needed.

After further review of the workshop manual, I found the wiring diagram, and it showed that this new EBCM also needed a steering angle sensor (SAS), an off button for the stability and traction module, a new relay called a stop lamp relay, and some changes in the brakes wiring, mainly to connect the stop lamp relay with a few new wires into the EBCM main harness .

Before purchasing the required components, I wanted to make sure this would work. So, I started to review the wires directly from my car, and to my surprise, the harness for the SAS and the off button were already there. It seemed that the required components for the new feature should interact with each other, so there was only one missing piece of the puzzle: will the new components integrate with all the other control modules?

I performed some additional research and came across something car manufacturers call variant coding, which is a code that tells all control modules which features they have enabled and which are disabled. This code is set on the BCM — so without the ability to modify the variant code, the new EBCM wouldn’t work. Fortunately, there are open source tools out there that can help do exactly that.

So, I purchased all the required parts, plugged them in and rewired everything according to the specifications in the workshop manual. Pictured below is the EBCM main plug on which I had to perform some rewiring.

After turning the car on, as expected, a bunch of diagnostic trouble codes (DTCs) popped up since the new EBCM was expecting a variant coding with the new feature enabled.

What followed were several hours of trial and error, disconnecting the car battery and reconnecting it after each change on the variant coding. Finally, I found the right variant code for my specific car make, model and set of features, shown below.

Most of the DTCs were gone at this point, and all that was left to do was calibrate the SAS and change a setting on the ECM to tell it that the new module was now available (this was done with a decoder software).

Finally, I went out for a test drive and the newly added stability and traction feature seemed to work as expected. However, there was one missing piece: there was supposed to be a light on the dashboard that would tell me each time the module was engaged, but I did not see that light popping up during the test drive. The next step was to disassemble the dashboard and check what was going on. After opening it, it became evident that the LED for that indicator, as well as some resistors and transistors, were missing. Fortunately, the circuit board had the space to solder in all those components.

This experiment took some time and minor research but notice how I did not run into any security controls that hindered the changes I wanted to make.

The same methods I used to perform these modifications could allow a criminal to embed a custom piece of hardware and control almost any feature on a vehicle, ranging from brakes and acceleration to windshield wipers and microphone. This can be as simple as putting together a Raspberry Pi, a CAN bus interface and wireless access, then plugging it into the CAN bus of a vehicle. Doing this would require physical access to the vehicle – but remember that connected cars are becoming more and more common these days and that could only make things easier for remote attackers in the future.

The Future of Vehicle Cybersecurity

To wrap up, here are some key takeaways from this personal project:

1. Variant code tells the control modules of a car which features are active or inactive.
2. There are several computers in modern vehicles, each managing very specific tasks, that are interconnected through a local network within the car.
3. Components from different models made by a manufacturer may work if they are properly configured and wired.
4. Car control modules may trust whatever information is sent on the local network and may not perform any kind of validation of the packets or the authenticity of other control modules or devices connected to the CAN bus.
5. Most importantly, anyone with enough knowledge and time can create new modules. This can be both good or bad, and with malicious intent, an attacker could implement a module to control your car remotely.

Remember: any device that can wirelessly provide access to the internal CAN bus of a vehicle is a potential new attack vector, making it critical to implement proper vehicle cybersecurity measures.

Knowing that modern day vehicles are all equipped with numerous internal computers, a network-like central, and minimal controls, and with connected cars already a daily reality, it is high time to develop and implement controls into every new model if we don’t want to find ourselves in the midst of vehicular security chaos in the years to come.

Read a case study on autonomous vehicle testing