π₯ No fuzz drivers needed. Our paper on injecting greybox fuzzers into running systems at user-defined amplifier points (in-vivo fuzzing) was accepted at #ICSE25!
π https://mboehme.github.io/paper/ICSE25-invivo.pdf
π§βπ» https://github.com/OctavioGalland/afllive (subject to AE)
//Lead by Octavio Galland (former #MPI_SP intern).
π https://mboehme.github.io/paper/ICSE25-invivo.pdf
π§βπ» https://github.com/OctavioGalland/afllive (subject to AE)
//Lead by Octavio Galland (former #MPI_SP intern).
Comments
Existing fuzzers are designed to test a software system in-vitro, i.e. under artificial lab conditions. An in-vitro fuzzer must first be βgluedβ to the software via fuzz drivers / harnesses. For instance, OSS-Fuzz is a collection of fuzz drivers.
1/
2/
To deploy in-vivo fuzzing, the user specifies amplifier points (function calls to be hijacked) and amplifier constraints (e.g, when fuzzing ππππ* πππ adjust ππΉπΈ πππ_πππ). Whenever an amplifier is called, copy the state and fuzz the function call.
3/
4/
5/
## No Grammars for Structure-Aware Fuzzing?
A fuzzerβs effectiveness depends critically on the quality of the initial seeds. E.g., inputs generated by mutating valid PNG files will reach more deeply into a PNG parser library than a random string of bytes.
6/