The interesting thing to me is the stark difference between this and golang's approach.
With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.
I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.
some fuzzing tools (libFuzzer for example) leverage LLVM's intermediate representation to provide code-coverage metrics that they feed back into their fuzzing algorithms, increasing test coverage
fuzzing lore: https://threadreaderapp.com/thread/1799457232607985698
great read if you wanna waste 11 minutes
The interesting thing to me is the stark difference between this and golang's approach.
With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.
I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.
some fuzzing tools (libFuzzer for example) leverage LLVM's intermediate representation to provide code-coverage metrics that they feed back into their fuzzing algorithms, increasing test coverage
Golang does that natively ;-)
Thank you for sharing this - very useful!!!