Fuzzware will always monitor any output to stdout/stderr from an application or responses to network packets, including responses to Web Service method requests. If this output is unique (i.e. Fuzzware has not seen this output/response previously) then the test case and output/response is saved to file, with the filename set to the state of the test case. At the end of fuzzing the list of states with unique output/responses is given.
Sometimes the output/response will always be unique e.g. it includes the time, so in the output destination options for fuzzing network packets or Web Services there is an advanced option that configures a 'character tolerance'. The tolerance is the number of consecutive characters that can differ before the response is considered unique. By default the tolerance is 0. Note, the tolerance only applies to responses of the same length, if a response has a different length to previous responses it is considered unique.
When fuzzing an application, if the application crashes the test case is recorded. If the application needs to be killed (because it did not respond quickly enough to the close command), then the test case is recorded.
When fuzzing Web Services since a response is received for each method called, individual responses are checked for uniqueness (against other calls to the same method) and if they are unique all the requests and responses for that test case are saved to file.
Whilst the output/response is often useful, often we may want to monitor other things to determine if a particular test case has had an interesting effect on the target of fuzzing. Fuzzware can also monitor:
Monitor the Event Log
Fuzzware can monitor the Event Log for the appearance of certain keywords and record any test case that cause the keywords to appear. The Event Log monitored can be local or remote.
Monitor for Process Termination
Fuzzware can monitor if a specific process gets terminated (useful when fuzzing Windows services). Fuzzware can also optional pause fuzzing, run a series of command lines, and resume fuzzing. The process termination can be local or remote.
Application Crashes
Fuzzware has its own debugger (called FuzzwareDbg and built on the Windows Debug Engine) that can be used to record information about any application crashes. When fuzzing an application Fuzzware can run the application with FuzzwareDbg attached so that any crashes can be recorded. Alternatively, FuzzwareDbg can be set as the just-in-time/post-mortem debugger for the OS (this option just needs to be selected, Fuzzware makes the necessary changes), this means if any application crashes, the crash will be recorded. Note, Fuzzware sets FuzzwareDbg to be the post-mortem debugger while fuzzing and restores any previous post-mortem debugger once fuzzing ends.
FuzzwareDbg records crashes in a configurable directory. For each crash a new directory with the application name is made, then a directory for the exception type, then a directory for the exception address and finally a crash dump is stored along with a crash log containing the state and date/time of the crash. If another crash with exactly the same executable, exception type and exception address occurs, FuzzwareDbg appends to the crash log the state that caused the crash but does not create a new crash dump. This is useful for applications that crash repeatedly from the same bug. The crash dumps can be opened in WinDbg for further analysis.
|