I recently added this functionality to Ruzzy and I thought it might be useful here too. I know Atheris and Jazzer support similar functionality.
The TL;DR is:
- As a means of improving coverage, when fuzzing...
- If you encounter a
regexp match-like call, then
- Parse its associated regex pattern
- Determine a minimum string value that fulfills the regex's pattern (this is faster than I initially thought)
- Feed that string back into the memcmp hook so the fuzzer will incorporate it into its dictionary
This allows the fuzzer to progress through regex conditions that simple string comparison hooks are insufficient for. Ruzzy also has a cache for the "solved" regex patterns so it doesn't have to re-compute them every time.
For Go I suspect some care will also need to be taken for top-level match calls vs. compile-then-match/find/replace. In other words, the compile-then calls will need some state management for connecting the regex pattern to the associated match/find/replace call that's encountered when fuzzing.
I recently added this functionality to Ruzzy and I thought it might be useful here too. I know Atheris and Jazzer support similar functionality.
The TL;DR is:
regexpmatch-like call, thenThis allows the fuzzer to progress through regex conditions that simple string comparison hooks are insufficient for. Ruzzy also has a cache for the "solved" regex patterns so it doesn't have to re-compute them every time.
For Go I suspect some care will also need to be taken for top-level match calls vs. compile-then-match/find/replace. In other words, the compile-then calls will need some state management for connecting the regex pattern to the associated match/find/replace call that's encountered when fuzzing.