jtpereyda / boofuzz

A fork and successor of the Sulley Fuzzing Framework

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

arguments discrepance between s_string() and String()

cq674350529 opened this issue · comments

commented

It's possible to extend the fuzz libary via option fuzz_values. However, there is an argument discrepance bwtween String() and s_string().

It's ok when using String().

hello = Request("hello", children=(
        String("name", "boofuzz", max_len=0, fuzz_values=["boofuzz123","boofuzzaaa"])
    ))

However, these is no option fuzz_values when using s_string(), according to its definition:

def s_string(value="", size=None, padding=b"\x00", encoding="ascii", fuzzable=True, max_len=None, name=None):

Since s_string() is the old school Spike-style static protocol definition format, does it mean that using the former is preferable?

Good point @cq674350529.
The reason for this discrepancy in the args of the old and new format is that the static format s_* primitives don't take kwargs.
fuzz_values comes from Fuzzable which all primitives inherit from so it's not just a thing for String().

I'd say the new format is definitely preferable and it would make the API and code more clean if we'd remove the old static format. I think we've discussed this somewhere with @jtpereyda and it was found that backward compatibility is more important.
Maybe we could mark s_* blocks and primitives deprecated so that new users don't get tempted to use them?

In case we want to keep supporting s_* primitives, we could add *args and **kwargs. That should at least fix this specific issue.

commented

The reason for this discrepancy in the args of the old and new format is that the static format s_* primitives don't take kwargs. fuzz_values comes from Fuzzable which all primitives inherit from so it's not just a thing for String().

Yes, that's the point. And as you mentioned, adding *args and **kwargs can resolve this. I'm just curious about this behaviour, and there might be some reasons behind it. Thanks for your detailed explanation. @SR4ven

One more thing, if using the former, one must specify name to each primitive manually, even if the name is empty or useless. Is it possible to change it into the Spike-style way?

hello = Request("hello", children=(
    String("boofuzz", name="mark", max_len=0, fuzz_values=["boofuzz123","boofuzzaaa"])
))

There's no need to set a name with the new format.
You can do something like this, which will generate the default name String1

String(default_value="boofuzz", max_len=0, fuzz_values=["boofuzz123", "boofuzzaaa"])
commented

Yeah, actually I prefer the following:

String("boofuzz", max_len=0, fuzz_values=["boofuzz123", "boofuzzaaa"])

When defining many primitives, less means faster and convenience, just my original opinion :)

I think at some point we agreed to place the name argument first because every primitive and block has a name but not everyone has a default value. Not exactly sure though.
However, now it's too late to change the order. It would be a breaking change which we're trying to avoid.

But thanks for sharing your thoughts @cq674350529!

commented

Indeed a breaking change. Neverthelsess, it doesn't matter, maybe just my personal favor.

Thanks!