CAN bus security: learning the messages before the attacks

CAN bus security is one of the areas I want to understand better as I build pentesting skills. It takes a familiar security question and puts it in a very different environment: what tells a receiver that a message should be trusted?

This is a learning note built around a small virtual lab. I haven't assessed a real vehicle.

What a CAN identifier tells you

In classical CAN, the arbitration identifier helps determine message priority. It isn't an authenticated sender identity. The base frame format uses an 11-bit identifier, and the extended format uses 29 bits. Classical CAN carries up to eight data bytes; CAN FD can carry more.

The bus provides error handling and arbitration. Cryptographic sender authentication is a separate concern. Higher layers and gateways can add controls, so the absence of authentication in a basic CAN frame doesn't mean every vehicle exposes every function to any connected device.

The Linux SocketCAN documentation explains the frame formats and how Linux exposes CAN interfaces.

Start with a virtual interface

On a Linux lab machine with the vcan module and can-utils installed, this creates a virtual CAN interface:

sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
candump vcan0

In a second terminal, send a made-up frame to that virtual interface:

cansend vcan0 123#01020304

The receiving terminal should show ID 123 with four data bytes, which only proves that a frame can be sent and received locally. It doesn't model a particular car, get past a gateway, or prove an ECU will accept a command.

When finished, remove the virtual interface:

sudo ip link delete vcan0

These examples deliberately use vcan0. Real vehicle testing belongs in an authorized, isolated setup with the relevant safety controls, and a diagnostic connector doesn't promise unrestricted access to every bus.

A repeated frame isn't automatically a valid command

Capturing a message and replaying it is the obvious first step, and it's tempting to stop there and assume the protocol is understood. A receiver may also check a counter, checksum, timing, state, or application-level authentication. A message that means something while the system is in one state might be ignored in another.

I'd keep separate notes for observations and hypotheses. "These bytes changed when this event happened" is an observation. "This field controls the actuator" is a hypothesis that still needs evidence.

Think about the defender's view

On the defensive side, I'd want to know which buses a gateway connects, which diagnostic actions require authorization, whether firmware updates are authenticated, and how unexpected message patterns get detected.

Timing and frequency can point to anomalies, but normal maintenance or a software update can also change the traffic, so an alert on its own isn't a conclusion.

My next step is a small simulated receiver with documented behavior, so I can test what it accepts, what it rejects, and whether its logs explain why. That gives the exercise a result I can reproduce, which is more than I'd get from a pile of frames I can't explain.

The tools used here are maintained in the linux-can can-utils project.