 So, welcome everyone to the next talk, and Huzefa will be giving you a talk about fuzzing and finding flaws in your code for free. So, floor is yours. Okay, so let's get this thing started. So welcome to my talk. My name is Huzefa Sitpurwala. My talk is on fuzzing. And in the next 30 minutes or 40 minutes, I would like to talk about the various experiences I have had with fuzzing in the last three or four years. How it can be helpful to you if you want to start doing that, and if we have some time at the end of the presentation, I'll see if you know if we can show a small demonstration as well. So, who am I and why am I here? As I mentioned, my name is Huzefa. I work as a principal product security engineer with Z Hat, product security team. I'm a member of various upstream security teams. So I'm a part of the upstream Mozilla team, PHP, Python, LibreOffice, OpenOffice, MariaDB, and a couple of more which I can't remember right now. I have been a Fedora contributor for the past eight to 10 years. I maintain packages. I did some infrastructure work some years back. I wrote some code as well. I'm a part-time security researcher. I found a lot of flaws with LibTIF. I found a few flaws with events, which is the most popular library or the most popular application to open PPDF files. I found a couple of flaws with LibXML. I found flaws with LibreOffice. Most of the flaws were found by using fuzzing. I speak at various conferences as well. I spoke at DevCon last year. I spoke at DevCon the year before that. I spoke about shell shock. I'm not sure how many people remember that. My talk was voted as the best talk at that time. And then last year, I think I spoke about Diffie Helm and Kiki Exchange. So I'm back. So what is basically fuzzing? Fuzzing basically is feeding random or semi-random mutations of data to your application and basically trying to figure out how your application reacts to that particular data. All applications need data as input. So whatever application you have, be it a web browser or be it a library or be it something else, all applications need data as input and they show some kind of an output. So when you try to mutate the data which you give to an application, then applications will behave in a very strange way. And some of that behavior can have security implications as well. So that's basically what fuzzing is. Most of the security flaws nowadays, and this is very, very interesting, most of the security flaws nowadays are found by fuzzing. So because I work for Red Hat products security, there are a lot of people, there are a lot of security researchers who mail us saying that they have found flaws in Lyftif. This guy has found a flaw in PHP or he has found a flaw in OpenSSL or something like that. And most of these people, they come and they tell us that these flaws have been found by using fuzzing. So fuzzing is gaining more and more ground nowadays. There are a lot of people who are using fuzzing for various things. So the last line which you see over here is the most simplest fuzzer which you can basically write. You pipe the output of there, you random into a particular service which is running on port numbers and you try to figure out what happens. This was probably one of the first fuzzers which was out there. Vulnerability finding is very, very interesting. And I have really some good stories about that. Security bugs, if you find a security bug in an application, you can get from anywhere from 500 US dollars to 1 million US dollars. And these are true stories. If you find a flaw in Mozilla, if you find a flaw in Firefox, then Mozilla will pay you around 3,000 USD. So Mozilla pays you 3,000 USD for finding a flaw in the browser. If you find a flaw in Google Chrome, then Google will pay you anything from 500 USD to 50,000 USD. And I have seen instances where people get 1 million USD as well. So if you have heard of a person called Pinkie Pie, so Pinkie Pie is not a ZZL person, it's a nickname. So Pinkie Pie found a lot of flaws with Google Chrome. And he made around 2 million USD in a year. So vulnerability finding is really, really big business out there. If you are a good bug hunter, then you can probably earn any ways between 180 to 200 to 250 USD an hour. It's that, that is the amount of money which you can make from it. A few companies can find good people. It is very, very difficult to find good security researchers. It is still more difficult to find people who can fuzz very well. So it's very, very difficult. People don't even realize that it's very difficult to find such people. Fuzzing is largely a black art. A lot of people still don't understand what fuzzing is. There are commercial fuzzers available out there. So if you have heard of Code Monicon. So Code Monicon has got a commercial fuzzers available which are extremely expensive. So they have a fuzzer which is 1,000 USD per protocol, right? So if you want to fuzz a particular protocol, so if you want to fuzz a FTP or HTTP or if some protocol you want to fuzz, then they have fuzzers which are 1,000 USD per protocol. So these are extremely expensive tools. A lot of people don't even know what fuzzing is or how it can be done. So why use fuzzing basically? So there are various methods in which you can test your code. There is a white box testing in which you know what the code is. You are able to understand. You need to know the nuances of a language, right? So if you want to do a white box testing and if your code is C or C++, you need to understand how pointers work. You need to understand how data types work. You need to know what data overflow is, what data underflow is, what are the implications of buffer overflow and stuff like that. So if you want to do a white box testing, then you need to understand the nuances of the language. You need to understand the flow of the program as well. So how many people have seen OpenSSL code? Extremely complicated, right? OpenSSL is extremely complicated. It's not only C, it's assembly. You need to have a PhD in mathematics. It is that complicated. So if you really want to do a white box test, if you want to audit OpenSSL code, then you better understand how C works. You better understand how assembly works. You better understand how the architecture works because OpenSSL has got a lot of architecture-dependent code. And in N, you better understand what Diffie-Hellman is. You need to know what primes are and all of these important things. So yeah. So if you really need to do white box testing on all of these code bases, then you really need to know what you are doing. Then there is black box test testing, which basically means that you have the binary with you. You really don't know how the binary works. You don't know what the source code is, how the binary was written, what are the various inputs which are required. And then in the end, there is gray box testing, which basically means that you have the binary with you and it is possible to do reverse engineering on the binary, convert binary into assembly language and try to understand how it works. So basically, fuzzing will work with each of these. So you can do fuzzing with white box testing. You can do with gray box. You can do with black box as well. And we will see a few examples as well. So basically, how does one get started? So I want to start fuzzing. How does one get started? Number one is identify an application, right? You normally want an application which takes a lot of user input. That is one thing. Second thing is you want an application which is very important. So if I have an operating system which is made up of 20 components or 25 different components, I want to take the one which is the most important to me right now. So I identify application. I identify the input, right? Because fuzzing basically is sending mutated data as input to the application. So I try to identify what are the various inputs my application will basically take. Then I identify the kind of data my application needs. So if I want to fuzz a web browser, then a web browser can accept HTML. It can accept JavaScript. It can accept image libraries. It can accept images. It can accept video input, right? So I basically try to understand what kind of input I want to provide to the application. Then I try to identify or write a fuzzer of my own. In this presentation, we'll try to see a couple of open source fuzzers which are out there. And we'll try to see which of them is the best. So we try to identify the fuzzer which we want to use with this particular application. And if the fuzzer is not available, we'll see if we want to write our own and fuzz. And then probably at the end of this, I find a few flaws. So let's say I want to fuzz HTML. I want to fuzz HTML. I want to fuzz Mozilla Firefox. Or I want to fuzz Internet Explorer or something like that. And I want to fuzz HTML. So the thing about HTML is that HTML though has a definite structure, most of the implementations are really, really flexible. So most of the websites out there, they use different kind of HTML. And you will never see your browser show you an error window saying unable to render because so and so tag was unavailable or something like that. So most of the browsers which are out there, they really implement HTML in a very flexible way. So something like that. Only one title should be there. If you write two titles in your HTML file, then your browser is not going to come complain. So this is basically how HTML is. So if I want to fuzz something like this, so what one needs to do is one needs to start with a good corpus of HTML files. So what fuzzing basically does is it takes your input file and it mutates the input file. Now how well your input file is mutated depends upon how well your input files are, right? So what you need to do is you need to get a good corpus of HTML files. And there is no, the net is full of HTML files, right? So you can download Internet HTML files from a lot of places. You create a good corpus of HTML files and then you use a fuzzer which will mutate the HTML file. So you have HTML file number one, you pass it to a fuzzer which will mutate the file and then you pass the mutated file to the browser and then you observe what happens, right? So step number one is get an HTML, you give it to the fuzzer which will mutate the file, pass it to the browser and see what happens and then if nothing happens, then step number two is mutate it more. So we keep on doing that in a loop, we keep on mutating the HTML files or we keep on changing the fuzzers till the browser will crash or something important happens. And if there's a crash, then it probably could be a security issue. Although modern browser fuzzing is much more than this. So there are people out there who have clusters who will fuzz browsers, right? So it's a combination, most of the browser fuzzers nowadays, they are a combination of HTML and JavaScript and everything which will, you know, move the DOM objects and stuff like that and that will probably cause the browser to crash. Now how does one find security flaws by using fuzzers? So when security researchers fuzz, they are basically looking at a crash, right? So when there's an application, when I give mutated data to an application and the application crashes, that's probably a security flaw. So when security researchers fuzz, they are looking to crash the application and what they are basically looking for is called memory violation. So they are looking for memory violation in which either there is a buffer over read or there's a buffer over write or there is some something like that. Now a crash is most probably a security issue. So when your application will crash, it's most likely a security issue, but applications will not crash all the time. So a very, very simple example is if you have, if you use C and you know, if you do a malloc, say malloc seven or something like that, then you know, because of all the padding issues and everything, when you do a malloc seven, malloc is going to return a buffer of say size eight or size 12 or something like that, right? So when there's an OB right of one byte, then your application is not going to crash. So in a lot of cases nowadays, due to either GCC optimizations or you know, because of the way the architecture is, you know, because of the way things are made in a lot of K cases, your application will not crash. So we use some something which is called ASAN. It is called address sanitizer. So address sanitizer is an application which was invented by Google, right? It's basically a compile time and it's a compiler and an architecture library. So what it basically does is, yeah. It's a memory detector for C and C++. So if you have used Walgrain or if you have used Electric Fence, so these are the most to mostly use, you know, software which we use out there, but there's a problem with Walgrain, there's a problem with Electric Fence as well. And I have a small demo right now which you know, probably I can show you. And which will actually show you that address sanitizer is much, much better. So even though if you don't want to fuzz, you know, if you're just looking at to find a memory leaks or you know, something in your application, then ASAN is a very, very good application. So how it basically works is it uses compiler instrumentation and there's a runtime module as well. It's called LibASAN. It's available in GCC 4.8. It works on most architectures. It works on x8664. It works on Darwin. It works on Android and FreeBSD as well. It uses ShadowMAM. So basically what happens is when you say malloc8, then it creates another area where it will store the malloc data and it tends to poison the data before and after that. So I have a small demo prepared and we'll see if it actually works. So I have a... So this is a basic C program which tries to do a malloc100. And it populates the first element of the array. Then it does a free and then it tries to do a use after free. So this is a very, very simple program. You do a malloc, you do a use, you do a free and then you do a use after free. Okay? So basically I have two versions of this. I have an ASAN-compiled version and I have a non-ASAN-compiled version. So in order to compile with ASAN, there is a flag in GCC called minus F-senitize equal to address, right? So something like GCC minus F-senitize, something like that. So what I've already done is I have two versions. There is a version called, there is a binary version called use after free and there's a version called use after free ASAN which shows that it's compiled with ASAN. And if you want to figure out which version is compiled with ASAN, you basically run strings on that. So if I do strings, use after free ASAN, GEP minus I, ASAN, it shows me that this version is compiled with ASAN, right? And if I do it on the version which is not compiled with ASAN, it doesn't show you anything, right? So now when I run use after free with the version which is not compiled with ASAN, so this is just plain GCC, right? And it's not compiled with ASAN, nothing happens. There's nothing which happens. Now if I run valgain on this, if I run valgain on this, valgain is very, very intelligent. It basically tells me that there's an invalid right of size one, right? Which means there's something wrong which has happened. Now if I run the ASAN version, if I run the ASAN version, it will explode, right? So if I actually want to see what happened, if you see on the top, I'm trying to run with less, okay? There's a heap use after free, right? So ASAN will basically explode. It will crash and it will tell you that there's a heap use after free. So this is very, very interesting. A lot of people use this program. Google uses it a lot. Mozilla uses it a lot. They are ASAN builds of Google Chromium which is available. So if you want to do some security testing on Google Chromium, Google makes ASAN builds available for people to download so that you can fuzz and you can run it on their ASAN builds and you can find out flaws. Mozilla also has got ASAN builds available. A long time back, there was some discussion about compiling an entire distribution with ASAN, right? So you know, compiled all the components which you have in ASAN and as soon as something crashes, you know that there's something wrong. So there was some talk of that. So now, the real fun fun is, the real fun is I have a pro-pro program which is a stack buffer overflow, right? So I create a card array 100 and then I try to write one byte outside the array, right? So very, very simple pro-program. I create an array of 100 and I try to write on the 100 and want location, right? And I have two versions as you, as always. I have the ASAN version and I have the non-ASAN version. If I run the non-ASAN version, if I run the non-ASAN version, then nothing happens. And if I try to run this through wall grind, but nothing happens, which is very, very interesting, right? When you try to, there is a stack buffer overflow by one byte, but wall grind is not able to figure out what the issue is. Now, if I run the ASAN build and if I let me clear my screen and yeah, let me run my, if I do all this and I think on top it should tell someone. Yeah, it's on the top, right? Yeah, I'd say it's stack buffer overflow. Yeah? Yeah. Yeah, yeah, yeah, yeah, right? So ASAN is very, very useful while wall grind is not able to figure out what a stack buffer overflow is. If there's a heap buffer overflow, then wall grind would probably try to show you there's a heap buffer overflow. But if there's a stack buffer overflow, then ASAN, then wall grind does not know what a stack buffer overflow is. So address sanitizer is a very, very important tool. It's useful not only in fuzzing, but if you want to test your code or even if you want to do something else, then it's useful as well. We'll quickly go back to the presentation. The same flags, flags were used to compile both. Yeah, the question is how I compile the application, right? Yeah, the same flags, flags were used to compile both the applications. That is minus G minus O zero. So I use the same flags to compile both the applications. The only difference is the ASAN version had minus F sanitize is equal to address, while the non-ASAN version, they did not have that. If you want, we could try to un-compile the application into assembly and try to figure out if the compiler actually removed that code or not. But I've tried to do that, and it seems that the compiler did not remove the code. OK, thank you. And there are more examples as well. So if you go to the code.google.addressSanitizer website, they have a lot of more examples as well. So what this application can really do? So we'll quickly try to go back to OK. So we have tried to figure out at least one part of what we want to do. We want to make sure that we compile the application with ASAN so that if there is a memory violation by even one byte, we will be able to figure out what or where the memory violation are. Now, the most important part which we still need to figure out is how do we actually fuzz. And there are various open source and free fuzzers which are there in the market a few years back. I think in 2015 or 2014, I started to fuzz. And I found around 12 CCCVs. And you can use one of these open source fuzzers which are available out there. And they are very easy to use. You can download them. You can compile them. You can make changes to them as well. So the first one which I want to discuss is called Fuzzadamsa. And this is a very, very general purpose fuzzer developed by OUPSG. And what you basically do is you pass some data as input. And it creates some data. There's a very, very simple example over here. So when I say, echo, hello, devcon, and pipe it to the application, it creates some kind of a random mutation. And each time I run this, the output is different. So there is a mathematical algorithm which it will use. And you can actually control what algorithm needs to be used, what kind of seed it needs to use. So all of the different parameters you can control over here. And it creates an output. And you can pass this output to the application which you want to fuzz. And this fuzzer was created by OUPSG. This is, I think, a university somewhere in US. I don't remember what the full form is. And there is a very interesting test case. So what these people did was they have a very small lab. So these guys had a small lab with one laptop or something like that. And they wrote this fuzzer called Zadamsa. And they found flaws with Mozilla Firefox. And they found flaws with Google Chromium. And they reported flaws. And both Mozilla as well as Google paid them a lot of cash. And they used that cash to buy more equipment for the lab. So they bought servers. They bought a few clusters. And so right now they have a very big lab. I think they have a 25 node cluster or something like that. And they kind of run distributed fuzzing. So this is a very useful fuzzer. It was one of the first open source fuzzers which was out there. It broke a lot of blah, blah, blah. If you go to the website, I think 45 CVs were assigned. So in the first year, they found 45 different flaws. It broke a lot of browsers. It broke image libraries. And it broke a lot of different, different open source applications out there. They even found flaws with Internet Explorer. They found flaws with WebKit. They found flaws with Apple products as well. So very, very, very, very easy to use. Then there's Zoff. Zoff is also a very, very powerful fuzzer which we have. You can control the amount of mutation you want to do. So if I say minus r0001, you can control how much of the data you want to be mutated. So you can control the mutation. You can control the seed. You can give a seed to it. And you can also control the various mathematical algorithms which the fuzzer will use. You can pass the application. So what the fuzzer will basically do is it will mutate the data. It will pass the mutated data to the application. It will observe what happens. Did the application crash? If the application crashes, it will store that mutated data somewhere for you to analyze and continue with the mutation. So unless and until you stop it, it will not stop. It will continue with mutation. And as many as crashes it gets, it will store that crash data somewhere. A lot of projects use Z, Z, Z, Zoff. So there are a lot of projects which integrate Zoff as a part of some kind of a test testing or something. I used to use Zoff a lot. In 2011, I found 1, 2, 3, 4. So I found four CCCVs. I think one of them is Macromedia Flash, if I remember. Then I found a couple of flaws with Liptiff as well. Liptiff was very, very easy. It took me around 10 minutes, which doesn't mean that I'm very intelligent. It means that Zoff is a very, very powerful mutator out there. So if you want, then there's Humphous. Humphous is also a very, very powerful security-oriented fuzzern. It is written by an ex-Google employee. He wrote it while he was working with Google. So now he's an ex-Google employee. Again, it's a continuous fuzzer. So it will keep on mutating the data. So you can run something like Humphous minus f. And then you can put all the test cases in a directory. So there's an input directory. You can put all the test cases over there. And it will try to mutate all the test cases one by one. And at the end of that, for example, if you want to fuzz Liptiff, Liptiff has a file called tiffinfo. So you can run something like this. You can put all the test cases in the input directory. And it will take the first test case. It will pass to tiffinfo, see what happened. And it will keep on doing that. I found one, two, three. So there are three security flaws which I found by using Humphous. I think one of these is LibreOffice. So I found a flaw with LibreOffice. And then one of these is OpenOffice. So the latest craze nowadays is called AFL. So if you have heard of American Fuzzy Lop. So this is a fuzzer which is created by Michael Zaleski. So Michael Zaleski is a Google employee. He works for the Google security team. It's a very, very interesting fuzzer. It's an instrumentation base for fuzzer, which basically means that you need to have the source code. And you need to compile the source code with AFL hooks. So what AFL basically does is it puts instrumentation hooks inside the source code. So when you run the fuzzer, what basically happens is that the fuzzer will modify the test case. The fuzzer will modify the test case in a way that all the different parts are being taken. So if your source code has got if a equal to, then do this. Or if b equal to do this, then what the fuzzer basically does is it will modify the test case in such a way that all the different parts are being taken, so that all parts of your source code can get tested. It broke a lot of software out there. It broke Google Chrome. It broke Mozilla. If you look at the web page, it explains a lot of CVE flaws which are found. I'm going to go a little bit fast because I want to show a small demo at the end. There are a lot of network. There are very few protocol fuzzers out there. So Hubert wrote a fuzzer called TLS for fuzzer. And there are a few, few more out there, but most of them are really proprietary. As I mentioned, there is a company called Code Nomican, I think it's a spelling mistake, which has got a lot of fuzzers, but you can buy them. They are extremely expensive. It's 1,000 USD per protocol which you want to fuzz. Not a lot of people can basically afford that. There are other fuzzers out there also. There is something called Peach, if you have heard of Peach. Peach is a semi-commercial software, which means that there is a free version which you can use. And if you want to use more features, then you need to buy. Peach is extremely expensive as well. You need to, when you fuzz, you basically need to make sure you automate your efforts. You basically make sure that your fuzzer will keep on fuzzing till it's able to find stuff. And last thing which I wanted to discuss before I conclude was Google has a new initiative called OSS Fuzz. So if you have not heard of OSS Fuzz, it's an initiative in which open source projects out there can use Google's infrastructure. So fuzzing basically means that you need to have a lot of machines and you need to have a lot of computing power, which not everyone has. So Google has got, I think, 50,000 node cluster or something like that. And if you are an author of a very popular open source software, like if you are an author of OpenSSL or Gagannu Taylor's or LipTIF or LipPng or something like that, you can go and you can talk with them. And what they will basically do is they will continuously fuzz these applications on their infrastructure. And if they find anything, they will report back to you. They will also write a patch. They will patch your application. And they will re-fuzz to make sure that all of these flaws have been fixed. So this is a really, really great thing which they have been doing. There are a lot of these projects which are involved. So there's LibreOffice. There's free type image libraries, OpenSSL. I think NSS. I'm not sure about NSS. Gagannu Taylor. So all of these these softwares, they are trying to use the OSS Fuzz infrastructure. And I think if I have some time, I want to show a small demo of AFL. So I have something prepared and you know. So I'm trying to fuzz Libxml over here, right? So I'm trying to fuzz Libxml over here, which is the most popular XML library out there. And what I basically do is, yeah, I have a directly called test case directly, which has got just one XML file, right? What you would normally do is you would try to search for XML files on the internet. And you know, you try to store, you try to get as many XML files as you can. So we put all of those XML files into this test case directly. And I'm going to run AFL on this. And yeah, so what one needs to do is, one needs to recompile Libxml. So I download the source code. I recompile Libxml with the instrumentation hooks which comes with AFL, right? And once that is done, I run the fuzzer. I tell the fuzzer that all my test cases are in this directory. And the output, all the crashes which it will find, it needs to store in the fuzzly findings directly. And I'm using the XML link. XML link is an application which comes with Libxml, right? So I'm using XML link. So when I run this, it sets up a few things and then it will show you a nice screen, right? So this is what it basically does. And these are a different type of fuzzing which it can do. It can do a bit flip. It can do a byte flip. It can do arithmetic. It can do a heuristic base fuzzing as well. So all of the different kind of stuff it can do. It shows me how much time it's been fuzzing. How many crashes it found, right? So if you look at the top right one, it says unique crashes. So when it finds a crash, it will store, it will take the crash application and it will store it in a directory. And I can actually go and I can see what the crash is basically is. It will also tell me if there's a hang, right? So if my application hangs because of, you know, it's using too much RAM or if it's using too much CCPU, it will also tell me how many times it will hang. And this will keep on going till I stop it, right? So it will try different, different combinations. It will keep on going for days and weeks till I'm able to actually stop it. Google does this on a very large scale, right? So as I mentioned, they have a fuzzing cluster internally. Your AFL can basically spread fuzzing to different machines as well. So if I have a fuzzing cluster, I can have a node which will basically, you know, which will say that, you know, I want to do first one on this machine, first two on this machine, first three on this machine. And at the end of that, you know, all of these machines will report back to the controlling node. And, you know, it will tell how many crashes it found or, you know, what issues were basically found. So this is what Google does at a very, very large scale, right? And this is very, very easy to set up as well. So, you know, if you have an, if you are working on some open source software, you know, if you have a project or something and if you want to fuzz, then AFL is really, really easy to set up. And you can try to integrate it with your testing as well, right? So I'm going to stop this. And it didn't find anything yet. So I don't think I have anything else. Any questions? Yeah. It can, can, it can, can, can, yeah. Yeah. Yeah. Yeah. So, so, so the question is, can fuzzing be used to poison the cache? Like, you know, if you have a Firefox cache or something like that, can fuzzing be used? So long, long time back I, so wire, wire shock, I believe wire shock has got some kind of a cache as well. So long, long time back when I started to fuzz, I, I, I used the wrong, wrong switch on, on Z, Z, Z off. And instead of trying to, you know, fuzz the input file, it went and it fuzz the cache, right? So I'm, I'm sure you can, but then I'm not sure what is the format of the cache. So when you fuzz a lot of these, you know, special files, like, you know, if you try to fuzz live PNG. So, so the thing with PNG files is that, you know, this PNG files have tags. And what, what, what basically happens is at the end of the tag, there is a check, a check, a checksum. So the PNG file is made up of, you know, tag number one, there's a check, a check, a checksum. Then tag number two checksum, tag number three checks, checksum. So basically when you fuzz the PNG file, you always, almost will, you will always mess up the checksum, right? So you need to be very, very careful when, when, when you try to fuzz, fuzz, fuzz these things. Any more questions? Yes? So is this, I mean, in the KPIs or, or web services? You can, there, yeah. So, so the question is, can I use fuzzing to find security flaws in web services, right? There are a lot of fuzzers out there which are used to fuzz web, web source services. I think there is a JSON fuzzer, then there is a JBoss based fuzzer as well. There is a Java fuzzer as well. So there are a lot of fuzzers out there which can fuzz these kinds of services. There is a, there's a kernel fuzzer as well. So I don't remember the name right now, but there's a guy who wrote a fuzzer which will pass first day data to CCCTT or something like that. Sorry? Trinity? Yes, Trinity, yes, yes, Trinity. Yes? So as soon as part of the problem with fuzzing is to, you know, you can get to a state where you don't know exactly how you do that. So is there any integration with fuzz like RR for, you know, replay of the time that led you to the crash after that? Right, so basically your question is that, you know, are we able to reproduce the crash? Okay, most of the fuzzers like, you know, Z-ZARF or Hong-Fuz or stuff like that, they have an option in which, you know, when there's a crash, either the fuzzer will stop and, you know, it will give you the output, the file which crashed, right? Or, you know, it won't stop, but, you know, it will, whatever file crashed your application, it will probably, you know, move it somewhere else and it will store it in some directory where you can, later you can go on and you can, you know, try to figure out what caused the crash. So that's most of the things which these fuzzers can do. But there is no integration yet, right? There is no integration with other tools. Okay. So basically you would think, not to discuss that you keep doing, but if it crashes, then, you know, you can approach exactly the same steps you had as the single step and then go on and on and on. Yeah. Yes? I did not get your question. Can you execute the problem over time? Yeah, most, some of these are, yeah, the question is that without, without needing to call an external executable, could you fuzz a library for function, right? Yeah, like a library call. Library call instead of fuzzing. Make it something that you... Kind of a little bit difficult because if you need to do something like that, then you need to, these fuzzers will need to have an API or something like that, right? You need to, the fuzzers, so there is something called libfuzzer. There's an application called libfuzzer, which basically, what it basically does is it will tie the application with the fuzzer. So instead of writing an application which will, you know, which you actually pass the data to, you can use the libfuzzer library. And what the libfuzzer library does is you can compile libfuzzer with the application or with the library which you want to fuzz. And libfuzzer on one side, it will call the application which you want to fuzz. And on the second side, it will actually call the fuzzer which passes the mutated data. That's better. Yeah. Yeah. Makes sense. Yes, yes. Thank you. Yes, yes, yes. Also... Yeah. Yes? Wouldn't it be possible to use Asana to build applications that are resilient against memory safety-based execution exploits? Okay, the question is, would it be possible to use Asana to build applications which are resistant to memory violations? Yes. Is that the question? The problem with Asana is that it's an overhead to use Asana, right? Because for each malloc which you do, it does malloc twice. So for each malloc, for each memory, each memory byte, your application would use, it's using actually twice the amount of memory byte. So Asana in production is an overhead. So at least there is a performance hit by 20 to 25 per percent. So that's why it's not really advisable to use Asana-compiled application in real life. If you want to test, then it's a very, very good thing. But if you try to launch a browser which is compiled with Asana, it's going to take a lot of time to start and it's going to take a lot of time to run. Any more questions? Yes or no? Okay, thank you. Really nice talk. Thank you. A lot of interesting information. Yeah. Don't start fuzzing like today. Ha ha ha. I'm a liner, I'm a little unfettered. Yeah, and I could, oh, oh, oh, oh, oh. Sorry, I read that. Nirenjan does the packaging. Ha ha ha. I forgot actually. The thing is, I wanted to make a lot of changes to the presentation. But in the last minute, I don't know that, I don't know, slide out totally for forgot. So at the end, when I was sitting outside, I was trying to figure out if everything is okay, and then I figured out why this is missing. Nirenjan's with false positives, like, detections from the Asana, I mean, compared to Valgra, my brain, who brings up, because I don't know, we had like, a lot of false positives in Valgra, but kind of decreases the usability of such a tool. Okay, so I have been using Asana for around two and a half years now. I've not found, I've found very few false positives. And most of the time, the issue is that, either Asana will crash, because it's not able to handle something, or because you need at least 20% more RAM with Asana. So because you're trying to do a huge malloc, your Asana will basically hang or it will crash. So I have not seen a lot of false positives, but most of the things which I have seen is either, you know, Asana is not able to handle something, or it will crash, or it will hang. It's extremely good, you should. Yeah, yes. One, one, one, one, one, one, one, one, one, one, one. Sure. So this is the video, right? Yeah. Okay, four, each team, one. Well, yeah. Any important questions, one, two, three, two, three, two, three, two, three, two, three, two, three, two, there. Okay. So I'm actually bringing somebody else's picture. Yeah, sure. So we have a microphone, we have a microphone that's there. And then you have. Perfect. How much can you hold like really close? Really close. Ah, we can slide here. Oh, okay. Pull, I'll be. Okay. Nice turn for a walk, like yesterday or the day before I came here. So it was nice. Really cool. Kind of cold. It's good, you can keep this on pass. Okay, so there is a microphone. Yeah, I'll take the handphone. The power of the handphone. Do I need to do anything, or I'll put that in? You can use it. So sorry, 15 minutes for talking? Yeah. Okay. So when it will be like 35, I will show you like, okay, you have 10 minutes left, and then so you have like the extra time for the questions. You can handle it. Please. Yo, yo, test, test, test, test. Then you come back and everything is on fire. And now I just came today. But I was here last year. So I'm really happy about that. So you work here? Yes. But this weather is kind of like warm for your nose. Yeah, this is all I have. I don't have a jacket. And it's like, this is a really cold weather for a year. Yeah, somebody was saying that you can use it again. Here we have like snow through the whole of January. It's like minus 15 in the night. So it's like everybody is like, oh my God, oh my God, what's happening? And it was supposed to be sunny today. And it was snowing. And they're like, what? Are you planning to go to the party in the evening? Yes, I don't know where it is though. It's not part of from here. It actually just like you stopped from the tram. Like three or four stops to the north. So back to the city center. Where are you staying? The hotel. I have no idea. We're staying at Rendezza. Rendezza. It's in the city center. Because you have a place to sleep. And it's warm. It's fine. And how long are you staying here, guys? I leave it 2 a.m. Yes, it's about 8 p.m. Which office? We have three already. And we have a fourth one in April.