pfg666/dtls-fuzzerdtls-fuzzer est un fuzzer d'état de protocole pour les implémentations de serveur DTLS.
dtls-fuzzer est un outil Java qui effectue du fuzzing d'état de protocole de serveurs DTLS. Plus concrètement, il supporte les fonctionnalités suivantes :
dtls-fuzzer utilise TLS-Attacker pour générer/analyser les messages DTLS ainsi que pour maintenir l'état. À cette fin, TLS-Attacker a été étendu avec le support de DTLS. dtls-fuzzer repose sur la version 3.0b de TLS-Attacker, une version implémentant l'amélioration DTLS.
L'artefact contient :
Les dossiers les plus importants dans le répertoire racine de dtls-fuzzer sont :
'experiments/results' contient les résultats expérimentaux, qui sont la principale production du travail. En particulier :
Les dossiers de sortie sont nommés en fonction de la configuration de l'expérience, c'est-à-dire :
Par exemple, le nom de dossier 'jsse-12_rsa_cert_none_rwalk_incl' indique une expérience sur l'implémentation JSSE 12 de DTLS, utilisant un alphabet incluant des entrées pour effectuer des handshakes RSA, l'authentification par certificat client est désactivée, l'algorithme de test est random walk et les retransmissions sont incluses.
Un dossier de sortie contient :
L'évaluateur peut vérifier (par exemple) que les résultats expérimentaux dans 'included' correspondent à ceux affichés dans le Tableau 4, ou que les configurations testées dans le Tableau 2 apparaissent également dans 'all_ciphers'. Notez que les modèles apparaissant dans l'article sont le résultat d'un élagage/trimming significatif, tandis que les modèles apparaissant dans les dossiers de sortie sont inchangés.
Pour l'évaluation de dtls-fuzzer, il est nécessaire d'effectuer les étapes suivantes :
Cette section d'évaluation est suivie d'un guide sur l'utilisation de dtls-fuzzer qui présente ses principaux cas d'utilisation.
dtls-fuzzer a été testé sur les distributions Linux Ubuntu 18.04 et Debian 9. Il devrait fonctionner sur toute distribution Linux récente. Le support pour d'autres plateformes n'a pas été testé. Ce guide suppose qu'une distribution basée sur Debian est utilisée (qui dispose de 'apt-get').
Un JDK (Java Development Kit) Java 8 est requis. La version utilisée pour exécuter les expériences est 1.8.0_222, bien que les versions ultérieures de Java 8 devraient également fonctionner. Notez que l'outil ne compile pas sur Java 9 ou ultérieur. Nous utilisons également maven (l'utilitaire 'mvn') pour la gestion des dépendances / le déploiement.
Nous recommandons d'utiliser une machine suffisamment puissante, sinon des paramètres de timing sensibles tels que le temps d'attente de réponse pourraient devenir trop bas, provoquant des sorties différentes de celles obtenues dans l'article. Pire encore, ils peuvent entraîner l'échec des expériences d'apprentissage. Les expériences originales ont été exécutées sur un serveur multi-cœur, mais nous nous attendons (bien que non testé en profondeur) que l'apprentissage devrait être possible sur un ordinateur de bureau avec un processeur i7. L'apprentissage est également possible sur des systèmes plus faibles si les paramètres de timing sont ajustés en conséquence. Enfin, la visualisation des modèles .dot en les exportant au format .pdf nécessite l'installation de la bibliothèque graphviz. On suppose que l'utilitaire 'dot' fourni par graphviz se trouve dans le PATH du système.
En résumé, les prérequis conseillés sont :
dtls-fuzzer nécessite JDK Java 8 (Java Development Kit). Si Java n'est pas installé, nous installons l'implémentation OpenJDK (via 'apt-get' sur Ubuntu), et pouvons passer le reste de cette sous-section.
> sudo apt-get install openjdk-8-jdk
Si une version de java est installée, nous pouvons vérifier quelle version elle est en exécutant :
> java -version
Le code de version devrait commencer par 1.8 (par exemple 1.8.0_242), et la machine virtuelle devrait être "Server VM" (indiquant que le JDK complet est installé, plutôt que seulement l'environnement d'exécution). Si c'est le cas, nous en avons fini avec Java. Si ce n'est pas le cas, nous pouvons vérifier si JDK Java 8 est installé sur notre plateforme mais pas actuellement sélectionné, en listant les machines virtuelles Java installées via :
> update-java-alternatives --list
Si JDK Java 8 apparaît, nous pouvons utiliser la même commande pour configurer JDK Java 8 comme implémentation Java par défaut.
> sudo update-java-alternatives --set java-1.8.0-openjdk-amd64
Sinon, nous devons effectuer l'installation complète comme indiqué au début. Malheureusement, 'update-java-alternatives' échoue parfois, indiqué par des messages "error". Si un tel cas se présente, nous pouvons utiliser 'update-alternatives' pour configurer de manière interactive quelle machine virtuelle Java est sélectionnée par 'java' (interpréteur) et 'javac' (compilateur).
> sudo update-alternatives --config java
> sudo update-alternatives --config javac
Avec Java 8 configuré, nous procédons à l'installation des autres dépendances, maven, graphviz ainsi que quelques dépendances communes du SUT. Nous clonons ensuite le dépôt de dtls-fuzzer dans un dossier de notre choix, en extrayant la branche de l'artefact. Pour terminer, nous faisons de ce dossier notre répertoire courant.
> 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
Nous exécutons d'abord le script 'prepare.sh' qui installe les bibliothèques dont dtls-fuzzer dépend, à savoir deux .jars locaux et TLS-Attacker 3.0b. Nous installons ensuite l'outil lui-même. Les commandes résultantes sur un système POSIX seront :
> bash prepare.sh
> mvn clean install
Après ces étapes, un répertoire nommé 'target' devrait avoir été construit contenant 'dtls-fuzzer.jar'. C'est notre bibliothèque exécutable. À partir de ce point, on suppose que les commandes sont exécutées depuis le répertoire racine de dtls-fuzzer.
Supposons que nous voulions générer un modèle pour OpenSSL 1.1.1b en utilisant uniquement PSK (Pre-Shared Keys). Une exécution rapide de dtls-fuzzer se déroule comme suit.
D'abord, nous configurons le SUT, ce qui est fait automatiquement par un script 'setup_sut.sh'.
> bash setup_sut.sh openssl-1.1.1b
Ensuite, nous sélectionnons un fichier d'arguments dans le dossier 'args/openssl-1.1.1b'. Nous remarquons qu'il y a plusieurs fichiers d'arguments parmi lesquels choisir, à savoir :
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
Le fichier d'arguments qui nous intéresse est 'learn_openssl-1.1.1b_psk_rwalk_incl', car son nom indique PSK. Nous le sélectionnons donc, et exécutons le fuzzer dessus. Nous plafonnons en plus le nombre de tests à 200, pour raccourcir le temps d'apprentissage. Enfin, pour OpenSSL, LD_LIBRARY_PATH doit être défini sur le répertoire de l'implémentation ('suts/openssl-1.1.1b/'). Avant d'exécuter l'apprentissage, nous pourrions vouloir exécuter un test simple pour vérifier que notre configuration fonctionne. Un bon test est simplement d'effectuer un handshake. Nous fournissons le fichier d'arguments, ainsi qu'un test correspondant depuis 'examples/tests' en paramètre. Nous obtenons :
> 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
Si tout se passe bien, le serveur devrait avoir imprimé "This is a hello message", un message que nous envoyons après avoir terminé le handshake. Sachant que notre configuration fonctionne, nous pouvons maintenant démarrer l'apprentissage en exécutant :
> 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
Nous remarquons qu'un répertoire de sortie, 'output/openssl-1.1.1b_psk_rwalk_incl/' pour l'expérience a été créé. Nous pouvons faire 'ls' dans ce répertoire pour vérifier l'état actuel de l'expérience (le nombre d'hypothèses générées...).
> ls output/openssl-1.1.1b_psk_rwalk_incl/
Si tout se passe bien, après 20 à 30 minutes, le répertoire de sortie devrait contenir un fichier 'learnedModel.dot'. Nous pouvons visualiser le fichier en utilisant l'utilitaire 'dot' de graphviz, en exportant au format .pdf et en ouvrant le .pdf avec notre visionneur de .pdf préféré.
> 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
Enfin, nous pouvons utiliser 'trim_model.sh' pour générer une version plus belle/plus épurée du modèle. Cela peut être fait comme suit :
> 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
Nous pouvons maintenant déterminer la conformité du système en vérifiant le modèle par rapport à la spécification...
En faisant 'ls' dans le répertoire de sortie, nous pourrions trouver 'error.msg'. C'est un signe que l'expérience a échoué et que l'apprentissage s'est terminé brusquement. Dans de tels cas, afficher le contenu révèle la raison de l'échec.
> cat output/openssl-1.1.1b_psk_rwalk_incl/error.msg
Notez que la vérification de la conformité peut toujours être effectuée sur la dernière hypothèse générée, tant que les résultats potentiels sont validés par rapport au système (comme ils devraient l'être de toute façon).
Nous fournissons un script pour configurer le SUT. Ce script télécharge les fichiers source, installe certaines dépendances (jvm) et compile le SUT. Pour voir les SUT pour lesquels une configuration automatique est fournie, exécutez :
> bash setup_sut.sh
Pour configurer, par exemple, l'implémentation tinydtls de Contiki-NG, exécutez :
> bash setup_sut.sh ctinydtls
Le script générera deux dossiers dans le répertoire racine de dtls-fuzzer.
Malheureusement, l'automatisation de la configuration du SUT est un processus complexe, c'est pourquoi nous prenons les raccourcis suivants. Pour les SUT Java (JSSE, Scandium), nous ne compilons pas les implémentations, nous utilisons plutôt les .jars compilés du répertoire 'experiments/suts'. Notez que le code source de ces SUT Java (applications serveur) est disponible publiquement en ligne, voir Scandium et JSSE, ce qui est également le cas pour PionDTLS. L'installation automatique des dépendances peut demander un accès 'sudo'. Cela se produit pour GnuTLS qui repose sur des bibliothèques externes telles que nettle, et pour TinyDTLS d'Eclipse, qui repose sur autoconf. Enfin, nous ne fournissons pas de configuration automatique/fichiers d'arguments pour NSS et PionDTLS en raison de la complexité de leur configuration.
Si des choses dans le processus de configuration cessent de fonctionner, supprimer le dossier 'suts' (ou le dossier 'suts/SUT' spécifique au SUT) et relancer le script de configuration peut résoudre le problème. De plus, en cas d'échec de compilation, le code source de l'implémentation devrait toujours être téléchargé dans le répertoire 'suts'. Une solution de contournement consiste à compiler l'implémentation manuellement. Tant que l'implémentation est compilée, notre configuration devrait fonctionner.
Nous donnons ci-dessous un arbre incomplet des dépendances des différents SUT. Ceux en italique sont des dépendances que 'setup_sut.sh' essaie d'installer en utilisant l'accès 'sudo'.
Nous sommes maintenant prêts à apprendre une configuration de SUT. Des fichiers d'arguments pour diverses configurations de SUT sont fournis dans le répertoire 'args' situé dans le répertoire de base de dtls-fuzzer. Chaque nom de fichier d'arguments décrit la configuration de l'expérience (SUT, alphabet, authentification) comme décrit par les noms de dossiers de sortie dans 'experiments/results/'. Pour démarrer l'apprentissage pour un SUT en utilisant un fichier d'arguments, exécutez :
> java -jar target/dtls-fuzzer.jar @args/nom_sut/fichier_args
Le dossier de sortie sera stocké dans un répertoire 'output' généré.
Par rapport aux expériences de l'article, nous avons augmenté le délai d'attente de réponse pour plusieurs SUT comme adaptation à un matériel moins puissant. Pour raccourcir le temps d'apprentissage, nous suggérons de diminuer la limite de tests de l'algorithme random walk de 20000 à 5000. Cela peut être fait par :
> java -jar target/dtls-fuzzer.jar @args/nom_sut/fichier_args -queries 5000
Cela écrasera le paramètre de limite dans le fichier d'arguments. En dehors de GnuTLS, PionDTLS et JSSE, nous nous attendons à ce que l'apprentissage produise les mêmes modèles pour cette limite inférieure.
Le timing peut devenir un problème, provoquant du non-déterminisme, suivi d'une terminaison brutale avec un fichier 'error.msg' informatif. Dans de tels cas, il y a deux paramètres qui peuvent être ajustés :
Ces paramètres peuvent être ajustés en écrasant (probablement avec une valeur plus élevée) les paramètres correspondants dans le fichier d'arguments :
> java -jar target/dtls-fuzzer.jar @args/nom_sut/fichier_args -timeout nouveau_délai_réponse -runWait nouveau_délai_démarrage
Pour éviter les problèmes liés au timing, nous suggérons d'exécuter les expériences sur une machine suffisamment puissante. La principale cause de non-déterminisme est le SUT qui prend trop de temps pour démarrer ou pour générer une réponse. Cette probabilité diminue à mesure que la puissance de calcul augmente.
Nous pouvons souhaiter terminer automatiquement les expériences après une certaine période, en particulier les expériences qui ne sont pas censées se terminer un jour. La définition de cette période est possible via le paramètre time limit qui reçoit la durée maximale que l'expérience est autorisée à exécuter. Cette durée est fournie au format ISO 8601. Pour limiter le temps d'exécution d'une expérience à 60 minutes, nous exécuterions :
> java -jar target/dtls-fuzzer.jar @args/nom_sut/fichier_args -timeLimit "PT60M"
Il est possible d'exécuter plusieurs expériences en même temps à condition que les serveurs soient configurés pour écouter sur des ports différents. Nous pouvons choisir de lancer chaque expérience dans un terminal séparé. Alternativement, nous pouvons lancer les expériences dans un seul terminal en utilisant l'utilitaire 'disown' :
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk 1>/dev/null 2>&1 & disown
Cependant, en exécuter plus de quelques-unes (>2) impose une charge supplémentaire sur la machine. Cela augmente également le risque d'échec de l'apprentissage dû à une collision de port accidentelle. Dans la plupart des configurations, les serveurs sont configurés pour écouter sur un port codé en dur via localhost, les configurations fournies dans 'args' utilisant des ports codés en dur distincts. Pour les configurations JSSE et Scandium, la configuration est différente. À chaque test, le SUT lance un serveur écoutant sur un port choisi dynamiquement et communique le port via des sockets TCP à dtls-fuzzer. Cela a l'avantage de notifier dtls-fuzzer lorsque le serveur est prêt à recevoir des paquets (en l'absence de cela, dtls-fuzzer devrait attendre aveuglément un temps arbitraire pour que le serveur démarre). L'inconvénient est que le port alloué pourrait être le même que celui d'un port codé en dur d'une expérience différente, où un thread serveur a récemment été arrêté et un nouveau thread n'a pas encore été démarré (ce qui signifie que le port codé en dur pourrait être utilisé dans l'allocation dynamique). Pour éviter cette forme de collision, nous conseillons d'exécuter les expériences Scandium et JSSE séparément de toutes les autres.
Nous suggérons les configurations suivantes pour lesquelles la compilation automatique est fiable, l'apprentissage est plus rapide ou des bugs intéressants ont été trouvés. Assurez-vous de configurer le SUT avant d'exécuter la commande fournie. Vous noterez que nous nous concentrons sur les configurations PSK lorsque possible. C'est parce que PSK avec de petits mots de passe nécessite beaucoup moins de temps de traitement que tout autre mécanisme de chiffrement.### OpenSSL 1.1.1b Toute configuration openssl-1.1.1b (par exemple 'args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl') peut être essayée. Les expériences se terminent rapidement (moins d'une journée), en exerçant tous les algorithmes d'échange de clés. Commande pour la configuration nécessitant un certificat client utilisant tous les algorithmes d'échange de clés (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
Note : lors de l'apprentissage d'OpenSSL, il est nécessaire de pointer la variable LD_LIBRARY_PATH vers le répertoire d'installation.
Toute configuration mbedtls-2.16.1 peut être utilisée pour les mêmes raisons qu'OpenSSL. Les expériences prennent plus de temps à terminer car le SUT est plus lent. Commande pour la configuration avec authentification par certificat client désactivée utilisant tous les algorithmes d'échange de clés :
> java -jar target/dtls-fuzzer.jar @args/mbedtls-2.16.1/learn_mbedtls_all_cert_none_rwalk_incl -queries 5000
Une version expurgée du modèle obtenu pour cette configuration figure en annexe. Nous pouvons utiliser une limite de tests faible de 2000 car l'alphabet d'entrée est petit, ce qui facilite les tests.
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk -queries 2000
Pour WolfSSL, nous fournissons une configuration PSK pour laquelle l'apprentissage devrait se terminer relativement rapidement.
> java -jar target/dtls-fuzzer.jar @args/wolfssl-4.0.0/learn_wolfssl-4.0.0_psk_rwalk -queries 2000
La version plus récente de GnuTLS que nous avons analysée a produit des modèles compacts et de qualité. Malheureusement, l'activation de l'authentification client a entraîné une forte augmentation du nombre de tests nécessaires. Nous suggérons une configuration qui la désactive pour raccourcir le temps d'apprentissage :
> java -jar target/dtls-fuzzer.jar @args/gnutls-3.6.7/learn_gnutls-3.6.7_all_cert_none_rwalk_incl -queries 2000
Une version expurgée du modèle obtenu pour cette configuration figure dans l'article. Le modèle révèle des bugs importants, mais l'expérience est longue. L'expérience ne doit pas être exécutée en parallèle avec des expériences n'impliquant pas Scandium ou JSSE. Commande :
> java -jar target/dtls-fuzzer.jar @args/scandium-2.0.0/learn_scandium-2.0.0_psk_rwalk -queries 2000
Une version expurgée du modèle obtenu pour cette configuration figure dans l'article. Le modèle révèle des bugs importants. L'expérience ne doit pas être exécutée en parallèle avec des expériences n'impliquant pas Scandium ou JSSE. Notez que l'apprentissage pour JSSE ne se termine/converge pas, produisant des hypothèses avec de plus en plus d'états. Nous avons donc configuré les expériences JSSE pour qu'elles se terminent automatiquement après un jour (deux jours dans l'article). Commande pour l'échange de clé RSA :
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl
Au lieu d'un apprentissage laborieux, nous pouvons simplement vouloir tester si une poignée de main peut être achevée dans ce paramètre sans envoyer aucun message de certificat. Cela peut être fait en exécutant :
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl -test examples/tests/rsa
Une fois l'apprentissage terminé, les éléments à analyser dans le répertoire de sortie sont :
Le modèle appris au format .dot peut être visualisé à l'aide de la bibliothèque graphviz, par conversion en .pdf :
> dot -Tpdf learnedModel.dot > learnedModel.pdf
Malheureusement, à mesure que les modèles grandissent, les .pdf générés par cette méthode deviennent de plus en plus difficiles à lire. Nous avons donc développé/utilisé/importé des scripts d'élagage accessibles via 'trim_model.sh'. Le script fournit des informations d'utilisation en exécutant :
> bash trim_model.sh
Nous conseillons d'utiliser le script dans sa forme la plus basique, à savoir :
> bash trim_model.sh learnedModel.dot
Le script :
(5) nécessite l'installation de la bibliothèque mypydot Python 3 personnalisée située dans 'experiments\scripts'. Toutes les autres étapes utilisent du 'sed' simple ainsi que la bibliothèque Java dot-trimmer. Un .jar pour cette bibliothèque est inclus dans 'experiments\scripts'.
Exécutez :
> java -jar target/dtls-fuzzer.jar -help
Le nombre d'options peut être écrasant. Pour apprendre une implémentation de serveur DTLS, il suffit de spécifier quelques options, à savoir : "-connect ip_address:port" qui est l'adresse d'écoute du serveur DTLS en cours d'exécution. Toutes les autres options sont définies sur des valeurs par défaut, y compris l'alphabet.
Pour lancer une exécution d'apprentissage pour un serveur local existant par exemple écoutant sur le port 20000, exécutez :
> java -jar target/dtls-fuzzer.jar -connect localhost:20000
Il y aura probablement des problèmes avec ce type d'apprentissage. L'apprentissage nécessite de pouvoir réinitialiser le serveur après chaque test. Certains serveurs conservent un état d'un test à l'autre. Cela peut entraîner du non-déterminisme pendant l'apprentissage, d'où une meilleure approche : lancer un nouveau thread serveur à chaque test en utilisant une commande fournie. Le thread serveur est tué une fois le test exécuté, garantissant une réinitialisation correcte. Exemple pour OpenSSL :
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -cmd "openssl s_server -accept 20000 -dtls1_2"
Avec autant de paramètres, les commandes peuvent devenir très longues. dtls-fuzzer utilise JCommander pour analyser les arguments, qui peut également lire les paramètres à partir d'un fichier. Allez dans 'experiments/args' pour des exemples d'arguments. Pour fournir un fichier d'arguments à dtls-fuzzer, préfixez-le par "@". Vous pouvez également ajouter d'autres arguments explicites aux commandes (qui écraseront ceux du fichier d'arguments)
> java -jar target/dtls-fuzzer.jar @arg_file ...paramètres écrasants...
Pour lancer un lot d'exécutions d'apprentissage, vous pouvez utiliser le script 'launcher.py' dans 'experiments/scripts'. Étant donné un répertoire contenant des fichiers d'arguments, l'outil lancera un processus d'apprentissage pour chaque fichier d'argument.
> python3 experiments/scripts/launcher.py --jar target/dtls-fuzzer.jar --args args_folder
Avant de lancer des expériences d'apprentissage, il est utile de vérifier que les arguments sont correctement définis, en particulier les paramètres de temporisation. À cette fin, dtls-fuzzer peut exécuter une suite de tests personnalisée (collection de tests) sur le SUT et fournir un résumé des sorties. Cette fonctionnalité peut également être utilisée lors du diagnostic d'expériences d'apprentissage ayant échoué, par exemple pour découvrir ce qui n'a pas fonctionné.
Pour exécuter la suite de tests sur un serveur en utilisant l'alphabet par défaut, vous pouvez exécuter :
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file
Pour des exemples de fichiers de test, allez dans 'examples/tests'. Un fichier de test comprend une liste d'entrées séparées par des sauts de ligne. Les tests sont séparés par des lignes vides. La fin de chaque test est soit la fin du fichier, soit une ligne vide. "#" est utilisé pour commenter une ligne.
Si vous disposez d'un modèle/spécification, vous pouvez également exécuter la suite de tests et comparer la sortie avec celle d'une spécification.
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -specification model
Le nombre de fois que les tests sont exécutés est configurable via le paramètre '-times', dont la valeur par défaut est 1. Le définir à une valeur élevée aide à détecter le non-déterminisme dans les configurations d'apprentissage, en comparant la sortie de chaque test.
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -times 10
Enfin, si vous disposez du fichier d'arguments pour une expérience d'apprentissage, vous pouvez les utiliser pour exécuter des tests sur le SUT impliqué en ajoutant simplement les arguments de test nécessaires :
> java -jar target/dtls-fuzzer.jar @learning_arg_file -test test_file