Refactor: Update from master

[jtpereyda]

Merging updates from master into sulley_refactor. It was messy, but nothing tricky for the most part.

From here, it should be easy to merge future master fixes into sulley_refactor.

[Fitblip]

Hey @jtpereyda!

Wow! Awesome. Thanks a ton for doing this. I seriously appreciate it. I know that merge was messy and took a decent amount of time.

If it's not too much trouble would you mind squashing this PR into a single commit (http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit)? There are a few commits just for merging in branches/PRs that aren't specific to the sulley_refactor branch.

Cheers!

[jtpereyda]

My pleasure.

I'd be happy to squash the commits, but when I tried, I ran into all of the same merge conflicts again. :/

Here is my command:

> git rev-parse --abbrev-ref HEAD  # show current branch
refactor-update-from-master
> git rebase -i openrce/sulley_refactor

And here's what I saved for the rebase file:

pick afcd647 Implement a quick fix to network_monitor.py
squash fead662 Added return value on function start_target so sulley doesn't close on "Restarting the target failed, exiting.".
squash 2edc1ca Fix issue #66
squash 8952ad0 Allow the loopback interface to be used.
squash 829758b Add "offset" parameter to the s_size funtion. TL;DR I had a block whereby the whole block contents had to be considered for checksum calculation, but one field (fixed length) not included in the size field for the block. Detail: I was creating a fuzzer for PNG fields whose "Chunks" required the above consideration, see: http://www.w3.org/TR/PNG/#5Chunk-layout
squash 68dc3f5 Add support for binary prinitives to be defined with a list / tuple of values.
squash 7bc54f2 Fixed primitives "off-by-one" error. This was preventing "full_range" from emitting the maximum possible value of a primitive. Fixed a failing unit test.
squash b742a0d Mutate primitives defined with lists / tuples through the values. When these primitives are not mutating, cycle them through the values. If they are "Fuzzable" they will generate a mutation with each possible value. If they are not fuzzable they will cycle through values according to the demands of other mutating item, with no guarantee that all specified values will be used.
squash ac0c625 Corrected exception thrown when the wrong value is used. Updated .gitignote to ignored generated pydocs. Updated user guide to include details on defining integer primitives with lists of values. Also further minor improvements to assist with readabiity that I noted from my initial read through of the guide when familiarising myself with the product.
squash cf74c68 OpenRCE/sulley Issue #79 Changing code and usage string to indicate that -s is required. Also removed default vmrun value and fixed two typos.
squash b842560 network_monitor.py now runs its server in a thread, making Ctrl+C work in Windows.
squash 007edd3 Adding workaround since singal.pause() is missing in Windows. OpenRCE/sulley issue #49
squash 54bdbbe Update sessions.py
squash 8928ce8 process_monitor.py now accepts relative filenames in -c argument.

As it was rebasing, it started bringing up all of the old merge decisions. In order to do it this way, I'd need to re-make every single decision. :/

Besides, I'm apprehensive to squash since all of these happened before my merge. My only commit is the very last one, b78c235.

All of the commits already exist in the OpenRCE repo, they're just new to this branch. My guess is that this PR won't add any superfluous commits to the repo, though it will expand the history of sulley_refactor. I think this is a good thing, though -- at least it's how I understood merges to work anyway.

Let me know if you have another approach to squashing you'd like me to try.

[jtpereyda]

Maybe the squashing guideline doesn't apply for merges like this. I couldn't find much online about this exact scenario.

[Fitblip]

Hrm, I'll try to take a whack at it when I get a chance, but it's really not the worst thing if all the merges are there. Probably not worth the effort.

If what I try encounters any problems I'll just merge it in :-P.

[jtpereyda]

@Fitblip Any chance to check this one out yet?

[Fitblip]

Hey @jtpereyda - Sorry for the smokebomb. I've been crazy busy at work (we're just getting ready to start our pilots), so I probably can't look at this until next week some time.

[jtpereyda]

@Fitblip Well knock it out! I hope all goes well.