Hello, about mutiny-fuzzer HOT 15 CLOSED

Hi, you can reproduce a given seed with the "-r" flag. (You can add -q to prevent logging.)

Otherwise, the data in the log file is in a python-representation format. You can always turn it into raw binary with a quick one-liner:
python -c "print 'datafromlogfile'" >./binary_file

Otherwise, the experiment branch has a -d flag to dump raw packets for a single seed, and -x to generate a standalone script to reproduce. However, these features aren't merged into master yet.

from mutiny-fuzzer.

@jspadaro

Hello,

Thank you for answer.

I solved the problem.

I have additional questions.

fuzzer stops running if it finds a crash.

Is there a way to continue running fuzzer?

Thanks.

from mutiny-fuzzer.

Yep, if you copy mutiny_classes/exception_processor.py into the same folder as your .fuzzer file, you can edit the function to override the behavior.

(Note: mutiny will scan your .fuzzer file folder for exception_processor.py, message_processor.py, and monitor.py by default. If they exist, they'll override the default code.)

Specifically, this line:

            if exception.errno == errno.ECONNREFUSED:
                # Default to assuming this means server is crashed so we're done
                raise LogLastAndHaltException("Connection refused: Assuming we crashed the server, logging previous run and halting")

You can have it throw LogCrashException() instead to log the crash and continue, although if it's hitting that, you need to make sure your target is coming back up. You could also put in a time.sleep() if you need to wait for the target to come back up.

from mutiny-fuzzer.

Thank you for answer. 💯

from mutiny-fuzzer.

@jspadaro

Hello,

I have additional questions.

I run the fuzzer and see a constant error message after a certain period of time.

Fuzzing with seed 392979
[Errno 110] Connection timed out
Run aborted: Server closed the connection

** Sleeping for 0.000 seconds **


Fuzzing with seed 392980
[Errno 110] Connection timed out
Run aborted: Server closed the connection

** Sleeping for 0.000 seconds **


Fuzzing with seed 392981
[Errno 110] Connection timed out
Run aborted: Server closed the connection

... continue

When verified using the ps command, the server process is running.

However, it is impossible to connect to the server using the client.

Since the server process is running, no conflict files are created in the log.

Do you have any ideas to solve the problem?

Thanks

from mutiny-fuzzer.

You can amend exceptionprocessor above to log connection time outs or even LogAndHalt if you want to stop when this happens. It sounds like Mutiny has generated data that has rendered your target unresponsive.

In other words, it's probably done it's job and you've got some kind of crash or issue on your hands. To actually figure that out, you should reproduce the crash from the last time it was responsive and narrow down what happened using a debugger.

This is outside the scope of what I can help with regarding using Mutiny, though, as it's specific to your application at this point. :)

from mutiny-fuzzer.

@jspadaro

Hello,

I found the suspicious part.

I used fuzzer in local environment (localhost).

The fuzzer transmits data at high speed, and after a certain period of time, the server application hangs. (The server application does not shut down, but can not send data.)

I do not know why, but I keep testing it by adjusting the sleeptime.

In my opinion, it would be nice to support the process restart option in fuzzer.

Example) Send 1000 packets. -> Restart the process -> Send the packet again.

This allows you to run fuzzer without modifying the server application.

Thanks.

from mutiny-fuzzer.

That makes sense.

Instrumenting a target is a feature that has been considered, but isn't currently in the works. However, there is a messageprocessor call back when mutiny makes a connection. You can copy mutiny_classes/message_processor.py to the folder containing your .fuzzer and implement restarting your process within that callback if you'd like.

The callback is preConnect(), and one of the arguments is the current run number. You could do something like kill the target and restart if runNumber % 1000 == 0

from mutiny-fuzzer.

@jspadaro

Hello,

Thank you for answer.

I added the functionality I want to the preConnect() function.

Send 1000 packets. -> Restart the server process -> Send the packet again.

My code is a mess, but it seems to work the way I want.

I will continue to test to see the results.

Thank you for your help.

Thanks.

from mutiny-fuzzer.

@jspadaro

Hello,

I have a question.

The application crashes, but the crash file that fuzzer stores is not accurate. (Impossible to reproduce)

So I use the "--logAll" option to save all the files.

Since all files are stored, collision can be reproduced.

I have solved the problem. (I am using shell script, check the process, delete the file.)

but this wastes resources. (Hard disk capacity increase / other problems)

Is there a better way?

Thanks.

from mutiny-fuzzer.

We usually reproduce with the -r switch more often than by looking at the crash log.

Why is the log inaccurate? Is it a problem with Mutiny or is it crashing earlier than Mutiny is detecting?

from mutiny-fuzzer.

@jspadaro

Hello,

As I understand it, Mutiny needs a crash log to use the -r option.

is it crashing earlier than Mutiny is detecting?

Yes. Accurately.

So I use the logAll option, but it wastes resources.

Thanks.

from mutiny-fuzzer.

Ah, OK, so no, you do not need logs to use -r. -r will provide the same seed to the mutator for a run, so as long as you haven't altered the .fuzzer message contents, it will reproduce the exact same thing.

For example, if you run the fuzzer and see a crash on run 1001, you can run mutiny.py your.fuzzer yourhost -q -r 1001 and it will rerun 1001, only outputting that exact run and skip logging.

You can do this as many times as you can. You can also do -r 1001- to replay from a crash point on (or resume if you hit Ctrl-C on the fuzzer), or things like -r 990-1001 if you want to try a range of seeds before the crash to nail down what is happening.

In any case, the logs are purely for your use. The fuzzer doesn't need them.

Also, if Mutiny is not correctly detecting the crashes, you can create a Monitor to monitor the target on a separate thread. (there's some info on all the customization options in the readme).

from mutiny-fuzzer.

@jspadaro

amazing.

I thought I needed the "--logAll" option to use the "-r" option.

However, - r could be used without that "--logAll" option.

Mutiny-fuzzer is a very intelligent tool.

Thank you for your help.

from mutiny-fuzzer.

No problem, I'm glad Mutiny is working for you. =)

from mutiny-fuzzer.