Custom mutator for proto messages

[KanishAnand]

We want to mutate a particular string field in a proto message with some specific values.
We have considered following approaches but none of them suits best here:

1. Using dictionary to add those specific string values. But issue here is that fuzzer will use dictionary values to mutate all protobuf string fields not just this specific field, so this might not be good for fuzzers mutations?
2. Using post-processing mutations which is ideally meant to not modify good messages. We can use this in some hacky way to insert specific string values at the time of mutation but not while running inputs from corpus. But post-processing mutations is not meant to do this.

So what would be best approach in this case, should libprotobuf-mutator provide custom mutators for protobuf message.

P.S: We need this due to libfuzzer's limitation in tracing CMP instructions due to which it's not able to use various string values present in our codebase in it's mutations, explained in detail here

[Skryptonyte]

Hi, I know this is quite a bit late since I just spotted this now but I ran into a similar conundrum a long time back. Yes, libFuzzer's cmp tracing falls short when you are fuzzing large projects where the table gets overwhelmed pretty quickly.

If I understand right, you want the mutator to only select out of a pool of certain strings. What you could do is define an enum field and encode a string based on what the enum field value is. However, if you want a generalized pattern that does not require tediously writing switch cases for each and every one of them, you could use a mix of EnumValueOptions string extensions and/or reflection APIs (as was in my case at least).

If your string itself has a structure to it that cannot be enumerated by enum values easily, you can break them down into more protobuf messages and serialize them accordingly.

I myself worked on a libprotobuf-mutator based fuzzer for a Google Summer of Code project if you (or anybody else) are interested in my approach (https://gitlab.com/Skryptonyte/libvirt/-/tree/gsoc_fuzz?ref_type=heads) where I have adopted the aforementioned patterns. Though I must warn that it's pretty convoluted and involved, and a bit tricky to build :).

[KanishAnand]

Hi,
Thanks for you reply :)
We ended up adding support for registering additional mutations in libprotobuf-mutator (similar interface as Post Processing Registration) to address our use case. These registered mutations are run alongside default mutations. We think this feature could be generally more useful in other cases as well.
If there's interest, would be happy to create draft PR to discuss further.

[Skryptonyte]

Hi, Thanks for you reply :) We ended up adding support for registering additional mutations in libprotobuf-mutator (similar interface as Post Processing Registration) to address our use case. These registered mutations are run alongside default mutations. We think this feature could be generally more useful in other cases as well. If there's interest, would be happy to create draft PR to discuss further.

I am not a maintainer fyi, just another user of this project :). But that would be cool to see nonetheless.