New CLI arguments and experimental code coverage

[jtpereyda]

Lots of changes bundled together. This was mostly for the experimental code coverage, but I made lots of fixes along the way that are also bundled.

1. New CLI arguments:
   1. --stdout: hide/capture/mirror stdout and stderr
   2. --qemu, --qemu-path: experimental code coverage feedback
   3. --web-port: web GUI port
   4. --restart-interval: restart every n test cases
   5. --target-start-wait: adjustable process startup wait time (default 0). Also removed duplicate wait times sprinkled throughout the code.
2. Experimental code coverage using afl-qemu-trace
   1. Includes some experimental web UI stats
3. TCP connections:
   1. Safer shutdown approach (shutdown, recv, close) -- should improve stability
4. edge.py: Human-readable id instead of integer id.
5. Session:
   1. Add register_post_start_target_callback(): callback after a target is started or restarted.
   2. Code coverage support
   3. stop target even when exceptions are raised
   4. keep web interface open even when exceptions are raised

[jtpereyda]

Nice big change! Looks good so far but I haven't done any testing yet. Do you have an example use case or some documentation on how to use the code coverage feature?

Here's an example using the CLI:

python /home/jpereyda/code/boofuzz-ftp/ftp.py fuzz --web-port 26000 --target 127.0.0.1:2200 --target-cmd '/home/jpereyda/code/LightFTP/Source/Release/fftp /home/jpereyda/code/LightFTP/Source/Release/fftp.conf' --stdout hide --restart-interval 32000 --target-start-wait 3.5 --qemu ftp --username ubuntu --password ubuntu

This is with the boofuzz-ftp cli-main branch: https://github.com/jtpereyda/boofuzz-ftp/tree/cli-main and target LightFTP. The coverage approach should work on Linux against most binaries, anything that can run in Qemu.

The relevant command line args are the --qemu switch, and the --target-cmd which specifies the target binary.

[jtpereyda]

TODO:

1. Failing Windows tests

Edit: Done

[jtpereyda]

@SR4ven Good to merge this one? The remaining test failures should resolve with your PR.

I gave up on the whole 2.7 compatibility thing. :/

[SR4ven]

So far so good. I left one more question about which socket behaviour we’re going to use.

I didn’t find time to run the example code yet, but I’ll try to do that today. Shouldn’t stop you from merging.

[SR4ven]

There are still some stickler warnings. Some seem to be false positives.