How to Hack a Car – A Quick Crash Course

Modern cars are basically networks of computers on wheels. Dozens of electronic control units (ECUs) communicate with each other to control everything from the engine to the radio. By understanding these networks, you can peek under the hood of your car‘s digital control systems and even modify them.

In this quick crash course, I‘ll teach you the basics of car hacking. You‘ll learn how your car‘s network works, how to connect to it, reverse engineer the messages getting sent, and even inject your own messages to control your car. Let‘s get started!

Your Car‘s Network Architecture

Your car likely has 30 to 100 little computers called ECUs controlling different functions. For example, there are ECUs for the engine, transmission, airbags, windows, radio, navigation, and more. These ECUs need to communicate with each other to coordinate their actions.

ECUs are connected together in a network, much like computers in an office. The industry standard network protocol they use to communicate is called Controller Area Network (CAN). It allows ECUs to broadcast messages onto a shared bus that all other ECUs can listen to.

Diagram of ECUs on a car network

There are usually multiple CAN buses in a vehicle, segmented by function and real-time priority:

  • A high-speed CAN bus connects critical ECUs that need to communicate quickly and reliably, like the engine, transmission, and brakes. This usually runs at 500 kbps.
  • A medium-speed CAN bus connects less critical ECUs at around 125 kbps, for things like the instrument cluster.
  • A low-speed CAN bus connects non-critical ECUs at 33.3 kbps, for things like windows, locks, and the radio.

We can tap into these CAN buses to observe what messages are being sent between ECUs. We can even pretend to be an ECU and inject our own spoofed messages. This is the essence of car hacking.

The CAN Protocol

To hack a car‘s CAN buses, you need to understand the format of the messages being sent. A CAN packet or frame has the following fields:

  • 11 or 29 bit arbitration ID that identifies the packet type and priority
  • 0 to 8 bytes of data payload
  • Various other fields for length, checksum, acknowledgement, etc.

Breakdown of CAN frame fields

When a CAN frame is broadcast onto the bus, every ECU sees it, but usually only one ECU will act on it. The arbitration ID acts like an address for the packet‘s intended recipient.

Lower arbitration IDs have higher priority on the bus. If two ECUs transmit at the same time, the one with the lower ID will win, and the other will back off and retry later.

CAN is a very reliable protocol with automatic error detection and retransmission. It operates at the low levels of the OSI model, so higher level protocols are often built on top of it for specific functions.

Tools of the Trade

To get started hacking your car, you‘ll need some hardware and software to interface with the CAN buses:

Hardware

– An OBD-II to USB cable that supports CAN, like the MacChina. This will plug into your car‘s OBD-II diagnostic port under the dash and connect to your laptop.
– Optionally an oscilloscope or logic analyzer to observe raw CAN signals.

Software

– The can-utils suite for Linux, which provides command line tools for dumping and sending CAN messages.
– Python and the python-can library for scripting interactions with the CAN bus.
– Wireshark with a custom DBC file for decoding CAN frames specific to your make and model vehicle.

I‘ll be showing examples using an Ubuntu laptop and Python, but the concepts apply to any setup. You should be comfortable with Python and Linux to follow along.

Reversing CAN Messages

The CAN messages for each make, model, and year of vehicle are different, so you‘ll need to do some reverse engineering to figure out what each frame means. The process boils down to:

  1. Find the ID of the frame you‘re interested in
  2. Capture examples of that frame while different actions happen
  3. Analyze the data bytes to identify patterns
  4. Fuzz the data by modifying it and replaying it to see the effects

Let‘s walk through an example of reversing the tachometer (engine RPM) reading in an instrument cluster, since that‘s a visual way to validate our hacking attempts.

Finding Frames of Interest

With your OBD-II cable plugged into your car and laptop, bring up the CAN interface:

sudo ip link set can0 type can bitrate 500000
sudo ip link set up can0

This brings up a virtual CAN interface called "can0" connected to your OBD-II cable at 500 kbps, the standard high-speed CAN rate.

We can monitor all frames on the high-speed CAN bus with candump:

candump can0

This will spit out one line per frame as they come in, way too fast to read in real-time. Press Ctrl+C to stop it.

To find frames that relate to the RPMs, we can diff the output while revving the engine in neutral. Set the parking brake and put your foot on the brake pedal for safety.

candump can0 | tee baseline.log # Log a few seconds of data with the engine at idle
candump can0 | tee revving.log # Log a few seconds of data while revving the engine
diff baseline.log revving.log # Shows which frames changed between the two states

Diff of candump logs

In this example, we see that ID 0B4 is constantly changing, so it‘s probably unrelated to RPMs. But IDs 191 and 195 changed consistently while revving, so one of them is likely the RPM reading. Time to investigate further.

Analyzing Data Patterns

Pick one of the candidate frames and let‘s look at a few examples of it. Using the same technique as before, capture some logs of the CAN traffic while revving the engine to different RPMs.

Then use grep to extract just the frames with the ID you‘re analyzing:

grep "191 " revving.log

Filtered candump frames for ID 191

In this case, the 2nd and 3rd bytes seem to change together as the RPMs change. The 2nd byte increments when the 3rd byte overflows from 0xFF to 0x00. This suggests they form a 16-bit integer where the 3rd byte is the least significant.

We can use Python to combine those 2 bytes and plot them against the engine RPMs we observed:

import matplotlib.pyplot as plt

rpms = [1250, 4400, 3200, 800]  # RPM readings from tachometer for each frame
x = range(len(rpms))
y = []

for frame in frames:
    b2 = int(frame.split()[3], 16) 
    b3 = int(frame.split()[4], 16)
    y.append((b2 << 8) + b3)

plt.plot(x, y)
plt.plot(x, rpms)
plt.show()

Plot of extracted RPM signal vs actual RPM

The fact that the two lines have the same shape tells us we‘re on the right track. It looks like a 16-bit value starting at byte 2 represents the RPM value, just scaled down by about 4x. We can test our hypothesis by modifying those bytes and replaying the frame.

Injecting Forged Frames

To spoof frames, we can use the cansend utility, which takes the frame ID and data bytes as arguments. For example, to send a frame with ID 191 and 8 data bytes:

cansend can0 191#112233445566778

We can script this in Python to send forged RPM frames in a loop:

import os

scale_factor = 3.85 # Roughly 3.85 RPM per CAN count

rpms = int(input("Enter RPM value to spoof: "))
b2 = (int(rpms / scale_factor) >> 8) & 0xFF  
b3 = int(rpms / scale_factor) & 0xFF

cmd = f"cansend can0 191#{b2:02X}{b3:02X}0000000000"

while True:
    os.system(cmd)

The key parts are converting the desired RPM value to the correct raw bytes to send, and repeating the command in a loop. This is because the real ECU will still be broadcasting the true RPM value several times per second, so we need to "overpower" it with our forged messages.

Here‘s the result of running that script and entering 8000 RPM:

Tachometer showing spoofed 8000 RPM

We did it! We successfully made the instrument cluster think the engine was revving way higher than it really was. This proves that with some patience and ingenuity, you can reverse engineer and spoof almost any signal on a car‘s CAN buses.

Other Ideas to Try

With the techniques you‘ve learned in this guide, you can start hacking all sorts of functions on your car. Just use the same process of finding a frame related to the function, analyzing its data bytes, and forging modified frames to spoof the function. Here are some ideas to get your creative juices flowing:

  • Unlock the doors by replaying lock/unlick frames
  • Pop the trunk by spoofing the trunk release signal
  • Roll the windows up and down by forging window control frames
  • Flash the lights, honk the horn, wiper the windshield
  • Forge speedometer readings by modifying the wheel speed sensor
  • Control the radio volume, change stations, input touchscreen taps

I‘ll leave it to you to figure out the exact details. Be sure to do your hacking with the car in park and the engine off for safety. And of course, don‘t use your powers for evil!

Security Implications

I hope this guide has opened your eyes to the fact that most cars are insecure by design. The CAN buses that form a vehicle‘s nervous system are completely unencrypted and unauthenticated. There‘s no privilege separation – any component can impersonate any other component and send any command. It‘s similar to if anyone on a company‘s network could access any resource or machine without passwords.

Hackers and security researchers have repeatedly demonstrated dangerous car hacks like:

  • Shutting off the engine while driving
  • Slamming on the brakes or preventing braking
  • Jerking the steering wheel
  • Displaying fake speedometer and engine readings

These are not just theoretical – they‘ve been shown on real cars driving on the road, by compromising a single ECU via bluetooth, cellular, or wired access.

The problem is that automakers tend to favor cost savings and convenience over security. But as cars become more computerized and gain more wireless connectivity, the risk of automotive hacks will only increase.

The automotive industry needs to adopt defensive programming practices – input validation, privilege separation, cryptography, OTA updates, etc. But it will likely take regulations and liability to force meaningful changes.

So the next time you‘re cursing at an annoying bug or security flaw, just be thankful it can‘t crash your car!

Learn More

This guide was just a quick crash course in car hacking, but there‘s so much more to learn. I‘d encourage you to check out some of these resources to go deeper:

  • The Car Hacker‘s Handbook
  • Charlie Miller and Chris Valasek‘s car hacking research
  • Keen Security Lab‘s car hacking blogs
  • OpenGarages.org forums and videos

I hope this has inspired you to take a closer look at the code running in your car. Drive safe and hack responsibly!

Leave a Reply

Your email address will not be published. Required fields are marked *