# table entry: [type][len][string][checksum] if s_block_start("table entry"): # we don't know what the valid types are, so we'll fill this in with random data. s_random("\x00\x00", 2, 2) # next, we insert a sizer of length 2 for the string field to follow. s_size("string field", length=2) # block helpers only apply to blocks, so encapsulate the string primitive in one. if s_block_start("string field"): # the default string will simply be a short sequence of C's. s_string("C" * 10) s_block_end() # append the CRC-32 checksum of the string to the table entry. s_checksum("string field") s_block_end() # repeat the table entry from 100 to 1,000 reps stepping 50 elements on each iteration. s_repeat("table entry", min_reps=100, max_reps=1000, step=50)
@aedrax thanks! I do not have a lot of time for this right now, but I can look at it later.
While I was working with Boofuzz I found so far two things we could get better. The first (and main) one is s_string. Even if we restrict max_len if generated mutations, there are quite lot of duplications of long strings. Well, not exact duplications, but just different length of the same type of payload. Another thing is that maybe some of payloads seems to have quite low change to break something. The second issue is logging. If Boofuzz is used in some CI enviroment, there still need to be written some tool which takes data from .db file or whatever other logs we defined and parse it to some of the standardized format of test reports, e.g. JUnit. So my suggestion is to write another built-in logger class, which will produce JUnit file.
I will focus on these two things and I will try to create some general solution and open some PR for further discussion.