Fuzzing UDS
Payload casuali su service ID standard o non standard, con rientro nella sessione, timeout configurabili e una lista di esclusione.
Motore · Fuzzing
Rompilo sul banco, non sul campo.
AutoST lancia traffico malformato e inatteso contro una ECU e osserva il momento in cui smette di rispondere, si resetta o genera un guasto. Ogni esecuzione è riproducibile, così un crash può essere riprodotto e consegnato agli sviluppatori.
In breve
Il motore di fuzzing invia traffico casuale e riproducibile a una ECU in due modalità. Il fuzzing UDS invia payload casuali (fino a 128 byte) su service ID selezionati o non standard tramite ISO-TP, rientrando periodicamente nella sessione diagnostica. Il fuzzing CAN invia frame CAN e CAN FD casuali su arbitration ID presi da un DBC. Le esecuzioni usano un seed, così un risultato può essere riprodotto esattamente. Il rilevamento dei crash gira dopo ogni iterazione: un controllo di liveness TesterPresent (sempre attivo), un monitor opzionale del conteggio DTC e il rilevamento di timeout o errori di trasporto. L’avanzamento è trasmesso in tempo reale e i risultati si esportano in PDF.
Due modalità
UDS e CAN, a tua scelta
Fuzzing CAN
Frame classici e FD casuali su arbitration ID dal tuo DBC, con un conteggio di riproduzione per confermare un risultato prima che venga registrato.
Rilevamento dei crash
Come AutoST capisce che qualcosa si è rotto
Liveness
Un controllo TesterPresent dopo ogni iterazione intercetta una ECU che ha smesso di rispondere. Sempre attivo.
Monitor DTC
Osserva facoltativamente il conteggio dei diagnostic trouble code e segnala qualsiasi variazione durante l’esecuzione.
Timeout
Timeout ed errori di trasporto su una richiesta fuzzata vengono registrati come risultati, con il payload esatto.
Riproducibile per progettazione
Un crash che puoi riprodurre
Ogni esecuzione di fuzzing è guidata da un seed che AutoST memorizza e mostra. Riesegui con lo stesso seed e ottieni la stessa sequenza, così un crash non è un caso isolato impossibile da ritrovare.
Ogni risultato è registrato con la sua iterazione, il timestamp, il monitor che lo ha intercettato e il payload, più un breve storico degli ultimi payload che lo hanno preceduto.
- Esecuzioni con seed, riproducibili
- Payload e monitor registrati per ogni risultato
- Iterazioni, crash e richieste al secondo in tempo reale
- Liste di esclusione per ID e service ID
Sicurezza
Solo per il banco
Il fuzzing può mandare una ECU in stato di guasto, resettarla o renderla inutilizzabile. AutoST è uno strumento da banco: non eseguire mai fuzzing su un veicolo nel traffico o su un sistema il cui guasto potrebbe ferire qualcuno.
- Esegui su un banco isolato
- Mai su strade pubbliche
- Mantieni un percorso di recupero per la ECU
FAQ
Domande frequenti
Il fuzzing è riproducibile?
Sì. Ogni esecuzione usa un seed memorizzato, così puoi riprodurre la sequenza esatta che ha innescato un crash e consegnarla agli sviluppatori.
Come rileva un crash?
Con un controllo di liveness TesterPresent dopo ogni iterazione, un monitor opzionale del conteggio DTC e il rilevamento di timeout o errori di trasporto sulle richieste fuzzate.
Posso eseguire fuzzing su un’auto su strada?
No. Il fuzzing è un’attività da banco. Può mandare una ECU in stato di guasto, quindi non deve mai girare su un veicolo nel traffico.
Vedilo sulla tua ECU
Guarda AutoST in azione sul tuo tipo di ECU
Prenota una demo dal vivo di un’ora. Scansioniamo un target reale, analizziamo insieme i risultati e il Fix Plan, e rispondiamo a tutto quello che ci chiedi.
- Lo esegue un ingegnere della sicurezza, non un commerciale
- Porta le tue domande su protocolli e hardware
- Gratis, e un passo successivo chiaro alla fine
La tua demo è conTom ZaubermannFondatore di Zyberum, ex responsabile del VW InCar Security Testing Lab
Già scelto da fornitori Tier 1, Tier 2 e OEM. Referenze su richiesta.
Oppure inviaci un messaggio
Rispondiamo entro un giorno lavorativo.