Fuzzing de UDS
Payloads aleatorios en IDs de servicio estándar o no estándar, con reentrada en la sesión, timeouts configurables y una lista de exclusión.
Motor · Fuzzing
Rómpela en el banco, no sobre el terreno.
AutoST lanza tráfico malformado e inesperado contra una ECU y vigila el momento en que deja de responder, se reinicia o lanza un fallo. Cada ejecución es reproducible, así un fallo se puede reproducir y entregar a los desarrolladores.
En resumen
El motor de fuzzing envía tráfico aleatorizado y reproducible a una ECU en dos modos. El fuzzing de UDS envía payloads aleatorios (hasta 128 bytes) en IDs de servicio seleccionados o no estándar sobre ISO-TP, reentrando en la sesión de diagnóstico de forma periódica. El fuzzing de CAN envía tramas CAN y CAN FD aleatorias en IDs de arbitraje tomados de un DBC. Las ejecuciones usan semilla, así un hallazgo se puede reproducir con exactitud. La detección de fallos se ejecuta tras cada iteración: una comprobación de actividad con TesterPresent (siempre activa), un monitor opcional del recuento de DTC, y la detección de timeouts o errores de transporte. El progreso se transmite en vivo y los resultados se exportan a PDF.
Dos modos
UDS y CAN, tú eliges
Fuzzing de CAN
Tramas aleatorias clásicas y FD en IDs de arbitraje de tu DBC, con un recuento de reproducción para confirmar un hallazgo antes de registrarlo.
Detección de fallos
Cómo sabe AutoST que algo se rompió
Actividad
Una comprobación de TesterPresent tras cada iteración detecta una ECU que ha dejado de responder. Siempre activa.
Monitor de DTC
Opcionalmente vigila el recuento de códigos de avería de diagnóstico y marca cualquier cambio durante la ejecución.
Timeouts
Los timeouts y los errores de transporte en una petición fuzzeada se registran como hallazgos, con el payload exacto.
Reproducible por diseño
Un fallo que puedes reproducir
Cada ejecución de fuzzing se guía por una semilla que AutoST almacena y muestra. Vuelve a ejecutar con la misma semilla y obtienes la misma secuencia, así un fallo no es algo puntual que nunca podrás volver a encontrar.
Cada hallazgo se registra con su iteración, marca de tiempo, el monitor que lo detectó y el payload, más un breve historial de los últimos payloads que condujeron a él.
- Ejecuciones con semilla y reproducibles
- Payload y monitor registrados por hallazgo
- Iteraciones, fallos y peticiones por segundo en vivo
- Listas de exclusión para IDs e IDs de servicio
Seguridad
Solo para el banco
El fuzzing puede dejar una ECU en un estado de fallo, reiniciarla o inutilizarla. AutoST es una herramienta de banco: nunca hagas fuzzing a un vehículo en circulación ni a un sistema cuyo fallo pueda hacer daño a alguien.
- Ejecuta en un banco aislado
- Nunca en vías públicas
- Mantén una vía de recuperación para la ECU
FAQ
Preguntas frecuentes
¿El fuzzing es reproducible?
Sí. Cada ejecución usa una semilla almacenada, así puedes reproducir la secuencia exacta que provocó un fallo y entregársela a los desarrolladores.
¿Cómo detecta un fallo?
Con una comprobación de actividad de TesterPresent tras cada iteración, un monitor opcional del recuento de DTC, y la detección de timeouts o errores de transporte en las peticiones fuzzeadas.
¿Puedo hacer fuzzing a un coche en la carretera?
No. El fuzzing es una actividad de banco. Puede dejar una ECU en un estado de fallo, así que nunca debe ejecutarse en un vehículo en circulación.
Míralo sobre tu ECU
Mira a AutoST en acción sobre tu tipo de ECU
Reserva una demo en vivo de una hora. Escaneamos un objetivo real, repasamos los hallazgos y el Fix Plan, y respondemos a todo lo que nos plantees.
- La ejecuta un ingeniero de seguridad, no un comercial
- Trae tus preguntas sobre protocolos y hardware
- Gratis, con un siguiente paso claro al terminar
Tu demo es conTom ZaubermannFundador de Zyberum, ex responsable del VW InCar Security Testing Lab
Ya confían en él proveedores Tier 1, Tier 2 y OEM. Referencias a petición.
O envíanos un mensaje
Respondemos en un día hábil.