Car Hacking y el Protocolo CAN

Car Hacking y el Protocolo CAN es un punto de encuentro entre dos mundos: la pasión por los autos y el análisis técnico de sistemas embebidos. A diferencia del hacking “clásico” sobre redes IP, aquí la superficie de ataque suele estar dentro del vehículo, en buses internos diseñados para confiabilidad y desempeño, no para resistir adversarios. Entender cómo funciona CAN, cómo se “reversea” y qué puede salir mal es clave tanto para investigar de forma responsable como para mejorar la seguridad real de los vehículos.

Por qué el car hacking no empieza en Wi-Fi

Muchas investigaciones populares se enfocaron en autos conectados: infotainment con Internet, Bluetooth, telemática, etc. Ese enfoque tiene sentido porque el acceso remoto es atractivo y porque, históricamente, varios componentes se comportaron como “IoT con ruedas”: gran funcionalidad, poca seguridad por defecto.

Pero una parte importante del aprendizaje en Car Hacking y el Protocolo CAN ocurre cuando no hay conectividad moderna disponible. Si el vehículo no tiene Wi-Fi, Bluetooth ni servicios expuestos, el camino natural es bajar de nivel y mirar los protocolos internos del automóvil. Ese cambio de perspectiva obliga a estudiar buses, tramas, señales y comportamiento de las ECUs, y a asumir que “romper cosas” puede tener consecuencias físicas.

Advertencia esencial: esto puede ser peligroso

Manipular sistemas de un vehículo puede ser peligroso para quien investiga y para terceros. Hay escenarios donde una acción sobre el bus puede provocar comportamientos inesperados: apagados, luces que quedan encendidas, fallos transitorios o, en el peor caso, pérdida de funciones críticas. Este riesgo aumenta si el vehículo está en movimiento.

En investigaciones reales, también es común que el auto quede en estados raros y que la recuperación requiera acciones de “reinicio” del sistema eléctrico del vehículo (por ejemplo, desconectar y reconectar alimentación). En todo caso, cualquier experimentación debe hacerse con medidas de seguridad, en entornos controlados y con un enfoque de investigación responsable.

El puerto OBD2: la puerta de diagnóstico que interesa a los investigadores

Un punto de acceso recurrente en Car Hacking y el Protocolo CAN es el conector OBD2, pensado para diagnóstico y mantenimiento. Los mecánicos lo usan para leer fallas, revisar parámetros y, en algunos casos, ejecutar acciones de diagnóstico (por ejemplo, resetear ciertos indicadores).

OBD2 no expone un único protocolo: puede transportar varios, desde opciones más antiguas de diagnóstico hasta CAN, que es el que suele habilitar capacidades más amplias dentro del vehículo.

Algo importante: que el puerto exista no garantiza que CAN esté disponible ahí. En la práctica se revisa si están presentes las líneas del bus (comúnmente asociadas a pines específicos como CAN High y CAN Low) o se verifica señal/voltaje con instrumentación. Esto define si el análisis por OBD2 será viable o si habrá que buscar el bus directamente en cableado interno.

Qué es CAN y por qué se usa dentro del auto

El Controller Area Network (CAN) se diseñó para entornos con ruido eléctrico y necesidad de comunicación robusta. Dentro del vehículo, el bus CAN permite que distintos nodos (sensores y ECUs) compartan información en una topología tipo bus. Un mismo mensaje puede ser útil para múltiples módulos al mismo tiempo, lo que encaja con la lógica de sistemas automotrices.

Señal diferencial: CAN High y CAN Low

CAN utiliza señalización diferencial para mejorar la inmunidad a interferencias. En términos simples, el emisor “duplica” la señal en dos líneas complementarias. El receptor interpreta el estado comparando ambas. Este enfoque ayuda a resistir el ruido típico del entorno automotor.

Lógica dominante y recesiva

En CAN suelen describirse dos estados: dominante y recesivo. Este detalle no es solo teoría: influye en cómo el bus resuelve contención y en cómo se comporta la prioridad de los mensajes cuando varios nodos intentan transmitir.

La trama CAN: por qué no hay origen/destino como en TCP/IP

Una trama CAN típica se compone, a alto nivel, de:

• ID (identificador del mensaje)
• DLC (data length, longitud del dato)
• Data (hasta 8 bytes en el formato clásico)

En Car Hacking y el Protocolo CAN, este punto sorprende a quienes vienen del mundo IP: no hay direcciones de origen/destino, ni puertos, ni “servicios”. Entonces, ¿cómo decide un nodo si debe procesar un mensaje? Por convención: cada ECU sabe qué IDs le interesan. Lee el ID, interpreta los bytes según su lógica interna, o ignora la trama si no aplica.

Además, la trama no “dice” qué representa su contenido. Si un mensaje codifica RPM, luces o estado de freno, eso no viene etiquetado. Por eso, la investigación se apoya en un proceso de reversing de señales y comportamiento.

Prioridad en el bus: un detalle con impacto de seguridad

En CAN, la prioridad está asociada al ID: ciertos IDs “ganan” acceso al bus cuando hay contención, por cómo se arbitra la transmisión. En el mundo automotriz, esto tiene sentido funcional: mensajes críticos deben transmitirse con mayor prioridad.

Desde una mirada de seguridad, este mecanismo puede convertirse en una debilidad si un actor malicioso logra transmitir mensajes de alta prioridad y saturar la comunicación, afectando la disponibilidad del bus y el funcionamiento normal de las ECUs. Es un ejemplo clásico de cómo una decisión de diseño orientada a confiabilidad puede abrir un riesgo cuando aparece un adversario activo.

El reversing en CAN: el trabajo tedioso que nadie puede saltarse

El “truco” no suele ser encontrar el bus: lo realmente difícil es descubrir qué trama hace qué cosa. En la práctica, el reversing es repetitivo:

1. Conectar un dispositivo de captura (sniffer) al bus accesible (por ejemplo, vía OBD2).
2. Observar el tráfico continuo de tramas.
3. Ejecutar una acción física en el auto (encender luces, activar direccionales, freno, etc.).
4. Comparar qué cambia: ID, uno o más bytes, o patrones temporales.
5. Repetir hasta aislar el comportamiento.

Ese proceso puede tomar horas en una posición incómoda, con cientos o miles de tramas por minuto. Y no hay garantías: lo que funciona en un modelo, puede no aplicar en otro, incluso dentro de la misma marca. Para los fabricantes, los mapeos internos de señales son información sensible y varían por plataforma, región y versión.

Un ejemplo típico: luces y bytes que cambian

Un patrón común durante el reversing es observar que, al activar una función (por ejemplo, luces bajas o altas), un byte específico cambia y se mantiene estable mientras la función esté activa. En otras funciones, como balizas o direccionales, puede haber alternancia entre estados (encendido/apagado) con un ritmo fijo. Esta observación no es suficiente por sí sola, pero guía hacia el vector correcto.

Herramientas: del osciloscopio a analizadores más prácticos

En el nivel más bajo, un osciloscopio permite ver la señal física. Es útil para diagnóstico eléctrico y análisis de calidad de señal, pero suele ser caro y, para reversing funcional, no siempre es la herramienta más eficiente.

Para Car Hacking y el Protocolo CAN, suele ser más práctico usar herramientas que muestren tramas decodificadas y permitan trabajar con IDs y bytes de manera legible. Hay opciones comerciales y también alternativas de open hardware.

Sniffing y SocketCAN en Linux

En ambientes Linux, SocketCAN es una pieza clave: ofrece una interfaz de red para CAN que permite capturar, filtrar y manejar tramas con utilidades y librerías estándar del sistema. Esto habilita flujos de trabajo reproducibles para análisis, registro de tráfico y pruebas controladas.

Inyección de tramas: por qué no siempre “se prende” lo que querés

Una vez que se identifica una trama, surge la tentación de transmitirla para reproducir el efecto. Sin embargo, no siempre es tan simple: muchas ECUs emiten su estado actual continuamente. Si el sistema del vehículo “dice” todo el tiempo que algo está apagado, y el investigador inyecta “encendido” con una frecuencia baja, el resultado puede ser intermitente (por ejemplo, un efecto de titileo en lugar de un encendido sostenido).

Esto introduce un requisito técnico: la inyección debe respetar timing y frecuencia del entorno real, y además considerar que el bus es compartido. Desde una perspectiva defensiva, este comportamiento es un recordatorio de que la seguridad no puede depender de “que el atacante no alcance la velocidad”, porque hardware dedicado puede resolverlo.

Hardware a medida y control remoto: el concepto de “backdoor” físico

En investigaciones presentadas por la comunidad, un camino frecuente fue construir hardware propio: un microcontrolador con soporte CAN, un transceptor para convertir la lógica a señal diferencial, y una interfaz para configurar e inyectar tramas. Algunos prototipos evolucionaron para soportar dos modos:

• Modo programación: configuración desde una computadora (por ejemplo, vía USB) y persistencia en memoria.
• Modo operación: conexión al vehículo y ejecución de acciones definidas previamente.

La idea de un “backdoor” aparece cuando el dispositivo es pequeño, queda conectado en el área del conector de diagnóstico y pasa desapercibido. En ese escenario, el riesgo no es solo técnico: es también físico y operativo. Un dispositivo conectado en un punto expuesto puede ser instalado en minutos si no hay controles.

Control por mensajes y listas de autorización

Para minimizar abusos en prototipos de investigación, se ha mencionado el uso de filtros simples como permitir comandos solo desde números autorizados, incluir un comando de detención (“stop”) y mantener el dispositivo en escucha si la solicitud no cumple validación. Es una medida básica, útil para un laboratorio, pero insuficiente como defensa real en un entorno hostil.

Disponibilidad del bus: el riesgo de denegación de servicio

Uno de los impactos más serios en Car Hacking y el Protocolo CAN es la disponibilidad. Si un actor logra monopolizar el bus con mensajes de alta prioridad a gran velocidad, puede impedir que otros nodos transmitan. En un vehículo, la pérdida de comunicación entre módulos puede traducirse en fallos y comportamientos peligrosos.

Este punto es especialmente importante porque no depende de “entender” todas las señales del auto: a veces basta con afectar el canal compartido. Por eso, la mitigación debe considerar mecanismos de aislamiento, gateways y detección de anomalías, no solo “ocultar IDs”.

Open CAN DB: por qué una base de datos abierta cambia el juego

Un obstáculo central del car hacking es la falta de mapeos públicos: descubrir tramas lleva tiempo. Para reducir esa barrera, la comunidad ha propuesto bases de datos abiertas de frames, donde investigadores pueden subir:

• Marca y modelo del vehículo
• El frame observado (ID y bytes relevantes)
• El vector o función asociada (qué hace)
• Región (porque puede variar por país/mercado)

Esto no elimina la necesidad de investigación responsable, pero sí acelera la curva de aprendizaje y muestra un hecho incómodo: cuando el conocimiento se comparte, la seguridad por oscuridad pierde valor. La respuesta defensiva debe ser sistémica.

Modernidad ≠ seguridad: más electrónica, más superficie

En vehículos más antiguos, muchas funciones críticas eran mecánicas. En modelos más modernos, aparecen sistemas by-wire y módulos que integran asistencia avanzada (por ejemplo, estacionamiento automatizado). A medida que más funciones dependen de ECUs y buses, la superficie de ataque crece.

Además, no siempre hay un único bus. Un vehículo puede tener múltiples redes internas, y el conector de diagnóstico puede exponer solo una parte. Esto explica por qué a veces una señal buscada no aparece por OBD2: puede estar en otro segmento, detrás de un gateway, o en una red diferente. Para defensa, esto es una oportunidad: segmentación y control de acceso interno pueden reducir el impacto de una intrusión localizada.

Cómo mitigar riesgos en CAN sin depender de “secretos”

Mitigar riesgos en Car Hacking y el Protocolo CAN requiere combinar varias capas, porque el problema no es solo el protocolo: es el ecosistema completo.

1) Controlar el acceso físico al diagnóstico

El primer control es operativo: reducir la posibilidad de que alguien conecte hardware no autorizado. Esto puede incluir cubiertas, sellos, reubicación o políticas de revisión en flotas. No es infalible, pero eleva el costo del ataque.

2) Gateways y segmentación entre redes

Los gateways pueden filtrar qué mensajes pasan entre segmentos, limitar tasas de transmisión, y bloquear patrones anómalos. Separar redes críticas de redes menos críticas reduce el “radio de explosión” si una parte se ve comprometida.

3) Detección de intrusiones orientada a CAN

Un IDS automotriz puede aprender perfiles normales: frecuencias de mensajes, rangos de valores, correlación entre señales y estados del vehículo. Cambios abruptos (por ejemplo, tasas imposibles o valores incoherentes) pueden disparar alertas o medidas de contención.

4) Autenticación e integridad a nivel de mensajes

CAN clásico no fue diseñado con autenticación. Para elevar el nivel, se usan extensiones, encapsulamiento, gateways con verificación, o arquitecturas que agregan integridad y autorización para comandos sensibles.

5) Reducir funciones peligrosas desde diagnóstico

Algunas funciones de diagnóstico son útiles para mantenimiento pero riesgosas si quedan accesibles sin control. Revisar qué acciones están permitidas, bajo qué condiciones (vehículo detenido, modo servicio, autenticación) y cómo se auditan, es parte de un enfoque maduro.

Investigación responsable: cómo aprender sin causar daño

Car Hacking y el Protocolo CAN es fascinante, pero el aprendizaje debe hacerse con límites. En términos prácticos:

• Entornos controlados y vehículo inmovilizado para pruebas.
• Registro y trazabilidad de capturas y condiciones para reproducibilidad.
• Enfoque defensivo para convertir hallazgos en mitigaciones concretas.
• Divulgación responsable si se identifica un riesgo real.

Hacia dónde va el car hacking

El protocolo CAN no vive solo en autos: también aparece en otros vehículos y maquinaria. A medida que crecen los sistemas embebidos y la conectividad, aumentan los escenarios de riesgo y la necesidad de seguridad por diseño. La comunidad seguirá explorando hardware, software, bases de datos colaborativas y técnicas de análisis, pero el objetivo sostenible es el mismo: que fabricantes y operadores adopten defensas que no dependan de suposiciones frágiles.

Preguntas frecuentes

¿Qué significa exactamente “Car Hacking y el Protocolo CAN”?

Es el análisis de seguridad aplicado a vehículos, con foco en cómo las ECUs se comunican por CAN, cómo se identifican tramas relevantes y qué riesgos aparecen cuando un adversario puede leer o transmitir en el bus.

¿OBD2 siempre permite acceder a CAN?

No. OBD2 es un conector de diagnóstico que puede exponer distintos protocolos. En algunos vehículos, CAN está accesible; en otros, no lo está o solo se ve una parte de las redes internas.

¿Por qué es tan difícil saber qué hace un frame CAN?

Porque la trama no incluye semántica: solo ID, longitud y bytes. La interpretación depende de cada ECU y del fabricante, por lo que hay que hacer reversing observando cambios al ejecutar acciones reales.

¿Qué es más crítico: tomar control de funciones o afectar disponibilidad?

Ambos pueden ser críticos. Alterar funciones depende de conocer tramas específicas; afectar disponibilidad puede lograrse con saturación del bus y puede provocar fallos amplios si no hay mitigaciones.

¿Los autos más nuevos son más seguros o más vulnerables?

Suelen tener más funciones electrónicas y, por tanto, más superficie de ataque. El nivel de seguridad depende de la arquitectura: segmentación, gateways, monitoreo y validaciones marcan la diferencia.

¿Qué defensas suelen dar mejores resultados?

La combinación de control físico del diagnóstico, segmentación con gateways, IDS orientado a CAN y validación/autorización de mensajes críticos es más robusta que depender de “ocultar” información.

Conclusión

Car Hacking y el Protocolo CAN demuestra que un bus diseñado para robustez puede volverse riesgoso cuando aparece un adversario con acceso al canal. Comprender tramas, prioridad, reversing e inyección permite evaluar el impacto real, pero el valor final está en aplicar defensas: segmentación, monitoreo, controles de diagnóstico y validación de comandos sensibles.

Si querés profundizar en investigación y defensa de sistemas automotrices desde una perspectiva práctica y responsable, vale la pena seguir charlas técnicas de la comunidad y conocer más sobre eventos como la DragonJAR Security Conference a través de su sitio oficial.

Mira la charla completa sobre "Car Hacking y el Protocolo CAN"