 So I'm going to, oh, we have guests waiting already. Let's wait for Dheeraj to get here and then I will transfer ownership. And I just put it on YouTube. Right now it's unlisted, but as soon as we're almost ready to go, I will move it to listed and publicize it. In the meantime, I'll just fill with settings. Okay. One minute, are we not supposed to be streaming? Maybe we're all supposed to be streaming to YouTube. I think that for this workshop, it was on streaming on the logistic sheet. Yeah, that's right. That's exactly what I'm checking right now. But I think that you go ahead. Let me just check with him. Hello. Hello. Hello. Hi Dheeraj. Hi. How are you? Doing well, how are you? Good, good, thanks. Simple me. Hi. So I just made Jean-Yves the host and you should be co-host Dheeraj and I will pretty much leave you to it. So I just wanted to let you know I did connect to the YouTube live stream. So assuming that's still okay with you, we'll publish it in basically in about 10 minutes. Right now it's unlisted and we haven't posted anywhere. No problem, yeah, we'll do that, okay. All right, perfect. Then I will leave you guys to it and it looks like there's already people in the waiting room so you can let them in when you want. I hope it goes great, have fun. Thank you. Thank you so much for running the workshop and Jean-Yves, thanks so much for helping out. No problem, thank you. Have a good one. Hello Dheeraj. So I'm Jean-Yves and I will do my best like to make this workshop go well. No problem, yep, yep. Just quick one, I have shared my screen. Can you see it? Yes, I can see it. Yeah, is this part? Yes, I see the presentation. Yes, also. Okay, that's perfect, then that's perfect. Okay. And do we have like the course, we have like the right to create the breakout rooms? Like the 15, 10 minutes break, is it? You say? Are you talking about breaks? No, no, you know, with Zoom you can create like some special rooms like breakout room to put like people there so everyone will be remain on the main room. Also everyone would be on the same room to the best of what I understand, yeah, yeah. No, it's just that if at point you want like to separate people in different like smaller room you can create that with the breakout rooms and if you don't have like the right for that and at the point you want to do that, I can do that. Fair enough, yeah, makes sense. Because I think that may, I'm not sure how many people will actually join but it could be based on the list a lot so it could be interesting like to put them on the change room. Oh, okay, okay, we'll see that, yeah. Okay. And when do you want me to accept people? We can do it maybe in a couple of two to four minutes now. Okay, okay, yeah, yeah. Okay, I'll start admitting people. It is okay for you? Yeah, that's fine, yep, yep. Okay. Hello, hello. Am I audible? Yes, I can hear you. Yes, Dilec. Okay, perfect, thanks. Let me just share my screen. Okay, so hi everyone. I hope you guys are well and safe wherever you are and thanks for having me. Thank you very much for this and welcome to Nordsec 2021. This is Introduction to Fuzzing. If you really don't know about what fuzzing is specific to how we fuzz open source software in Linux operating system, then you are at the right place. Decoming two to three hours is all yours. Sit back, relax. Please feel free to ask questions that would be really awesome. So welcome again. This is Introduction to Fuzzing at Nordsec 2021. So we will start. Before we get started, this is a little bit about myself. My name is Dheeraj Misra. I work as a threat assessment specialist for a company based out in Dubai. And I have been contributing to open source projects from past one, one and a half years now. Start from AFL, AFL++, Metasploit, Nmap and so on and so forth. So at my free time, I write blogs on input zero.io and tweet at random Dheeraj. So if in case you have any queries regarding to fuzzing, you can buzz me on my email or on the Twitter itself. I'm happy to collab and learn with you guys at the same time. So this is a little bit about myself. So before we get started, so I have been doing fuzzing for almost two and a half years now. Okay, so before we get started, I hope you guys are running the local VM which I have shared on the Discord channel itself. So if not just buzz me on the Discord channel, I'll be helping you out if in case you have any issues when you spin up the VMs because that VM is very much required to get through this entire workshop. And also I'll be really, really happy if this workshop goes in a TCP based mechanism where I say something and you answer me back on the Discord channel or maybe in the Zoom chat. I really don't want this to be UDP session where I just keep on saying. So yeah, that was two things. So coming back to the slide, I have been fuzzing for almost two and a half years. Now start from open source software to closed source. I have recently started with Windows fuzzing as well. So the one success mantra which I have learned so far is fuzzing requires a lot of patience basically. So because after this session or this workshop maybe when you go back to your desk and you start fuzzing with any open source repository from GitHub or GitLab, there are certain things or there are certain big projects where you won't be getting crashes for maybe a month, two month or three month. There are certain projects or open source projects being maintained that maybe depends upon what techniques you are using. You can get crashes very quickly. But the key idea over here is fuzzing requires a lot of patience. So if you start fuzzing with any open source software post this workshop, it doesn't matter whether it's a PHP, it's a huge code complex or whether it's a very small library image, library utilize somewhere. Press me, it requires a lot of patience. So once when your fuzzing framework has been spanned up just let it run for its own sweet time until unless it doesn't cover the entire cycle. So what is cycle technically we are going to look at it in our coming slide. So the key idea to showcase this slide is fuzzing requires a lot of patience. So if you fuzz any software just let it run for a month or so until unless you don't discover any crash. If you get crash then you have to go ahead and try it. That's fair. Moving forward, most of the people come back to me asking what would be the system requirement for fuzzing? Trust me, we need to have a lot more. So Google runs a program called OSS Fuzz and they are running most of the commonly used open source software on thousands of cores basically. So you need a lot more when it comes to fuzzing. The more, the better. But technically for this workshop a minimum would be 40 gigs of RAM where we have 40 GB of hard disk with any Debian based OS. The system requirement which you see in this presentation is what I have been shared with you guys. I hope you have spanned it up on your virtual box or VMware, whatever you are using. So also just make sure when you fuzz you don't fuzz it on your base or host machine because fuzzing does a lot of input-output jobs and that might hinder your actual day-to-day programs which you are running. So whenever you are performing any fuzzing make sure that you have a dedicated server on the cloud or you are doing it on a virtual box basically. So this is something about the system requirement. Moving ahead. The hosted VM, the local copy VM which I have shared the username is zero with the password called party P-A-R-T-Y. If you can just navigate to your virtual box or to your Ubuntu OS it should work if you hit party. So I hope you guys are able to log in. So I see on the Discord that Eric forgot to download that's fair enough because the coming 15 to 20 minutes maybe it's more of understanding the fuzzing fundamentals. Meanwhile you can download if you have forget to download the Ubuntu OS meanwhile you can just start downloading it. It shouldn't take more than 30 to 40 minutes maybe. So if you have it already spinning up locally the username is zero with the password called party P-A-R-T-Y feel free to change password if you want. So what's the agenda? The agenda is pretty much straightforward not to get bored. I'll make sure that you guys are not bored and we do a lot of fuzzing activities. And the last but not least feel free to ask questions. The more the better. So we have Discord. I may be not able to answer very much directly because I have to toggle between the presentation and the Discord, but for sure I will do it. So that's the clear cut agenda for this workshop. The coming two to and a half or three hours is all yours. We'll be fuzzing most of the commonly used software start from GNU library such as Benutils. Then depending upon the time we can start fuzzing TCP dump as well. So this is what the overall agenda looks like pretty much straightforward. Let's not get bored. And remember the key aspect that let's make this workshop more of a TCP based workshop where both the parties acknowledge at the same time. Perfect. So before we get started why fuzzing basically, right? Why we are here? Why the fuzzing term itself is here? So if you remember back in 2014 there was this vulnerability called Heartbleed. So Heartbleed was nothing just a heat based server for workflow on the one of the SSL library. So what happened is fuzzing can find certain bugs which has a huge attack surface basically. So Heartbleed was having a very huge attack surface in those days basically. So the modern software have a huge code base and manually going them to perform a code audit is very much a tedious task, but fuzzing is something which can makes the entire thing automated and at least help you to find out bugs which are not being detected in a manual code review, right? So that's where fuzzing is very important. And the idea to showcase this slide is fuzzing can lead to certain bugs which can have a huge attack surface. Like if you first PHP, there are certain libraries or certain functions in PHP that can have a very huge attack vector, right? There are many other operating, not operating, but open source applications such as VIM, we have code and so on and so forth. It comes by default in most of the Debian operating systems, right? So if you target a very proper, if you have a proper target and you fuzz it in a certain way, you trigger a crash and that crash is exploitable, then you have a very huge attack surface. That's why fuzzing is very important and people are started, not started, basically people were doing fuzzing from the past and that can lead to bugs such as hard bleed, right? So without further delay, let's get started with AFL. So AFL is known as American Fuzzy Lope developed by Michael. This is a mutation-based or input-based fuzzer. It is also known for coverage-guided fuzzer. It's one of the common coverage-guided fuzzer basically. When it was being developed back in 2012 or 13, if I guess on 2012, if I'm not wrong, it was known as Bunny the Fuzzer. Then Michael went ahead and changed the name as American Fuzzy Lope, I'm not sure why, but this framework is one of the common framework utilized for input-based fuzzers. So when I say input-based fuzzing, that means let's suppose you have an application A and it accepts an input I and once when it executes I, it generates the output O, right? So let's try to imagine in this way, like A plus I is equal to O, right? So application accepts an input and generates some sort of output. So if you have application in such fashion, then AFL has a very quick when to fuzz it, right? So if you have, again, I'll just repeat it. If you have an application which accepts input and generates an output, some sort of output, then AFL is a very quick when to fuzz those kinds of programs. So that's why we say it has, it is an input-based fuzzer basically. So how AFL works in general, right? Oh, I'm just checking the Discord channel itself. If in case you see me not speaking, that means I have been shifting to the Discord channel. So how AFL works in general, right? You, we have a target binary, like let's suppose we have a target any XYZ target and you compile those targets with AFL, right? It makes more sense when we do it, but understanding it in a theory or a fundamental perspective is very much important at the same time. So let's suppose you have a binary, we need to compile it using AFL. Now why using AFL? Because AFL instrument those binaries. When I say instrument, it basically pinpoints certain blocks which would be covered as part of his fuzzing approach. So I'll show you what coverage means or what instrumentation means in our, when we run into the terminal. But just in a theory, we have a target binary, we need to compile those binaries with AFL. If we haven't compiled those binaries with AFL, specifically the open source one, you won't be able to execute or spin up your fuzzer, right? And the reason why we compile it because AFL instruments those target. What is instrumentation? I also let you know that part when we jump to the practical, right? So once the compiled binary with AFL has been done, we provide an input file. So let's suppose we have a binary called lippng, for example, right? From the name itself, we think that lippng accepts png file as an input maybe, right? So we have to assume like, because lippng was very much straightforward, there are certain programs for example, like for example, lippcap maybe. So the word says that it might accept pcap file, right? So when you know this program accepts only pcap as an input, you cannot pass dot txt as an input. That would not render or that would not execute the actual condition of the program. So if you have, if you're fuzzing an XML parser, we need to pass the XML file. If you have fuzzing lippng, we need to pass png, teff, or the image file format files basically, right? Once when we pass those input, AFL mangles those test keys. When I say the word mangles, that means it mutates those input. So there are two words which I'll be, which we will be doing or discussing this. It can be input or test case or it can be corpus. So most of the people say it has a corpus. Corpuses are nothing just the input file or the seeds which you provide very initially. So let's suppose we are fuzzing an XML parser. We compiled it with AFL. We created our XML file, very normal XML file which once run, it says that hello world or something else. And that XML file would be mutated or mangled by the AFL. When I say that, I'm not sure if you can see this part. So let's suppose the original hex of the input file is A, B, C, D, E, F, G, one. Once when the AFL spin the fuzzer, it mutates the test case to A1, the B becomes one, and C, B, E, A, F, G, right? It tries to play around with the bits and bytes of the input and that bits and bytes mangled test cases are passed into the application which we compiled previously, okay? And once when it get executed perfectly, AFL try to analyze the output of it and depending upon that, it discovers the new path. So I hope you get the idea, right? So we have a compile program with AFL, we send the input, the input gets mutated, the input, the mutated input is being shared with the compile binary. And depending upon the output generated by the application, AFL decide whether this is a new coverage or new path or not. So that's how the in general AFL works, right? Okay, perfect. So here's the very quick idea again about how AFL mutates, right? We discussed this. We have an original file with the hex value of 48, 65, 60, 60 and 6F. The mutated test case with the AFL would be that like 48 becomes 68 and rest all remains same. So it totally depends upon the AFL itself. Sometime it will only change one bit, sometime it change only the last three bytes, sometime it might change the random byte. It totally depends upon the AFL. But the core idea over here is it plays around with the bits and bytes of the initial corpus basically. So let's understand the color code of AFL framework because it is very important again. When we see anything in red, that means it requires our attention. So red can be no progress, very slow, wrong syntax, crashes and so on and so forth. Then we have other different color coding mechanisms such as magenta, yellow, blue and green. Like magenta starts for like fuzzing is being spanned up. Yellow is for new findings. Blue would be go for the last cycle. Green is larger number of cycle was being performed, right? So there are different color coatings, but for this workshop or what your eyes should be catching at is the red part because if you see over here, says that I was fuzzing some JSON parser where it discovered 2,248 crashes, but 28 was them were unique. Over here it says unique crashes, 28, right? So red color is something which should always, you guys should always look for because there are two mechanism for the red color that one can be your framework is not running fine or second, you have got any crashes, right? So red is the new crash basically. So let's move forward and discuss about the each blocks or the each segment over here for the AFL, right, the actual fundamentals. So we have process time, overall results, cycle process, map coverage, so on and so forth. I'll just quickly run through them. So when we talk about this block process timing, that means that what's the duration of your fuzzer being running? Like it's seven minutes, it's 12 days, 20 days, 600 days, it depends upon how much you are actually spinning up your fuzzer for how long. It also says that last new path. When I say last new path, that means once when the executed input has been passed through the application, it tries to see whether we discovered any new path or not. When I say new path, that means was any new variation of input was being generated. If yes, then it goes back to the queue and it start fuzzing again, right? So new path is something we should always look for as well at the same time. If the new path is two second, that means your fuzzer frame work is finding new different variations of input, which would be passed in the application to get it first. Then you have last unique crash and then last unique hang, which is pretty much self-explanatory that one minute ago, you found the last unique crash and the unique hang in this case is not yet seen, right? The overall results, the very first one is cycles done. Cycles done is something which I can explain in our further slide. Again, it's one of the important concept because cycle done is the flag from the framework where you understand that, oh, okay. Now I can go ahead and close my fuzzing framework. He has tried all the possible ways to trigger the crash on an application target, right? Then we have total paths, unique crash and unique hangs. Cycle progress is something the idea of the current test case. Like over here it is running 338 test case for some sort of mutation engine. So AFL comes with nine mutation engine. We are going to discuss that again. And it is running some mutation engine over here with 338 test case ID and it has been already completed 99.41%, right? So this part is something which showcase the current test case ID of what framework has been running. Map coverage is something this section provides you about the coverage observed by the instrumentation embedded, right? So when I say how much if you instrument a very big program, it requires a lot of map coverage. That means if you are fuzzing any complex program, PHP, VAM and so on and so forth, it requires a lot of map coverage. So this stats basically gives you an idea about what's the coverage being discovered by the AFL framework itself. So the more you cover, the better results you get when you start with fuzzing. We'll be having a look on this when we start fuzzing basically. Stage process is something where different sort of, different sort of executions is being taken place of what methodology are being used. We have arithmetic, we have Havoc, we have supplies and so on and so forth. So AFL utilizes nine different methodologies to nine different mutation engine to basically fuzzer program. I have elaborated each one of them in our next slide, but this part is something where you can have a look which mutation engine is been running by the AFL currently and what sort of mutation is being getting used, right? Moving on, findings in depth. Again, we have to specifically target on the favorite path, new edges, if it was being discovered. What is the total timeout? When I say the timeout, that means there can be certain test cases where AFL try to execute it, but there's no proper output. In that case, framework goes ahead and says that it was a timeout. Total crash is something which we should look for. So here it says that 2,248 crashed, but there are only 28 unique crashed. The reason why, because AFL might find same crash multiple time. So we have to focus for 28 unique crashes rather than 2,248 crashed, right? So when 28 unique crashes have been discovered, the corpus for those crashes would be saved in a different folder itself. So you don't have to jumble across all the 2,000 crashes or which is the actual crash which triggers the seg fault in the application, right? So 28 unique is something which we should always focus for. This is fuzzing strategy and yells. Again, we'll discuss this in our next slide. Then we have path geometry. This is very... This is most of the things are self-explanatory that we have stability, we have levels, we have pending, we have pending favorite path, own find. So basically levels are some things like initial test case. Like initial test case over here was been passed 15. So it says 15 was the initial level, right? Stability of this framework to first those target binary was 100%. So it's 100%. Just to use FII that once when you start fuzzing with a complex program, you will see that the stability goes down to 60%, 40%, 80% for that matter, which is fair enough. I have been running framework, fuzzing framework on my Zen server, which stability has 10 to 12%. For sure you compromise with your execution speed at that time, but if you really want your fuzzing instance to be running, then you can ignore the stability part basically, right? But 100% is something which is fair enough. All the small programs basically will run on 100%. If you first for complex programs, it might take down to 80% or 94, 95, not more than that. It also depends upon how long you are running your fuzzing framework, seven days, 12 days, and so on, so forth. CPU utilization, this is pretty much self-explanatory that what's the percentage of utilization of your CPU or your core basically. You can use AFL-GotCPU for this. We'll be having a look on it. So the Ubuntu OS, which I have provided to you guys has four cores. So each core can run one framework, fuzzing framework instance, and it utilizes 100%, 120%, 86%, depending upon what's the input-output execution speed of the first program is. So this is the main part. This is what the nine different mutators or nine different engines which AFL utilizes. Calibration, trim, bit flip, arithmetic, interest, extras, Havoc, splice, and sync, right? So over here, it says that now trying arithmetic eight on eight. When you say arithmetic, that means the fuzzer tries to subtract or add small integers in your corpus. So you get an idea, right? You try to minimize your test case, add something else, and then send it to the framework. When we talk about Havoc, it says that various stack-based operations is being done. That means AFL changes the stack operations of your past input, and then send it to the framework just to see how target binary reacts. So AFL basically utilizes nine different core methodologies to fuzz a binary program. And when it starts, it doesn't matter whether it starts from calibration or sync. When all these methodologies or the mutators are being completed, then it goes to cycles done one. That means that it is always recommended that when you fuzz any program, at least make sure that you have cycles done is equal to one. That means your framework has achieved or tried this A to Z point on your target binary, right? You should always also look for the pending favorite. If it is zero, that means the AFL is not able to discover any new parts in your target binary, right? So if you have cycles done is zero and pending favorite is thousand, that means let your framework keep alive, let it run. If you have pending favorite zero and cycles done one, that means, okay, you can go ahead and stop the framework and you can try with some other test cases or maybe you can try some different attributes for that matter, right? So this is how AFL strategy works in general. So I'm just, I'm sorry for this, but I'll keep asking in between. Am I perfectly audible to you guys if anyone can message on Discord? That would be fair. Yes, you are. Okay, perfect. No problem. Okay, perfect. Thank you. Thank you very much. So moving on, there are certain AFL utilities which we need to be get aware of like AFL GCC, AFL Clang, AFL Fuzz, AFL Seaman and Godseep and so on and so forth. So there are multiple utilities over here. So when we talk about AFL GCC, that means if you recall at our very first slide where I explained that we need to compile a program with AFL to get it first, right? So our GNU compiler by default is GCC or Clang for that matter, whatever you prefer to. We need to replace those compiler with AFL-GCC and AFL-Clang. So we'll be doing that. So if I, for this entire workshop, when I say compile the program, you have to use AFL Clang. AFL GCC was being deprecated long now, not deprecated to be honest, but most of the people prefer AFL Clang because it comes with the LLVM instrumentation. Now LLVM is one of the most powerful library utilized for discovering so it comes with different components. Basically it has a LLVM symbolizer discovering more new parts and so on and so forth. But AFL GCC is something which was being used at the very start. So you can use AFL Clang for now. AFL Fuzz is something as the actual binary which helps you to spin up your framework. So you have to use AFL Fuzz for that. AFL Seamon is something which minimizes your test case. We'll be having a look on that as well. We have AFL God CPU which shows your CPU utilization. So at least the top four or five is something which we are going to cover. The rest is pretty much very easy and straightforward. You can have read me on this, but if in case you have any issues running AFL plot or AFL teaming, just buzz me on Discord, I'll be happy to help, right? But the core focus area over here is AFL Clang, Fuzz, Seamon and God CPU. Something more on this. So when I say we have to change our cross compiler from GCC from normal GNU compilers of GCC to AFL Clang, that means we have to use CC and CXX. That means changing our cross compilers, right? So CC is time for your primary cross compiler and secondary is CXX. So we have to override our GNU compilers with AFL Clang for that matter, right? So we have certain projects where we have .configure file. So .configure file is something, if you have an open source project which has a .configure file, that means it is responsible for getting things ready. It checks for all the dependencies, whether, like for example, you are compiling a PHP source code on your Debian operating system. So .configure file is something with checks for all the dependencies and all the common factors which requires to get PHP compiled successfully. hyphen hyphen disabled hyphen share is one of the important component in fuzzing. That means don't build shared libraries. Okay, so I'll share this knowledge in bits and bytes in our coming slide, but when I say disabled hyphen share, that means let's suppose TCP dump, right? TCP dump, we all know it utilizes winpcap or libpcap for that matter. So TCP dump is a software application, but linkpcap is a library which is being utilized by TCP dump, right? So if you don't disable shared libraries, and if in case, first of all, if you don't disable the shared libraries, AFL won't be able to spin up properly, right? And if in case it gets spin up, the crashes which would be discovered, you won't be able to try it properly because you won't have a clear idea whether this was triggered in a library or in the software application itself, right? So if I have an agenda to first TCP dump, so I have to disable the shared libraries, the rest of the shared libraries, because if any of the crash, when I start fuzzing with TCP dump, if any of the crash has been triggered, then I have a 100% accurate result that TCP dump is vulnerable or TCP dump trigger has a crash when we send any malformed characters and so on and so forth, right? So it gets assigned to TCP dump, TCP dump team basically. But if in case you find any crashes and without looking at you blindly, go ahead and submit to TCP dump project team maintainers, if they analyze it, and if they found that it has not been part of, the crash has not been triggered because of TCP dump code and it has been getting crashed because of some XYZ library, then you have to navigate back to those library maintainers. And at that case, you get out of your agenda because you were trying to find out a crash on TCP dump, not on that third party libraries, right? So just make sure that if you have a complex program and you want to disable shared libraries, always use hyphen, hyphen, disabled hyphen share. Okay, perfect. Moving on, we have make file. Now make file is something which actually makes your entire program. Now dot configure file is also responsible to create make file, right? Then the next one is cmakelist.txt. Similarly, when we have make file, we have cmakelist.txt as well. I'll just let you know what it is. Then we have add the rate, add the rate. Just keep in mind that, okay, for now let's try to ignore this one because it makes more sense when I demonstrate this. And the last but not least is echo core which navigates to proxies kernel core underscore pattern. So you know, Ubuntu has a very different way to showcase a crash. If you are running any application which gets crashed, Ubuntu gives a system pop-ups stating that we want to send this error to Ubuntu developer team or not, right? So if AFL spins up the first and if it finds multiple crashes like 2000 crashes which you see on our previous screenshots, you will get 2000 different pop-up at the same time, right? To disable that, we use echo core and we pass everything onto a core underscore pattern file basically, right? So it's very important to do this because if you don't do this probably, your fuzzer won't be able to work. So initially when we start with the practicals, when you run or try to spin up the fuzzer, you'll get an error. So I would request you to navigate to a new terminal, run as sudo su and then run this command. Then you will be able to spin up the fuzzer. But the idea is we disabled system pop-ups and we deny sending all the logs or reports to the Ubuntu developer team or for that matter, whatever operating system you are using. So here are some prerequisite. If, so Ubuntu VM has already everything but just in case you want to create everything from scratch, you can use sudo apt install, build, essential, clang, GCC and GDB. Then there are some standard package, you know? So when you start fuzzing big programs, dependencies will be your enemies basically because it will, when you compile a program, they will say like, let's suppose complex.h header file is being missing. Now you have to Google for it. Basically complex.h header file is being utilized by which many packages then you will install those packages, right? So what I have been doing from this many years is I'm trying to gather certain package which when you install on your Ubuntu VM, at least it would make your life easy as part of the dependency, right? So you can navigate to this pack.sh URL if you want to have a setup from scratch and you are facing any dependency issues. This all are the list of packages which I have captured or observed so far which would decrease your amount of, the amount of efforts for dependency issues, right? Installing AFL is straightforward. In Ubuntu, you can do it APT get install AFL or you can navigate to github.com slash Google slash AFL and you can just do make and pseudo make install. That's it. You are good to go. You can install AFL and it would be perfectly working on your operating system. I know you guys must be thinking. So we are doing this for more than half an hour, 40 minutes right now. So, but understanding the fundamental is very much important. I hope at least it gave you an idea about how AFL works in general at a very high level overview. And there are a few certain things which would be capturing in our theory part itself. So let's jump down to start with fuzzing. So let's navigate to our 1, 2 OS. Let's log into party. Just wanted to confirm was the theory part was being fair and clear enough? Is there any questions so far? Yeah, I'm already with. Yeah, perfect. Yeah. When we disabled the shared libraries with the minus minus disabled shared library option. So is there any way to check that whether a binary is using any shared library or not? It means without having the source code. Perfect. We can have so most of the developers are maintainers of those program. They already maintain a folder and get up called third party. So if you have that folder, does that mean the open source that specific application is utilizing third party libraries? Or else they will write it on their readme.md file that we are utilizing this as a third party library. So, you know, it's a very quick win to analyze whether this has been utilizing any third party libraries or not. Okay. Yeah. Hi, this is the same as disabling the dependencies like not included. I'm sorry, I didn't got your question. The dependencies which are there, is it similar to like, will it not take up the dependencies when we enable this disabled shared? No, so it totally ends up upon what application we are trying to see. If we do disabled shared, it is not always necessary that we'll end up completing our dependencies because the target binary might also have certain XYZ dependencies as well. So we have to fulfill those at the same time. Okay. Okay, perfect. So we'll move ahead. If you're logging on to your Ubuntu OS, just navigate to CD fuzzing directory. And you will see certain set of folders over there. So AFL is already installed, right? We don't need to do anything over here. So if you do AFL-double tap, if you press tap twice, you will see AFL analyze, clang, clang fast, and bunch of other options. Okay, so the password would be party, P-A-R-T-Y. Someone asked on the Discord, it's P-A-R-T-Y. Everything in small. Okay, so if you navigate to CD fuzzing, you will see a bunch of folders over here, right? We will go to LibWay for now. So your part should be home, zero fuzzing LibWay. Just let me know if I'm going too fast or too slow, I'll be happy to manage according to you guys. Sure, sure. Once we are in LibWay, navigate to CD tools. There are two options over here, wave underscore gain and wave underscore info. Let's go for wave underscore info for now. And you see we have a make file and a C file, right? Okay, as a quick question, what do you think this application does when it, like, what do you think as of right now when you understand wave underscore info? What sort of extension would it accept as an input? Any guesses, any idea if you can buzz it on Discord? Audio files. Audio files, right? It would be maybe a dot wave file, yes, exactly, yep. So we have to guess it in certain way, like, okay, that was wave underscore info. That means it accepts dot wave as an input. So perfect. If we go to cat make file, you can see make file is a file which is responsible to create your binaries. That's what we learned in AFL utils. So if you do simply make and hit enter, and if you do LS, it creates your make, it creates your actual binary, right? If you do dot slash wave underscore info, it says that usage is wave info and the file name. You have to pass a file name basically or a file, right? But over here, if you see, we compile this program using GCC, right? So what we can do is just for an example, let's create MKDIR example and we'll copy this, copy wave underscore info to that example folder. And we will navigate to example or maybe just rename it MV wave info to wave info underscore GCC because we compile it using GCC, right? So what, it's a very quick one. We copied this compile binary of GCC to another folder and we just renamed it to wave underscore info underscore GCC because I really want you guys to understand what's the difference between the normal compilation and the AFL when it compiles. Basically, I really want to give you a picture of what the term instrumentation mean, right? If you are done with this, let's do RM wave underscore info, this file basically, wave underscore info, not wave info dot C. So technically you should have, you should be back to what, when we navigate it. Now let's do nano make file. So over here, the cross compiler is GCC. We will go ahead and change it to AFL hyphen clan and just do control X and save this file. Now, if you do cat make file, it should be CC equals to AFL hyphen clan, right? And when we do this make over here, it makes the same output, but it says AFL CC instrumented at 71 locations, non-hardened mode, the issue is hundred percent, right? I'll just wait for a few seconds. So what we did basically, we changed our cross compiler to AFL hyphen clan and then we made make, we ran make to make our file. And this time you see a difference between normal compilation and the AFL compilation itself. So here it says that instrumented at 71 locations. Okay, so here's the huge difference when you see the stack or the instrumentations basically of the wave underscore info. And if you normally hit enter NM dot wave underscore info and you open up a new terminal, you go to the example folder where we compile the program using GCC. And when you do NM dot wave underscore info dot GCC, right? So you'll see the stack operations are totally different in the compiled of compile version of AFL clan and the compiled version of GCC. So if you do NM wave underscore info and if you grip for AFL, you see AFL uses different variable declarations to instrument in this program, right? And when you do this with the program which was compiled with GCC, you will find nothing, right? So that's how AFL instruments the program. And now this instrumented program can be first successful using AFL framework because now AFL framework knows that where all bytes which has been, which has been instrumented perfectly. And over here with the GCC compiler, it was not instrumented with AFL, right? So this is a very quick idea or glimpse that how AFL injects its own instrumentation to the binary, target binary, and which GCC doesn't. So that's why we change our cross compilers to from GCC to AFL clan. What is the NM used for? I got your point. Yeah, so NM is like, you can check hex of the files. You can use hex editor for that matter. It's just give you the view of the view or the tree of the target binary application. Okay. I'll just wait for a couple of seconds. Are you guys with me? If anyone can write it on the Discord? Yeah. Have you tried running AFL in WSL means without directly on Windows or with Hyper? Yep, yep. So we have Windows AFL, Win AFL basically. AFL, so it's a different version of AFL. We can use Win AFL for that matter. If you want to fuzz any binaries in Windows. Okay. So what we change in Nano was, there's a question on Discord. If we do cat make file, we change this cross compiler from GCC to AFL-GCC, AFL-clang, I'm sorry. So if you just do nano make file, it was GCC before, you just have to change it to AFL-clang. So we are changing the cross compiler so that our program gets instrumented perfectly. So once you're done with this, what you can do is you can create MKDIR in, which is an input file. And then you can do CP navigate. So I have already created a directory called corpus, where there are certain set of corpuses over here. Sample underscore wave folder would not be on your system. I'll just share this within a couple of minutes. You should have PS, sample.wave and test case, right? So we have to copy sample.wave file into the infolder. So once you have copied the sample. So this is how your current directory should look like. That should be an infolder, the compile binary with AFL-clang. So in infolder, you should have sample.wave file, not some other files basically. So if you do wave underscore info with in and sample.wave file, so it accepts the input, right? And it gives an output, a small information about what this sample.wave file is, right? It has a RIF type format, et cetera, et cetera. So it depends upon what this specific wave file is. It gives a header basically, it prints out the value and gives you information about the wave file. So our, this program basically gives you an info about any wave files or audio files basically, right? So this was a very quick dry run that, okay, the past input has been accepted by our compile binary, right? Now, what we will do is we'll actually run the fuzzer, AFL-fuzz-i, that means stands for input folder, hyphen O stands for output folder. That means I am saying AFL to catch all the input and hyphen O create a new output folder to capture the new outputs. Then you use hyphen hyphen dash just to break the lines or if you don't use it, it's fair enough, it's up to you guys. Then you use wave underscore info and then add the rate, add the rate. So if you recall in our slide, I just skipped the add the rate, add the rate part. The reason because it makes more sense over here, that means when AFL try to fuzz this, it will capture all the input file from here and it will just execute at replacement of the add the rate, add the rate, right? So this is just an pointer to understand AFL that where he needs to execute or put the input file once when the framework is running, right? When you hit enter, it gives you the error that echo code proxies kernel, move it to the co-pattern, right? This is what we discussed because we don't want Ubuntu to give system popups. So now we get to a new terminal, do sudo su, use the same password party and just run this. And if you spin the fuzzer right now, it should work. And if you see AFL, I've got CPU, I'm utilizing one of my code which is overbook and three codes are available for now. It should be same for you guys. So I'll wait for five minutes in case you have any questions, just buzz on the Discord. So I got one unique crash. Can we first go by and raise with this? I'm sorry? Go lang binaries, can we first that also? Yes, we can. Yes, that is AFL. There's a different extended framework itself where you can first go binaries, you can first Python binaries. So there's a question on Discord that the sample wave file is normal wave file or not. Yes, it's a very normal wave file downloaded over the internet. There's nothing being modified explicitly. AFL is something which would modify those file to trigger the crash, which you can see it on my screen. So it's a very sample wave file downloaded over the internet. You can download any wave file for that matter. You have five to 10 minutes for this exercise because I want that everyone should have at least two to three unique crashes. Then we can go forward. When we submit the report of the AFL to the developer or the team which is maintaining the software. So do we need to also give exploit for this? Means first we need to develop an exploit or they will do that or verify there? So it depends upon like, that's what the vulnerability resource term comes into the place. So if you see, first of all, all the discovered crashes, crashes doesn't mean that we have a bug. Crashes can be where a malformed subject is being passed to the target application and the application is not able to handle them and the program get crash, right? So all crashes are not bugs. So it depends upon what kind of crashes you have analyzed you need to debug it. And if you're willing to go ahead to write a proper chain of exploit and if you think it is exploitable, then you can go ahead and submit with the exploit code. So that's a proper end to end research vulnerability. If you find certain crashes, which is not exploitable at all, but as part of a proper code sanitization you want to give back to the community that okay, if you pass a malformed character specific to this function, your program get crash. You can just go ahead and share it with the maintainer itself. So there are two aspects of this. Either you can be a proper vulnerability researcher or else you can, if you can't mold those crashes to a proper bug, you can just at least inform vendors or the developers that some malformed character or malformed URI crashes your program XYZ. So there are two different aspects of this. So we got few thumbs up on that. People are getting crashes. We'll wait for a few more minutes. Okay, so the password for the VMS party, P-A-R-T-Y everything in small, just to give a quick idea that what we did was we compiled our wave file with using AFL hyphen clang and we copy dot wave sample dot wave file from our corpus directory to the present working directory and we ran it using dot slash wave underscore info to see what the output is being generated. Then we went ahead and we spin up our fuzzer AFL fuzz hyphen I stands for the input folder hyphen O stands for the output folder. This is just a break between two different commands. You can ignore this part as well. Then you can use dot slash wave underscore info and then you do add the rate, add the rate. Now add the rate, add the rate again is let's suppose let assume it acts as a pointer where it AFL fuzz catches all the input from the infolder and push it over here just after wave underscore info file. And once you run it, you should be able to get crash. Like for example, I got four unique crash and I have done with one cycle and zero pending favorite. That means the fuzzer has completed all his expires at tasks. So I'll go ahead and control C, just stop this. So that's fair. If you have four unique crash and pending favorite is one, that's fine because we at least got four unique crash. Let's try as them as we can do control C that's up to you guys. But because we are doing as part of a session we can do control C, but if in case you're fuzzing any actual program, make sure that you have at least one cycle done with pending favorite is zero. Then you get an idea that, okay, you have to go ahead and stop your fuzzer. Right? So let's move forward. Now, if you do LS out, you will see there are different folders generated by AFL itself, crashes, first bitmap, fuzzer states, hang, plot, data and queue, right? We'll be focusing on crashes for now. If you do LS out crashes, these are the input files which basically triggers crashes. If you see wave underscore info, out, crashes, ID, zero, zero, zero and hit enter. It says couldn't open the file. So sometime what happened is if, if the application returns error, the framework says that, okay, it was being crashed. So in this case, again, we have to eliminate false positive. Now for me, the test case ID, so that's how you read. This is ID number, zero, zero, zero, right? I have ID number one over here. I have ID number two over here and ID number three over here. So my ID is zero is false positive. I'll test for, so it would be different for all of you guys. If I do wave info out, crashes, ID one, I trigger a sec fault over here, right? That means the program was being crashed. It, so sec fault, segmentation fault is one of the common term. That means the program didn't execute it successfully and there was a crash which was being triggered. So you have to see, it's a quick task, which one of your triggers the crash and which one says that error couldn't open the file. Just verify it from your end, take a couple of minutes for this. Okay. Yep, so if there are certain test cases which don't triggers any crash execute successfully, those are false positive as well. So we have to eliminate them until unless you don't see any sec fault, that means that now for me, the test case ID zero zero one is the ID which, if in case I want to share the crash to get analyzed by the developers, this is the test case ID which I need to share. So we are not focusing more on debuggers right now, but if you just open GDB with wave underscore info, right? And if you run out crashes with my, so I cannot do tab, I'll just copy ID, this hit enter, right? It receives a sec fault and when I do backtracks, it says that wave underscore info file and the line number 18 was responsible for this. So that's how you can do a very quick debug. What I did was I ran the wave underscore info using GDB, one of the debugger which comes by default on Linux. I did R, R stands for run. And you have to share the entire path out crashes. For my, the ID number is zero zero one, for you, it might be different. So what it does basically, it runs the exact same thing which was being run above and it says that it found an invalid point. And when you do BT, that mean backtracks, just to understand what causes the crash over here, this all a system-based file. That means, you know, some crashes might have linked mechanism to the OS based file itself, but that doesn't mean that OS is also helping to generate this crash. But over here, when you say wave underscore info.c, you know that this is the C file which has been responsible to trigger crash on line number 18 and 28. Now, again, we have to analyze explicitly. There can be two different functions here on line number 18 or line number 28. You can just do nano if you want on your, if you want to take more time. You will find that there are two different functions. It can be 18 or 28. And according to that, you can give more information to the maintainers or the developers of the program that this specific function is causing the crash basically. So if you quickly want to have a VIN debug, you have to see it. You have to do gdb wave underscore info, do R run. And once the program is being run, you do BT, which is backtrace. And you found that two functions basically are responsible for getting or triggering this crash. This is just a very simple debugging step which you can see. Is it a heap overflow? So if we do more debugging analysis over here, which we are ignoring for now, so we will get a very clear picture whether what kind of vulnerability it is, whether it was just a normal sec fault or heap or stack or so on and so forth. So just to give a very quick win, we have sanitizers in our next slide. So which gives you an idea whether it was a heap overflow or a stack or something else. So you might be able to get more clear picture when we go further. Thank you. In my case, I got five crashes, but all of them were this. They opened the help. They opened the help file. So that means you have to spin up your fuzzer again for that matter. Also meanwhile, just navigate to your fuzzing corpus folder and just share this. You have to do W get. I'll just share it on the chat itself. Just do W get this to the corpus folder. So again, this W get to GitHub, root up and the sample underscore wave dot zip contains the number of zip wave files which we'll be utilizing in our further slide for the practical. So if you do a sample underscore wave, it should have different different files basically. So if you guys are with me, you discover the crash. So I gave you idea about how you edit the make file. You change your cross compilers and then you change your cross compiler to AFL iPhone Clang and then you spin up the fuzzer, right? Now over here, so there can be certain instances where you have, okay, so if you go back to your fuzzer, it says that some test cases are huge, 129 KB. And if you read this file dot TXT performance dot TXT, that means that the execution speed over here is slow, right? So there are different ways to make your execution speed faster. So in the sample program, which we are testing, so I hope you have W get the URL which I have shared on the zoom chat. And if you extract the zip file, you will find multiple wave files, right? And what I'll suggest is just do RM to your actual in directory, RM-RFN and create MKDIR sample and copy all the test cases from the sample underscore wave to the sample folder on your current working directory, right? So the hierarchy should be something like this. It should be LS sample dot wave, right? There are multiple wave files over here. So we are discussing about a topic called test case minimization, where AFL itself minimize the test case in certain way that it enhance your execution speed and it also give results much more faster, right? So if you copy, if you have W get the zip file, extracted it onto the corpus directory, then copy the extracted corpus to your present working directory on a sample folder, create one more directory called MKDIR corpus and we'll do the same task, but this time we'll use AFL-semin. Now semin is a test case, basically minimizer. Over here we say hyphen I, we pass the folder which has all the sample files, right? And we say once you minimize it, save it to a directory called corpus, then we do hyphen hyphen. That means we are just differentiating the different commands. Then we do wave underscore info at the rate at three, right? And when we hit enter, so it processes the different tuples and record it into the captured tuples from the sample folder and record to the corpus folder. So if you do LS sample, there were multiple files, but when it minimized it, minimization as in framework itself, understand that which of the test case would generate much more better or faster result when the framework has been spanned up. If we do LS corpus, so there were one, two, three, four, five, six, seven, eight, nine, 10, almost 12 test cases and AFL selected only one. So it minimized the test case and told us that this test case would be much more reliable and would be able to give the results much more faster. So if we do AFL fuzz hyphen I to corpus, this time, oh my bad. Can you please repeat? Just a minute, yeah. So you want me to repeat the AFL semen? Okay, I'll do it from AFL semen. Okay, so what we did basically, we did LS sample. We had multiple sample files over here. And we had semen, right? So AFL semen is a test case minimization basically, which captures all the sample or the corpus file from the actual folder and says to the framework that which would be the best input file to fuzz this specific program or what would be the best possible outcome or the stats when you start fuzzing with this specific binary. So when we run this basically, also we already ran this. So in corpus directory, it selected only one file that was taunt.wave, right? So now AFL framework told that taunt.wave file is one of the file which can be the easy and the quick when to enhance your execution speed for fuzzing wave underscore info, right? So that's how test case minimization work basically. You have certain, so if you have 1000 test cases, you cannot push all the 1000 test case to the framework, right? Your framework becomes slow. So in that case, we do a test case minimization using AFL semen. So we capture all the 1000 test case to a folder. We create a sample folder and we say to AFL semen that according to you, from this 1000 test case, which would be the fair test case to fuzz this program, right? Now we're here, there were 12 test cases and AFL semen found that this would be one of the best test case as compared to the rest, right? So if you do AFL hyphen fuzz hyphen I, corpus hyphen no out and we fuzz the program again, it will start fuzzing again at the same fashion. So it only works when you have a larger set of binaries, complex binary or a larger set of input files and you have to do a test case minimization over here. For now, we only had 12 sample wave file when you have 500 or 600 sample files and you have to cut it down to 10 or 20, AFL semen is the person to go. So the command for that would be AFL semen hyphen I sample hyphen O corpus to capture all the new corpuses and then you share it or then you pass it to wave underscore info. So basically that's how we do test case minimization. So it's always a best way to pass more test cases because more test case can have a better result but that doesn't mean that we will pass 1000 test case at the same time to the framework. So AFL semen is something which will help us to understand which of the test cases fair to run or to fuzz on the target application, right? We will move forward. Now, we understood how we fuzz when we have a program with the make file, right? If we navigate to fuzzing right now and if we navigate to CD Benutils 2.35 which I guess is one of the latest one, if I'm not wrong at least it should be back from 2020 or 20. Yeah, it should be from 2020 Benutils, right? So if you navigate it over here there is no make file, right? So, but we have dot configure file. So over here when we have, so we are going to a next step. Now, I made you understand that how you fuzz a program when you have a make file, how you judge our input and how you pass it and how you do a test case minimization, right? We actually covered some good chunk of fuzzing methodology in our first phase. Now, second is when you have certain open source such as configure now Benutils, you might be familiar that Benutils comes by default in most of the Debian operating system, right? It has read ELF, it has OBJ dump and so on, so forth. So in this case, we don't have make file we have configure file. So in that case, we'll be the general practice would be running dot configure and hit enter, right? But we have to compile this using AFL clang or we have to instrument the programs with AFL. So what we have to do is we have to do cc equals AFL hyphen clang and cxx equals AFL hyphen clang, hyphen fast or maybe clang plus plus. Let's see we have plus plus AFL hyphen clang. Oh, yes, we do have plus plus, right? So we have that means we are changing our cross compilers from normal GNU compilers to AFL hyphen clang and AFL hyphen clang plus plus. Then we hit dot configure. Now I have read to the read me file of Benutils that they don't utilize any third party libraries. So in that case, we don't use disable hyphen share, right? We will just go ahead for now and just hit configure and we'll hit enter over here. It says that, okay, somewhere it should say that, yeah, checking for GCC, it took AFL hyphen clang. That means things are working perfectly. It also instrumented somewhere during the configuration itself. Now you can do. So at the end, you can say creating make file. So that dot configure file actually created a make file. Now we have to do make hyphen J2 for that matter. We use hyphen J2 first. Can you show that command again? CC, where you set the variables. So CC equals to AFL hyphen clang and CXX equals AFL hyphen clang plus plus. Then we have to do dot configure. Here, here do you think that the several shared libraries that you made any other configuration changes or if we use a raw benutil or there are no. Yeah, yeah. So there was no other configuration changes on this. We are just running it off or kicking it off from the dot configure itself. We are not disabling any shared libraries. This CC and CCX is a our path variables. Oh, sorry. Our environment variables. Yeah, this you can actually export it to your environment variables as well like this. CC equals AFL hyphen clang. So you don't have to utilize it every time, but you know, it's not a best practice to do that. So that's why we always prefer doing like this. So CC is primary cross compiler and CXX is our secondary cross compiler. That mean there are certain set of files which only get compiled with AFL clang, but there can be certain set of files where it requires clang plus plus. So in this case, we are giving two different options to the binary itself. And if in case there are any ifs and buts, it handles by its own logic. So that's why we are using two different compilers. Yes, you can actually go ahead and export this, but to be honest, I won't recommend this. So what happened is basically you are exporting this to your environment variable. But to be honest, I wouldn't recommend this. Dheeraj is CC for C files and CXX for C plus plus files or something else. It depends upon what you are doing. It can be for C and C plus plus. It can be for dot C and dot CC as well. But to be honest, it always focused for the justifying two different cross compilers, the primary and the secondary. Okay, thank you. Once you are done with the configure, you have to do make hyphen J2. That means you are making it and hyphen J2 means you are utilizing two threads to compile it very quickly because bin utils is a big program. It would take at least two to three minutes to get compiled, right? And just make sure that your program gets instrumented with AFL. You will see, you can see it gives a info over here that it was been instrumented, right? So just make sure you get that text in green color that instrumented at this many locations. Dheeraj, I have a question. What does AFL underscore harden used for can you explain that mean way? Yeah, so we have sanitizers as a different topic in our further slide. So basically sanitizers are a utility. It comes with a LLVM. Sanitizers basically discover bugs in the runtime instrumentation itself. Now AFL also have its own sanitizers, not the actual sanitizers, but they have named called AFL underscore harden. So it acts or works has similar to sanitizers. So when you learn sanitizers in our next slide, it's similar. So AFL has its own internals of having AFL underscore harden. So basically that means it hardens the code in such a way that it discovers new path. And to be honest, I personally don't prefer AFL harden because other sanitizers are much more powerful as compared to the AFL harden. And if you enable AFL harden and also enable ASAN, then the program would never work. Either you have to enable any one of them. So that's what the AFL harden is. Nothing just an internal sanitizer for the AFL framework. Okay. So is AFL sanitizers are more useful or should we go with all the ones? So address sanitizer is much more useful. I find it to be more fruitful as compared to AFL underscore harden. But it depends upon the people choice. I have seen many of my colleagues specifically utilizing AFL harden. I'm not sure why, but obviously there would be a huge difference between the results, but I personally prefer address sanitizers. If you're done with the compilation of Benutils, which I guess it should. So there are multiple folders now. See, we are one step ahead. Now previously there was a very sample program and we know we compiled it, generated Dave underscore info. The first silly challenge over here in complex program would be finding the actual folder where the program exists, right? Now either you can navigate to each and every folder, which I'll say it's a bad practice, or you can specifically look for SRC folder. You can specifically look for predefined folder such as Benutils. So if I go to Benutils, you can see I have certain ELF files. I have AR, BFD test. I have size, I have OBJ dump, OBJ copy. I have strings, sys info. I have read ELF, right? So read ELF is our target for now. So if we do dot slash read ELF and hit enter, now we are dealing with much more complex code base as compared to what we actually did on wave info, right? So just a quick one. Again, read ELF also comes by default in Ubuntu. So don't, if you are missing dot slash, that means you are not executing the compiled binary, right? Just make sure you have dot slash. If you are not using dot slash, that means you're calling system read ELF. So let's do read dot slash read ELF. So now can anyone can guess or maybe can put it on Discord that what file format it would accept by reading at the readme file or the help file? Anyone? Binary files. Binary files. Okay, can anyone be more specific? ELF binary files. ELF binary files, right? It says usages ELF files basically, right? Yeah, ELF is the actual file. Now, again, we'll get back to MKDIR in and we copy from our corpus or maybe not from the corpus. What we will do, we already have multiple ELF files in our system itself. We'll do CP user bin PS. Now PS is which shows basically your normal process IDs, right? If you do file PS, okay. If you do file user bin PS, it's a ELF file, right? So we'll do CP slash user bin PS to our input folder. Now, if we do LSN, we have a PS file, ELF file basically, right? Once we have ELF file, we do read ELF and we do NPS and hit enter. Now it doesn't work, right? It doesn't give any output. It doesn't give any output. It gives back the read me option over here. It was not very much straightforward what we did in wave underscore info because this requires attributes over here. Now there are different set of attributes hyphen A for all hyphen H for header hyphen L hyphen S and so on so forth. So if we do read ELF hyphen H in slash PS, yes. Now it gives the header file of this PS file, the past input file, right? If we do hyphen A, it executes all the possible commands from the read ELF and gives the output. That means now it is working perfectly. So just make sure if you don't add any attribute with the intended program, it will give you the help or the read me hyphen, hyphen health output basically, right? So in complex program, it won't be very much straightforward that you do read ELF or in slash PS, what we did in wave underscore info, it would be totally different. You need to understand the different attributes and functions called by those program. Over here, let's suppose we take hyphen A or maybe for let's suppose hyphen H it gives the header for the PS file, right? Now we can go ahead and do AFL fuzz hyphen I N O out and do read ELF hyphen H at the rate at the rate. I hope you got the point now. So we know that it uses hyphen H and if I place hyphen at the rate at the rate hyphen H this would be a wrong statement. Now basically what AFL would do it will take all the input from here, it will put here, then execute the H file which is basically a wrong syntax. So in that case, we have to be very specific that we use hyphen H first and then at the rate at the rate. If you hit enter, it spins up your fuzzing framework and you start fuzzing read ELF which is one of the GNU binary. One question here. So if we go for minus A instead of minus H so will we get different like test cases or? Yes, yes, it we would. So let's assume it in this way that when you use, you have a certain set of input and you are using hyphen A which only captures and provides the output of the header file. That means you are only utilizing the header file of the big chunk of your input file, right? Once when you do hyphen H which utilizes the entire input file to give an output in that case you have a big coverage and there are chances where you can find crashes. It totally depends, right? So it depends upon you which function you are fuzzing. It can be hyphen A, it can be hyphen H. It depends upon what you prefer basically. In this case, many of the instrumentation which AFL did will not be used. If we use hyphen A, no, no, no. So instrumentation happens on the binary itself not on the input, right? So I was specifically, so I'll explain it again, no problem. So the instrumentation happens on the input file. So which is that? No, no, I'm saying that binary has some functions inside C functions. Oh yeah, yeah, makes sense. Some of the functions will not be means fuzzing. Yes, that's a good point basically. So it depends upon if you use hyphen A which only hyphen H which utilizes header that means you don't have a big coverage in 3DLF. Yes, that's a good point. If you type in A, that means we have a great coverage in 3DLF and in the input file as well for that matter. So it totally depends upon the flexibility of who is fuzzing if I want to fuzz hyphen A. If I see past bugs in 3DLF, most of the people have gone for hyphen H because it might go with a big coverage bit, more instrumentation coverage and so on and so forth. But I have also seen bugs in hyphen A or hyphen H for that matter. It depends. So it's up to you what you want to fuzz if you have or you can have multiple fuzzing instance spin up on one fuzzer you use hyphen A on the other one you use hyphen H and you compare both of them, right? So in this case, let's focus for hyphen A or else hyphen H for that matter and hit enter. Now bin utils have, so 3DLF is one of the very mature program. It won't trigger any crash very quickly, right? Because the maintainers are very much sharp. The project has been maintained properly. People are been using bin utils from decades now. So in this case, you won't find any crash, right? But let's go to CD fuzzing and you have all bin utils 2.14. That means the older version of bin utils. I guess this is almost four to five years back. The reason to showcase is this because you will understand the different variation of the concepts of how bin utils was vulnerable that time and how it has been sharpened right now. There's a very quick win as well. I'll just first unzip this part. XVF then we do bin utils. We are doing the older version bin utils. Again, we will compile it. CC equals AFL hyphen clang hyphen of that's it clang CXX equals AFL hyphen configure, right? It got configured. Then I did make hyphen J1 or J2. Do you have any way to guide how to pick up the targets? Yes, we do have. It's in the coming slide. Yeah, like the ones you told, like there has been quite some time since people are fuzzing it. So how do we get to know about the targets which are more vulnerable? I'll just show that slide in a minute. So we were just compiling the own old bin utils over here. We navigate to CD bin utils folder. And we have reDLF over here as well. Now this 3DLF is five to four years older than the latest 3DLF. We do MKDIRN. We again copy the same corpus. There is no change in the corpus. We have been PS to infolder and we run the fuzzer hyphen. What we used, it was hyphen H or A. It was hyphen H. We use the same attribute hyphen H and at the right. So in this step, I am using the latest version of 3DLF, at least one year older. And over here, it was five years old and we quickly triggered a crash. Right. So at least four to five years back, reDLF was having certain set of not vulnerability, I would say, but it was a quick way to first such older binaries those days to trigger a crash. Right. And over here, I can see the huge difference now. Within past five years, people have first been utils so much that it's very difficult to get crash within. Over here, we got crash in 35 seconds. And over here, the latest version, it's been running for three minutes, but there's no crash. Right. So there's a huge difference between how people accepted fuzzing as a technique and they, they started focusing on well-known components such as bin utils such as PHP call and so on so forth. So that we don't, so that those programs are not vulnerable to such crashes. Right. So you can quickly do this exercise. I run a older version in the same side and run a new version of reDLF on the different terminal. If in case you are done with bin utils, there's a quick, let's just take quick five to 10 minutes for, there's another utility called first goat hyphen master. Now first goat is made by a developer or a maintainer. I cannot recall the name, but the use shout out to him. It's a vulnerable C program itself. It has a tons of vulnerabilities. So just navigate to first goat and to see what all you can do. If you have any questions, just let me know. If not, you can skip this part. Do it has, um, um, post this workshop, but let's just wait for more five minutes. Um, okay. We will move forward. Um, we had a look on bin utils. We had a look on baby info. Um, first goat is something which is a vulnerable framework. It's not framework, but vulnerable software application itself where you can make your hands much more dirty over here. So moving forward, someone asked the question about how we, um, get more targets. How we find targets basically because it's one of the very common question I get across the training or workshop. Um, so there are certain programs which you can fuzz, um, such as, um, lip, PNG, PHP, lip, deaf, open SSL, put the engines, Apache, and so on, so forth. So this are very, this is not a very exhaustive list, but the program that you see right now in this slide is a very quick glimpse that all this big complex programs are open source and, um, you can fuzz them basically. So this is one set of target, which you can utilize. Second, you can, if you need more targets, basically you can fuzz open to packages itself. Now one two has a lot of packages. Now, you know, one two might have thousands of packages, right? So you have 1000 different targets over here. I guess one two would have more than 1000 targets. So what you can do is you can do APT get source and um, look for any keyword like lip web and hit tab. You will find different, so different packages. You can download those packages as a source code and then you can and then you can do your further analysis, right? So you have very commonly used, uh, open source, uh, application like Apache open SSL, Paul, PHP Ruby and so on and so forth. If you don't want to prefer them, you can go to, um, the Ubuntu. You can start fuzzing the Ubuntu packages itself for that. You just have to do APT iPhone get source. I think you have to add the, the, um, source URLs to your repository and then you can do APT iPhone get source and then do lip web or lip P and hit tab and see what all, uh, packages are being offered by the Ubuntu developer itself or the Ubuntu platform itself and you can fuzz those, right? So now you have a very huge attack vector or not attack vector. For that matter, you have a very huge attack target and then you can go ahead and understand how those things work, whether they accept input as a, like whether there is any parameter which accepts input and then you can perform your fuzzing over there, right? Um, Will these be vulnerable? No, it's, it's, it totally depends upon right? Um, it doesn't matter a hundred percent that it would be vulnerable, right? The developers would have, so there would be few developers who will be actively maintaining their repository was that there might be few of them which, which developers might be busy so they don't push any, um, mitigation or updates. So it depends upon what you are fuzzing, how it has been fuzz so far in the past, it totally depends upon all those stats or scenarios, right? Um, moving on, uh, we have some not so pro tip, uh, if in case you encounter any dependency issue like it says that live PNG package was not being found or live GTK package was not being found rather than Googling which package should I go for? You can just do APT iPhone cash search and then search for that package name. Now Ubuntu will list all the possible packages for that and you can install, um, uh, depending upon what the requirement is rather than jumbling across and Googling first, Googling or this is going to the stack cover flow pages. Uh, it's better you do APT iPhone cash search and search for the missing packages that would help you to resolve your, um, dependencies very quickly. Again, a question here. So, uh, but during fuzzing we would avoid these dependencies, right? Uh, no, no. So we would encounter these dependencies because most of the program would have a lot of dependency and if you have a fresh setup of Ubuntu OS, you, we have to install it, right? So we won't be ignoring these dependencies because we need to fulfill those dependencies then the program has successfully been compiled. Okay, but to first, but to first the program we don't want to first these dependencies, right? No, no, that's totally two different things, right? Dependency is just to fulfill the requirement of, uh, uh, that our program has been compiled properly and when you fuzz it, you fuzz only the program not the dependencies. Dependencies are just the dependencies that our, uh, program gets compiled properly. That's it. What about the shared libraries? They are used when, when we run a binary or they are also used when we compile a binary. Um, so for shared libraries, as I mentioned, you can explicitly ignore them using disabled shared and, um, if you want to target the library itself, then I have a coming slide that how you can target the binding library itself to fuzz it. So this are some little bit future questions for our slide if in case you hold on, I can be able to, um, give a proper representation way, uh, if you don't mind. Sure. Yeah. Um, so moving on, um, the AFL path is being completed. Um, so we started with how why fuzzing is in place. First of all, um, we understood the prerequisite of installation of AFL. We went ahead. We understand the core fundamentals, the, the mutation strategy of AFL. We first, a very simple program called live wave where we utilized make file to compile the binary and then we fuzz it. We, um, had a look on, uh, test case minimization using AFL hyphen semen. Then we moved on first bin utils, which is much more complex program as compared to wave info file. Um, and bin utils, we basically compared to different aspect, one with the older version and one with the newer version. Oh, so there was a very great catch, which I forward to mention during the bin utils. So this is one of the not so pro tip way. Basically what happened is once when you fuzz, the older versions of bin utils, when you were fuzzing, you discovered certain crash, right? I saw someone in discord that, uh, there were 35 or 34 unique crashes, right? So the idea over here is you can utilize those crashes has your actual seats or inputs to the latest version of the bin utils. Are you getting my point? Right? We have, we are fuzzing the older version of bin utils. The crash, which was generated in the output slash crash folder. We copy those side seats, basically a copy those corpus and we utilize those corpus as a new input to the latest version of bin utils. Now, what happened is you already have a mutated input, which triggers the crash in the older version of bin utils. And there are, there might be, not there are, but there might be certain base where AFL simply mangles two or three bytes in that input. And you might, you might go ahead and get crashed in the latest version of bin utils, right? Are you getting my point? That means you are holding the, you are using the, utilizing the older crash to the newer version of the software itself. I cannot recall the repository name, but if in case I get it again handy, I'll share it on the Discord. There's a guy who maintains all the crash inputs, where they start from the Excel. If you first Microsoft Excel from the Adobe, from the wave file, from the redlfl file, the Txt files, whatever has been discovered, used after free or memory corruption bug, he captures all those tuples or corpus into a repository. If in case I come handy with that, I'll share it. You can utilize those as your input, actual initial input for the application. This is a very quick, quick and very quick easy catch to trigger crashes. Anyways, moving forward, we'll talk about ASAN, which is called as address sanitizers, basically. Now sanitizers are maintained by the team, the team from the Google itself. There are different sort of sanitizers, but we are specifically focusing for address sanitizer and memory sanitizer. Now address sanitizer detects addressability issues. It can be multiple issues. Memory sanitizers only deals with uninitialized memory, but what I have been observed is if you enable address sanitizer and if you compile the program, memory sanitizer comes by default in it. So it is not really highlighted to explicitly maintain memory sanitizers basically. So if you enable address sanitizers, it by default enables memory sanitizers as well. Address sanitizer, also known as ASAN, is a memory error detector. It can find tons of bugs basically, start from memory corruption such as use after free. Then it can detect global buffer overflow stack, use after return, use after scope, initialize order bugs, read after write bugs. Most of the common bugs, which have been utilized across the CEC plus plus program or in general, ASAN is capable of detecting all of them very quickly. There's an alternative for memory sanitizers. It's called Valgrind. You can use that as well. People do use Valgrind, but again, it's your personal choice. You can use Valgrind or sanitizers, address sanitizers. Again, I personally prefer sanitizers because it's much more relevant, which I feel, but I have seen people using Valgrind as well at the same time. So this is how it looks. If you navigate and log into your VM, there would be CD fuzzing, CD overflow, and then this small program cat buffer.cc. Now just a quick one that if you see it as a cat buffer defined 20, that means if you pass buffer more than 20, it's an overflow, right? If you use GCC, now sanitizers usually work in GCC and clang. We don't have to use AFL. So it comes by default. GCC hyphen f sanitize equals address buffer.cc hyphen no buffer. And if I do well as and when I do buffer hit enter, it says enter some text or maybe before this, let's have a look how things work when we don't use sanitizers. Let's go to CD fuzzing overflow and let's do MKDIR no underscore ASAN, CD ASAN, or maybe copy this buffer file to no ASAN, CD. Okay. If you do GCC buffer.c hyphen o buffer hit enter. And when we run this normally, it says enter some text. I entered some text hit enter. I entered more than 20 values. That's why it says that stack smashing detected, right? And if I do this with the binary, which was being compiled with sanitizers, if I do hit enter, it gives me a detailed view that this is a stack buffer overflow. And on what address with the unique EIP set and some other information, which can be very handy if you are doing any CDF challenge or if you are doing any in house compilation of the program itself. So, you know, what's the best part of address sanitizers is it detects bug during the runtime itself. AFL detect bugs when it executes them, right? Address sanitizers detect bugs when you actually run the program itself. There's a huge difference between execution of the program, the complete of the complete execution of the program and the runtime itself. So this all are the basic difference of the address sanitizers and the AFL. So address sanitizers are capable of detecting bugs on the runtime. So I'll just give you a quick idea. Just five minutes to quickly run this. You can use GCC-F sanitize equals address. If you want to use memory sanitizer at the same time, you can use comma memory. I'm getting an unrecognized argument. So can you share the screenshot on the discord please? Okay, I'll do that. It's GCC error that F sanitize don't have memory option. So you can remove that maybe. Clang might have the memory option, not GCC basically. But again, if you use address, it comes by default. It enables by default the memory sanitizers. And I feel I personally found that address sanitizers is the common because I have only found two to three places, uninitialized memory using memory sanitizers. But most of the time I prefer address sanitizers. So Clang might come with memory and GCC have address sanitizers. So address sanitizers come very much handy when you when you do any CTF basically. So not sec has a CTF itself. I guess tomorrow if I'm not wrong. And I assume I'm not sure I assume that would be owning challenges as well where you have to reverse engineer the buffer overflow ELF files and so on so forth. So you can participate on it. You can explicitly look for the overflows binaries and you can utilize what all you have learned so far from this workshop to the CTF challenge. So address sanitizers comes very much handy. I have been playing Pico CTF. I guess I played back in 2019. But most of the Pico challenges was I utilized you. I understood at least the the offsets or the IP is using address sanitizer itself. And if you are a in-house developer for your company and Microsoft Visual Studio. So more in-house even Microsoft Visual Studio comes with address sanitizer enable enable enablement from back in 2016. So if you want to discover bugs on your own product, if you're working for any product based companies, then you can use address sanitize at the same time. So here's the like I cannot recall who asked the question, but here is the answer for how we deal with shared libraries basically and specific to ASAN. Right. If you have an executable and the library, both are compiled with ASAN address sanitizers. You will have a it would work perfectly. Right. If you have executable like executable as in like let's suppose TCP dump with LIPP cap both are compiled with ASAN. It works perfectly. If you have TCP dump compiled with ASAN and LIPP cap not compiled with ASAN still it would work. But if you have TCP dump with no ASAN, like not compiled with address sanitizer, but library explicitly have compiled with sanitizers, the program won't work because there's a huge dependency gap between both of them. So my suggestion would be used enable enablement of address sanitizers in the executable and in the library both itself. So that's how we deal with shared libraries specifically to address sanitizers. The binaries which we create using address sanitizers. Then we fuzz on this using AFL. That's what something which we are going to have a look on it. Now what happens when you enable AFL and ASAN together? This is what something which we want to look for. So hold on. Before we get over there, there's something called as a LLVM symbolizer. Now if you see this, this, this specific start trace over here, you see the addresses being discovered, right? Now if I want to know, I don't want this address. Basically I want to know the actual line or code. Then you can use a LLVM symbolizer. Now this is a bonus slide. Basically you can enable LLVM symbolizer in your compilation itself. Once when you run it rather than the address, memory address or the offsets, basically specifically the symbols, you will be able to find the file names or the line numbers for that matter using LLVM symbolizers. So again, back from 2016, Microsoft has enabled LLVM symbolizers and sanitizers in Visual Studio. So if you are a product, if you are working for a product based companies utilizing dot net as a core component, even you can check runtime bugs in your product itself or in your platform post this workshop. So that can come handy over there. If you're a researcher, you can utilize this in your, any sort of research. If you are playing any CTF, this can come handy as well. So I hope that's pretty much clear. I'll be sharing this entire presentation post quickly after my workshop so you can refer all the URLs and everything. Okay. So what happens again? This was the question asked by someone, like what happened when we enable AFL plus ASAN, right? There's a huge massive amount of coverage, which comes out of the both, when both gets combined basically, right? We are not LLVM sorry to interrupt. Okay. So there is a, you can export in the environment variable itself. So if you use LLVM underscore symbolizer equals one to the best of my knowledge, it would, and if you have LLVM or clang perfectly installed, so LLVM have different versions. So I think LLVM symbolizer comes by default in LLVM version five and above. So if you export this in your environment variable and then you compile the program, then you will find that LLVM symbolizers are enabled. And for VB.net, I'm not, I'm sorry, not for VB.net, but for the visual studio, I guess there is a write up on docs.microsoft.com itself, that how you enable sanitizers when you are compiling the source code of.net. So I can share that if you want. Yeah. Can you share it in the chat? Yeah, I'll do that. Yeah. I'll just, I'll just look for it and I'll share it. No problem. Okay. So we were discussing about AFL plus ASAN now, AFL find bugs during the execution of a program. Now ASAN find bugs during the runtime. When we compile both of it, there are chances that we will discover certain bugs, which can be missed by AFL, right? So when we compile address sanitizers with AFL, that means if AFL is skipping any part, because AFL only catches those bugs, which triggers crash, right? Over here, it, it catches bugs, which was actually executed at the runtime itself. So if AFL excludes those specific path, ASAN will capture it and your framework will show that, okay, that is one crash triggered when, but over here you won't be actually able to trigger a crash. If you have enabled address sanitizers, you can only see the stack trace, right? So address sanitizers basically detects bug, which are actually not being seen at the, it's not been actually executed at the user level. You cannot replicate it as a proper crash until unless that specific piece of code has been called somewhere, right? So once when you enable AFL plus ASAN, it's a massive energy to, to compile and to fuzz a program for that, everything remains the same. Over here, I have also used symbolizer. So if you want AFL plus ASAN plus symbolizer, so this is the go to command cc equals AFL hyphen clang hyphen fast. Now over here, I'm using clang hyphen fast. You can use clang. Then it's clang hyphen fast plus plus then ASAN underscore options equals symbolize equals one and AFL underscore use underscore ASAN equals one, one stand for the enablement and zero stands for the disable of the address sanitizers. And similarly, you can do it for MSAN, AFL underscore use underscore MSAN equals one. Now I would request you guys to go back to wave info because it's a very small program and export all this environment variables and then try to fuzz it. However, you won't find much difference because it's a very small program, so I really want you guys to have a very quick look on how things work. There would be a huge difference in stats or at least in the new part discovered. So let's just take 10, 15 minutes maybe. You can go ahead, do it on the wave info. If any questions, just pass me on this call. Sorry, sorry to interrupt again. So this ASAN will include MSAN, right? Yeah. Okay, and this is a better option than AFL Hardin. Yes, like I prefer it personally. So it's your personal choice. It totally depends. I personally like address sanitizers. You can go for, you can try for Hardin as well, AFL underscore Hardin. Thank you. Can you explain the difference between running a binary and execution means? So basically what happened is you have a binary A which has to reach to a point called Z. And when it reaches to a point Z, and it discovers an output O, that means it executed the entire A to Z flow to discover that O, right? That's called execution. In the runtime, you start with A, you are going to BCD, but in the runtime itself, it discovered that there is somewhere O. It hasn't reached Z yet, but it has found O. So that means the very quick time lapse between the execution from point A to Z somewhere ASAN finds the bug. So that's why we say it's a runtime bug basically. Got it. Thank you. Dheerish, during the make, do we get to know that address sanitizers have been activated? Is there a way to find out? Yes. So if you have exported it properly, it would say that compiled with ASAN mode. So if you see over here, it says that 64-bit ASAN slash AMSAN mode. Oh, actually I compiled it in Ben Newton's. It should work for Ben Newton's as well. I don't see it as a problem. Just give me a minute. Dheerish, I'm creating some post-credits. Just a minute, just a minute. I also got an error. Okay, perfect. So what happened is, what this error means is basically address sanitizers requires a lot of memory, right? So over here, that would be a quick change in command. So it would be AFL-fuzz. Oh, sorry. AFL-fuzz-m-none. That means you are saying memory is none. You can utilize whatever you want. Then you try to go ahead with your own command. That should work basically. So there's a good catch again. If you are using address sanitizers in AFL, make sure that you have an M space none. None means you are giving full right to utilize 100% of your CPU or the memory basically. Or else you can specify 90, 186, and so on and so forth. I go for none basically. You can try whatever you want to. I think it should work. Yeah, working with none. Okay, perfect. By compiling with bin utilities and getting an error, while giving these plugs. Yeah. So yes, exactly. It should, it should, it might give some, the reason because older versions are not that, the code was not that flexible to, am I audible? Because my internet connection says it's unstable. Yeah. Yeah. During configure, like while giving CC is equal to FNC LAN. And with that I'm giving these ESN option is going to symbolize equal to one and thought slash configure them getting an error. Are you compiling the latest version or the older version? The older one. Okay. Yeah. So older one should, older, older one will have few errors because you know, older programs where, cannot be embedded to the latest ESN categories these days, right? So you, you might found certain errors which needs to, which you have to resolve it. Just give me a minute. Let me see what all errors do we get? But yes, because bin utilities is almost, this is the older version is almost five to six years back. And ESN is something which is a new technology. And that would be a very cross gap between both of the technologies. So if we do bin utilities to make clean, so we either we have to resolve those errors manually or you can try it on the latest version. Compiling with ESN as well as AFL. Do we need to change, make any changes in make file also? No, no. So you can export ESN to the environment variable itself. That should be fair. So you don't have to change anything. So here I'm exporting it as an environment variable. Then I'm trying to configure it. Okay. Actually I gave it with the command. No, that's fine. You can export it. If you export it, I think, things should work properly. Just give a try. Mine was also means while combining. That it is only showing non-hardened mode. I didn't got your question. So by here, for me it shows that it uses ESN and ESN mode, right? So, okay. What you can do is first export. So, okay. That is an error basically, right? It says error in in complete element, right? But if you see, did we build the file? Yes, we did. We still did build the ledlf. So we can exclude this error. Anyways, the point is what I would suggest you guys is to export the ESAN first into the environment variable using export afl underscore use underscore asan equals one. And then go ahead with the compilation and in the older version itself. So I'm doing it in the older version. If you do so, you will find that you will give a text saying that it uses ESAN and MSAN option mode enabled. Yeah, when exported, I got that. I think I gave the wrong, okay. I think I gave the wrong one. No problem. I hope that's clear. Yeah. It works when we export the environment variable. Otherwise it doesn't work for me. Okay. Even I did the same. So there can be different ways to do this. I personally go for exporting the address sanitizers into the environment variable itself. That's very much flexible for me. You can use, I'm sorry. Yeah, you can use. I was going to the discord channel. Yeah. This is exported to the environment variable and then try to configure it. I think it should work. One more question. So for C C long fast and C long. So these variables are different. No, no. So everything remains the same. Only the cross compilers are different. So for clang fast clang fast plus plus the environment variables remains the same. Okay. Can you go back to the slide? Just a minute. Yeah. I'm just replying on discord. Okay. Yeah. Yeah. Actually I use this one. Isan underscore option is going to symbolize equal to one. Yeah. It was giving an error. If I use both of them, but if I use just a fail underscore, you use Isan equal to one, then it doesn't throw an error. That's fine. If it gives error, you can export it. It should work properly. And the, the fashion which you are also working for it's also pretty much fair. I think it's fair enough. Okay. So both of them are to be used or only the last one can be used. You can use only Isan. That's fine symbolizers. If you really want to, if you get certain situation where address you want to convert address to the line code, then go for symbolizers basically, or else you can always prefer address sanitizers with AFL. That's fair. Symbolize option should be, should be used when we already know that there is a crash. There is a crash triggered and in that crash itself, you are not getting the line codes or line number. Yes. And you have addresses. Then yes, exactly. Then you have to go ahead and use symbolizers. Okay. And when we are using make files, like when we are making changes in the make files, do we can be exported there also? Do we need to give it in some other variables? So you can export it. So if you have make file, if you don't want to change it into the make file itself, you can simply go ahead and export it. The reason why I, at the initial exercise I showed, because you know you either have to gain knowledge from both the prospective. If you don't want to export it, you have to look for, because few make files are very much big. So I really wanted you guys to understand that you can edit in make file as well and you can export it as an environment variable as well. Okay. Can you show it in the main file? How do we add this variable for ASAN? Or we can just add this export command in the BASH RC. Export one would be fair enough. It would be very simple and easy. If you go to left wave. We can also like add this export command in BASH RC file. Yes, exactly. In the environment variable, you can by default have it in your BASH RC. And if you know that operating system is specifically mean for fuzzing, then you don't have to export it again and again. So that's, that's what we where we come. That's what where we came from, right? If you have a Zen server setup or any, any fuzzing instance on the cloud, specific for fuzzing so you can enable ASAN symbolizers, the change of the compilers from normal GCC to AFL GCC, then everything would be perfectly working over there. So I guess we have to cover a little bit more and we are running out of time. Thumbs up for the people who have completed ASAN in this part, please. At least the buffer.cc program, not the, the waving for the complex one. Perfect. We'll move on. This is the last quick topic for the introduction to fuzzing. We'll talk about protocol fuzzing in this case. So let's have a look. So for protocol fuzzing, we are using DUNA. You can also use Bufas as well. Now Bufas is the Python module. You can use Bufas. You can use DUNA for that matter. In this, in this workshop, we are specifically looking for DUNA. So DUNA is capable of fuzzing STTP, FTP, SMTP, I guess LDAP as well, different other protocols. So let's quickly jump to DUNA, what, how things work in DUNA. I'll just give a very quick idea. So you should have DUNA by default installed in 1.2. And let's run Python-M, simple STTP server. Right. It runs on port 8,000. Let's go to DUNA. So we have multiple arguments over here. Hyphen M, STTP, hyphen T for target, hyphen P for port. Right. So we are using STTP modules. So that's why, because we ran simple STTP over here in Python. Then simple STTP, hyphen T for targets. It's my local host, 127.0.0.1. And hyphen P is 8,000. If I run this, it's start fuzzing the STTP protocol. Now, what it does basically, DUNA has a very exhaustive list of fuzzing such sort of protocol. Now, for example, it is just sending AA in the URL itself. Now, slowly and gradually you will see it will start sending more big A characters. Then it will start adding different ASCII characters. It will change the method of sending those characters. It will start changing from get to post, post to head, head to delete, put and etc. So basically what DUNA is trying to do is it is sending forcefully malformed URIs to the end server just to make sure that the server is crashed somehow. So this is one of the way you fuzz STTP protocols. You are sending any malformed URIs to the end. So over here you can see these syntax got changed. It is sending the slashes, the backward slash, the forward slash. Then you will find that it will start sending the backward slash with the different methods. So how DUNA works basically, if you see the source code of DUNA because it is open source, it has different format like A into 33 times, A into 24, then backslash into 26. So everything is being defined. There is this different function defined called format strings where it sends high percentages into four, percentages, percentage P, percentage X, percentage D and so on so forth. So basically it has a combination of every possible keyboard, every possible keywords which we have in our keyboard and it sends or passes it has a URI basically. So over here we are fuzzing Python simple STTP server. So if you can quickly get your hands on this part, then we can move forward. So we ran Python simple STTP server on one terminal and then we use DUNA to fuzz it. Do we have any latest fuzzers for STTP? DUNA is, I mean, I have checked the repository. Yeah, it's old. Yes, DUNA else. So yeah, so we have AFL. So there's an extended version of AFL itself. I'll just share the URL in the chat, which does the network protocol fuzzing. But to be honest, there are certain test cases which DUNA performs, which AFL might skip. And there are certain test cases which AFL performs and DUNA might skip. So you know, it's always a, it's a rat and mouse game. If we fuzz our server with AFL and with DUNA, that would be the best part. And I personally have discovered few vulnerabilities using DUNA in known products. So, but still I will share the URL for the network protocol fuzzing. There's this guy who wrote an extended version of AFL which specifically fuzz network protocols. Yeah, recently someone from China gave you a packet fuzzing also like to pack pcap, which captures. Yeah, exactly. So you capture the pcap files and then you can fuzz that. Yep. Yep. So these all are extended versions of AFL basically. The mechanism remains same, but they are different functionalities to fuzz. DUNA is just a very basic idea about how we fuzz STTP network fuzz are basically. We are getting some error like custom ASN underscore option set without abort on error equals to one. Can you share this screenshot please on the discord? Oh, okay. So just moving forward in the meanwhile, we'll stop DUNA for now. You can navigate to CD fuzzing. There is this PDF.js. Now PDF.js is a rendering engine which is used in Mozilla Firefox to render PDF files. Now over here, you can use pseudo. You just navigate to the PDF.js and do pseudo npm install. Let it install. Now what I found was the, the, the PDF.js have a development server, which can be invoked using Gulf server. So it's a command where it enables a STTP protocol in the PDF.js, which is a rendering engine, which comes with Firefox, but they also have a development server at the backhand with doesn't, it's not part of Firefox, but they do have it for their development purpose, which hosts a few STTP, which utilizes STTP protocol on 8888. Now if you use DUNA over here, so it's start fuzzing as well, but over here by default, there's no debug enablement of Gulf server. That's why you are not getting any response or you are not finding anything which is, which you can see or visualize. So in such case, you can use TCP dump or Wireshark to capture all the packets on the local host itself and then you can analyze it further. Right. But when I, when I saw this, so I ran DUNA on the screen itself for, for maybe two to three hours and I end up with this command, like if you see call hyphen v STTP, 7.0.0.1 on port 8888, if you share such values and hit enter, basically the development server gets crashed. So this was reported to the Firefox and they basically patch it. So the reason was because, you know, percentage S was not it was a mile formed URI, first of all, and it was not being decoded properly. When it receives the request, right? So they use now. So currently the path is they use part dot normalize and then they decode URI for certain parts. So for example, local host 8888, percentage S, percentage S would return 400 now in the latest version of PDF.js. So I utilize DUNA and BOOFers both in this. I have a quick write up using BOOFers on this URL. I'll be sharing that as well. So I would request you guys to quickly run through this exercise. So I can just, I'm getting a few questions one on one. You can use npm install, pseudo npm install. Then you can use Gulp server to spin up your STTP server. And you can send col-vsttp127.0.0.1 with percentages, percentages. Now, to be honest, I, it took more than two to three hours or maybe five hours to find this, but you can use BOOFers or DUNA in such case to fuzz STTP or STTP as base modules. How much time is remaining? We are almost running out of time. It's just, I guess, 10 minutes or five minutes, 10, five minutes maybe. Okay. So I'll just move forward just a minute, just a quick thumbs up on the, the discord if you are done with the DUNA exercise. Which is the challenge on which I should change it. I'm not able to pick up. Which one? I'm sorry. I didn't got you. I went to use this discord. It's the first time. So I'm not able to understand where to change the screen shot. Okay. No problem. So we'll figure out some other way on this. No problem. You can email me. That's fine. If it's working on discord. Yeah. Yeah. So moving on, I got a question that how we find such targets. So now what we have learned so far can come handy when you do any research, but you, there, there is a Node.js modules, which is part of our hacker one.com. Apparently they don't offer bounty, but you know, if you gain a lot of reputation, you will start getting the private bounties, private invites as well. So as one has got few of them, you can use it. Sorry. Node.js have few modules, which is part of hacker one. You can use HTTP hyphen server, simple hyphen server serve and local web server and simple STT server. They all are Node.js. Basically you can utilize them to to. So basically these are some set of targets, which you can use with this. You find any vulnerabilities. You reported via hacker one and again, reputation to find more private invites. So this can be few targets when you start fuzzing with it. So here are some research with, which I would like to showcase. Now it's, we are almost at the edge of completing the workshop. So back in 2019, I first WebKit, someone has already shared the link on discord itself. And I found a small denial of service in WebKit where if you pass a 5000 in script like an in an alert box, the WebKit get crash. So it was in the UI subsystem process of the WebKit, which was being also patched. So you can use, you can refer to the below URL to replicate the same thing or to start something from scratch. CV 2019 8375 was been assigned to this. You can have a look, read on it if you want. I have first Wolf SSL as well. Now Wolf SSL is the SSL library, which is being used by most of the IoT devices. I found a heat-paste buffer overflow where if you send 16 KB of test packets into a test program, it causes an heat buffer overflow. Apparently I was able to find only this vulnerability in the test binary, not in the actual Wolf SSL binary, but still this was being passed on the pull request 2013. You can refer to this URL for the further communication. I have first Gatelab. This was a pretty much straightforward. You can use Gatelab or discover Python C print A to 20 times. It have a crash. Basically it's a very generic plain vanilla stack buffer overflow. CV 2019 6498 was assigned to this at that time. I participated in Putti. Putti had a bug bounty program back in those days and I found memory uninitialized memory bugs using fuzzing technique and enablement of memory sanitizers. I submitted two bugs to different functions where I had been having uninitialized memory in PSFTP. They both were prized as an open. They both were prized as a low severity, but it was being passed in the latest version of Putti. How you can enable fuzzing plus IVB? There is this concept called IVB called internet bug bounty program where you go to hacker one directory, apply for the below filter like you can enable IVB and you can select for active program. So basically if you first Ruby, they have active bug bounty program. If you first PHP, they have active bug bounty program. If you first call CURL call, they also have a bug bounty program. So these all are open source. You can go to their activity dashboard and see what sort of bugs people are reporting. And at least you can try replicating them and then you can go ahead and start everything from the scratch. Right. So if you are a developer, you can utilize whatever I hope you if you're a developer for a company, I hope you've got certain chunk of knowledge where you can enable those in your in-house product. If you are a researcher, you can utilize this in your research perspective. If you mold, if you want to mold this knowledge into bug bounty, you can go ahead with the hacker one. More fuzzers ahead. We have Win AFL for fuzzing. So this is again just an FII. If you want to fuzz binaries in Windows, we have Win AFL. If you want much more powerful framework apart from AFL, you can go for Hong Fuzz. If you want to first Python based binaries or anything specific to Python, you can use TT and say you have cluster fuzz as well, which does CICD for the entire fuzzing automation. Then you have fuzzily if you want to fuzz JavaScript engine. Fuzzily can be used to fuzz browser engine. Someone asked the question in Discord. So you can use fuzzily for that. You have a readme file. Readme for that specific how you can start fuzzing fuzzily with JSC, Chakra core or WebKit basically. If in case you have any doubt specific to fuzzily, I'm happy to help. You can buzz me on Discord one on one. So and apart from that, there are tons of fuzzers out there. If you go to GitHub repository and search for fuzz or keyword and navigate to repository, you will find a ton of frameworks. People are writing it for fuzzing XYZ stuff. So this is not an exhaustive list. So there are many out there. So that's it from my side. Thank you very much. I hope you got something from this workshop. I would really request you guys. If you like the workshop, tweet it on random deal share your thoughts on Discord. That would really encourage me to take workshop in different conferences. If you have any issues, message me on dealer.input 0.io. And I'll be just sharing the slide just after this. So that's all from my side. Thank you. Thank you very much. Can we share it on LinkedIn? Oh, okay. I'll do that. No problem. Yeah. No, no. I am asking. Can we share? Yes. Yes. Of course you can. Yes. Very much. Thank you. Thank you very much.