You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe that I've encountered a bug while using Boofuzz open source code.
The problem is in the .db output file.
While looking on the .db output file, I noticed that there was no correlation between the name of the test case and the test case itself.
To test my claims, I fuzzed a boofuzz server with the following grammar:
I limited the number of fuzzable fields to 1 for simplicity.
The problem is that there is no correlation between the testcase that is presented in the db, to the testcase that is sent to the target server.
For example, in the .db file, the value in the name of the testcase is 10, but the testcase that is actually sent to the server is 2038. At first I thought the intention was to write the index of the testcase, (like this is the 10th test case that has been sent to the server, but you already have an index column in the .db file- number column.
Expected behavior
Here is my fuzzing session, recorded on wireshark:
You can see that according to wireshark, transaction_id has the values 0 to 9, and then 2038 and goes on.
Here is the session in the .db file:
Here you can see that there is no correlation between the .db file testcase input and the actual input itself.
When the .db doesn't include the proper testcase, it cannot tell us what testcase caused the server to crash.
My expectation is that the .db file will show us what specific test case was sent to the server in every case.
For example, in testcase number 11, after testcases 1 to 10, that seem to match the wireshark recording, you can suddenly see a jump to 2038 that isn't recorded in the .db file.
Actual behavior
the actual behavior is also described in the "expected behavior" section.
Steps to reproduce the problem
go to the file session.py in the Boofuzz open source code (inside sessions directory).
go to line 1536.
change the field that goes into the format function from mutation.index to mutation.value.
before change:
after change:
here is an example of how the .db file will look after the change:
now it does report exactly what testcase has been sent to the target server.
boofuzz script
def_test_case_name(self, mutation_context):
"""Get long test case name. Args: mutation_context (MutationContext): MutationContext to get name from. Returns: Long formatted test case name """message_path=self._message_path_to_str(mutation_context.message_path)
mutation_names= (
"{0}:{1}".format(qualified_name, mutation.value)
forqualified_name, mutationinmutation_context.mutations.items()
)
return"{0}:[{1}]".format(message_path, ", ".join(mutation_names))
boofuzz version
0.4.2
Python version
3.10
Platform
Linux
Anything else?
I really liked it that in order to not save a lot of mutations of testcases in memory, you use yield and return one testcase from the function each time. It is very cool and storage saving
The text was updated successfully, but these errors were encountered:
Report
Hii,
I believe that I've encountered a bug while using Boofuzz open source code.
The problem is in the .db output file.
While looking on the .db output file, I noticed that there was no correlation between the name of the test case and the test case itself.
To test my claims, I fuzzed a boofuzz server with the following grammar:
I limited the number of fuzzable fields to 1 for simplicity.
The problem is that there is no correlation between the testcase that is presented in the db, to the testcase that is sent to the target server.
For example, in the .db file, the value in the name of the testcase is 10, but the testcase that is actually sent to the server is 2038. At first I thought the intention was to write the index of the testcase, (like this is the 10th test case that has been sent to the server, but you already have an index column in the .db file- number column.
Expected behavior
Here is my fuzzing session, recorded on wireshark:
You can see that according to wireshark, transaction_id has the values 0 to 9, and then 2038 and goes on.
Here is the session in the .db file:
Here you can see that there is no correlation between the .db file testcase input and the actual input itself.
When the .db doesn't include the proper testcase, it cannot tell us what testcase caused the server to crash.
My expectation is that the .db file will show us what specific test case was sent to the server in every case.
For example, in testcase number 11, after testcases 1 to 10, that seem to match the wireshark recording, you can suddenly see a jump to 2038 that isn't recorded in the .db file.
Actual behavior
the actual behavior is also described in the "expected behavior" section.
Steps to reproduce the problem
before change:

after change:

here is an example of how the .db file will look after the change:

now it does report exactly what testcase has been sent to the target server.
boofuzz script
boofuzz version
0.4.2
Python version
3.10
Platform
Linux
Anything else?
I really liked it that in order to not save a lot of mutations of testcases in memory, you use yield and return one testcase from the function each time. It is very cool and storage saving
The text was updated successfully, but these errors were encountered: