FUZZING FOR BEGINNERS (KUGG teaches STÖK American fuzzy lop)
Summary
TLDRIn this video, Stick teams up with Christopher, aka Cook, to delve into the basics of fuzzing using AFL (American Fuzzy Lop). Christopher explains the process of using AFL to find bugs in binary programs through automated testing. They discuss the importance of compiling programs with instrumentation, setting up the environment, and running AFL on an HTTP server. The video demonstrates how to identify and analyze crashes, offering insights into bug hunting and reporting. Additionally, they highlight the value of fuzzing for various parsers and the potential for exploiting vulnerabilities.
Takeaways
- 😀 Introduction to Fuzzing: The script introduces fuzzing as a method to find bugs in binary programs by sending numerous requests into a system.
- 🔧 AFL Tool Overview: AFL (American Fuzzy Lop) is highlighted as a fast testing tool used for fuzzing, which can automate the process of finding bugs.
- 🛠️ Compilation with AFL: The script explains how to compile a program using AFL by replacing the GCC with AFL-GCC and setting the CC environment variable.
- 🔬 Instrumentation: AFL's instrumentation feature allows for tracking the internal state of a program during execution, which is useful for identifying when specific code paths are reached.
- 🔄 Synchronization in Multi-core Systems: AFL can synchronize output across multiple cores or machines, which is beneficial for large-scale fuzzing operations.
- 📁 Output Directory Importance: The output directory in AFL is crucial for syncing results, storing crashes, and managing the fuzzing queue.
- 🚫 SSD Fuzzing Caution: The script advises against running fuzzing on SSDs due to the high volume of writes, suggesting the use of RAM-based storage like tmpfs instead.
- 🔄 Fuzzing Automation: AFL automatically mutates input data to discover new paths within the program, learning from each iteration.
- 🛑 Handling Crashes: The script discusses how to handle crashes found during fuzzing, using tools like gdb to analyze and understand the cause of the crash.
- 🔑 Security Implications: Fuzzing can reveal serious security vulnerabilities, such as privilege escalation and denial of service, which can be critical in systems running as root.
- 🔍 Debugging and Exploitation: The process of using gdb to debug a program post-crash is outlined, which is essential for creating proof-of-concept exploits.
- 🌐 Community and Resources: The script mentions the availability of web casts and the F-Secure Lab channel on YouTube as community resources for learning more about fuzzing.
Q & A
What is AFL and what does it stand for?
-AFL stands for American Fuzzy Lop, but in the context of this script, it refers to a fast testing tool used for finding bugs in binary programs by sending a lot of requests into something.
How does fuzzing work in the context of AFL?
-Fuzzing involves sending a lot of random inputs into a program to see how it behaves. AFL takes an original input and transforms it in each iteration, running thousands of iterations every second to test the program's response to various inputs.
What is the role of GCC in AFL?
-GCC is a compiler used in Linux for compiling software. In AFL, you replace GCC with AF-GCC, which compiles the program with built-in instrumentation, allowing AFL to understand what's happening inside the program during execution.
What is instrumentation in the context of AFL?
-Instrumentation in AFL refers to the process of modifying the code being built so that every time the program reaches a certain state, it is registered by the instrumentation. This helps AFL understand the program's internal workings and behavior.
Why is it recommended to not run AFL on SSD drives?
-SSD drives are not always ready to handle the high volume of writes that AFL generates, which can be harmful and wear them out quickly. Instead, using tmpfs, which is a temporary file storage in RAM, is recommended for the output directory to avoid excessive writes to SSD.
What does the output directory in AFL contain?
-The output directory in AFL contains the results of the fuzzing process, including crashes, hangs, bitmaps, statistics, and other data. It is also used for synchronization between multiple machines or cores running AFL.
What is the purpose of the queue data in AFL?
-The queue data in AFL shows the original file in the queue where it started and its current position. It helps AFL learn from each iteration and adjust its approach, flipping bits and learning what type of data the program wants or doesn't want.
How does AFL handle synchronization in a multi-core or multi-machine setup?
-AFL uses the output directory to synchronize multiple slaves in a multi-core or multi-machine setup. The master process gives the slaves a queue of tasks to do, ensuring they always have work to do until the master updates the queue.
What is the significance of finding crashes during fuzzing?
-Finding crashes during fuzzing is significant because it indicates potential vulnerabilities in the program. These crashes can be the starting point for further analysis and exploitation, leading to the discovery of serious bugs or security issues.
How can the crashes found by AFL be used for further analysis?
-The crashes found by AFL can be analyzed using tools like gdb to understand the program's behavior at the time of the crash. This can help in identifying the cause of the crash, such as a segmentation fault or memory corruption, and potentially lead to the creation of a proof-of-concept exploit.
What is the role of gdb in analyzing crashes found by AFL?
-Gdb (GNU Debugger) is a tool used for debugging programs. It can be used to analyze crashes found by AFL by running the program with the problematic input and observing the behavior, stack trace, and register states at the time of the crash, which can help in understanding and exploiting the vulnerability.
Outlines
😀 Introduction to AFL Fuzzing
In this introductory segment, Stick and Christopher (also known as Cook) discuss the basics of fuzzing and AFL (American Fuzzy Lop). Cook explains that AFL is a fast testing tool designed to find bugs in binary programs by sending numerous requests into a system. The process involves taking an original input and transforming it through thousands of iterations per second. Cook demonstrates how to set up AFL by replacing the GCC compiler with AF-GCC and setting the CC environment variable. This enables the compilation of programs with built-in instrumentation, which allows AFL to monitor the program's state and detect when it reaches points of interest, such as breakpoints.
🔍 Fuzzing an HTTP Server Configuration File
The second paragraph delves into the specifics of fuzzing an HTTP server's configuration file. Cook discusses the importance of fuzzing the configuration file parser, especially when an attacker might have arbitrary write access. The goal is to potentially crash the process and exploit the memory overwrite. The input for AFL in this case is the configuration file, and the output is a directory where AFL syncs its findings. Cook also mentions the importance of not running AFL on SSD drives due to the high number of write operations, which can wear out SSDs. Instead, using tmpfs (temporary file storage in RAM) is recommended. The discussion also touches on the ability to synchronize fuzzing efforts across multiple machines or a cluster.
🚀 AFL Fuzzing in Action and Finding Crashes
In this segment, the focus is on running AFL to fuzz an HTTP server and observing the results. Cook demonstrates how AFL quickly identifies crashes, which are the starting point for further analysis. The discussion includes the scalability of AFL, which can be run on multiple cores to increase the number of attempts per second, potentially leading to the discovery of more bugs. Cook also explains that AFL can be run in the cloud or on multiple cores to speed up the process. The output directory is highlighted as a crucial component, containing information about crashes, hangs, and the queue of inputs being tested. The segment ends with a look at the crashes directory, which contains the configuration files that caused the crashes.
🐛 Analyzing Crashes and Using GDB
This paragraph discusses the analysis of crashes found during fuzzing. Cook explains that the output directory contains a 'crashes' directory with files that caused the crashes, as well as a README file that provides information on how the bug was found. The discussion moves to using GDB (GNU Debugger) to further investigate the crashes. GDB is highlighted as a valuable tool for security research and CTF competitions. Cook demonstrates how to run GDB on the HTTP server and analyze the crash by setting breakpoints and examining the program's behavior. The goal is to understand why the program crashes and potentially exploit the vulnerability.
🔎 Exploring the Impact of Fuzzing and Reporting Bugs
In this segment, Cook and Stick discuss the implications of fuzzing and the process of reporting bugs. They mention that fuzzing can lead to the discovery of denial of service vulnerabilities and privilege escalation issues. Cook shares his experience of reporting a bug to an HTTP server vendor, providing details on how the bug was found and the stack trace obtained using GDB. The conversation also touches on the potential for fuzzing to uncover bugs in various file formats and parsers, which can be exploited for different purposes. The importance of responsible disclosure in bug bounties and penetration testing is emphasized.
🌐 Community and Resources for Fuzzing
The final paragraph wraps up the discussion by highlighting the community aspect of fuzzing. Cook mentions setting up webcasts to help people get started with fuzzing and provide a platform for live interaction and support. The F-Secure Lab channel on YouTube is introduced as a resource for those interested in fuzzing. The conversation concludes with an appreciation for the learning experience and an invitation for viewers to join the fuzzing community and explore the potential of AFL and fuzzing techniques.
Mindmap
Keywords
💡Fuzzing
💡AFL (American Fuzzy Lop)
💡Instrumentation
💡GCC (GNU Compiler Collection)
💡Configuration File Parser
💡Crashes
💡SSD (Solid-State Drive)
💡tmpfs
💡GDB (GNU Debugger)
💡Segmentation Fault
💡Privilege Escalation
Highlights
Introduction to using AFL (American Fuzzy Lop) for beginners as a fast testing tool to find bugs in binary programs.
Fuzzing is the process of sending numerous requests into a system to find vulnerabilities.
AFL works by taking an original input and transforming it through thousands of iterations per second.
The importance of automation in fuzzing to ensure efficiency.
Setting up AFL involves using a compiler like GCC with an environment variable CC.
Compiling with AFL involves instrumenting the code to track program states.
Instrumentation allows AFL to understand and learn from the program's behavior during execution.
AFL can be run on multiple CPUs with tuning options for performance.
The discovery of a vulnerability in an HTTP server during fuzzing sessions.
Explanation of how fuzzing an HTTP server's configuration file can lead to crashes.
The use of an output directory for AFL to synchronize findings across multiple processes or machines.
Avoiding SSD drives for the AFL output directory due to high write operations that can wear out SSDs.
AFL's ability to mutate input data to discover what type of data a program wants or rejects.
AFL's use of a queue system to manage input data and mutations.
Finding crashes with AFL and the significance of these crashes for vulnerability discovery.
Using GDB (GNU Debugger) to analyze crashes and understand the underlying code issues.
The process of reporting a discovered vulnerability responsibly to the affected vendor.
AFL's continuous learning and mutation process until it exhausts the search space.
The potential for fuzzing to be applied to various file formats and parsers in security research.
The value of fuzzing in bug bounty programs and penetration testing.
Upcoming webcasts on fuzzing to help beginners get started and troubleshoot issues.
F-Secure Lab's initiative to create a community around fuzzing to increase its adoption.
Transcripts
hi I'm stick and today I'm gonna learn
something new and for this reason I
brought on Christopher yeah also known
as cook to help me understand the
beginner's guide to fussing or a mean
audience in a beginner's guide but it's
gonna be an introduction to using AFL
thank you so far
hi I'm cook hi cook cook instead show
yeah so we you and I outside of this
camera
situation has had been has been playing
around a little bit with fussing and I
kind convince you to get on here and
teach me and others how this actually
works and talk a little bit about
fussing so without any further ado
please take it away
all right so today we're gonna play with
AFL AFL is fast testing tool and it's a
method to find bugs in binary programs
fussing is sending a lot of like
requests into something right is that
the idea yeah so you have an original
input in a dictionary of possible inputs
and then it's taking that original thing
and transforming it every time it runs a
new iteration and it runs thousands of
iterations every second so this is
automation yeah definitely you have to
automate it otherwise it won't work okay
show us how you did it okay so
essentially when you want to do this
when you want to run AFL you have to use
a compiler so compiling software you do
it with in Linux you do it with GCC
normally and GCC is by the compiler
program called make or make file sis is
define an environment variable called CC
so CC equals GCC is an environment
variable that's automatically assumed
every
you do a compilation and compiling
programs means to take all that C code
and turn it into turn it into a binary
program cool with AFL you're going to
replace GCC with with your thing so our
thing is AF - GCC and setting that
environment variable we can now compile
the program with something called
instrumentation built-in and that means
that it's changing the code that you're
building so that every time it comes the
program turns into a certain state then
that's registered by something called
the instrumentation instrument or the
instrumentation state oh cool right so
having instrumentation means that you
can know what's going on inside of the
program when you run it and this is a
really nice feature with a FL that other
Foster's aren't that good at and that
means that if al can understand when you
have reached into a point that you're
interested in reaching say you want to
you want to break a certain point in a
certain place than a FL will know if you
are there so it's some kind of break
points so taking its just measuring all
the time like where are you in the code
and if something breaks breaks it's
gonna know instantly yeah yeah it's
definitely like a break point I think
this is more more what you could call a
function hook where you take a regular
function you put yourself in a place of
it and and that's something that it can
put into some kind of a live
documentation that it's understanding
and learning from that so it's a sort of
a self learning program cool so once you
have compiled your program you can start
it using the AFL foster that looks a bit
like this AFL fuss is name of the
program you want to run efl by the way
is a program that you can download using
apt-get install AFL that's it
so it's it's super easy to set up just
get started and yeah now you're up and
running on different CPUs you have some
different tuning options that you want
to set and those tuning options is
something that AFL will tell you what to
do with so you can adapt to multiple
cores and you can do different things
but it depends on your architecture
we've already done this but if I will
tell you exactly what you need to do for
your CPU cool so the - I argument it
gives you the inputs to the program and
we're gonna take a look at the input to
this program because we are today
fussing HTTP server no I got cool and
the HTTP server we are fussing we did
one more take with this last week and we
are ready to publish it when we realize
that we have found this here today and
we had to report it and that meant that
we couldn't really publish it at that
time right so this is the second
recording for that obviously yeah when
you financier days do during your
fussing sessions it's a good thing to
report those yeah so we're gonna show
you how we found that Saturday but we're
not going to show you what program it's
in but it's a HTTP server we'll give you
that much so if you look it into the
input directory I have a default
configuration file that sort of looks a
bit this is this a fake configuration
folder I wrote it's this similar to the
default file where the domain domain
name is f-secure comm which is my my
employer the the configuration file is
pretty straightforward we are today
going to fuss the configuration file
parser and the reason why we want to
fastest parser is because we are
assuming that an attacker has arbitrary
write access but once the escalator
privileges to root or get access to
whatever that server is is doing and
since you have write access if you write
to that configuration file something
arbitrary and bad
then maybe you can make the process
crash and if the process crashes then
you can overwrite this memory and that's
what we're gonna try to do or already
used wait for it let's say that we had a
malicious conferral that we created and
uh well we would use do is to either use
crash the daemon itself right or or just
wait for it to reboot and then hopefully
you know nobody's noticing what's going
on in wala suddenly we have root axes
yeah exactly
and in this case the input to a FL is
that configuration file so the default
the default configuration file is pretty
much what we need as an input as an
output output in this case is a
directory where a FL is syncing whatever
it's doing with other processes so if
you run this with multiple course you
can synchronize that output using the
output directory and this is something
that you can synchronize between
multiple machines even so if you're
having a cluster running it and you want
all these machines to know what's going
on
that's good things just meant can you
map this over network or is that not
recommended yeah you can so what what
the master process does is it
synchronizes multiple slaves using the
output directory and then it gives the
slaves a queue of things to do so if
there is a certain lag between the
machines that queue will sort of work
itself out so as long as the lag is not
longer than the queue then the slaves
will have something to do to do until
the master realizes that this is where
we want to go with with the fussing so
all the directory is pretty important it
also contains wherever our like crashes
and things that we found out during the
this attempt is going to end up in the
output directory
oh cool I got a question though and I
know last time we talked a little bit
about it we and it didn't really strike
me self out for me but you've mentioned
that it would be a good idea to not run
this on SSD drives right so the output
directory is some directory that is
written to a lot of times so it's
written for every single instance in my
case is writing 2000 times every second
and that means a lot of Rights and for
an SSD that can be a bit harmful SSDs
are are not always ready to handle that
much data and it can wear them out
quickly and therefore there is something
called tmpfs which is like what do you
have in /tmp in your machine where you
can write as many times as you like
because it's on the RAM and it's all
very quick so so we have the input which
is the config file actually we can have
a directory full of inputs so if we had
a bunch of other bunch of other config
files there that would be fine and that
gives a file inspiration to how to
destroy things oh okay so it's fetching
all this other stuff as well and yes
thinks about maybe this you can put
random data in there and you can put
legitimate data in there eventually AFL
will figure out what type of data this
program wants
so it's or doesn't want so the next
argument for AFL is to type in hd-dvd
and that's the name of the server that
we are fussing and there C is the
arguments for a config file and then we
type in at-at-at that is the variable
where EFL will input the forcing
mechanism so this is where it will go
and attack so if we run this it's going
to initiate by trying to find basic
paths into the program and just try to
understand the program and now it's
started and even like in the first
second here we found a crash and when
this turns red and it says one unique
crash then we have essentially we have
the beginning of a CRT
because this is yeah and that's not the
time it takes to sometimes there's the
second one
and so now we're running in two thousand
attempts a second you can I mean you can
scale this as much as you want to if you
have more course you can scale this much
much faster and if you do that then you
can find more bugs basically and if you
are pressed with time let's say that
you're a developer and you want to test
your own software then maybe you want to
do this in the cloud or you run it on
multiple cores and you get it up to
maybe thirty thousand twice a second
because that's gonna take the tax base
or make it much shorter absolutely it's
like if you can run this like not just
one time faster like ten or twenty times
faster yeah horse you're gonna save like
a lot of time where it yeah isn't it
gonna be like very CPU intensive and
very expensive that if you let's say
you're putting it in a cloud storage
somewhere yeah I mean it uses only CPU
so if you have a story solution where
where CPU is cheap and the rest is
expensive then that's fine
but but it's using a lot of CPU and
somewhat a bit of network if you have it
networked but but it's only using as
much as you allow it to use so you can
make it make it crash and hang in
different different ways
damn it that means that I'm gonna have
to buy back all my old rack servers now
again yeah yeah so CPU cost nothing if
you own the server if you have your own
servers and this is what they're for
right used abuse for cracking and CPUs
for fussing yeah oh man oh man so right
now we're running on 12% of the CPU that
means in this case that we're running on
bond core only which is enough for our
example and in another caste we can show
maybe how to increase that number
because if you use more than or up to a
hundred percent of the CPU that means
all course then you can then you can
make a lot of damage
hey let's do that that would be exciting
but and it's this ever going to stop
though or or it doesn't ever feel like
I'm done now this this never exhausts
because it actually has ways of muting
the output and coming up with new ideas
until forever so I think this can pretty
much go on forever in this case but you
can exhaust the search space for a given
input so imagine you have you know that
a program only takes true or false as an
argument then that search space will be
exhausted pretty quickly and the program
will just run on hot fuse basically cool
so we we currently have two crashes what
does that really mean like what do one
simply do with the crashes yeah so now I
interrupted the program typing control-c
and it says we're done have a nice day
thanks and I'm done too right so now we
have the output directory let's take a
look at that so in the output directory
you can see the crashes directory the
first bitmap that gives an information
about where in RAM are we at this point
statistics hangs that's an option to
crashes so the hang is when a program
doesn't finish in a given certain time
so you put a timeout on a program you
can assume that it's not supposed to
hang until this or that or it's supposed
to finish before that's the particular
time and and every input that exceeds
that ends up in hang block data don't
know the queue is where the next input
is queued let's look at the queue yet
for now because this is pretty pretty
interesting so looking at what it's
doing it shows the original file in the
queue where it started and then it shows
where it's at so right now this queue
data here is on position 25 and it's
flipping one bit and
we can look at what that looks like it
pretty much looks like a shorter version
of the previous file it's flip flip flip
they stopped what it did previously and
every time it does this it learns that
parsing the config file at this point
gave that output and config parsing the
config file it and another point Kay
gave something else in terms of of we're
in the matheletes ending up let's move
into the crashes directory because
that's what you wanted to see right
whoopsie yep
so there is a readme file and this
readme file is pretty good the readme
file shows what you actually ran to find
this bug and that's something that you
can give to a to a organization that the
dust is testing so that they can
actually know what's going on I mean if
they want to reproduce this bug then
then it's good to have that command line
saved so this entire directory is
relevant for anyone who wants to
reproduce it cool inside of here we have
the config file that caused the crash so
this is a config file that has a
character called 8a in it and that's
like a non ASCII character maybe that's
the reason white crashed maybe there is
another reason it says that the log
access file is called hard bracket that
looks kind of weird as well and the doc
index has bracket as well maybe that's
not it we don't know exactly but we can
find out eventually we can look at the
other file for now so this is two files
representing two different crashes
all right so this is a weird one and
weird is good the weirder the better
yeah so now it's actually advantage to
produce this kind of a string here where
it says TMM Vernis whatever that means
yeah and that's yes the the machine
talking and in other cases woman when I
did fussing with with pictures before I
started with basically an empty file and
it actually managed to produce in a few
days it managed to produce a valid JPEG
header by us looking at the reaction
from the programs like if I want to get
a step further I have to type in this in
this position oh cool so here it's
actually created the image for you yeah
yeah and that's built it up yeah that's
the definition of mutation right cool so
this is a configuration file that also
causes a crash and there's also non
ASCII characters in a comment on the
last line maybe that has something to do
with it I'm not exactly sure yet so I'm
gonna back out to this directory where
the HTTP server was yeah and now I'm
gonna run gdb and gdb sounds for annuity
bugger it's if you are into CTF or any
type of security research gdb is a good
tool to know it's older than me and it
has a lot of good plugins for its that
can enable you to write exploits later
cool so we're gonna run gdb on httpd
which is the name of the server and
right now I didn't compile it with the
bug symbol so it's not super easy to
find out what I what's going on but if I
have debug symbols on it's going to tell
me on what line in the code the bug
exists which is pretty nice sorry I'm
gonna set up an argument which is - see
this is the configuration I do for the
programs I typeset args - C and then
output crashes and then I paste in the
name of that file the second file that
cost a problem for us
so this is now the configuration file of
the program at this point I can set up a
breakpoint myself if I happen to know
what I'm going for if there's something
in particular I'm interested in but yet
right now I don't know so now I can run
some people put the breakpoint on main
for instance which is usually a function
that starts initially in the pro in the
program in this case I know there is no
main function so it's not gonna work the
main function doesn't work necessarily
the way I wanted to but you can put the
breakpoint on either and offset into the
file or into a function that you think
caused the crash this is much easier to
do if you have debug symbols on so if I
type on run right now then you'll see
that there is a segmentation fault and
this is not supposed to happen normally
like a program is not supposed to seg
fault every time it reads the cosmic
file then you have a serious
vulnerability in this case this is a
vulnerability where we are running as an
unprivileged user writing to a config
file right and the service is reading
that config file and it's corrupting
memory causing a seg fault somehow yes
and it's doing it as root because root
is needed to start this service and bind
port 80 and this is running as root
initially and then when it's running
it's it's crashing and I have Minkoff
all of the memory so that's a privilege
escalation on the kind of suite and and
here we can do a back trace
oops sorry a back trace where it shows
the states of of the program and you can
look into the info about the registers
that you're dealing with right now
no idea
I'm sorry about that there are more
tutorials that can go into depth and
show how to do this the exploitation and
proof of concept state because what we
have right now is a crash right we have
a denial of service vulnerability that's
local by the way but it's still
something after this point in time we
start figuring out why is the return
winter here at this point why is it
there what happened how did it secure if
we do that using gdb we can start
figuring out writing a proof-of-concept
exploit have you done osip by the way
the buffer overflow part is very much
like this right so this is exactly
that's that you have to do at this point
you can you can input a certain pattern
into the program see if that pattern
reoccurs and if you do that you can see
where this is a memory and what you were
able to overwrite using the original
config file that we looked at and this
is pretty much how you say a file that's
amazing so the whole idea with AFL is
for us to by automation and a little bit
of and I wouldn't called ai but at least
a little bit of learning that it learns
what's going on in the process and then
when it crashes its try to replicate it
and see what happens again again again
again until you know whatever kind of
break it then this happens and it
outputs that file and that's where the
exploitation creation begins right yeah
we're we're people this is where when
people write exploits this is what they
do
yeah and this is how you this is how you
find a bug and and this is something
that I already in this point
reported to the vendors I told the HTTP
server vendor what the bug was about how
it was found what the stack looked like
by using gdb and gave the core dump file
to them so they could reproduce that bug
in their local environment and see that
this is a problem that's very
responsible of you I'm I'm very proud in
bug bounty do you think this is useful
for you maybe it's not this situation
because in bug bounties you don't if you
get this far you report it and get out
right you can touch just a part of it
this that's that's game over you've done
your work you don't privilege escalate
further on you might just be doing it in
pen testing my buddy bounties you don't
do it but I see other areas where this
can be very interesting like there's
file formats there's
different other servers parsers and
things that are being used by our
industry that if you can find an exploit
or something that breaks that that could
turn into I don't know a DOS or some
kind of other this configuration
happening maybe I don't know maybe even
a little bit of memory leak if you're
lucky right so I mean if you have an
input like a sip file or a JavaScript
parser or something where you can upload
maybe a HTML document that's key
getting parsed or CSS getting parsed or
maybe maybe a video file or something
mm-hmm there's there's all these parsers
out there that that's gonna have to deal
with and I know you and I have been
goons and reaches research on this and
eventually yeah I would recommend anyone
to to you at least started to doing a
little bit of fussing I think it's super
super fun and and so rewarding when you
see that crashes sign coming up you're
like yeah so I mean it's it's so easy to
get started with and the types of bugs
you find you can use them on the large
scale for much longer time because this
low-level level programs are reused
identically on multiple platforms I mean
so imagine that you we were playing with
a media transformation for Matt I found
the bug the other week and that's
something you can reproduce forever you
know like it's reported and all and they
don't seem to want to fix it because
it's just a hang and not a crash I was
like okay fine so then you can use that
to identify this media transformer tool
well all this is super interesting but
could you've been you've been doing this
for a while and I know you got some aces
up your sleeve can you tell us a little
bit more about that so we're setting up
we're setting up in web casts where you
can follow along and live answer and ask
questions how to get a get started with
fussing and if you have getting got
stuck recently with it you can get help
there in the web cast and it's on a
secure Labs where me my colleagues
publish lots of talks of
we're doing basically that's amazing so
so it's going to be a community-based
thing that if security is doing to get
more people into fussing yes so this is
the f-secure lab channel on youtube and
it's it's available to anyone who wants
to wash it that's amazing
god damn it I learned something new
today as well and and I'm gonna be a
huge fan of the channel of course I'm
gonna glue myself to that so thank you
very much for taking your time and
learning me or teach me about AFL thanks
for for joining in guys so this is it's
really fun to teach and thank you stuck
for having me appreciate it
awesome a my bike
[Music]
[Music]
Voir Plus de Vidéos Connexes
Fuzzing for beginners! FFuF - Hacker Tools
Fuzzing (fuzz testing) 101: Lessons from cyber security expert Dr. David Brumley
Fuzzing XSS Sanitizers for Fun and Profit | Tom Anthony
Belajar Membuat Monitoring Resources dengan Node Exporter, Prometehus & Grafana | DevOps 101
How to set up Visual Studio Code for Executing and Debugging C Programs | Tutorial
Team China's AFL journey
5.0 / 5 (0 votes)