change github workflow go build to 19
run gofmt and update err handling on master
Update structure to use cmd convention
inspired by AFL++
Hopper Master
Ex:
./compile target.c
HOPPER_OUT
: Where to save Hopper output; sanitizer reports, crash inputs and
hopper reports, defaults to .
HOPPER_LOG
: Enable Logging on Master, defaults to HOPPER_LOG=0
Master
onlyHOPPER_LOG_INTERVAL
: Logging interval in minutes, defaults to
HOPPER_LOG_INTERVAL=30
(ignored if HOPPER_LOG
is not set) Master only1
(recommended:
increase havoc for larger seeds)6969
Ex:
go build ./cmd/hopper-master && ./hopper-master -H 5 -I test/in
localhost
6969
false
. Hopper will put bytes in a file and feed that file to target.--depth=1 @@
;
, ex:
ENV1=foo;ENV2=bar;
false
Ex:
Args:
go build ./cmd/hopper-node; ./hopper-node -I 1 -T target --args "--depth=2 @@"
Stdin:
go build ./cmd/hopper-node; ./hopper-node -I 1 -T target --stdin
If you want to run Hopper locally with 10 fuzzing Nodes on a test application with a known vulnerability you can do the following:
git clone https://github.com/Cybergenik/hopper.git && cd hopper
docker build -t hopper-node .
./examples/parse/docker/run_master_docker.sh
./examples/parse/docker/run_node_docker.sh 1 10
(I'd recommend no more
than 1x # of logical cores on your machine, any more nodes on one system
and they just get throttled and competing for CPU time)You can also look at all the Hopper containers running by doing: docker ps -f "name=hopper"
The Masters job is to schedule fuzz tasks on Nodes in the cluster, keep track of coverage, mutate seeds, and produce reports. The Master handles all these responsibilities concurrently. There are two main processes running concurrently on the Master, an RPC server and the Mutation Engine.
Hopper uses a bloom filter to keep track of coverage and to deduplicate seeds based on coverage and content.
The mutation engine acts as a load balancer by popping energized seeds from the energy priority queue (EPQ), mutating them, and feeding newly formed seeds to the task queue. The Mutation Engine only mutates when there’s enough space in the Task Queue for more tasks, otherwise it stalls. Because a single energized seed can turn into tens of seeds, this can be seen as an inverse funnel, thus the Mutation Engine has some control of flow through the system.
A Hopper Node’s job is to run the PUT, gather and parse coverage, and report coverage/crash data to the Master. Each Node runs a main Fuzz loop. Nodes are fairly synchronous, with a few sections of parallelism for logging crashes and clean-up. But generally we keep each instantiation of a Node synchronous such that we can more easily reason about it as a discrete unit of computation.