Car Hacking and CAN Bus - How Automotive Attacks Really Work
Recently, I started playing around with GearGoat, which I modified a bit to have a visual 3D environment and create better PoCs. It is a pretty interesting automotive hacking lab. The idea is simple: simulate a modern car, its ECUs, and CAN traffic to learn how many automotive attacks really work.
Before getting into the attack side, here is a quick clarification about the lab.
GearGoat does not work against a real car. In this case, everything happens over a virtual CAN interface called vcan. On Linux, vcan allows you to create a simulated CAN bus inside the system itself, without physical hardware, USB-CAN adapters, or an OBD-II connection.
The idea is to have something like this:
GearGoat / 3D Simulator
↓
vcan0
↓
candump / cansniffer / cansend
In other words, the simulator generates and consumes CAN traffic on vcan0, and from the terminal I can listen to or inject frames just like I would in a real environment, but in a safe and controlled way.
For example:
candump vcan0
cansend vcan0 201#00C8
This makes the lab perfect for practicing concepts like replay, spoofing, or message reversing without touching any physical vehicle.
And honestly, when you start looking at how modern cars work internally, you realize one thing:
A modern car is basically a network of computers on wheels.
I am not talking about “one central computer”. I am talking about dozens of small distributed systems constantly talking to each other.
The engine has its ECU. The doors have another one. ABS has another one. The instrument cluster has another one. The multimedia screen has another one.
And all of them continuously exchange messages while you drive.
That is where CAN comes in.
🧠 What Is an ECU
ECU stands for:
Electronic Control Unit
Or, simply put:
small specialized computers inside the car.
Each ECU has:
- processor,
- memory,
- firmware,
- inputs/outputs,
- sensors,
- its own logic.
And normally each one is responsible for a specific function.
Typical examples:
| ECU | Function |
|---|---|
| Engine ECU | Engine control |
| BCM | Lights, doors, comfort features |
| ABS ECU | ABS braking |
| Dashboard ECU | Speedometer and instrument cluster |
| Airbag ECU | Airbags |
| Infotainment ECU | Multimedia screen |
| TCU | Transmission/gearbox |
When you press the accelerator:
- one ECU reads sensors,
- another calculates power,
- another updates the instrument cluster,
- another controls stability,
- etc.
All of this happens constantly and in real time.
📡 What Is CAN Bus
CAN, short for Controller Area Network, is the protocol many ECUs use to communicate with each other.
The idea is quite simple:
All ECUs share the same bus.
Something like this:
Engine ECU
|
ABS ECU
|
Dashboard ECU
|
BCM ECU (lights/doors)
When an ECU transmits:
- everyone listens,
- and each ECU decides whether that message is relevant to it or not.
Example structure:
201#00C8
Where:
201is the CAN ID,00C8is the data.
In a classic CAN frame, the payload can contain up to 8 bytes. In CAN FD it can be larger, but classic CAN is enough to understand the basics.
An important detail: the ID does not usually mean “this specific ECU”. It normally identifies a type of message or signal. For example, an ID may represent speed, door state, lights, RPM, etc.
And here comes the interesting part.
Classic CAN does have arbitration, CRC, and error detection mechanisms at the bus level, but it does NOT have:
- cryptographic authentication,
- encryption,
- real source validation.
In other words:
if you manage to transmit on the bus, you can try to impersonate another ECU.
And that is where many automotive attacks begin.
🔌 Do You Need to Plug Into the Car?
This was one of my doubts when I started, and the conclusion is: it depends.
Most basic labs and tests are done by physically connecting to the vehicle.
The typical setup is:
Laptop → OBD-II → CAN Bus
Using hardware such as:
- CANable,
- Panda,
- USB-CAN adapters,
- etc.
From there, you can:
- listen to traffic,
- send messages,
- perform replay attacks,
- fuzzing,
- UDS diagnostics,
- etc.
But there is an important caveat: in modern cars, the OBD-II port does not always give you full access to all internal networks. It is often behind a gateway that filters messages or separates different internal buses.
OBD-II connection
📶 How a Real Car Gets Compromised
In real-world attacks, you usually compromise a vulnerable ECU first.
Examples:
- Bluetooth,
- WiFi,
- LTE/telematics,
- mobile apps,
- TPMS,
- OTA updates.
And once inside:
Internet
↓
Infotainment ECU
↓
Internal gateway
↓
CAN Bus
↓
Other ECUs
This is where things become interesting, because the goal is usually not “attacking CAN directly from the Internet”, but finding an entry point in an exposed ECU and then pivoting into internal networks.
🔍 How to Start Analyzing CAN
This is where tools like these come in:
candump
cansniffer
cansend
And at first it looks impossible.
You open cansniffer and see:
100 00 01 44 90
101 10 22 00 01
201 00 14
301 FF 00 88 12
Everything changes constantly, thousands of messages, but the key is NOT to read everything.
The key is:
observe what changes when you perform ONE specific action.
🚘 CAN Reverse Engineering
For example:
- Capture traffic.
- Press “unlock”.
- Look for bytes that changed.
- Repeat several times.
- Inject the suspicious frame.
Typical example:
Before:
101#0100
After unlock:
101#0101
Then you test:
cansend vcan0 101#0101
And the doors unlock.
🔁 Replay Attacks
Another very common attack is replay.
The idea:
- Capture legitimate traffic.
- Save it.
- Replay it later.
For example:
candump -l vcan0
You perform actions such as:
- unlock,
- blink,
- accelerate.
And then replay the dump:
canplayer -I dump.log
In a simple lab or in ECUs without additional protections, the system may repeat the action:
- lights,
- doors,
- speed,
- etc.
This happens because classic CAN normally does not validate:
- authenticity,
- freshness,
- origin.
But in modern vehicles it is not always that straightforward. Many signals may include counters, checksums, required previous states, or pass through gateways that make a basic replay more difficult.
🧠 UDS - The Serious Part of Automotive Hacking
Diagnostic protocols such as UDS, Unified Diagnostic Services, are also used over CAN.
UDS usually runs over CAN using ISO-TP, and this is where you enter the world of:
- diagnostics,
- flashing,
- memory reading,
- diagnostic sessions,
- configuration changes.
Typical services:
| Service | Function |
|---|---|
| 0x10 | Diagnostic Session |
| 0x27 | Security Access |
| 0x22 | Read Data |
| 0x2E | Write Data |
| 0x34 | Request Download |
Many real-world attacks go through this area:
- seed-key bypass,
- ECU reflashing,
- firmware extraction,
- configuration modification,
- diagnostic session abuse,
- etc.
This is already much more serious than simply sending random CAN frames.
🚀 Conclusion
When you start researching automotive hacking, you realize that modern cars are much more complex than they seem.
After watching live CAN traffic for a while, the feeling changes a lot: you are no longer looking at a car, you are looking at several embedded systems coordinating in real time.
Many attacks, at least conceptually, come down to something quite simple:
Gain access
↓
Listen to traffic
↓
Understand messages
↓
Manipulate trust between ECUs
GearGoat obviously simplifies the real world a lot. It does not replicate real firmware, modern gateways, or complete architectures.
But it teaches the basics very well:
- CAN,
- replay,
- spoofing,
- reversing,
- ECU logic.
Note: All analysis and tests described were performed in virtual/lab environments for educational purposes. No tests were performed on third-party vehicles or unauthorized systems.