Hacking de Coches y CAN Bus - Cómo Funcionan Realmente los Ataques Automotive

Hace poco empecé a trastear con GearGoat, al que le hice unas modificaciones para tener un entorno 3D visual y poder hacer mejores PoCs. Es un laboratorio de hacking automotriz bastante curioso. La idea es simple: simular un coche moderno, sus ECUs y el tráfico CAN para aprender cómo funcionan realmente muchos ataques automotive.

Antes de entrar en la parte de ataques, una aclaración rápida sobre el lab.

GearGoat no trabaja contra un coche real. En este caso todo ocurre sobre una interfaz CAN virtual llamada vcan. En Linux, vcan permite crear un bus CAN simulado dentro del propio sistema, sin hardware físico, adaptadores USB-CAN ni conexión OBD-II.

La idea es tener algo así:

GearGoat / Simulador 3D
        ↓
      vcan0
        ↓
candump / cansniffer / cansend

Es decir, el simulador genera y consume tráfico CAN en vcan0, y desde la terminal puedo escuchar o inyectar frames igual que haría en un entorno real, pero de forma segura y controlada.

Por ejemplo:

candump vcan0
cansend vcan0 201#00C8

Esto hace que el lab sea perfecto para practicar conceptos como replay, spoofing o reversing de mensajes sin tocar ningún vehículo físico.

Y la verdad es que cuando empiezas a mirar cómo funcionan los coches modernos por dentro, te das cuenta de una cosa:

Un coche moderno es básicamente una red de ordenadores con ruedas.

No hablo de “un ordenador central”. Hablo de decenas de pequeños sistemas distribuidos hablando constantemente entre ellos.

El motor tiene su ECU. Las puertas tienen otra. El ABS otra. El cuadro de instrumentos otra. La pantalla multimedia otra.

Y todas se pasan mensajes continuamente mientras conduces.

Ahí es donde entra CAN.

---

🧠 Qué es una ECU

ECU significa:

Electronic Control Unit

O dicho de forma simple:

pequeños ordenadores especializados dentro del coche.

Cada ECU tiene:

• procesador,
• memoria,
• firmware,
• entradas/salidas,
• sensores,
• lógica propia.

Y normalmente cada una se encarga de una función concreta.

Ejemplos típicos:

ECU	Función
Engine ECU	Control del motor
BCM	Luces, puertas, confort
ABS ECU	Frenado ABS
Dashboard ECU	Velocímetro y cuadro
Airbag ECU	Airbags
Infotainment ECU	Pantalla multimedia
TCU	Transmisión/cambio

Cuando pisas el acelerador:

• una ECU lee sensores,
• otra calcula potencia,
• otra actualiza el cuadro,
• otra controla estabilidad,
• etc.

Todo eso ocurre constantemente y en tiempo real.

---

📡 Qué es CAN Bus

CAN, de Controller Area Network, es el protocolo que usan muchísimas ECUs para comunicarse.

La idea es bastante simple:

Todas las ECUs comparten el mismo bus.

Algo así:

ECU Motor
    |
ECU ABS
    |
ECU Dashboard
    |
ECU BCM (luces/puertas)

Cuando una ECU transmite:

• todas escuchan,
• y cada una decide si ese mensaje le interesa o no.

Ejemplo de estructura:

201#00C8

Donde:

• 201 es el ID CAN,
• 00C8 son los datos.

En un frame CAN clásico, el payload puede tener hasta 8 bytes. En CAN FD puede ser mayor, pero para entender las bases con CAN clásico es suficiente.

Un detalle importante: el ID no suele significar “esta ECU concreta”. Normalmente identifica un tipo de mensaje o señal. Por ejemplo, un ID puede representar velocidad, estado de puertas, luces, RPM, etc.

Y aquí viene lo interesante.

CAN clásico sí tiene mecanismos de arbitraje, CRC y detección de errores a nivel de bus, pero NO tiene:

• autenticación criptográfica,
• cifrado,
• validación real de origen.

Es decir:

si consigues transmitir en el bus, puedes intentar hacerte pasar por otra ECU.

Y ahí empiezan muchos ataques automotive.

---

🔌 ¿Hay Que Enchufarse al Coche?

Esta era una de mis dudas al empezar, y la conclusión es: depende.

La mayoría de labs y pruebas básicas sí se hacen conectándose físicamente.

Lo típico:

Laptop → OBD-II → CAN Bus

Usando hardware tipo:

• CANable,
• Panda,
• adaptadores USB-CAN,
• etc.

Desde ahí puedes:

• escuchar tráfico,
• enviar mensajes,
• hacer replay,
• fuzzing,
• diagnóstico UDS,
• etc.

Pero hay que matizar algo importante: en coches modernos, el puerto OBD-II no siempre te da acceso completo a todas las redes internas. Muchas veces está detrás de un gateway que filtra mensajes o separa distintos buses internos.

Conexión OBD-II

---

📶 Cómo Se Compromete un Coche de Verdad

En ataques reales normalmente primero comprometes alguna ECU vulnerable.

Ejemplos:

• Bluetooth,
• WiFi,
• LTE/telematics,
• apps móviles,
• TPMS,
• OTA updates.

Y una vez dentro:

Internet
↓
Infotainment ECU
↓
Gateway interno
↓
CAN Bus
↓
Otras ECUs

Aquí es donde la cosa se vuelve interesante, porque el objetivo no suele ser “atacar CAN directamente desde Internet”, sino encontrar una entrada en una ECU expuesta y después pivotar hacia redes internas.

---

🔍 Cómo Se Empieza a Analizar CAN

Aquí es donde entran herramientas como:

candump
cansniffer
cansend

Y al principio parece imposible.

Abres cansniffer y ves:

100  00 01 44 90
101  10 22 00 01
201  00 14
301  FF 00 88 12

Todo cambia constantemente, miles de mensajes, pero la clave NO es leer todo.

La clave es:

observar qué cambia cuando haces UNA acción concreta.

---

---

🚘 Reverse Engineering de CAN

Por ejemplo:

1. Capturas tráfico.
2. Pulsas “unlock”.
3. Buscas qué bytes cambian.
4. Repites varias veces.
5. Inyectas el frame sospechoso.

Ejemplo típico:

Antes:

101#0100

Después de unlock:

101#0101

Entonces pruebas:

cansend vcan0 101#0101

Y las puertas se desbloquean.:

---

---

🔁 Replay Attacks

Otro ataque muy típico es replay.

La idea:

1. Capturas tráfico legítimo.
2. Lo guardas.
3. Lo reproduces después.

Por ejemplo:

candump -l vcan0

Haces:

• unlock,
• blink,
• acelerar.

Y luego reproduces:

canplayer -I dump.log

En un lab simple o en ECUs sin protecciones adicionales, el sistema puede repetir la acción:

• luces,
• puertas,
• velocidad,
• etc.

Esto ocurre porque CAN clásico normalmente no valida:

• autenticidad,
• freshness,
• origen.

Pero en vehículos modernos no siempre es tan directo. Muchas señales pueden llevar contadores, checksums, estados previos requeridos o pasar por gateways que dificultan un replay básico.

---

🧠 UDS - La Parte Seria del Automotive Hacking

Sobre CAN también se usan protocolos de diagnóstico como UDS, Unified Diagnostic Services.

UDS suele viajar sobre CAN usando ISO-TP, y ya entra en el mundo de:

• diagnóstico,
• flashing,
• lectura de memoria,
• sesiones diagnósticas,
• cambios de configuración.

Servicios típicos:

Servicio	Función
0x10	Diagnostic Session
0x27	Security Access
0x22	Read Data
0x2E	Write Data
0x34	Request Download

Muchos ataques reales van por aquí:

• bypass de seed-key,
• reflashing de ECUs,
• lectura de firmware,
• modificación de configuración,
• abuso de sesiones diagnósticas,
• etc.

Ya es bastante más serio que simplemente mandar frames CAN sueltos.

---

🚀 Conclusión

Cuando empiezas a investigar automotive hacking te das cuenta de que los coches modernos son muchísimo más complejos de lo que parecen.

Después de un rato viendo tráfico CAN en directo, la sensación cambia bastante: ya no estás mirando un coche, estás mirando varios sistemas embebidos coordinándose en tiempo real.

Muchos ataques, al menos a nivel conceptual, se reducen a algo bastante simple:

Conseguir acceso
↓
Escuchar tráfico
↓
Entender mensajes
↓
Manipular confianza entre ECUs

GearGoat simplifica muchísimo el mundo real, obviamente. No replica firmware real, gateways modernos ni arquitecturas completas.

Pero sí enseña muy bien las bases:

• CAN,
• replay,
• spoofing,
• reversing,
• lógica ECU.

Nota: Todo el análisis y pruebas descritas se realizaron en entornos virtuales/laboratorio y con fines exclusivamente educativos. No se realizaron pruebas sobre vehículos de terceros ni sistemas no autorizados.