La idea es recopilar información y presentar una guía de como hackear coches. No prometo nada, a ver que sale.
¡Bien! ¡vamos a ello!. Si lo que buscamos es introducirnos en un vehículo para modificarlo que es en la base del hacking, mientras examina el exterior del vehículo, hágase estas preguntas:
•¿Cuáles son las opciones de entrada de audio: CD? ¿USB? ¿Bluetooth?
•¿Hay puertos de diagnóstico?
•¿Cuáles son las capacidades del tablero de instrumentos? ¿Hay un GPS? ¿Bluetooth?
Los modelos de amenazas generalmente se crean durante el proceso de desarrollo y
diseño del producto. Si la empresa que produce un producto en particular tiene un buen ciclo
de vida de desarrollo, crea el modelo de amenaza cuando comienza el desarrollo del producto
y actualiza continuamente el modelo a medida que el producto avanza a través del ciclo de vida
de desarrollo.
Los modelos de amenazas son documentos vivos que cambian a medida que
cambia el objetivo y aprende más sobre un objetivo, por lo que debe actualizar su modelo de
amenazas con frecuencia.
•Si el vehículo es eléctrico, ¿cómo se carga?
Su modelo de amenaza puede constar de diferentes niveles; si un proceso en su
modelo es complicado, debería considerar desglosarlo más por
Al examinar el interior, tenga en cuenta lo siguiente:
•¿Hay acceso físico al teclado?
Se han escrito libros enteros sobre el modelado de amenazas, pero le daré un recorrido
rápido para que pueda crear sus propios modelos de amenazas. (Si tiene más preguntas o si
esta sección le emociona, por supuesto, ¡tome otro libro sobre el tema!)
•¿Hay sensores táctiles o de movimiento?
Al modelar la amenaza de un automóvil, recopila información sobre la arquitectura de
su objetivo y crea un diagrama para ilustrar cómo se comunican las partes del automóvil. Luego,
utiliza estos mapas para identificar entradas de mayor riesgo y mantener una lista de verificación
de cosas para auditar; esto lo ayudará a priorizar los puntos de entrada que podrían generar el
mayor rendimiento.
Como puede ver, hay muchas formas en que los datos pueden ingresar al vehículo. Si alguno
de estos datos tiene un formato incorrecto o es intencionalmente malicioso, ¿qué sucede? Aquí es
donde entra en juego el modelado de amenazas.
Cuando evalúe la superficie de ataque de un vehículo, piense en usted mismo como un
espía malvado que está tratando de hacerle cosas malas a un vehículo. Para encontrar
debilidades en la seguridad del vehículo, evalúe el perímetro del vehículo y documente el
entorno del vehículo.
Asegúrese de considerar todas las formas en que los datos pueden
ingresar a un vehículo, que son todas las formas en que un vehículo se comunica con el mundo exterior.
•¿Qué señales se reciben?
•¿Hay sensores táctiles o de movimiento?
•¿Ondas de radio? ¿Llavero? ¿Sensores de distancia?¿Internet?
Como puede ver, hay muchas formas en que los datos pueden ingresar al vehículo. Si alguno
de estos datos tiene un formato incorrecto o es intencionalmente malicioso, ¿qué sucede? Aquí es
donde entra en juego el modelado de amenazas.
Modelado de amenazas
Se han escrito libros enteros sobre el modelado de amenazas, pero le daré un recorrido
rápido para que pueda crear sus propios modelos de amenazas.
Al modelar la amenaza de un automóvil, recopila información sobre la arquitectura de
su objetivo y crea un diagrama para ilustrar cómo se comunican las partes del automóvil. Luego,
utiliza estos mapas para identificar entradas de mayor riesgo y mantener una lista de verificación
de cosas para auditar; esto lo ayudará a priorizar los puntos de entrada que podrían generar el
mayor rendimiento.
Los modelos de amenazas generalmente se crean durante el proceso de desarrollo y
diseño del producto. Si la empresa que produce un producto en particular tiene un buen ciclo
de vida de desarrollo, crea el modelo de amenaza cuando comienza el desarrollo del producto
y actualiza continuamente el modelo a medida que el producto avanza a través del ciclo de vida
de desarrollo. Los modelos de amenazas son documentos vivos que cambian a medida que
cambia el objetivo y aprende más sobre un objetivo, por lo que debe actualizar su modelo de
amenazas con frecuencia.
Su modelo de amenaza puede constar de diferentes niveles; si un proceso en su
modelo es complicado, debería considerar desglosarlo más por agregar más niveles a sus diagramas. Sin embargo, al principio, el Nivel 2 es lo más lejos
que podrá llegar. Analizaremos los distintos niveles en las siguientes secciones,
comenzando con el nivel de amenaza 0.
Nivel 0: Vista de pájaro
En este nivel, usamos la lista de
verificación que creamos al considerar
las superficies de ataque. Piense en cómo
los datos pueden entrar en el vehículo.
Dibuja el vehículo en el centro y luego
rotula los espacios externos e internos. La figura 1-1 ilustra un posible diagrama de Nivel 0.
Los cuadros rectangulares son las
entradas, y el círculo en el centro
representa todo el vehículo. En su camino
hacia el vehículo, las entradas cruzan
dos líneas punteadas, que representan
amenazas externas e internas.
El círculo de vehículos no representa
una entrada, sino un proceso complejo,
es decir, una serie de tareas que podrían
desglosarse aún más.
Los procesos están numerados y, como
puede ver, este es el número 1.0. Si tuviera
más de una pieza compleja en su modelo
de amenaza, las enumeraría en sucesión.
Por ejemplo, etiquetaría un segundo
proceso como 2.0; un tercero, 3,0; y así.
A medida que aprende acerca de las
características de su vehículo, actualiza el diagrama.
Está bien si aún no reconoces todos los
acrónimos en el diagrama.
En este nivel, usamos la lista de
verificación que creamos al considerar
las superficies de ataque. Piense en cómo
los datos pueden entrar en el vehículo.
Dibuja el vehículo en el centro y luego
rotula los espacios externos e internos.
Nivel 1: Receptores
Para pasar al diagrama del Nivel 1, elija un proceso para explorar. Debido a que solo
tenemos un proceso en nuestro diagrama, profundicemos en el proceso del vehículo y
concentrémonos en a qué se refiere cada entrada.
El mapa del Nivel 1 que se muestra en la Figura 1-2 es casi idéntico al del Nivel 0. La única diferencia es que aquí especificamos las conexiones del vehículo que reciben la entrada del Nivel 0. Todavía no analizaremos los receptores en profundidad; estamos viendo solo el dispositivo básico o el área con la que habla la entrada.
Observe en la Figura 1-2 que numeramos cada receptor. El primer dígito representa la etiqueta del proceso del diagrama de Nivel 0 en la Figura 1-1, y el segundo dígito es el número del receptor. Debido a que la unidad de infoentretenimiento es tanto un proceso complejo como una entrada, le hemos dado un círculo de proceso. Ahora tenemos otros tres procesos: inmovilizador, ECU y receptor TPMS.
Las líneas punteadas en el mapa de Nivel 1 representan divisiones entre la confianza límites. Las entradas en la parte superior del diagrama son las menos confiables y las que están en la parte inferior son las más confiables.
Cuantos más límites de confianza cruce un canal de comunicación, más arriesgado se vuelve ese canal.
Nivel 2: avería del receptor
En el Nivel 2, examinamos la comunicación que tiene lugar dentro del vehículo. Nuestro diagrama de muestra (Figura 1-3) se enfoca en una consola de información y entretenimiento basada en Linux, el receptor 1.1. Este es uno de los receptores más complicados y, a menudo, está directamente conectado a la red interna del vehículo.
En la Figura 1-3, agrupamos los canales de comunicación en cuadros con líneas discontinuas para representar una vez más los límites de confianza. Ahora hay un nuevo límite de confianza dentro de la consola de infoentretenimiento llamado espacio del kernel.
Los sistemas que se comunican directamente con el kernel tienen un mayor riesgo que los que se comunican con las aplicaciones del sistema porque pueden eludir cualquier mecanismo de control de acceso en la unidad de infoentretenimiento. Por lo tanto, el canal celular tiene un mayor riesgo que el canal Wi-Fi porque cruza un límite de confianza hacia el espacio del kernel; el canal Wi-Fi, por otro lado, se comunica con el proceso suplicante WPA en el espacio del usuario.
Este sistema es un sistema de información y entretenimiento en el vehículo (IVI) basado en
Linux y utiliza partes comunes a un entorno Linux.
En el espacio del kernel, verá referencias a los módulos del kernel udev, HSI y Kvaser, que reciben información de nuestro modelo de amenazas. El módulo udev carga dispositivos USB, HSI es un controlador en serie que maneja la comunicación celular y Kvaser es el controlador de red del vehículo.
El patrón de numeración para el Nivel 2 ahora es XXX y el sistema de identificación es el
mismo que antes. En el Nivel 0, tomamos el proceso del vehículo que era 1.0 y profundizamos en
él. Luego marcamos todos los procesos dentro del Nivel 1 como 1.1, 1.2 y así sucesivamente.
A continuación, seleccionamos el proceso de infoentretenimiento marcado como 1.1 y lo desglosamos
aún más para el diagrama de Nivel 2.
En el Nivel 2, por lo tanto, etiquetamos todos los procesos complejos como 1.1.1, 1.1.2, etc. (Puede continuar con el mismo esquema de numeración a medida que profundiza aún más en los procesos. Intentemos este ejercicio juntos. Comience en el Nivel 0—la vista de pájaro— El esquema de numeración es para fines de documentación; le permite hacer referencia al proceso exacto en el nivel apropiado).
Idealmente, en esta etapa, mapearía qué procesos manejan qué entradas, pero tendremos que adivinar por ahora. En el mundo real, necesitaría aplicar ingeniería inversa al sistema de infoentretenimiento para encontrar esta información.NOTA
Al construir o diseñar un sistema automotriz, debe continuar profundizando en tantos procesos complejos como sea posible.
Reúna al equipo de desarrollo y comience a analizar los métodos y las bibliotecas que utiliza cada aplicación para que pueda incorporarlos en sus propios diagramas de amenazas. Probablemente encontrará que los límites de confianza en el nivel de la aplicación normalmente estarán entre la aplicación y el núcleo, entre la aplicación y las bibliotecas, entre la aplicación y otras aplicaciones, e incluso entre funciones.
Al explorar estas conexiones, marque los métodos que tengan mayores privilegios o que manejen información más confidencial.
Identificación de amenazas
Ahora que hemos profundizado dos niveles en nuestros mapas de modelado de amenazas, podemos comenzar a identificar amenazas potenciales. La identificación de amenazas suele ser más divertida con un grupo de personas y una pizarra, pero puede hacerlo por su cuenta como un ejercicio mental.
Intentemos este ejercicio juntos. Comience en el Nivel 0—la vista de pájaro—y considere posibles problemas de alto nivel con entradas, receptores y límites de amenazas. Ahora enumeremos todas las amenazas potenciales con nuestros modelos de amenazas.
Nivel 0: Vista de pájaro
Al determinar las amenazas potenciales en el Nivel 0, trate de mantenerse en un nivel alto. Algunas de estas amenazas pueden parecer poco realistas porque conoce obstáculos o protecciones adicionales, pero es importante incluir todas las amenazas posibles en esta lista, incluso si algunas ya se han abordado. El punto aquí es hacer una lluvia de ideas sobre todos los riesgos de cada proceso y entrada.
Las amenazas de alto nivel en el Nivel 0 son que un atacante podría:
• Apagar un vehículo
• Acceder a la red interna de vehículos desde cualquier lugar
•Instalar malware en el vehículo
• Acceder al módulo de identidad del suscriptor (SIM)
Al principio, puede ser difícil idear un montón de escenarios de ataque.
Las amenazas de alto nivel en el Nivel 0 son que un atacante podría:
Celular
• Seguimiento de un vehículo
•Explotar la aplicación en la unidad de infoentretenimiento que maneja las entradas
• Escuchar las comunicaciones celulares
Un atacante podría explotar la conexión celular en un vehículo para:
•Frutar los sistemas de seguridad
•Desbloquear un vehículo
La identificación de amenazas en el Nivel 1 se enfoca más en las conexiones de cada pieza que en las conexiones que podrían hacerse directamente a una entrada. Las vulnerabilidades que postulamos en este nivel se relacionan con las vulnerabilidades que afectan lo que se conecta a los dispositivos en un vehículo.
•Utilice una red celular para conectarse al sistema de diagnóstico remoto.
Los desglosaremos en grupos de amenazas que se relacionan con conexiones de bus de telefonía móvil, Wi-Fi, llavero (KES), sensor de control de presión de neumáticos (TPMS),
consola de infoentretenimiento, USB, Bluetooth y red de área del controlador (CAN). Como puede ver en las siguientes listas, hay muchas formas posibles de entrar en un vehículo.
•Robar un vehículo
unidad de ment (Estrella) A menudo es bueno que personas que no son ingenieros también participen en esta etapa
porque, como desarrollador o ingeniero, tiendes a estar tan involucrado en el funcionamiento
interno que es natural desacreditar las ideas sin siquiera quererlo.
•Tomar el control de un vehículo de forma remota
• Espía a los ocupantes del vehículo
Ser creativo; trata de idear el ataque de villano más James Bond que puedas imaginar.
Tal vez piense en otros escenarios de ataque y si también podrían aplicarse a los vehículos. Por
ejemplo, considere el ransomware, un software malicioso que puede encriptarlo o bloquearlo de su
computadora o teléfono hasta que pague dinero a alguien que controla el software de forma remota.
¿Se podría usar en vehículos? La respuesta es sí. Anote el ransomware .
Nivel 1: Receptores
La identificación de amenazas en el Nivel 1, se enfoca más en las conexiones de cada pieza que en las conexiones que podrían hacerse directamente a una entrada. Las vulnerabilidades que postulamos en este nivel, se relacionan con las vulnerabilidades que afectan lo que se conecta a los dispositivos en un vehículo.
•Utilice una red celular para conectarse al sistema de diagnóstico remoto.
Los desglosaremos en grupos de amenazas, que se relacionan con conexiones de bus de telefonía móvil, Wi-Fi, llavero (KES), sensor de control de presión de neumáticos (TPMS), consola de infoentretenimiento, USB, Bluetooth y red de área del controlador (CAN). Como puede ver en las siguientes listas, hay muchas formas posibles de entrar en un vehículo.
Celular
Un atacante podría explotar la conexión celular en un vehículo para:
Acceder a la red interna de vehículos desde cualquier lugar
•Instalar malware en el vehículo
• Acceder al módulo de identidad del suscriptor (SIM) a través del infotain
Al principio, puede ser difícil idear un montón de escenarios de ataque.
Las amenazas de alto nivel en el Nivel 0 son que un atacante podría:
Celular
• Seguimiento de un vehículo
•Explotar la aplicación en la unidad de infoentretenimiento que maneja las entradas
•Utilice una red celular para conectarse al sistema de diagnóstico remoto
• Escuchar las comunicaciones celulares
• Atasco de llamadas de socorro
• Seguimiento de los movimientos del vehículo
•Establecer una base falsa de Sistema Global para Comunicaciones Móviles (GSM)
Wifi
Un atacante podría explotar la conexión Wi-Fi para:
•Acceda a la red de vehículos desde una distancia de hasta 300 yardas o más
•Capture la información criptográfica filtrada del inmovilizador durante el proceso de negociación
Un atacante podría explotar la conexión TPMS para:
• Sondee activamente un inmovilizador para agotar la batería del automóvil
•Encuentre un exploit para el software que maneja las conexiones entrantes
•Instalar código malicioso en la unidad de infoentretenimiento
• Clonar la llave
• Generar un fallo que luego podría ser explotada
•Engañar a la ECU para que corrija en exceso las condiciones de la carretera falsificadas
•Rompe la contraseña de Wi-Fi
• Configure un punto de acceso de distribuidor falso para engañar al vehículo haciéndole creer que
está siendo reparado
• Seguimiento de los movimientos del vehículo
estación
•Fuerza bruta el algoritmo del llavero
•Interceptar las comunicaciones que pasan a través de la red Wi-Fi
• Seguimiento del vehículo
Llaves
Un atacante podría explotar la conexión de la llave para:
•Enviar solicitudes de llaveros con formato incorrecto que colocan el inmovilizador del vehículo en un
estado desconocido. (Se supone que el inmovilizador mantiene el vehículo bloqueado para que
no se pueda conectar. Necesitamos asegurarnos de que mantenga la funcionalidad adecuada).
• Sondee activamente un inmovilizador para agotar la batería del automóvil
•Bloquear una llave
•Instalar código malicioso en la unidad de infoentretenimiento
•Enviar solicitudes de llaveros con formato incorrecto que colocan el inmovilizador del vehículo en un
estado desconocido. (Se supone que el inmovilizador mantiene el vehículo bloqueado para que
no se pueda conectar. Necesitamos asegurarnos de que mantenga la funcionalidad adecuada).
•Acceda a la red de vehículos desde una distancia de hasta 300 yardas o más
•Capture la información criptográfica filtrada del inmovilizador durante el proceso de negociación
Un atacante podría explotar la conexión TPMS para:
• Sondee activamente un inmovilizador para agotar la batería del automóvil
•Encuentre un exploit para el software que maneja las conexiones entrantes
•Enviar una condición imposible a la unidad de control del motor (ECU)
• Seguimiento del vehículo
• Atasco en la señal del llavero
Un atacante podría explotar la conexión Wi-Fi para:
Un atacante podría explotar la conexión del llavero para:
• Drene la energía de la llave
Sensor de control de presión de neumáticos
• Configure un punto de acceso de distribuidor falso para engañar al vehículo haciéndole creer que
está siendo reparado
• Seguimiento de los movimientos del vehículo
•Fuerza bruta el algoritmo de la llave
USB
•Suplantación de la señal TPMS para activar alarmas internas
• Conecte un dispositivo USB malicioso con archivos especialmente diseñados para romper los
importadores en la unidad de información y entretenimiento, como la libreta de direcciones y los
decodificadores de MP3.
•Instalar malware en la consola Bluetooth
• Bloqueo en el dispositivo Bluetooth
•Usar una aplicación maliciosa para acceder a la red de bus CAN interna
•Poner el receptor TPMS o la ECU en un estado irrecuperable que podría hacer que el conductor se
detuviera para comprobar si se ha informado de un pinchazo o que incluso podría apagar el vehículo
•Instalar malware en la unidad de infoentretenimiento
•Alterar la configuración de diagnóstico
•Instalar software de actualización modificado en el vehículo
•Cargar información con formato incorrecto, como una libreta de direcciones dañada diseñada
para ejecutar código
• Aprovechar una falla en la pila USB de la unidad de infoentretenimiento
•Encuentre un error de entrada que provoque resultados inesperados
• Acceder al vehículo desde distancias cortas (menos de 300 pies)
Bluetooth
Un atacante podría usar una conexión Bluetooth para:
•Pon la consola en modo de depuración
Un atacante podría usar una conexión de puerto USB para:
•Ejecutar código en la unidad de infoentretenimiento
• Aprovechar una falla en la pila de Bluetooth de la unidad de infoentretenimiento
•Usar una aplicación maliciosa para espiar las acciones realizadas por el vehículo
• Rastree un vehículo basado en las identificaciones únicas de TPMS
Consola de infoentretenimiento
•Acortar el puerto USB, dañando así el sistema de infoentretenimiento
•Usar una aplicación maliciosa para suplantar los datos que se muestran al usuario, como la ubicación
del vehículo
RED CAN BUS
Un atacante podría explotar la conexión del bus CAN para:
•Instalar un dispositivo de diagnóstico malicioso para enviar paquetes al bus CAN
• Conéctelo directamente a un bus CAN para intentar arrancar un vehículo sin llave
• Conéctese directamente a un bus CAN para cargar malware
•Instalar un dispositivo de diagnóstico malicioso para rastrear el vehículo
•Instalar un dispositivo de diagnóstico malicioso para habilitar las comunicaciones remotas directamente
al bus CAN, convirtiendo un ataque normalmente interno en una amenaza externa
• Puede usar claves de acceso predeterminadas
Nivel 2: avería del receptor
En el Nivel 2, podemos hablar más sobre la identificación de amenazas específicas. A medida que
observamos exactamente qué aplicación maneja qué conexión, podemos comenzar a realizar la
validación de formularios en función de las posibles amenazas.
Dividiremos las amenazas en cinco grupos:
Bluez (el demonio de Bluetooth), wpa_supplicant (el demonio de Wi-Fi), HSI (módulo de kernel celular de interfaz síncrona de alta velocidad), udev (administrador de dispositivos del kernel) y el controlador Kvaser (controlador de transceptor CAN). En las siguientes listas, he especificado amenazas para cada programa.
Bluez
Versiones anteriores o sin parches del daemon Bluez:
•Puede ser explotable
•Puede ser incapaz de manejar libretas de direcciones corruptas
• Es posible que no se configure para garantizar un cifrado adecuado
• Puede que no esté configurado para manejar el protocolo de enlace seguro
• Puede usar claves de acceso predeterminadas
wpa_supplicant
•Las versiones anteriores pueden ser explotables
• Es posible que no aplique el cifrado inalámbrico de estilo WPA2 adecuado
•Puede conectarse a puntos de acceso maliciosos
•Puede filtrar información sobre el controlador a través de BSSID (interfaz de red)
HSI
•Las versiones anteriores pueden ser explotables
•Puede ser susceptible a la comunicación en serie inyectable (man-in-the-middle)
ataques intermedios en los que el atacante inserta comandos en serie en el flujo de datos)
udev
•Las versiones anteriores sin parches pueden ser susceptibles a ataques
• Es posible que no tenga una lista blanca mantenida de dispositivos, lo que permite que un atacante
cargue controladores adicionales o dispositivos USB que no fueron probados o destinados para
su uso
• Puede permitir que un atacante cargue dispositivos extraños, como un teclado para acceder al
sistema de infoentretenimiento
Conductor de Kvaser
• Las versiones anteriores sin parches pueden ser explotables
•Puede permitir que un atacante cargue firmware malicioso en el Kvaser
Estas listas de posibles vulnerabilidades no son exhaustivas, pero deberían darle una idea de cómo funciona esta sesión de intercambio de ideas. Si tuviera que ir a un mapa de Nivel 3 de amenazas potenciales para su vehículo, elegiría uno de los procesos, como HSI, y comenzaría a mirar su fuente de kernel para identificar métodos sensibles y dependencias que podrían ser vulnerables a un ataque.
Sistemas de clasificación de amenazas
Habiendo documentado muchas de nuestras amenazas, ahora podemos calificarlas con un nivel de
riesgo. Los sistemas de calificación comunes incluyen DREAD, ASIL y MIL-STD-882E.
DREAD se usa comúnmente en pruebas web, mientras que la industria automotriz y el gobierno usan
ISO 26262 ASIL y MIL-STD-882E, respectivamente, para la clasificación de amenazas.
Desafortunadamente, ISO 26262 ASIL y MIL-STD-882E se enfocan en fallas de seguridad y no son
adecuados para manejar amenazas maliciosas.
Se pueden encontrar más detalles sobre estos estándares en https:// opengarages.org/ index
.php/ Políticas_y_Guías.
El sistema de calificación DREAD
DREAD significa lo siguiente:
Potencial de daño ¿Qué tan grande es el daño?
Reproducibilidad ¿Qué tan fácil es reproducirlo?
Explotabilidad ¿Qué tan fácil es atacar?
Usuarios afectados ¿Cuántos usuarios están afectados?
Capacidad de descubrimiento ¿Qué tan fácil es encontrar la vulnerabilidad?
Ahora podemos aplicar cada categoría DREAD de la Tabla 1-1 a una amenaza identificada anteriormente en el capítulo y calificar la amenaza de menor a mayor (1– 3). Por ejemplo, si tomamos las amenazas de HSI de nivel 2 analizadas en «Nivel 2: Desglose del receptor» en la página 10, podemos obtener clasificaciones de amenazas como las que se muestran en la Tabla 1-2.
Al realizar una evaluación de riesgos, es una buena práctica dejar hacer visibles los resultados para que la persona que los lea pueda comprender mejor los riesgos. En el caso de las amenazas HSI, podemos asignar un riesgo alto a cada una de estas amenazas, como se muestra en la Tabla 1-4.
Aunque ambos riesgos están marcados como altos, podemos ver que la versión anterior
La versión del modelo HSI presenta un riesgo ligeramente mayor que los ataques en serie
inyectables, por lo que podemos hacer que sea una prioridad abordar este riesgo primero. También
podemos ver que la razón por la que el riesgo de comunicación en serie inyectable es menor es que
el daño es menos grave y el exploit es más difícil de reproducir que el de una versión anterior de HSI.
CVSS: una alternativa a DREAD
Si DREAD no es lo suficientemente detallado para usted, considere la metodología de riesgo más detallada conocida como el sistema común de calificación de vulnerabilidades (CVSS). CVSS ofrece muchas más categorías y detalles que DREAD en tres grupos: base, temporal y ambiental. Cada grupo se subdivide en subáreas: seis para base, tres para temporal y cinco para ambiental, ¡para un total de 14 áreas de puntuación! (Para obtener información detallada sobre cómo funciona CVSS, consulte https:// www.first.org/ cvss/ cvss-guide).
NOTA: Si bien podemos usar ISO 26262 ASIL o MIL-STD-882E al calificar amenazas, quiere más detalles que solo Riesgo = Probabilidad × Gravedad.
Si tiene que elegir entre estos dos sistemas para una revisión de seguridad, elija MIL-STD-882E del Departamento de Defensa (DoD). El sistema de nivel de integridad de seguridad automotriz (ASIL) con demasiada frecuencia correrá el riesgo de caer en la clasificación QM, que básicamente se traduce como «meh».
El sistema del Departamento de Defensa tiende a dar como resultado una clasificación más alta, lo que equivale a un valor más alto por el costo de una vida. Además, MIL-STD-882E está diseñado para aplicarse durante todo el ciclo de vida de un sistema, incluida la eliminación, lo que encaja bien con un ciclo de vida de desarrollo seguro.
Trabajar con los resultados del modelo de amenazas
En este punto, tenemos un diseño de muchas de las amenazas potenciales para nuestro vehículo y las clasificamos por riesgo. ¿Ahora que? Bueno, eso depende del equipo en el que estés. Para usar la jerga militar, el lado atacante es el “equipo rojo” y el lado defensor es el “equipo azul”.
Si está en el equipo rojo, su próximo paso es comenzar a atacar las áreas de mayor riesgo que probablemente tengan las mejores posibilidades de éxito. Si está en el equipo azul, vuelva a su cuadro de riesgo y modifique cada amenaza con una contramedida.
Por ejemplo, si fuéramos a tomar los dos riesgos en “El sistema de calificación DREAD” en la página 11, podríamos agregar una sección de contramedidas a cada uno. En este capítulo, aprendió la importancia de usar modelos de amenazas para identificar y documentar su postura de seguridad, y de hacer que personas técnicas y no técnicas hagan una lluvia de ideas sobre posibles escenarios.
Luego profundizamos en estos escenarios para identificar todos los riesgos potenciales. Utilizando un sistema de puntuación, clasificamos y categorizamos cada riesgo potencial.
Después de evaluar las amenazas de esta manera, terminamos con un documento que define nuestra postura actual de seguridad del producto, cualquier contramedida actualmente implementada y una lista de tareas de elementos de alta prioridad que aún deben abordarse.
La Tabla 1-5 incluye la contramedida para el riesgo de ejecución de código HSI, y la Tabla 1-6 incluye la contramedida para el riesgo de intercepción de HSI.
Ahora tiene una lista documentada de vulnerabilidades de alto riesgo con soluciones. Puede priorizar cualquier solución que no esté implementada actualmente en función del riesgo de no implementar esa solución.
RESUMEN
En este capítulo, aprendió la importancia de usar modelos de amenazas para identificar y documentar su postura de seguridad, y de hacer que personas técnicas y no técnicas hagan una lluvia de ideas sobre posibles escenarios.
Luego profundizamos en estos escenarios para identificar todos los riesgos potenciales. Utilizando un sistema de puntuación, clasificamos y categorizamos cada riesgo potencial.
Después de evaluar las amenazas de esta manera, terminamos con un documento que define nuestra postura actual de seguridad del producto, cualquier contramedida actualmente implementada y una lista de tareas de elementos de alta prioridad que aún deben abordarse.
Tu sitio no incluye compatibilidad con el bloque «rehub/heading». Puedes dejar intacto este bloque o quitarlo del todo.
En este capítulo, discutiremos los diferentes protocolos de bus comunes en las comunicaciones de vehículos. Su vehículo puede tener solo uno de estos, o si fue construido antes del puede que no tenga ninguno.
Los protocolos de bus rigen la transferencia de paquetes a través de la red de su vehículo. Varias redes y cientos de sensores se comunican en estos sistemas de bus, enviando mensajes que controlan cómo se comporta el vehículo y qué información conoce la red en un momento dado.
Cada fabricante decide qué autobús y qué protocolos tienen más sentido para su vehículo. Un protocolo, el bus CAN, existe en una ubicación estándar en todos los vehículos: en el conector OBD-II. Dicho esto, los propios paquetes que viajan por el bus CAN de un vehículo no están estandarizados.
La comunicación crítica del vehículo, como la gestión de RPM y el frenado, ocurre en las líneas de autobuses de alta velocidad, mientras que la comunicación no crítica, como el bloqueo de puertas y el control del aire acondicionado, ocurre en las líneas de autobuses de velocidad media a baja.
Te detallaremos los diferentes buses y protocolos que te puedes encontrar en tu vehículo. Para determinar las líneas de autobús para su vehículo específico, verifique su configuración de pines OBD-II en línea.
El BUS CAN
CAN es un protocolo simple utilizado en la fabricación y en la industria del automóvil. Los vehículos modernos están llenos de pequeños sistemas integrados y unidades de control electrónico (ECU) que pueden comunicarse mediante el protocolo CAN. CAN ha sido un estándar en los automóviles y camiones ligeros de EE. UU. desde 1996, pero no se hizo obligatorio hasta 2008 (2001 para los vehículos europeos). Si su automóvil es anterior a 1996, es posible que aún tenga CAN, pero deberá verificarlo.
CAN funciona con dos cables: CAN alto (CANH) y CAN bajo (CANL).
CAN usa señalización diferencial (con la excepción de CAN de baja velocidad, que se
analiza en «El bus GMLAN» en la página 20), lo que significa que cuando entra una señal, CAN aumenta el voltaje en una línea y reduce la otra línea en una proporción igual. cantidad (vea la Figura 2-1).
La señalización diferencial se usa en entornos que deben ser tolerantes a fallas al ruido, como en los sistemas automotrices y la fabricación.
La Figura 2-1 muestra una señal capturada con un PicoScope, que escucha CANH (líneas más oscuras en la parte superior del gráfico) y CANL (líneas más claras en la parte inferior del gráfico).
Tenga en cuenta que cuando se transmite un bit en el bus CAN, la señal transmitirá simultáneamente 1V más alto y más bajo. Los sensores y las ECU tienen un transceptor que verifica que se activen ambas señales; si no lo son, el transceptor rechaza el paquete como ruido.
En algunos vehículos, encontrará estos conectores detrás de pequeños paneles de acceso. Por lo general, serán negros o blancos. Algunos son de fácil acceso y otros están escondidos debajo del plástico. ¡Busca y encontrarás! CAN es fácil de encontrar cuando busca entre cables porque su voltaje de reposo es de 2.5V. Cuando entra una señal, sumará o restará 1 V (3,5 V o 1,5 V).
Los cables CAN atraviesan el vehículo y se conectan entre las ECU y otros Los dos cables de par trenzado forman el bus y requieren que el bus termine en cada extremo. Hay una resistencia de 120 ohmios en ambos cables en los extremos de terminación.
Si el módulo no está al final del bus, no tiene que preocuparse por la terminación. Como alguien que puede pinchar las líneas, la única vez que tendrá que preocuparse por la terminación es si quita un dispositivo de terminación para olfatear los cables.
El conector OBD-II
Muchos vehículos vienen equipados con un conector OBD-II, también conocido como conector de enlace de diagnóstico (DLC), que se comunica con la red interna del vehículo. Por lo general, encontrará este conector debajo de la columna de dirección o escondido en otro lugar del tablero en un lugar relativamente accesible. Puede que tenga que buscarlo, pero su contorno es similar al de la Figura 2-2.
En algunos vehículos, encontrará estos conectores detrás de pequeños paneles de acceso. Por lo general, serán negros o blancos. Algunos son de fácil acceso y otros están escondidos debajo del plástico. ¡Busca y encontrarás!
Encontrar conexiones CAN
CAN es fácil de encontrar cuando busca entre cables porque su voltaje de reposo es de 2.5V. Cuando entra una señal, sumará o restará 1 V (3,5 V o 1,5 V). Los cables CAN atraviesan el vehículo y se conectan entre las ECU y otros sensores, y siempre están en pares de dos hilos. Si conecta un multímetro y verifica el voltaje de los cables en su vehículo, encontrará que estarán en reposo en 2.5V o fluctuando en 1V. Si encuentra un cable que transmite a 2,5 V, es casi seguro que CAN.
Debe encontrar las conexiones CANH y CANL en los pines 6 y 14 de su conector OBD-II, como se muestra en la Figura 2-3.
En la figura, los pines 6 y 14 son para líneas CAN estándar de alta velocidad (SA-CAN).
Las comunicaciones de velocidad media y baja ocurren en otros pines. Algunos automóviles usan CAN para la velocidad media (MS-CAN) y la velocidad baja (LS-CAN), pero muchos vehículos usan diferentes protocolos para estas comunicaciones.
Encontrará que no todos los buses están expuestos a través del conector OBD-II. Tú puede usar diagramas de cableado para ayudar a localizar líneas de bus «internas» adicionales.
Debe encontrar las conexiones CANH y CANL en los pines 6 y 14 de puede usar diagramas de cableado para ayudar a localizar líneas de bus «internas» adicionales. ID de arbitraje La ID de arbitraje es un mensaje de difusión que identifica la ID del dispositivo que intenta comunicarse, aunque cualquier dispositivo puede enviar varias ID de arbitraje. Si se envían dos paquetes CAN a lo largo del bus al mismo tiempo, gana el que tiene el ID de arbitraje más bajo. Si conecta un multímetro y verifica el voltaje de los cables en su vehículo, encontrará que estarán en reposo en 2.5V o fluctuando en 1V. Si encuentra un cable que transmite a 2,5 V, es casi seguro que CAN. Encontrará que no todos los buses están expuestos a través del conector OBD-II. Tú Hay dos tipos de paquetes CAN: estándar y extendido. Los paquetes extendidos son como los estándar pero con un espacio más grande para guardar documentos de identidad. (SA-CAN).
Diseño de paquetes de bus CAN
Hay dos tipos de paquetes CAN: estándar y extendido. Los paquetes extendidos son como los
estándar pero con un espacio más grande para guardar documentos de identidad.
Paquetes estándar
Cada paquete de bus CAN contiene cuatro elementos clave:
ID de arbitraje – La ID de arbitraje es un mensaje de difusión que identifica la ID del dispositivo
que intenta comunicarse, aunque cualquier dispositivo puede enviar varias ID de arbitraje. Si se
envían dos paquetes CAN a lo largo del bus al mismo tiempo, gana el que tiene el ID de arbitraje
más bajo..
Extensión de identificador (IDE) Este bit siempre es 0 para CAN estándar.
Código de longitud de datos (DLC) Este es el tamaño de los datos, que oscila entre 0 y 8 bytes.
Datos – Estos son los datos en sí. El tamaño máximo de los datos transportados por un paquete de
bus CAN estándar puede ser de hasta 8 bytes, pero algunos sistemas fuerzan 8 bytes rellenando el
paquete.
La Figura 2-4 muestra el formato de los paquetes CAN estándar.
Debido a que los paquetes de bus CAN se transmiten, todos los controladores en la misma red
ven cada paquete, como UDP en las redes Ethernet. Los paquetes no contienen información sobre qué
controlador (o atacante) envió qué. Debido a que cualquier dispositivo puede ver y transmitir paquetes, es trivial para cualquier dispositivo en el bus simular cualquier otro dispositivo.
Paquetes extendidos
Los paquetes extendidos son como los estándar, excepto que se pueden encadenar para crear
identificaciones más largas. Los paquetes extendidos están diseñados para encajar dentro del formato
CAN estándar para mantener la compatibilidad con versiones anteriores.
Entonces, si un sensor no es compatible con paquetes extendidos, no se romperá si otro paquete
transmite paquetes CAN extendidos en la misma red.
Los paquetes estándar también se diferencian de los paquetes extendidos en el uso de banderas. Al observar los paquetes extendidos en un volcado de red, verá que, a diferencia de los paquetes
estándar, los paquetes extendidos usan una solicitud remota sustituta (SRR) en lugar de la solicitud de
transmisión remota (RTR) con SSR establecido en 1. También tendrán la IDE establecido en 1, y sus
paquetes tendrán un identificador de 18 bits, que es la segunda parte del identificador estándar de 11
bits. Existen protocolos estilo CAN adicionales que son específicos de algunos fabricantes, y también son
compatibles con versiones anteriores del CAN estándar de la misma manera que el CAN extendido.
El protocolo ISO-TP
ISO 15765-2, también conocido como ISO-TP, es un estándar para enviar paquetes a través del bus
CAN que amplía el límite CAN de 8 bytes para admitir hasta 4095 bytes.
encadenando paquetes CAN juntos. El uso más común de ISO-TP es para diagnósticos
(consulte “Servicios de diagnóstico unificados” en la página 54) y mensajes KWP (un
protocolo alternativo a CAN), pero también se puede usar en cualquier momento en que se
necesite transferir una gran cantidad de datos. sobre CAN. El programa can-utils incluye
isotptun, una herramienta de tunelización de prueba de concepto para SocketCAN que
permite que dos dispositivos tunelicen IP a través de CAN. (Para obtener una explicación
detallada de cómo instalar y usar can-utils, consulte “Configuración de can-utils para
conectarse a dispositivos CAN” en la página 36).
Para encapsular ISO-TP en CAN, el primer byte se usa para direccionamiento
extendido, dejando solo 7 bytes para datos por paquete. Enviar mucha información a través
de ISO-TP puede inundar fácilmente el bus, así que tenga cuidado al usar este estándar
para transferencias grandes en un bus activo.
El protocolo CANopen
Otro ejemplo de extensión del protocolo CAN es el protocolo CANopen. CANopen divide
el identificador de 11 bits en un código de función de 4 bits y un ID de nodo de 7 bits, una
combinación conocida como identificador de objeto de comunicación (COB-ID). Un mensaje
de difusión en este sistema tiene 0x tanto para el código de función como para el ID de nodo.
CANopen se ve más en entornos industriales que en los automotrices.
Si ve un montón de ID de arbitraje de 0x0, ha encontrado un buen indicador de que el
sistema está utilizando CANopen para las comunicaciones. CANopen es muy similar al CAN
normal, pero tiene una estructura definida en torno a los ID de arbitraje. Por ejemplo, los
mensajes de latido tienen el formato 0x700 + ID de nodo.
Las redes CANopen son un poco más fáciles de revertir y documentar que el bus CAN estándar.
El BUS GMLAN
GMLAN es una implementación de bus CAN de General Motors. Se basa en ISO 15765-2
ISO-TP, al igual que UDS (ver “Servicios de diagnóstico unificado” en la página 54). El bus
GMLAN consiste en un bus de baja velocidad de un solo cable y un bus de alta velocidad
de dos cables.
El bus de baja velocidad, un bus CAN de un solo cable que funciona a
33,33 Kbps con un máximo de 32 nodos, se adoptó en un intento por reducir los costos de
comunicación y cableado. Se utiliza para transportar información no crítica para cosas como
el centro de infoentretenimiento, controles HVAC, cerraduras de puertas, inmovilizadores, etc.
Por el contrario, el bus de alta velocidad funciona a 500 Kbps con un máximo de 16 nodos.
Los nodos en una red GMLAN se relacionan con los sensores en ese bus.
El protocolo SAE J1850
El protocolo SAE J1850 se adoptó originalmente en 1994 y todavía se puede encontrar
en algunos de los vehículos actuales, por ejemplo, algunos vehículos de General Motors
y Chrysler. Estos sistemas de bus son más antiguos y lentos que CAN pero más baratos
de implementar.
Hay dos tipos de protocolos J1850: modulación de ancho de pulso (PWM) y ancho de pulso
variable (VPW). La Figura 2-5 muestra dónde encontrar los pines PWM en el conector OBD-II. VPW
usa solo el pin 2.
La velocidad se agrupa en tres clases: A, B y C. Las velocidades de 10,4 Kbps de PWM y
VPW se consideran clase A, lo que significa que son dispositivos comercializados exclusivamente
para uso en entornos empresariales, industriales y comerciales.
(El bus J1850 VPW de 10,4Kbps cumple con los requisitos de la industria automotriz para emisiones de baja radiación). Los dispositivos de clase B se comercializan para su uso en cualquier lugar, incluidos los entornos
residenciales, y tienen una segunda implementación del estándar SAE que puede comunicarse
a 100 Kbps, pero es un poco más caro.
La implementación final puede operar hasta 1 Mbps y seusa en dispositivos de clase C. Como era de esperar, esta tercera implementación es la más costosa y se usa principalmente en redes de medios y sistemas críticos en tiempo real.
El protocolo PWM
PWM usa señalización diferencial en los pines 2 y 10 y Ford lo usa principalmente. Opera con un alto voltaje de 5V ya 41.6Kbps, y utiliza señalización diferencial de doble hilo, como CAN.
PMW tiene una señal de bits fijos, por lo que un 1 siempre es una señal alta y un 0 siempre es una señal baja. Aparte de eso, el protocolo de comunicación es idéntico al de VPW. Las diferencias son la velocidad, el voltaje y la cantidad de cables utilizados para formar el bus.
El Protocolo VPW
VPW, un sistema de bus de un solo cable, usa solo el pin 2 y generalmente lo usan General Motors
y Chrysler. VPW tiene un alto voltaje de 7V y una velocidad de 10.4Kbps.
En comparación con CAN, existen algunas diferencias clave en la forma en que VPW interpreta
los datos. Por un lado, debido a que VPW usa señalización dependiente del tiempo, la recepción de 1 bit
no está determinada solo por un alto potencial en el bus. El bit debe permanecer alto o bajo durante un
tiempo determinado para que se considere un solo bit 1 o un bit 0. Tirar del autobús a una posición alta
lo pondrá a alrededor de 7V, mientras que enviar una señal baja lo pondrá a nivel del suelo o cerca del
suelo. Este bus también se encuentra en una etapa de reposo, o sin transmisión, a un nivel cercano al
suelo (hasta 3V).
Los paquetes VPW usan el formato de la Figura 2-6
Los datos de respuesta en marco (IFR) pueden seguir inmediatamente después de este mensaje.
Normalmente, una señal de fin de datos (EOD) que consiste en una señal de potencial bajo de 200 ÿs
de duración ocurriría justo después del CRC, y si se incluyen datos IFR, comenzará inmediatamente
después del EOD. Si no se utiliza IFR, el EOD se extenderá a 280 ÿs, provocando una señal de fin de
cuadro (EOF).
El Protocolo de palabras clave e ISO 9141-2
El Keyword Protocol 2000 (ISO 14230), también conocido como KWP2000, usa el pin 7 y es común
en los vehículos estadounidenses fabricados después de 2003. Los mensajes enviados con KWP2000
pueden contener hasta 255 bytes.
El protocolo KWP2000 tiene dos variantes que se diferencian principalmente en baudios de inicialización. Las variaciones son:
• ISO 14230-4 KWP (inicialización de 5 baudios, 10,4 kbaudios)(inicio rápido)
• ISO 9141-2, o K-Line, es una variación de KWP2000 que se ve con mayor frecuencia en
los vehículos europeos. K-Line usa el pin 7 y, opcionalmente, el pin 15, como se muestra en la
Figura 2-7. K-Line es un protocolo UART similar al serial. Los UART usan bits de inicio y pueden
incluir un bit de paridad y un bit de parada. (Si alguna vez configuró un módem, debe reconocer
esta terminología).
La Figura 2-8 muestra el diseño de paquetes del protocolo. A diferencia de los paquetes
CAN, los paquetes K-Line tienen una dirección de origen (transmisor) y de destino (receptor). KLine
puede usar la misma estructura de solicitud de ID de parámetro (PID) o una similar que CAN.
(Para obtener más información sobre los PID, consulte “Servicios de diagnóstico unificados” en la
página 54).
El protocolo de red de interconexión local
La red de interconexión local (LIN) es el más económico de los protocolos para vehículos. Fue diseñado para complementar CAN. No tiene código de prelación ni de arbitraje; en cambio, un solo nodo maestro hace toda la transmisión.
LIN puede admitir hasta 16 nodos esclavos que principalmente solo escuchan al nodo maestro. Necesitan responder en ocasiones, pero esa no es su función principal. A menudo, el nodo maestro LIN está conectado a un bus CAN.
La velocidad máxima de LIN es de 20 Kbps. LIN es un bus de un solo cable que funciona a 12V. No verá LIN dividido en el conector OBD, pero a menudo se usa en lugar de paquetes CAN directos para manejar controles en dispositivos simples, así que tenga en cuenta su existencia.
Una trama de mensaje LIN incluye un encabezado, que siempre envía el maestro, y una sección de respuesta, que puede enviar el maestro o el esclavo (consulte la Figura 2-9).
El campo SYNC se utiliza para la sincronización del reloj. El ID representa el contenido del mensaje, es decir, el tipo de datos que se transmiten. El ID puede contener hasta 64 posibilidades. Los ID 60 y 61 se utilizan para llevar información de diagnóstico.
Al leer información de diagnóstico, el maestro envía con ID 60 y el esclavo responde con ID 61. Los 8 bytes se utilizan en diagnósticos. El primer byte se denomina dirección de nodo para diagnóstico (NAD). La primera mitad del rango de bytes (es decir, 1–127) se define para diagnósticos compatibles con ISO, mientras que 128–255 puede ser específico para ese dispositivo.
El protocolo MOST
El protocolo de transporte de sistemas orientados a medios (MOST) está diseñado para dispositivos multimedia. Por lo general, MOST se presenta en una topología de anillo, o estrella virtual, que admite un máximo de 64 dispositivos MOST. Un dispositivo MOST actúa como el maestro de temporización, que continuamente alimenta fotogramas al anillo.
MOST funciona a aproximadamente 23 Mbaudios y admite hasta 15 canales de audio/video MPEG1 o audio con calidad de CD sin comprimir. Un canal de control separado funciona a 768 Kbaudios y envía mensajes de configuración a los dispositivos MOST.
MOST viene en tres velocidades: MOST25, MOST50 y MOST150. El MOST estándar, o MOST25, funciona con fibra óptica plástica (POF). La transmisión se realiza a través de la longitud de onda de la luz roja a 650 nm mediante un LED. A protocolo similar, MOST50, duplica el ancho de banda y aumenta la longitud de la trama a 1025 bits. El tráfico MOST50 generalmente se transporta en cables de par trenzado sin blindaje (UTP) en lugar de fibra óptica. Finalmente, MOST150 implementa Ethernet y aumenta la velocidad de fotogramas a 3072 bits o 150 Mbps—aproximadamente seis veces el ancho de banda de MOST25.
| Transmisión sincrónica de datos | (audio/video) |
| Paquete asíncrono de datos distribuidos | (TCP/IP) |
| Control Control y datos de baja velocidad | (HMI) |
Cada cuadro MOST tiene tres canales:
Además de un maestro de temporización, un maestro de red MOST asigna
automáticamente direcciones a los dispositivos, lo que permite una especie de estructura
plug-and-play. Otra característica única de MOST es que, a diferencia de otros buses,
enruta los paquetes a través de puertos de entrada y salida separados.
Capas de red MOST
A menos que su objetivo sea piratear la transmisión de video o audio de un automóvil,
el protocolo MOST puede no ser tan interesante para usted. Dicho esto, MOST permite
el acceso al micrófono del vehículo o al sistema celular, así como a la información de tráfico
que probablemente sea de interés para los autores de malware.
La Figura 2-10 muestra cómo se divide MOST entre las siete capas del modelo de
interconexión de sistemas abiertos (OSI) que estandariza la comunicación a través de
redes. Si está familiarizado con otros protocolos de red basados en medios, entonces
MOST puede parecerle familiar.
La mayoría de los bloques de control
En MOST25, un bloque consta de 16 marcos. Una trama tiene 512 bits y se parece a la
ilustración de la figura 2-11.
El área de datos contiene FblockID, InstID, FktID, OP Type, Tel ID, Tel Len y 12 bytes de datos.
FblockIDs son los ID de componentes principales o bloques de funciones. Por ejemplo, un FblockID de
0x52 podría ser el sistema de navegación. InstID es la instancia del bloque de funciones. Puede haber más
de una función central, como tener dos cambios de CD. InstID diferencia con qué núcleo hablar. FktID se
utiliza para consultar bloques de funciones de nivel superior. Por ejemplo, un FktID de 0x0 consulta una lista
de ID de funciones compatibles con el bloque de funciones. OP Type es el tipo de operación para realizar,
obtener, establecer, incrementar, decrementar, etc. Tel ID y Len son el tipo de telegrama y la longitud,
respectivamente. Los tipos de telegrama representan una transferencia única o una transferencia de varios
paquetes y la longitud del telegrama en sí.
MOST50 tiene un diseño similar al MOST25 pero con una sección de datos más grande. MOST150 proporciona dos canales adicionales: Ethernet e isócrono. Ethernet funciona como configuraciones normales de TCP/IP y Appletalk. Isochronous tiene tres mecanismos: modo ráfaga, velocidad constante y transmisión de paquetes.
Hackear la MAYORÍA
MOST se puede piratear desde un dispositivo que ya lo admite, como a través de la unidad de información y
entretenimiento de un vehículo o mediante un controlador MOST integrado. El proyecto basado en Linux
most4linux proporciona un controlador de kernel para la mayoría de los dispositivos PCI y, a partir de este
escrito, es compatible con las tarjetas Siemens CT SE 2 y OASIS Silicon Systems o SMSC PCI. El
controlador most4linux permite la comunicación en el espacio del usuario a través de la red MOST y se
vincula con el marco de la Arquitectura avanzada de sonido de Linux (ALSA) para leer y escribir datos de
audio.
Por el momento, most4linux debe considerarse de calidad alfa, pero incluye algunas utilidades de
ejemplo que puede aprovechar, a saber:
| most_aplay | Reproduce un archivo .wav |
| ctrl_tx | Envía un mensaje de control de transmisión y verifica el estado |
| sync_tx | Transmite constantemente |
| sync_rx | Recibe constantemente |
Por el momento, most4linux debe considerarse de calidad alfa, pero incluye algunas utilidades de
ejemplo que puede aprovechar.
El controlador most4linux actual fue escrito para kernels Linux 2.6, por lo que puede tener su trabajo cortado para usted si quiere hacer un sniffer genérico. MOST es bastante costoso de implementar, por lo que un sniffer genérico no será barato.
El BUS FlexRay
FlexRay es un bus de alta velocidad que puede comunicarse a velocidades de hasta 10
Mbps. Está diseñado para comunicaciones sensibles al tiempo, como drive-by-wire, steer-bywire,
brake-by-wire, etc. FlexRay es más costoso de implementar que CAN, por lo que la mayoría
de las implementaciones usan FlexRay para sistemas de gama alta, CAN para rango medio y
LIN para dispositivos de bajo costo.
Hardware
FlexRay usa cableado de par trenzado, pero también admite una configuración de dos
canales, lo que puede aumentar la tolerancia a fallas y el ancho de banda. Sin embargo, la
mayoría de las implementaciones de FlexRay usan solo un par de cableado similar a las
implementaciones de bus CAN.
Topología de la red
FlexRay admite una topología de bus estándar, como el bus CAN, donde muchas ECU se
ejecutan en un bus de par trenzado. También es compatible con la topología en estrella, como
Ethernet, que puede ejecutar segmentos más largos. Cuando se implementa en la topología en
estrella, un concentrador FlexRay es un dispositivo FlexRay central y activo que se comunica con
los otros nodos. En un diseño de bus, FlexRay requiere una terminación de resistencia adecuada,
como en un bus CAN estándar. Las topologías de bus y estrella se pueden combinar para crear un
diseño híbrido si se desea.
Implementación
Al crear una red FlexRay, el fabricante debe informar a los dispositivos sobre la configuración
de la red. Recuerde que en una red CAN cada dispositivo solo necesita saber la velocidad en
baudios y qué ID le interesan (si corresponde). En un diseño de bus, solo un dispositivo puede
hablar en el bus a la vez. En el caso del bus CAN, el ID de arbitraje determina el orden de quién
habla primero en una colisión.
Por el contrario, cuando FlexRay está configurado para hablar en un bus, utiliza algo
llamado esquema de acceso múltiple por división de tiempo (TDMA) para garantizar el determinismo:
la velocidad es siempre la misma (determinista) y el sistema depende de los transmisores para
complete los datos a medida que los paquetes pasan por el cable, similar a la forma en que
funcionan las redes celulares como GSM. Los dispositivos FlexRay no detectan automáticamente la
red o las direcciones en la red, por lo que deben tener esa información programada en el momento
de la fabricación.
Si bien este enfoque de direccionamiento estático reduce los costos durante la fabricación. En la fabricación, puede ser complicado que un dispositivo de prueba participe en el bus sin saber cómo está configurada la red, ya que un dispositivo agregado. La red FlexRay no sabrá qué datos están diseñados para entrar en qué ranuras.
Para solucionar este problema, se diseñaron formatos de intercambio de datos específicos, como el
formato de intercambio de bus de campo (FIBEX), durante el desarrollo de FlexRay.
FIBEX es un formato XML utilizado para describir FlexRay, así como configuraciones de red
CAN, LIN y MOST. Los mapas de topología de FIBEX registran las ECU y cómo se conectan a
través de los canales, y pueden implementar puertas de enlace para determinar el comportamiento de
enrutamiento entre buses. Estos mapas también pueden incluir todas las señales y cómo deben
interpretarse.
Los datos FIBEX se utilizan durante el tiempo de compilación del firmware y permiten desarrollar usuarios para hacer referencia a las señales de red conocidas en su código; el compilador maneja toda la ubicación y configuración.
Para ver un FIBEX, descargue FIBEX Explorer desde https://sourceforge.net/ projects/ fibexplorer/
Ciclos FlexRay
Un ciclo FlexRay se puede ver como un paquete. La duración de cada ciclo se determina en el
momento del diseño y debe constar de cuatro partes, como se muestra en la siguiente tabla.
| Estático | dinámico | Símbolo | ventana inactiva |
| | | | |
Figura 2-13: Cuatro partes de un ciclo FlexRay
El segmento estático contiene ranuras reservadas para datos que siempre representan el mismo significado. Las ranuras de segmentos dinámicos contienen datos que pueden tener diferentes representaciones. La ventana de símbolos es utilizada por la red para la señalización, y el
segmento inactivo (tiempo de silencio) se utiliza para la sincronización.
La unidad de tiempo más pequeña en FlexRay se llama macrotick, que es aproximadamente un milisegundo. Todos los nodos están sincronizados en el tiempo y activan susdatos de macrotick al mismo tiempo.
La sección estática de un ciclo FlexRay contiene una cantidad determinada de ranuras para
almacenar datos, como vagones de tren vacíos. Cuando una ECU necesita actualizar una unidad de
datos estáticos, completa su ranura o automóvil definido; cada ECU sabe qué automóvil está definido
para él. Este sistema funciona porque todos los participantes en un autobús FlexRay están
sincronizados en el tiempo.
La sección dinámica se divide en minislots, típicamente de un macrotick de largo. La sección
dinámica generalmente se usa para datos intermitentes menos importantes, como la temperatura del
aire interno. A medida que pasa un miniintervalo, una ECU puede optar por llenar los miniintervalos
con datos. Si todos los minislots están llenos, la ECU debe esperar al siguiente ciclo.
En la Figura 2-14, los ciclos FlexRay se representan como vagones de tren. Los transmisores responsables de completar la información de los intervalos estáticos lo hacen cuando pasa el ciclo, pero los intervalos dinámicos se completan por orden de llegada. Todos los vagones del tren son del mismo tamaño y representan las propiedades determinantes del tiempo de FlexRay.
La ventana de símbolos normalmente no se usa directamente en la mayoría de los dispositivos FlexRay,
lo que significa que cuando piensas como un hacker, definitivamente deberías meterte con esta sección.
Los clústeres de FlexRay funcionan en estados controlados por el administrador de estado
de FlexRay. De acuerdo con el estándar AUTOSAR 4.2.1, estos estados son los siguientes: listo,
activación, puesta en marcha, solicitud de detención, en línea, pasivo en línea, solo ranura de llave y
bajo número de arrancadores en frío.
| listo |
| activación |
| puesta en marcha |
| solicitud de detención |
| en línea |
| bajo número de arrancadores en frío |
| pasivo en línea |
| solo ranura de llave |
Estándar AUTOSAR 4.2.1
Si bien la mayoría de los estados son obvios, algunos necesitan una explicación más detallada.
Los bits de estado son:
•Indicador de preámbulo de carga útil
Específicamente, en línea es el estado de comunicación normal, mientras que en línea pasivo
solo debe ocurrir cuando hay errores de sincronización. En el modo pasivo en línea, no se envían
ni reciben datos.
Keyslot-only significa que los datos solo se pueden transmitir en las ranuras de
clave. Un bajo número de arrancadores en frío significa que el bus sigue funcionando en modo de
comunicación total, pero depende únicamente de las tramas de sincronización. También hay estados
operativos adicionales, como configuración, suspensión, solo recepción y espera.
El ID de trama es la ranura en la que se debe transmitir el paquete cuando se utiliza
para ranuras estáticas. Cuando el paquete está destinado a una ranura dinámica (1–2047),
la ID de la trama representa la prioridad de este paquete.
Si dos paquetes tienen la misma señal, gana el que tiene la prioridad más alta. La longitud de la carga útil es el número en palabras (2 bytes) y puede tener una longitud de hasta 127 palabras, lo que significa que un
paquete FlexRay puede transportar 254 bytes de datos, más de 30 veces la de un paquete CAN. El encabezado CRC debe ser obvio, y el conteo de ciclos se usa como un contador de comunicación que se incrementa cada vez que comienza un ciclo de comunicación.
Una cosa realmente interesante sobre las ranuras estáticas es que una ECU puede
leer ranuras estáticas anteriores y generar un valor basado en esas entradas en el mismo
ciclo. Por ejemplo, digamos que tiene un componente que necesita saber la posición de
cada rueda antes de que pueda generar los ajustes necesarios.
Si las primeras cuatro ranuras en un ciclo estático contienen cada posición de la rueda, la ECU de calibración puede leerlas y todavía tener tiempo para llenar una ranura posterior con cualquier ajuste.
Recabar datos de una red FlexRay
Al momento de escribir este artículo, Linux no tiene soporte oficial para FlexRay, pero hay
algunos parches de varios fabricantes que agregan soporte a ciertos núcleos y arquitecturas.
(Linux es compatible con FlexCAN, pero FlexCAN es una red de bus CAN inspirada en
FlexRay).
En este momento, no existen herramientas estándar de código abierto para rastrear
una red FlexRay. Si necesita una herramienta genérica para olfatear el tráfico de FlexRay,
actualmente tiene que optar por un producto patentado que costará mucho.
Si desea monitorear una red FlexRay sin un archivo FIBEX, al menos necesitará saber la velocidad en baudios del bus. Idealmente, también conocerá la duración del ciclo (en milisegundos) y, si es posible, el tamaño de la partición del clúster (proporción estática a dinámica). Técnicamente, un clúster FlexRay puede tener hasta 1048 configuraciones con 74 parámetros. Encontrará el enfoque para identificar estos parámetros detallado en el artículo “Identificación automática de parámetros en redes de comunicación automotriz basadas en FlexRay” (IEEE, 2006) de Eric Armengaud, Andreas Steininger y Martin Horauer.
Al falsificar paquetes en una red FlexRay con dos canales, debe falsificar ambos
simultáneamente. Además, encontrará implementaciones de FlexRay llamadas Bus
Guardian que están diseñadas para evitar inundaciones o la monopolización del bus por
cualquier dispositivo. Bus Guardian funciona a nivel de hardware a través de un pin en el
chip FlexRay, normalmente llamado Bus Guardian Enable (BGE). Este pin a menudo se
marca como opcional, pero Bus Guardian puede colocar este pin demasiado alto para
desactivar un dispositivo que se comporta mal.
Ethernet automotriz
Debido a que MOST y FlexRay son costosos y están perdiendo soporte (el consorcio
FlexRay parece haberse disuelto), la mayoría de los vehículos más nuevos se están
cambiando a Ethernet. Las implementaciones de Ethernet varían, pero básicamente son las mismas como lo que encontraría en una red informática estándar.
A menudo, los paquetes CAN se encapsulan como UDP y el audio se transporta como voz sobre IP (VoIP).
Ethernet puede transmitir datos a velocidades de hasta 10 Gbps, utilizando protocolos no patentados y cualquier topología elegida.
Si bien no existe un estándar común para el tráfico CAN, los fabricantes están comenzando a utilizar el estándar IEEE 802.1AS Audio Video Bridging (AVB). Este estándar admite calidad de servicio (QoS) y configuración de tráfico, y utiliza paquetes UDP sincronizados en el tiempo.
Para lograr esta sincronización, los nodos siguen un mejor algoritmo de reloj maestro para determinar qué nodo será el maestro de temporización. El nodo maestro normalmente se sincronizará con una fuente de tiempo externa, como un GPS o (en el peor de los casos) un oscilador integrado.
El maestro se sincroniza con los otros nodos mediante el envío de paquetes cronometrados (10
milisegundos), el esclavo responde con una solicitud de demora y la compensación de tiempo se
calcula a partir de ese intercambio.
Desde la perspectiva de un investigador, el único desafío con Ethernet para vehículos radica en averiguar cómo comunicarse con Ethernet.
Es posible que deba fabricar o comprar un cable personalizado para comunicarse con los cables Ethernet del vehículo porque no se verán como los cables de par trenzado estándar que encontraría en un armario de redes. Por lo general, un conector será solo cables como los que encuentras conectados a una ECU.
No espere que los conectores tengan su propio enchufe, pero si lo tienen, no parecerá un conector RJ-45. Algunos conectores expuestos son en realidad redondos, como se muestra en la Figura 2-16.
Mapas de asignación de pines del conector OBD-II
Los pines restantes en el pinout OBD-II son específicos del fabricante. Las asignaciones varían según el fabricante, y estas son solo pautas. Su pinout puede diferir dependiendo de su marca y modelo. Por ejemplo, la Figura 2-17 muestra un patillaje de General Motors.
Tenga en cuenta que el conector OBD puede tener más de una línea CAN, como línea de baja velocidad (LS-CAN) o de media velocidad (MS-CAN).
La baja velocidad opera alrededor de 33 Kbps, la velocidad media es de alrededor de 128 Kbps y la alta velocidad (HS-CAN) es de alrededor de 500 Kbps. A menudo, utilizará un conector DB9 a OBDII cuando conecte su rastreador al conector OBD-II de su vehículo. La figura 2-18 muestra la vista del enchufe, no la del cable.
La versión de EE. UU. tiene más funciones y le brinda más acceso a otros conectores OBD además de CAN. Afortunadamente, la alimentación es el pin 9 en ambos conectores de estilo, por lo que no debe freír su rastreador si toma el cable equivocado. Algunos sniffers, como CANtact, tienen puentes que puede configurar según el estilo de cable que esté usando.
El estándar OBD-III
OBD-III es una evolución bastante controvertida del estándar OBD-II. OBD-II se
diseñó originalmente para cumplir con las pruebas de emisiones (al menos desde la
perspectiva de los reguladores), pero ahora que el módulo de control del tren motriz
(PCM) sabe si un vehículo está dentro de las pautas, todavía nos queda el
inconveniente de la propietario del vehículo que tiene que ir a la prueba cada dos
años. El estándar OBD-III permite que el PCM comunique su estado de forma remota
sin la interacción del propietario. Esta comunicación generalmente se logra a través de
un transpondedor en la carretera, pero los teléfonos celulares y las comunicaciones por
satélite también funcionan.
La Junta de Recursos del Aire de California (CARB) comenzó a probar lectores
de carretera para OBD-III en 1994 y es capaz de leer datos de vehículos de ocho
carriles de tráfico que viajan a 100 millas por hora. Si se detecta una falla en el
sistema, transmitirá los códigos de diagnóstico de problemas (DTC) y los números de
identificación del vehículo (VIN) a un transpondedor cercano (consulte “Códigos de
diagnóstico de problemas” en la página 52). La idea es que el sistema informe que los
contaminantes están ingresando a la atmósfera sin tener que esperar hasta dos años
para un control de emisiones.
La mayoría de las implementaciones de OBD-III son específicas del
fabricante. El vehículo llama a casa al fabricante con fallas y luego contacta con el propietario para informarles de la necesidad de reparaciones.
Algunos presentaron solicitudes de propuestas para integrar OBD-III en vehículos. Los archivos afirman usar transpondedores para almacenar la siguiente información:
| • Fecha y hora de la consulta actual |
| •Fecha y hora de la última consulta |
| •VIN |
| •Estado, como «OK», «Problema» o «Sin respuesta» |
| •Códigos almacenados (DTC) |
| •Número de estación receptora |
Datos enviados
Como se puede imaginar, este sistema tiene algunas preguntas legales obvias que aún deben responderse, incluido el riesgo de vigilancia masiva de la propiedad privada. Ciertamente, hay mucho espacio para abusos por parte de las fuerzas del orden, incluidas las trampas de velocidad, el seguimiento, la inmovilización, etc.
Es importante tener en cuenta que incluso si OBD-III envía solo DTC y VIN, es trivial agregar
metadatos adicionales, como la ubicación, la hora y el historial del vehículo que pasa por el
transpondedor. En su mayor parte, OBD-III es el fantasma debajo de la cama. En el momento de
escribir este artículo, aún no se ha implementado con un enfoque de transpondedor, aunque se
están implementando sistemas telefónicos para el hogar como OnStar para notificar al
concesionario de automóviles sobre varios problemas de seguridad.
RESUMEN
Cuando trabaje en su vehículo objetivo, es posible que se encuentre con varios autobuses y
protocolos diferentes. Cuando lo haga, examine los pines que usa su conector OBD-II para su
vehículo en particular para ayudarlo a determinar qué herramientas necesitará y qué esperar
cuando invierta la red de su vehículo.
Me he centrado en este capítulo en los buses de fácil acceso a través del conector
OBD-II, pero también debe mirar los diagramas de cableado de su vehículo para determinar
dónde encontrar otras líneas de autobús entre los sensores. No todas las líneas de bus están
expuestas a través del conector OBD-II, y al buscar un determinado paquete, puede ser más fácil
ubicar el módulo y las líneas de bus que salen de un módulo específico para invertir un paquete
en particular. (Consulte el Capítulo 7 para obtener detalles sobre cómo leer los diagramas de
cableado).
Comunicación con Can Bus
Cuando comience a usar un CAN para las
comunicaciones del vehículo, es posible que
encuentre una mezcolanza de diferentes
controladores y utilidades de software.
Lo ideal sería unificar las herramientas CAN y sus diferentes interfaces en una interfaz común para que podamos compartir fácilmente información entre herramientas.
Afortunadamente, hay un conjunto de herramientas con una interfaz común, ¡y es gratis! Si
tienes Linux o instalas Linux en una máquina virtual (VM), ya tienes esta interfaz. La interfaz,
llamada SocketCAN, se creó en el sitio de desarrollo de código abierto BerliOS en 2006.
Hoy, el término SocketCAN se utiliza para referirse a la implementación de controladores CAN como dispositivos de red, como tarjetas Ethernet, y para describir el acceso de la aplicación al bus CAN a través de la interfaz de programación de socket de red. En este capítulo configuraremos SocketCAN para que podamos comunicarnos más fácilmente con el vehículo.
Volkswagen Group Research contribuyó con la implementación original de SocketCAN,
que admite chips CAN integrados y controladores de tarjetas, dispositivos USB externos y CAN
serie, y dispositivos CAN virtuales.
El paquete proporciona varias aplicaciones y herramientas para interactuar con los dispositivos
de red CAN, protocolos específicos de CAN y la capacidad de configurar un entorno CAN
virtual. Para probar muchos de los ejemplos de este libro, instale una versión reciente en una
máquina virtual Linux en su sistema. Las versiones más nuevas de Ubuntu tienen can-utils en
sus repositorios estándar.
SocketCAN se vincula con la pila de red de Linux, lo que lo hace muy fácil para crear herramientas de apoyo a CAN. Las aplicaciones SocketCAN pueden usar llamadas de socket C estándar con una familia de protocolos de red personalizados, PF_CAN.
Esta funcionalidad permite que el núcleo maneje los controladores de dispositivos CAN y se conecte con el hardware de red existente para proporcionar una interfaz común y utilidades de espacio de usuario.
La Figura 3-1 compara la implementación del software CAN tradicional con el de un SocketCAN unificado.
Con el software CAN tradicional, la aplicación tiene su propio protocolo que normalmente habla con un dispositivo de caracteres, como un controlador en serie, y luego
con el controlador de hardware real. A la izquierda de la figura, SocketCAN está implementado
en el kernel de Linux.
Al crear su propia familia de protocolos CAN, SocketCAN puede integrarse con los controladores de dispositivos de red existentes, lo que permite que las aplicaciones traten una interfaz de bus CAN como si fuera una interfaz de red genérica.
Configuración de can-utils para conectarse a dispositivos CAN
Para instalar can-utils, debe ejecutar una distribución de Linux de 2008 o posterior o una que
ejecute el kernel de Linux 2.6.25 o superior. Primero instalaremos can-utils, luego cubriremos
cómo configurarlo para su configuración particular.
Instalación de can-utils
Debería poder usar su administrador de paquetes para instalar can-utils. Aquí hay un ejemplo
de Debian/Ubuntu:
$ sudo apt-get install can-utils
Si no tiene can-utils en su administrador de paquetes, instálelo desde fuente con el comando git :
$ git clonar httpss://github.com/linux-can/can-utils
En el momento de escribir este artículo, can-utils tiene archivos de configuración, creación e instalación , pero en versiones anteriores, simplemente ingresaba make para instalar desde la fuente.
Configuración de conjuntos de chips integrados
El siguiente paso depende de su hardware. Si está buscando un detector de CAN, debe consultar la
lista de controladores Linux compatibles para asegurarse de que su dispositivo sea compatible. En el
momento de escribir este artículo, los controladores CAN integrados de Linux son compatibles con los
siguientes conjuntos de chips:
| • SoC Atmel AT91SAM |
| •BoschCC770 |
| •Tarjetas ESD CAN-PCI/331 |
| •Freescale FlexCAN |
| •SoC Freescale MPC52xx (MSCAN) |
| •Intel AN82527 |
| •Microchip MCP251x |
| •NXP (Philips) SJA1000 |
| • SoC de TI |
Chips compatibles con controlador Linux
Los controladores CAN, como el SJA1000, generalmente están integrados en tarjetas ISA, PCI y PCMCIA u otro hardware integrado. Por ejemplo, el controlador de la tarjeta EMS PCMCIA implementa el acceso a su chip SJA1000. Cuando inserta la tarjeta EMS PCMCIA en una computadora portátil, el módulo ems_pcmcia se carga en el kernel, que luego requiere el módulo sja1000 y el can_dev módulo a cargar.
El módulo can_dev proporciona interfaces de configuración estándar, por ejemplo, para establecer tasas de bits para los controladores CAN.
El concepto modular del kernel de Linux también se aplica a los controladores de hardware CAN que conectan controladores CAN a través de hardware de bus, como kvaser_pci, peak_pci, etc.
Cuando conecta un dispositivo compatible, estos módulos deberían cargarse automáticamente y debería verlos cuando ingrese al lsmod dominio. Los controladores USB, como usb8dev, generalmente implementan un protocolo de comunicación USB patentado y, por lo tanto, no cargan un controlador de controlador CAN.
Por ejemplo, cuando conecta un adaptador PEAK-System PCAN-USB, el módulo can_dev se
carga y el módulo peak_usb finaliza su inicialización.
Usando el comando de mensaje de visualización dmesg, debería ver un resultado similar a este:
Puede verificar que la interfaz se cargó correctamente con ifconfig y asegurarse de que ahora
haya una interfaz can0 :
Ahora configure la velocidad del bus CAN. El componente clave que debe configurar es la tasa de bits.
Por ejemplo, cuando conecta un adaptador PEAK-System PCAN-USB, el módulo can_dev se
carga y el módulo peak_usb finaliza su inicialización.
Esta es la velocidad del BUS. Un valor típico para CAN de alta velocidad (HS-CAN) es 500 Kbps.
Los valores de 250 Kbps o 125 Kbps son típicos para los buses CAN de baja velocidad:
$ sudo ip link set can0 type can bitrate 500000
$ sudo ip enlace configurado can0
Una vez que abra el dispositivo can0 , debería poder usar las herramientas de can-utils en
esta interfaz. Linux usa netlink para comunicarse entre el kernel y las herramientas del espacio del
usuario. Puede acceder a netlink con el comando ip link . Para ver todas las opciones de enlace de
red, ingrese lo siguiente:
$ ip link set can0 tipo puede ayudar
Si comienza a ver un comportamiento extraño, como la falta de capturas de paquetes y errores de paquetes, es posible que la interfaz se haya detenido. Si está trabajando con un dispositivo externo, simplemente desconéctelo o reinícielo. Si el dispositivo es interno, ejecute estos comandos para restablecerlo:
$ sudo ip link set canX type puede reiniciar-ms 100
$ sudo ip link set canX tipo puede reiniciar
Configuración de dispositivos CAN serie
Los dispositivos CAN externos generalmente se comunican a través de una serie. De hecho,
incluso los dispositivos USB en un vehículo a menudo se comunican a través de una interfaz en
serie, generalmente un chip FTDI de Future Technology Devices International, Ltd.
Se sabe que los siguientes dispositivos funcionan con SocketCAN:
| •Cualquier dispositivo que soporte el protocolo LAWICEL |
| •Adaptadores serie CAN232/CANUSB (https:// www.can232.com/) |
| • Adaptador USB a serie VSCOM (https:// www.vscom.de/ usb-to-can.htm) |
| •CANtact (https:// cantact.io) |
Interface compatibles con SocketCan
NOTA: Si está usando un Arduino o construyendo su propio sniffer, debe implementar el
Protocolo LAWICEL, también conocido como protocolo SLCAN, en su firmware para que su
dispositivo funcione.Para obtener más información, consulte https://www.can232.com/docs/canusb_
-S 3000000 Establece la velocidad en baudios en serie, o tasa de bits.
manual.pdf y httpss://github.com/linux-can/can-misc/blob/master/docs/SLCAN-API.pdf.
Para utilizar uno de los adaptadores de USB a serie, primero debe iniciar ize tanto el hardware serial como la tasa de baudios en el bus CAN:
$ slcan -o -s6 -t hw -S 3000000 /dev/ttyUSB0
$ ip enlace configurado slcan0
El daemon slcand proporciona la interfaz necesaria para traducir la comunicación serie
al controlador de red, slcan0. Las siguientes opciones se pueden pasar a slcand:
| -O | Abre el dispositivo |
| -s6 | Establece la tasa de baudios y la velocidad del bus CAN (consulte la Tabla 3-1) |
| -t hw | Especifica el control de flujo serie, ya sea HW (hardware) o SW |
| -S 3000000 | Establece la velocidad en baudios en serie, o tasa de bits. |
| /dev/ttyUSB0 | Su dispositivo USB FTDI |
Opciones comando slcand
| 0 | 10 Kbps |
| 1 | 20 Kbps |
| 2 | 50 Kbps |
| 3 | 100 Kbps |
| 4 | 125 Kbps |
| 5 | 250 Kbps |
| 6 | 500 Kbps |
| 7 | 800 Kbps |
| 8 | 1 Mbps |
tabla 3-1 velocidad can Bus
Como puede ver, ingresar -s6 prepara el dispositivo para comunicarse con una red de bus
CAN de 500 Kbps. Con estas opciones configuradas, ahora debería tener un dispositivo slcan0 . para empezar a recibir datos ingrese lo siguiente:
$ ifconfig slcan0
La mayor parte de la información devuelta por ifconfig se establece en valores
predeterminados genéricos, que pueden ser todos 0. Esto es normal. Simplemente nos estamos
asegurando de que podemos ver el dispositivo con ifconfig. Si vemos un dispositivo slcan0 ,
sabemos que deberíamos poder usar nuestras herramientas para comunicarnos en serie con el
controlador CAN.
NOTA En este punto, puede ser bueno ver si su dispositivo rastreador físico tiene luces adicionales. A menudo, un sniffer CAN tendrá luces verdes y rojas para indicar que puede comunicarse correctamente con
el bus CAN. Su dispositivo CAN debe estar conectado a su computadora y al vehículo para que
estas luces funcionen correctamente. No todos los dispositivos tienen estas luces. (Consulte el
manual de su dispositivo).
Configuración de una red CAN virtual
Si no tiene hardware CAN para jugar, no hay problema. Puede configurar una red CAN virtual para realizar
pruebas. Para hacerlo, simplemente cargue el módulo vcan .
$ modprobe vcan
Si marca dmesg, no debería ver mucho más que un mensaje como este:
Ahora acaba de configurar la interfaz como se explica en «Configuración de Conjuntos de chips”, pero sin especificar una velocidad en baudios para la interfaz virtual.
La suite de utilidades CAN
Con nuestro dispositivo CAN funcionando, echemos un vistazo de alto nivel a los can-utils. Se
enumeran y describen brevemente aquí; los usaremos a lo largo del libro y los exploraremos con mayor
detalle a medida que los usemos.
