 C'est pour passer par l'authentification. Vous pouvez utiliser la fusée pour tester la stabilité de l'offre, mais aussi la sécurité et la création des softwares. Tout ce que vous avez fait dans le point de vue de l'offre, donc votre goal est vraiment de cacher le programme. Si vous voulez cacher, vous faites ce que vous voulez. Et l'avantage de la fusée dans la compréhension de statistiques ou dynamiques, c'est que la fusée est vraiment, vraiment simple, ce qui signifie que dans 4 heures, vous pouvez mettre la fusée et trouver la première bague. C'est très rapide, parce que la plus rapide, c'est de trouver la bague dans 1 minute ou peut-être 1 heure, c'est très très rapide. Si vous comparez avec les analyses statistiques, ça peut prendre beaucoup d'heures. C'est aussi efficace, parce que vous êtes sûrs que vous pouvez cacher le programme. Parce que si vous readez le code source et que vous trouvez un code étrange, c'est peut-être possible de cacher, mais vous n'êtes pas sûrs et que vous ne savez pas exactement comment cacher. Si vous utilisez, vous avez déjà des données pour cacher le programme. La fusée peut être utilisée sur le software libre. Vous considérez le target comme un black box. Vous envoyez des données et vous arrachez la réaction, mais vous n'avez pas besoin de lire le code source. Donc, c'est possible de tester le code source, comme Microsoft. La fusée est mon programme, mon projet. C'est un library Python, avec beaucoup de tools pour créer un processus, pour regarder les outils standard, pour regarder les logs, pour regarder l'usage de la mémoire, pour regarder l'usage de la CPU, mais il y a aussi 20 outils. Un outil est très spécifique à un target, comme GIMP, Clamavé et Antiriris. Il y a beaucoup d'outils différents. Avec la fusée, j'ai déjà trouvé des bugs dans beaucoup de software comme Clamavé, GIMP, GnuLipsy, mais aussi Python. La fusée est la main-target, c'est un programme command-line en Linux, mais vous pouvez aussi tester un network-server, vous pouvez tester Firefox, qui est une application graphique. Les différents input-vectors, c'est le command-line, les files, les variables, les sockets de TCP, les sockets de UDP, etc. Et les proches, pour regarder la réaction de la software, pour regarder si la software est encore en train, si ça prend beaucoup de mémoire, etc. Il y a des outils standard, les logs, les statuts de processus, ce qui signifie qu'un code de processus est tué par un signal. Et le networking est utilisé sur les services remotes, pour tester si la software est encore en train. Il y a aussi un debugger intégré, qui s'appelle pitton-projectress. La fusée, je utilise les systèmes approcs, qui signifient que chaque probe a un score, et vous faites les summes de toutes les probes, et vous avez le droit de l'approche, pour dire que si vous avez beaucoup de points positifs, vous pouvez utiliser un score plus bas, pour l'approche. Un score de minus 1, ou minus 10% est input réjecté, 0 n'est rien spécial, et le plus haut score signifie simplement un crash. Dans la fusée, nous utilisons tous les types de la génération de données. La première technique la plus facile est de générer une pure rondeur, comme l'exemple avec Netcat. Mais cette technique fonctionne seulement sur un software avec aucun QA, sans sécurité, qui signifie aussi qu'il n'y a pas d'utilisateurs. Nous préférons, en fusée, des données validées. Vous pouvez prendre une picture de GPEG, un film, un file, et vous réplacez quelques bits, vous invertez des bits, etc. Vous pouvez aussi tronquer le file. Cette technique est très efficace parce que tous les joueurs de la vidéo ont un crash. C'est aussi la technique la plus facile et la deuxième technique est de générer des données en utilisant un modèle, c'est-à-dire que vous readez la spécification d'un format, comme un format PNG, et vous générez des données validées, respectant la spécification. D'autres tests vont plus loin dans le programme parce qu'il vous plait les premiers tests dont le programme n'est pas valid. Mais le problème avec ce modèle est que vous avez besoin de la spécification. Un exemple de la première c'est le Python. La première étape est de liste tous les modèles Python. La deuxième étape est de liste toutes les fonctions. Et ensuite, vous faites un function call avec des arguments. C'est très stupide, mais ça marche très bien. Un exemple d'exemple d'exemple d'exemple dans la fusée, c'est le Clamavi Antiris qui a déjà été formé dans un bug critique. Le bug était dans un document de Microsoft avec un seul file de 10 kilobytes que vous pouvez cracher. Il y a aussi le Firefox d'exemple, c'est-à-dire que vous pouvez tester un contenu d'exemple. Donc une photo, une vidéo, un file d'exemple, tout ce que vous voulez. Il y a aussi beaucoup d'audio-video-players, comme gestream et des joueurs sur VLC. Une image banjique qui est une librairie pour convertir des types de photos d'un format à un autre, mais aussi pour modifier une librairie comme GetText. GetText est une librairie pour transler l'anglais en anglais. Et j'aime cette librairie parce que ça marche très vite et il crache toujours le programme. Il y a aussi Poplar. Poplar est une librairie pour displays votre GPAC, excuse-moi, PDF documents. C'est utilisé par Evans et finalement, il y a aussi printf. The printf generates random calls to printf, but with valid data and valid format stream. So it's a test to make sure that the printf works correctly. And finally, there is a further specific to one programming language like the Python one, but also further for PHP. With the Python further I found something like 10 bugs or maybe 100 bugs there are a lot of bugs in Python. And the algorithm is like I said, a random function call with random arguments. An example of fuzzy. So you just type the name of the further it generates a lot of function calls. Here I test Python 252. It test each each time it test a different module. And here we have a crash on a local module which is a invalid memory read from a new address. By default, the further stop at the first crash. So in six seconds it's already found bugs in Python. And when we have a crash the fuzzy stores all data in the directory. Here it's a directory Python-2. We have the project log which are all logs of the project. And a sub directory for each crash. In the directory name you have already the information about the crash. So first the module name underscore local but also the type of the crash invalid read from a new address. In the directory you have Python-5. We play the script to replay the session session.log is all logs from this crash, this specific crash. STDO is a standard boot etc. Here you have session.log It repeats the same information so invalid memory read. And you have also the score of 282%. You can replay the crash with replay.py The same crash with getText. It's very important to replay the crash because you need for example to run it in a debugger. If you add a dash dash gdb you are able to replay the crash in a gdb. And here you can generate more information for example the backtrace you can also read the assembler code you can type register etc. So here it's a valid read with the error x register which is new. And you have also the backtrace using where. So here you have a bug in the local module. We have some information missing because you need to recompry the program with debug symbols. Here it's the generated script to test the local modules. So they are only a random function call. For example here the local code with integrals. Then with a new cut string. Then with bolia etc. And we test all functions from the module with different arguments to make sure that python doesn't crash. When you have a crash, then there is a most important point to analyze the crash. So for the quitticity of an error the denial service is the most typical type of error. Which means that the program crash or the server stops to answer to the client. To measure the quitticity of a quitter like losting data you are working in a very important file and if the program crash you lost all your work. Permanent error means that every time you can if you quit and restart the program the error is permanent. And then the difficulty to reproduce the error which means that for example you have to set a specific variable of environment. You need a specific language you need a specific file so it depends on the error. And the second question is it a bug or a vulnerability? Vulnerability means that you can steal data so read anywhere in the memory or read anywhere in the file system or modify files so write for example you can interface a website or the most interesting point is to inject code so you can execute your own code. When I send bugs to the editors there are three different type of answers. The first answer is that we don't care. For example, the get text author just tell me that you want performances, you want get text to be very very fast you don't care to security. The second type of error is to apply patches. So the editor just take my specific crash and fix it but he doesn't try to test if there is a similar error. And the last type of answer is editor interested to test fuzzy or to test similar tools to test software quality and in my point of view it reflects project quality because if the project reject patch or don't care it means that the program may crash or has a lower quality. Some ideas to generate new faults that are not implemented yet in fuzzy we can use a fail memo lock it generates error in memo reallocation of to use a dev full. It's a specific device, you can read some data from this device but after 10 bytes it generates an error. Another idea is to the time jumps which means that you can change the system clock and it doesn't crash. You can also send signals process signals like seek user seek term seek fault or something like that. And also network fuzzers because fuzzy most fuzzy fuzzers are specific to program using files like gimp, flamavir etc It's very interesting to test network clients or test network servers. There are different further library explain later which are specific to network. Another idea for new probs. The probs for example code coverage can be very useful to make sure that we go deeper and deeper into the program because you must further only test the first phase of the how can I say that and only make sure that your file validity is correct or not. With code coverage you can make sure that you are deeper in the program. So for code coverage you can use JCOV or Dynamo Rio using Valgrind or Purify. Because sometimes the program doesn't crash but if you replay the same session it will crash because of some memory bugs. Fuzzy is only one library but there are a lot of other free software fuzzers like Sully, Pish and EFS which are the three most important libraries. But there is also Bunny, Flyer, Scapi Flyer is the most interesting because it uses Valgrind to make sure that you don't have some strange memory errors but it also use Valgrind for the code coverage. Last year Samozva presented Zuf and there is also Spy Compratus which are free software fuzzers. So we are using Fuzzy instead of another fuzzer. The first idea is that Fuzzy is my program so it's the best. But also that Fuzzy is very good to run it in a world night and collects data and it doesn't need human interaction because you can ask to stop after one crash and you can also ask to crash after 1000 bugs or more and it only keeps the success files which means the crash files related to a crash so if the session is not interesting the files are just deleted there is also a replay script so you can make sure that the program is still a crash or you can replay it in a vall grind and there is and Fuzzy generates crash information like in the demo you have the module name you have the type of the area you have also the environment variables you have a lot of information about the crash which is very important to detect duplicate crashes and safety because Fuzzy Fuzzy is running in a different user it is running under the Fuzzy user not your own user or a root user it is very dangerous to run further in a computer because it can delete any file on your computer it can kill any process it can write very stupid data in your file so it is very important to use a different user there is other protection like memory protection the fuzzing process is limited to 10 megabytes or a little bit more there is also protection about time which means that if the process is running more than 60 seconds it's stopped so to conclude Fuzzy is a distributor under the GNU JPL license it's running on Linux but you can also use on any POSIX compliant OS like FreeBSD but also macOS or you can also try to run it on Windows but there is no tool to test a graphical application there is no tool to catch message boxes so you may try other fuzzer like Fuzzy Fuzzy is written for Python 2.5 and you have the URL below so do you have any question yes yes the coverage of the program yes the question is how can I know that I tested all all specification of the file format for example if I test GPEG files there are a lot of different chunks the answer is that I don't know you have to it depends of the method if you inject faults in valid data you will only test this specific file so you have to use 10 files or more to test different type of chunks of file chunks and if you generate data using a model you have to implement the word format so you know that each type of chunks is tested yes the question is most typical cause of crash the cause is always the same you have to validate inputs it's very common on a web application you have to validate each field in the form the same in any program you have to make sure that the image size is between 10 or 20 but not 1 million or 4 million yes you have to validate inputs about the performances it's not true because you can add some checks it's very cheap to test that a field is uncertain interval so it doesn't impact the performances another code of crash it's simply bugs in program for example you allocate memory but you don't check that memory is very allocated yes the question is did I test to test fuzzy on fuzzy the answer is no I don't plan to test fuzzy because I know that there are bugs in fuzzy but I don't but I don't want to test my own fuzzy my goal is to test software like games or other programs another question I tried but I don't found bugs yet but there are different fuzzy like CisFuse which do random system calls but you have to generate a random system call it doesn't work you have to write the same structure because if the system call invalid arguments the inputs are just rejected but yes there are further for the Linux kernel but also for Windows kernel it's very interesting to test the kernel if you find a bug in the kernel you are more the root user you can do anything you want yes excuse me I tested Firefox but the interaction is very low because I run Firefox with an URL and then I just send a special key the F5 to refresh the page but testing graphical application is a little bit more complex because you have to script the action but most of the time you don't need to test a graphical application because for example for example to test KPDF or evens you don't need to test the graphical application I use the PDF2Text which is a command life program and if I found a bug PDF2Text I'm sure that evens on KPDF will also crash and for example for the Gimp I didn't test the graphical application because there is a command line it's possible to script Gimp with a command line and it's similar for most applications on Linux you can use a command line to test the program any other question the question is about the CPU usage I don't know it's usually high but it depends on the program for example if a program takes 10 seconds to open the file sometimes the CPU usage is very low but if you find a denial of service a really a crash the CPU usage can be 100% other question ok the future of the future here are some ideas to find more bugs I'm very interested in network further because it's a little bit more funny to test a program in a remote position there are a lot of ideas you can do anything you want without further the ideas to find new ways to test a program for example if you test image magic or firefox you can test the GPEG file format it's very interesting because it's already done by other people the idea is to test a rare format like svg or some video file format so I don't have a static plan for the future but there are a lot of ideas to go further other question yes why did I watch Fuzi I'm an hacker I like programming and it was easier for me to write a further with my own code because for other frameworks you have to learn how to write a further and also main further main further of this list are targets windows on graphical application or network application but I prefer linux command line programs each further has a typical target like Fuzi Windows target closed source programs Protoss is more network programs and Fuzi is more for linux command line programs yes easier question about Ashwa yes I wrote the question is is it a relation between Fuzi and Ashwa I wrote Ashwa it's a generic library to parse file format I used Ashwa to test rpm rpm program I compute the checksum in each rpm you have to check them as a different position so I use already Ashwa to test Fuzi other question yes the question is is it easy to write a new further for me it takes one hour to write a new further but most of the time the further is very easy to implement but then you have to analyze the crash on this typical point analyze crash takes more time writing a further depends of the interaction for example for Gimp you have to write a script for Klamavé you have to generate files on one specific program which is very easy so it depends of the target and how you run the program but usually it takes less than one day to write a new further it's very fast but the problem today is that nobody cares about security other question so thank you