> wow....that is pretty interesting. how do you write your own fuzzer, seems like that's where the edge comes from? How much more of an effort is it to write an exploit? Is it necessary to build a Proof of Concept or is simply disclosing the vulnerability enough?
Dumb fuzzers can be written in anywhere from a day to a few weeks of work, smart fuzzers can take several years to write, also lots of fuzzers continually evolve over time because they have to. Its the Red queen effect[1], fuzzers keep finding bugs so they have to keep getting better to keep finding harder and harder to find bugs in a target codebase. So I would say an exploit is usually the harder task but some of the things smart fuzzers like SAGE[2] do would be incredibly hard to implement.
> If I buy ADA what software/API can I start tinkering with?
I'm not sure what ADA is. However for testable software I would go for programs that come installed on your operating system of choice. So in my case I was using MacOS at the time so I was targeting MacOS default applications.
> What you described seems like so much fun but scared of the writing exploit part. Now that seems really hard especially considering it needs to be fully undetectable for a long time until the buyer gets their return on investment.
Fuzzer development and exploit development are pretty different tasks. Fuzzer development is basically normal software development, while exploit development at least with security mitigations turned on is an entirely different beast. For example in exploit development your going to need to know x86-64 assembly, as well as general memory layout, how a particular operating system implements ASLR[3] so you can bypass that. As well as bypassing DEP/NX[4] which is often done using ROP[5] and now recently newer techniques[6]. The fuzzer I was describing above was a dumb file mutation fuzzer which can be extremely simple. So first it was a file fuzzer, meaning it fuzzed programs that take files as inputs, stuff like video and music players or in my case pdf files. The mutation part means the fuzzer took existing valid files and added random mutations as opposed to generative fuzzers that build semi valid files from scratch. The dumb part means it didn't do cool stuff like AFL that use a genetic algorithm and probe system to better test code paths in a target program.
> Is there a course or resource I can use to begin this path?
Search fuzzers online until you've seen every/most pages, no joke thats basically what I did theres a few books but most of the info they have can be found online for free. Also make sure to try building a fuzzer or two, go simple at first. As well as using existing opensource fuzzers like AFL, Trinity and syzkaller.
> How did you get into all of this?
I forget how I got into fuzzing but I did try and start a fuzzing company a few years ago, but it turns out its way easier making money doing web development then selling fuzzing software or doing bug bounties for a living.
Dumb fuzzers can be written in anywhere from a day to a few weeks of work, smart fuzzers can take several years to write, also lots of fuzzers continually evolve over time because they have to. Its the Red queen effect[1], fuzzers keep finding bugs so they have to keep getting better to keep finding harder and harder to find bugs in a target codebase. So I would say an exploit is usually the harder task but some of the things smart fuzzers like SAGE[2] do would be incredibly hard to implement.
> If I buy ADA what software/API can I start tinkering with?
I'm not sure what ADA is. However for testable software I would go for programs that come installed on your operating system of choice. So in my case I was using MacOS at the time so I was targeting MacOS default applications.
> What you described seems like so much fun but scared of the writing exploit part. Now that seems really hard especially considering it needs to be fully undetectable for a long time until the buyer gets their return on investment.
Fuzzer development and exploit development are pretty different tasks. Fuzzer development is basically normal software development, while exploit development at least with security mitigations turned on is an entirely different beast. For example in exploit development your going to need to know x86-64 assembly, as well as general memory layout, how a particular operating system implements ASLR[3] so you can bypass that. As well as bypassing DEP/NX[4] which is often done using ROP[5] and now recently newer techniques[6]. The fuzzer I was describing above was a dumb file mutation fuzzer which can be extremely simple. So first it was a file fuzzer, meaning it fuzzed programs that take files as inputs, stuff like video and music players or in my case pdf files. The mutation part means the fuzzer took existing valid files and added random mutations as opposed to generative fuzzers that build semi valid files from scratch. The dumb part means it didn't do cool stuff like AFL that use a genetic algorithm and probe system to better test code paths in a target program.
> Is there a course or resource I can use to begin this path?
Search fuzzers online until you've seen every/most pages, no joke thats basically what I did theres a few books but most of the info they have can be found online for free. Also make sure to try building a fuzzer or two, go simple at first. As well as using existing opensource fuzzers like AFL, Trinity and syzkaller.
> How did you get into all of this?
I forget how I got into fuzzing but I did try and start a fuzzing company a few years ago, but it turns out its way easier making money doing web development then selling fuzzing software or doing bug bounties for a living.
[1]: https://en.wikipedia.org/wiki/Red_Queen_hypothesis
[2]: https://patricegodefroid.github.io/public_psfiles/SAGE-in-1s...
[3]: https://en.wikipedia.org/wiki/Address_space_layout_randomiza...
[4]: https://support.microsoft.com/en-us/help/875352/a-detailed-d...
[5]: https://en.wikipedia.org/wiki/Return-oriented_programming
[6]: https://www.endgame.com/blog/technical-blog/rop-dying-and-yo...