How I Hacked My Connected Vehicle, and Other Thoughts on Vehicle Cybersecurity

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 also increases 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 we can expect for the future of connected vehicles and the security challenges this represents to customers and manufacturers — and also explain how I was able to hack my Mitsubishi.

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 manufactures 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 today commonly 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.

In fact, the internal vehicle network is constantly loaded with hundreds of messages being sent every minute from all different sensors and computers. 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.

Listen to the podcast: Connected Cars, Smart Homes and IoT Security

Emerging Challenges Related to Connected Vehicles

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, manufactures 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 your wireless key fob are becoming more common, and until car manufacturers addresses these security weaknesses, you may want to store your wireless key fob in a Faraday bag.

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 another challenge for security researches as these instructions are often not publicly available and must be reverse engineered. This 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, but it certainly doesn’t make the task impossible.

How I Was Able to Hack My Vehicle

To demonstrate that it is possible to add new modules/computers that a vehicle will simply trust without performing any checks, I’ll share with you 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 Mitsubishi car is called Active Stability and Traction Control (ASTC), which combines traction control 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 it, it became evident that the ASTC feature 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 ASTC feature.

After reviewing the workshop manual, I found the wiring diagram, and it showed that this new EBCM also needed a steering angle sensor (SAS), an ASTC off button, a new relay called a stop lamp relay and some changes in the brakes wiring. For reference, below are the two wiring diagrams from the workshop manual that helped me understand how my car is wired (the question marks represent the wires that were missing on my car).

Diagram 1

Diagram 2

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 ASTC off button were already there. It seemed that the required components for the ASTC 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. For Mitsubishi vehicles, this code is set on the BCM — they call it ETACS — so without the ability to modify the variant code, the new EBCM wouldn’t work. Fortunately, there’s a tool called ETACS decoder developed by Earl Vadim that allows you to 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.

Plug image 1

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 ASTC feature enabled.

Errors image 1

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 this specific car make, model and set of features, shown below.

Coding image 1

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 ASTC module was available (this was done with the same ETACS decoder software).

Finally, I went out for a test drive and the ASTC 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 ASTC 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 ASTC, as well as some resistors and transistors, were missing. Fortunately, the circuit board had the space to solder in all those components.

The Future of Vehicle Cybersecurity

The same methods I used to perform these modifications could allow a malicious hacker 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 vehicles are becoming more and more common these days.

To wrap up, here are some key takeaways from this 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 trust whatever information is sent on the local network and don’t seem to 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 modules to control your car remotely.

And 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.

Listen to the podcast: Connected Cars, Smart Homes and IoT Security

The post How I Hacked My Connected Vehicle, and Other Thoughts on Vehicle Cybersecurity appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Yered Cespedes