pfg666/dtls-fuzzerdtls-fuzzer è un fuzzer dello stato del protocollo per implementazioni di server DTLS.
dtls-fuzzer è uno strumento Java che esegue il fuzzing a livello di protocollo dello stato di server DTLS. Più concretamente, supporta le seguenti funzionalità:
dtls-fuzzer utilizza TLS-Attacker per generare/analizzare i messaggi DTLS nonché per mantenere lo stato. A tal fine, TLS-Attacker è stato esteso con il supporto per DTLS. dtls-fuzzer si basa sulla versione 3.0b di TLS-Attacker, una versione che implementa il miglioramento DTLS.
L'artefatto contiene:
Le cartelle più importanti nella directory principale di dtls-fuzzer sono:
'experiments/results' contiene i risultati sperimentali, che sono l'output principale del lavoro. In particolare:
Le cartelle di output sono denominate in base alla configurazione dell'esperimento, ovvero:
Ad esempio, il nome della cartella 'jsse-12_rsa_cert_none_rwalk_incl' indica un esperimento sull'implementazione JSSE 12 di DTLS, utilizzando un alfabeto che include input per eseguire handshake RSA, l'autenticazione del certificato client è disabilitata, l'algoritmo di test è random walk e le ritrasmissioni sono incluse.
Una cartella di output contiene:
Il valutatore può verificare (ad esempio) che i risultati sperimentali in 'included' corrispondano a quelli mostrati nella Tabella 4, o che le configurazioni testate nella Tabella 2 appaiano anche in 'all_ciphers'. Si noti che i modelli apparsi nell'articolo sono il risultato di un significativo pruning/trimming, mentre i modelli che appaiono nelle cartelle di output sono inalterati.
Ai fini della valutazione di dtls-fuzzer è necessario eseguire i seguenti passaggi:
Questa sezione di valutazione è seguita da una guida sull'uso di dtls-fuzzer che introduce i suoi principali casi d'uso.
dtls-fuzzer è stato testato su Ubuntu 18.04 e Debian 9 di Linux. Dovrebbe funzionare su qualsiasi distribuzione Linux recente. Il supporto per altre piattaforme non è stato testato. Questa guida presuppone l'uso di una distribuzione basata su Debian (che ha 'apt-get').
È richiesta una VM (Virtual Machine) con JDK (Java Development Kit) 8. La versione utilizzata per eseguire gli esperimenti è la 1.8.0_222, sebbene versioni successive di Java 8 dovrebbero funzionare. Si noti che lo strumento non viene compilato con Java 9 o successivo. Ci affidiamo anche a maven (l'utility 'mvn') per la gestione delle dipendenze/deployment.
Si consiglia di utilizzare una macchina sufficientemente potente, altrimenti parametri di temporizzazione sensibili come il tempo di attesa della risposta potrebbero diventare troppo bassi, causando output diversi da quelli ottenuti nell'articolo. Peggio ancora, possono far fallire gli esperimenti di apprendimento. Gli esperimenti originali sono stati eseguiti su un server multi-core, tuttavia ci aspettiamo (anche se non testato a fondo) che l'apprendimento sia possibile su un desktop con processore i7. L'apprendimento è possibile anche su sistemi meno potenti se i parametri di temporizzazione vengono regolati di conseguenza. Infine, la visualizzazione dei modelli .dot esportandoli in .pdf richiede l'installazione della libreria graphviz. Si presuppone che l'utility 'dot' fornita da graphviz si trovi nel PATH di sistema.
In sintesi, i prerequisiti consigliati sono:
dtls-fuzzer richiede Java 8 JDK (Java Development Kit). Se Java non è installato, installiamo l'implementazione OpenJDK (tramite 'apt-get' su Ubuntu) e possiamo saltare il resto di questa sottosezione.
> sudo apt-get install openjdk-8-jdk
Se una versione di java è installata, possiamo controllare quale versione è eseguendo:
> java -version
Il codice versione dovrebbe iniziare con 1.8 (ad esempio 1.8.0_242), e la Virtual Machine dovrebbe essere "Server VM" (indicando che è installato il JDK completo, non solo l'ambiente runtime). Se è così, abbiamo finito con Java. Se non lo è, possiamo controllare se Java 8 JDK è installato sulla nostra piattaforma ma non selezionato correntemente, elencando le VM Java installate tramite:
> update-java-alternatives --list
Se Java 8 JDK appare, possiamo usare lo stesso comando per configurare Java 8 JDK come implementazione Java predefinita.
> sudo update-java-alternatives --set java-1.8.0-openjdk-amd64
Altrimenti, dobbiamo eseguire l'installazione completa come mostrato all'inizio. Sfortunatamente, 'update-java-alternatives' a volte non ha successo, indicato da messaggi di "errore". Se si verifica un caso del genere, possiamo usare 'update-alternatives' per configurare interattivamente quale VM Java è selezionata da 'java' (interprete) e 'javac' (compilatore).
> sudo update-alternatives --config java
> sudo update-alternatives --config javac
Con Java 8 impostato, procediamo a installare le altre dipendenze, maven, graphviz più alcune dipendenze comuni del SUT. Quindi cloniamo il repository di dtls-fuzzer in una cartella a scelta, facendo il checkout del ramo dell'artefatto. Per finire, rendiamo quella cartella la nostra directory corrente.
> sudo apt-get install maven graphviz autotools-dev automake libtool
> git clone -b usenix20-artifact https://github.com/assist-project/dtls-fuzzer.git ~/dtls-fuzzer
> cd ~/dtls-fuzzer
Prima eseguiamo lo script 'prepare.sh' che installa le librerie da cui dtls-fuzzer dipende, ovvero due .jar locali e TLS-Attacker 3.0b. Quindi installiamo lo strumento stesso. I comandi risultanti su un sistema POSIX saranno:
> bash prepare.sh
> mvn clean install
Dopo questi passaggi, dovrebbe essere stata creata una directory denominata 'target' contenente 'dtls-fuzzer.jar'. Questa è la nostra libreria eseguibile. Da questo punto in poi si presuppone che i comandi vengano eseguiti dalla directory principale di dtls-fuzzer.
Supponiamo di voler generare un modello per OpenSSL 1.1.1b utilizzando solo PSK (Pre-Shared Keys). Un'esecuzione rapida di dtls-fuzzer avviene come segue.
Per prima cosa configuriamo il SUT, cosa che viene fatta automaticamente da uno script 'setup_sut.sh'.
> bash setup_sut.sh openssl-1.1.1b
Poi selezioniamo un file di argomenti dalla cartella 'args/openssl-1.1.1b'. Notiamo che ci sono diversi file di argomenti tra cui scegliere, ovvero:
learn_openssl-1.1.1b_all_cert_none_rwalk_incl
learn_openssl-1.1.1b_all_cert_nreq_rwalk_incl
learn_openssl-1.1.1b_all_cert_req_rwalk_incl
learn_openssl-1.1.1b_psk_rwalk_incl
Il file di argomenti di interesse è 'learn_openssl-1.1.1b_psk_rwalk_incl', poiché il suo nome indica PSK. Lo selezioniamo quindi ed eseguiamo il fuzzer su di esso. Inoltre limitiamo il numero di test a 200, per ridurre il tempo di apprendimento. Infine, per OpenSSL, LD_LIBRARY_PATH deve essere impostato sulla directory dell'implementazione ('suts/openssl-1.1.1b/'). Prima di eseguire l'apprendimento, potremmo voler eseguire un semplice test per verificare che la nostra configurazione funzioni. Un buon test è semplicemente completare un handshake. Forniamo il file di argomenti, insieme a un test corrispondente da 'examples/tests' come parametro. Otteniamo:
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_psk_rwalk_incl -test examples/tests/psk
Se tutto va bene, il server dovrebbe aver stampato "This is a hello message", un messaggio che inviamo dopo aver completato l'handshake. Sapendo che la nostra configurazione funziona, possiamo ora avviare l'apprendimento eseguendo:
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_psk_rwalk_incl -queries 200
Notiamo che è stata creata una directory di output, 'output/openssl-1.1.1b_psk_rwalk_incl/' per l'esperimento. Possiamo eseguire 'ls' su questa directory per controllare lo stato attuale dell'esperimento (il numero di ipotesi generate...).
> ls output/openssl-1.1.1b_psk_rwalk_incl/
Se tutto va bene, dopo 20-30 minuti, la directory di output dovrebbe contenere un file 'learnedModel.dot'. Possiamo visualizzare il file usando l'utility 'dot' di graphviz, esportandolo in .pdf e aprendo il .pdf con il nostro visualizzatore .pdf preferito.
> dot -Tpdf output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.dot > output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.pdf
> evince output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.pdf
Infine, possiamo usare 'trim_model.sh' per generare una versione migliore/più snella del modello. Questo può essere fatto come segue:
> bash trim_model.sh --output output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.dot output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.dot
> dot -Tpdf output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.dot > output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.pdf
> evince output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.pdf
Possiamo ora determinare la conformità del sistema controllando il modello rispetto alla specifica...
Quando si esegue 'ls' della directory di output potremmo trovare 'error.msg'. Questo è un segno che l'esperimento è fallito e l'apprendimento si è interrotto bruscamente. In tali casi, visualizzare il contenuto rivela il motivo del fallimento.
> cat output/openssl-1.1.1b_psk_rwalk_incl/error.msg
Si noti che il controllo di conformità può comunque essere eseguito sull'ultima ipotesi generata, purché i potenziali risultati siano validati rispetto al sistema (come dovrebbero essere comunque).
Forniamo uno script per la configurazione del SUT. Questo script scarica i file sorgente, installa alcune dipendenze (jvm) e compila il SUT. Per visualizzare i SUT per i quali è prevista la configurazione automatica, eseguire:
> bash setup_sut.sh
Per configurare, ad esempio, l'implementazione tinydtls di Contiki-NG eseguire:
> bash setup_sut.sh ctinydtls
Lo script genererà due cartelle nella directory principale di dtls-fuzzer.
Sfortunatamente, automatizzare la configurazione del SUT è un processo complicato, quindi adottiamo le seguenti scorciatoie. Per i SUT Java (JSSE, Scandium) non compiliamo le implementazioni, ma utilizziamo i .jar già compilati dalla directory 'experiments/suts'. Si noti che il codice sorgente di questi SUT Java (applicazioni server) è disponibile pubblicamente online, vedi Scandium e JSSE, come lo è anche per PionDTLS. L'installazione automatica delle dipendenze potrebbe richiedere l'accesso 'sudo'. Questo accade per GnuTLS, che si basa su librerie esterne come nettle, e per Eclipse's TinyDTLS, che si basa su autoconf. Infine, non forniamo configurazione automatica/file di argomenti per NSS e PionDTLS a causa della complessità della configurazione per questi sistemi.
Se le cose nel processo di configurazione smettono di funzionare, eliminare la cartella 'suts' (o la cartella 'suts/SUT' specifica per il SUT) e rieseguire lo script di configurazione potrebbe risolvere il problema. Inoltre, in caso di errore di compilazione, il codice sorgente dell'implementazione dovrebbe comunque essere scaricato nella directory 'suts'. Una soluzione alternativa è compilare manualmente l'implementazione. Finché l'implementazione è compilata, la nostra configurazione dovrebbe funzionare.
Forniamo di seguito un albero incompleto delle dipendenze che i vari SUT hanno. Quelle in corsivo sono dipendenze che 'setup_sut.sh' tenta di installare utilizzando l'accesso 'sudo'.
Siamo ora pronti per apprendere una configurazione SUT. I file di argomenti per varie configurazioni SUT sono forniti nella directory 'args' situata nella home directory di dtls-fuzzer. Ogni nome di file di argomenti descrive la configurazione dell'esperimento (SUT, alfabeto, autenticazione) come descritto dai nomi delle cartelle di output in 'experiments/results/'. Per avviare l'apprendimento per un SUT utilizzando un file di argomenti, eseguire:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file
La cartella di output verrà archiviata in una directory 'output' generata.
Rispetto agli esperimenti nell'articolo, abbiamo aumentato il timeout di risposta per diversi SUT come adattamento a hardware meno potente. Per ridurre il tempo di apprendimento, suggeriamo di diminuire il limite di test dell'algoritmo random walk da 20000 a 5000. Questo può essere fatto con:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -queries 5000
Questo sovrascriverà l'impostazione del limite nel file di argomenti. A parte GnuTLS, PionDTLS e JSSE, ci aspettiamo che l'apprendimento produca gli stessi modelli per questo limite inferiore.
La temporizzazione può diventare un problema, causando non-determinismo, seguito da terminazione brusca con un file 'error.msg' informativo. In tali casi, ci sono due parametri che possono essere regolati:
Questi parametri possono essere regolati sovrascrivendo (probabilmente con un valore più alto) le corrispondenti impostazioni nel file di argomenti:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeout new_response_timeout -runWait new_start_timeout
Per evitare problemi legati alla temporizzazione, suggeriamo di eseguire gli esperimenti su una macchina sufficientemente potente. La causa principale del non-determinismo è che il SUT impiega troppo tempo per avviarsi o per generare una risposta. Questa probabilità diminuisce man mano che viene fornita più potenza di calcolo.
Potremmo voler terminare automaticamente gli esperimenti dopo un certo periodo, in particolare gli esperimenti che non ci si aspetta terminino mai. L'impostazione di questo periodo è possibile tramite il parametro time limit a cui viene assegnata la durata massima per cui l'esperimento può essere eseguito. Questa durata viene fornita in formato ISO 8601. Per limitare il tempo di esecuzione di un esperimento a 60 minuti, eseguiremmo:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeLimit "PT60M"
È possibile eseguire più esperimenti contemporaneamente a condizione che i server siano configurati per ascoltare su porte diverse. Possiamo scegliere di avviare ciascun esperimento in un terminale separato. In alternativa, possiamo avviare gli esperimenti in un singolo terminale utilizzando l'utility 'disown':
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk 1>/dev/null 2>&1 & disown
Tuttavia, eseguirne più di pochi (>2) pone un carico aggiuntivo sulla macchina. Aumenta anche la possibilità di fallimento dell'apprendimento a causa di una collisione accidentale di porta. Nella maggior parte delle configurazioni, i server sono configurati per ascoltare su qualche porta fissa su localhost, le configurazioni fornite in 'args' utilizzano porte fisse distinte. Per le configurazioni JSSE e Scandium, la configurazione è diversa. Ad ogni test, il SUT avvia un server in ascolto su una porta scelta dinamicamente e comunica la porta su socket TCP a dtls-fuzzer. Questo ha il vantaggio di notificare a dtls-fuzzer quando il server è pronto a ricevere pacchetti (mancando questo, dtls-fuzzer dovrebbe attendere ciecamente un tempo arbitrario per l'avvio del server). Lo svantaggio è che la porta allocata potrebbe essere la stessa di qualche porta fissa di un esperimento diverso, in cui un thread server è stato recentemente fermato e un nuovo thread non è ancora stato avviato (il che significa che la porta fissa potrebbe essere utilizzata nell'allocazione dinamica). Per evitare questa forma di collisione, consigliamo di eseguire gli esperimenti Scandium e JSSE separatamente da tutti gli altri.
Suggeriamo le seguenti configurazioni per le quali la compilazione automatica è affidabile, l'apprendimento è più veloce o sono stati trovati bug interessanti. Assicurati di aver configurato il SUT prima di eseguire il comando fornito. Noterai che ci concentriamo sulle configurazioni PSK dove possibile. Questo perché PSK con password piccole richiede un tempo di elaborazione significativamente inferiore rispetto a qualsiasi altro meccanismo di crittografia.### OpenSSL 1.1.1b Qualsiasi configurazione openssl-1.1.1b (ad esempio 'args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl') può essere provata. Gli esperimenti terminano rapidamente (meno di un giorno), esercitando tutti gli algoritmi di scambio di chiavi. Comando per la configurazione che richiede il certificato client utilizzando tutti gli algoritmi di scambio di chiavi (PSK, RSA, ECDH, DH):
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl -queries 5000
Nota: quando si apprende OpenSSL, è necessario puntare la variabile LD_LIBRARY_PATH alla directory di installazione.
Qualsiasi configurazione mbedtls-2.16.1 può essere utilizzata per gli stessi motivi di OpenSSL. Gli esperimenti richiedono più tempo per essere completati poiché il SUT è più lento. Comando per la configurazione con autenticazione del certificato client disabilitata utilizzando tutti gli algoritmi di scambio di chiavi:
> java -jar target/dtls-fuzzer.jar @args/mbedtls-2.16.1/learn_mbedtls_all_cert_none_rwalk_incl -queries 5000
Una versione ridotta del modello ottenuto per questa configurazione appare nell'appendice. Possiamo utilizzare un limite di test basso di 2000 poiché l'alfabeto di input è piccolo, rendendo il test più facile.
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk -queries 2000
Per WolfSSL forniamo una configurazione PSK per la quale l'apprendimento dovrebbe terminare relativamente rapidamente.
> java -jar target/dtls-fuzzer.jar @args/wolfssl-4.0.0/learn_wolfssl-4.0.0_psk_rwalk -queries 2000
La versione più recente di GnuTLS che abbiamo analizzato ha prodotto modelli belli e compatti. Purtroppo, abilitare l'autenticazione client ha portato a un forte aumento del numero di test richiesti. Suggeriamo una configurazione che la disabiliti per ridurre i tempi di apprendimento:
> java -jar target/dtls-fuzzer.jar @args/gnutls-3.6.7/learn_gnutls-3.6.7_all_cert_none_rwalk_incl -queries 2000
Una versione ridotta del modello ottenuto per questa configurazione appare nell'articolo. Il modello espone bug importanti, purtroppo l'esperimento è lungo. L'esperimento non dovrebbe essere eseguito in parallelo con esperimenti che non coinvolgono Scandium o JSSE. Comando:
> java -jar target/dtls-fuzzer.jar @args/scandium-2.0.0/learn_scandium-2.0.0_psk_rwalk -queries 2000
Una versione ridotta del modello ottenuto per questa configurazione appare nell'articolo. Il modello espone bug importanti. L'esperimento non dovrebbe essere eseguito in parallelo con esperimenti che non coinvolgono Scandium o JSSE. Nota che l'apprendimento per JSSE non termina/converge, costruendo ipotesi con sempre più stati. Abbiamo quindi configurato gli esperimenti JSSE per terminare automaticamente dopo un giorno (due giorni nell'articolo). Comando per lo scambio di chiavi RSA:
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl
Invece di un apprendimento arduo, potremmo voler semplicemente testare se un handshake può essere completato in questa impostazione senza inviare alcun messaggio di certificato. Questo può essere fatto eseguendo:
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl -test examples/tests/rsa
Una volta terminato l'apprendimento, gli elementi da analizzare nella directory di output sono:
Il modello appreso .dot può essere visualizzato utilizzando la libreria graphviz, mediante conversione in .pdf:
> dot -Tpdf learnedModel.dot > learnedModel.pdf
Purtroppo, man mano che i modelli crescono in dimensione, i .pdf generati con questo metodo diventano sempre più difficili da leggere. Abbiamo quindi sviluppato/usato/importato script di pruning a cui si accede tramite 'trim_model.sh'. Gli script forniscono informazioni sull'utilizzo eseguendo:
> bash trim_model.sh
Consigliamo di utilizzare lo script nella sua forma più semplice, ovvero:
> bash trim_model.sh learnedModel.dot
Lo script:
(5) richiede l'installazione della libreria Python 3 personalizzata mypydot, che si trova in 'experiments\scripts'. Tutti gli altri passaggi utilizzano semplice 'sed' più la libreria Java dot-trimmer. Un .jar per questa libreria è incluso in 'experiments\scripts'.
Esegui:
> java -jar target/dtls-fuzzer.jar -help
Il numero di opzioni può essere opprimente. Per apprendere un'implementazione del server DTLS, è sufficiente specificare poche opzioni, ovvero: "-connect ip_address:port" che è l'indirizzo a cui il server DTLS in esecuzione sta ascoltando. Tutte le altre opzioni sono impostate sui valori predefiniti, incluso l'alfabeto.
Per avviare un'esecuzione di apprendimento per un'implementazione di server locale esistente in ascolto sulla porta 20000, esegui:
> java -jar target/dtls-fuzzer.jar -connect localhost:20000
Probabilmente ci saranno problemi con questo tipo di apprendimento. L'apprendimento richiede di poter ripristinare il server dopo ogni test. Alcuni server manterranno dello stato da un test all'altro. Ciò può portare a non determinismo durante l'apprendimento, quindi un approccio migliore è avviare un nuovo thread del server per ogni test utilizzando un comando fornito. Il thread del server viene terminato una volta eseguito il test, garantendo un corretto ripristino. Esempio per OpenSSL:
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -cmd "openssl s_server -accept 20000 -dtls1_2"
Con così tanti parametri, i comandi possono diventare molto lunghi. dtls-fuzzer utilizza JCommander per analizzare gli argomenti, che può anche leggere parametri da un file. Vai a 'experiments/args' per esempi di argomenti. Per fornire un file di argomenti a dtls-fuzzer fornisci il parametro preceduto da "@". Puoi anche aggiungere altri argomenti espliciti ai comandi (che sovrascriveranno quelli nel file degli argomenti)
> java -jar target/dtls-fuzzer.jar @arg_file ...overwriting params...
Per avviare un batch di esecuzioni di apprendimento, è possibile utilizzare lo script 'launcher.py' in 'experiments/scripts'. Fornita una directory con file di argomenti, lo strumento avvierà un processo di apprendimento per ogni file di argomenti.
> python3 experiments/scripts/launcher.py --jar target/dtls-fuzzer.jar --args args_folder
Prima di eseguire esperimenti di apprendimento, è utile verificare che gli argomenti siano impostati correttamente, in particolare i parametri di temporizzazione. A tal fine, dtls-fuzzer può eseguire una suite di test personalizzata (collezione di test) sul SUT e fornire un riepilogo degli output. Questa funzionalità può essere utilizzata anche quando si diagnosticano esperimenti di apprendimento falliti, ad esempio per scoprire cosa è andato storto.
Per eseguire la suite di test su un server utilizzando l'alfabeto predefinito, puoi eseguire:
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file
Per esempi di file di test, vai a 'examples/tests'. Un file di test comprende un elenco di input separati da nuove righe. I test sono separati da nuove righe vuote. La fine di ogni test è o la fine del file o una nuova riga vuota. "#" viene utilizzato per commentare una riga.
Se si dispone di un modello/specifica, è anche possibile eseguire la suite di test e confrontare l'output con quello in una specifica.
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -specification model
Il numero di volte in cui i test vengono eseguiti è configurabile tramite il parametro '-times', che di default è 1. Impostarlo su un numero elevato aiuta a rilevare il non determinismo nelle configurazioni di apprendimento, confrontando l'output di ogni test.
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -times 10
Infine, se si dispone del file di argomenti per un esperimento di apprendimento, è possibile utilizzarli per eseguire test sul SUT coinvolto aggiungendo semplicemente gli argomenti di test necessari:
> java -jar target/dtls-fuzzer.jar @learning_arg_file -test test_file