fuzzuf / fuzzuf

Fuzzing Unification Framework

fuzzuf

fuzzuf (fuzzing unification framework) is a fuzzing framework with its own DSL to describe a fuzzing loop by constructing building blocks of fuzzing primitives.

For build instructions and a tutorial, please follow building.md and tutorial.md.

Why use fuzzuf?

fuzzuf enables a flexible definition of a fuzzing loop defined in each fuzzer by describing it as combinations of building blocks with DSL notations while keeping extensibility for its original fuzzer. It already has various fuzzer implementations including AFL, VUzzer, and libFuzzer that can be further extended by users.

HierarFlow

fuzzuf utilizes its own DSL called HierarFlow for fuzzing loop statements. It is implemented on top of a C++ language with the grammar made to look like a tree structure to describe a fuzzing loop as a combination of building blocks.

With HierarFlow, we can write both existing and new fuzzers in a neat and tidy way, as the structure of a fuzzing loop can clearly be shown. For instance, we can divide an AFL fuzzer (which has already been implemented on fuzzuf as a template!) into multiple fuzzing primitives that include PUT executor, mutators (both deterministic and random), dictionary updater, and so on. Users can implement each primitive in C++ code and connect them together with HierarFlow's operator to eventually construct a fuzzing loop of a fuzzer they want to achieve.

Example: AFL in HierarFlow

The following short snippet represents AFL in HierarFlow:

    fuzz_loop << (
         cull_queue
      || select_seed
    );

    select_seed << (
         consider_skip_mut
      || retry_calibrate
      || trim_case
      || calc_score
      || apply_det_muts << (
             bit_flip1 << execute << (normal_update || construct_auto_dict)
          || bit_flip_other << execute.HardLink() << normal_update.HardLink()
          || byte_flip1 << execute.HardLink() << (normal_update.HardLink()
                                               || construct_eff_map)
          || byte_flip_other << execute.HardLink() << normal_update.HardLink()
          || arith << execute.HardLink() << normal_update.HardLink()
          || interest << execute.HardLink() << normal_update.HardLink()
          || user_dict_overwrite << execute.HardLink() << normal_update.HardLink()
          || auto_dict_overwrite << execute.HardLink() << normal_update.HardLink()
         )
       || apply_rand_muts << (
               havoc << execute.HardLink() << normal_update.HardLink()
            || splicing << execute.HardLink() << normal_update.HardLink()
          )
       || abandon_node
    );

This simply shows how flexible and powerful HierarFlow is. Please refer to the document for more details.

Benefits of using fuzzuf

There are mainly four advantages of writing fuzzers on fuzzuf framework:

• Can describe a fuzzing loop with combinations of each fuzzing primitive
  fuzzuf constructs a fuzzing loop with a combination of fuzzing primitives (an individual step in a fuzzing loop) like building blocks. Since each block can be appended, removed, replaced, and resuable, fuzzuf can keep the high modularity of every fuzzing loop defined.

• A flexible, user-definable fuzzing loops
  Since existing fuzzing frameworks tend to have fixed, or hard-coded fuzzing loops inside the frameworks themselves, their users could not manipulate their behaviors. fuzzuf can assign and implement a routine for each fuzzing primitive divided, and describe and modify the structure of a fuzzing loop as a user wants.

• Easy to compare a derived fuzzer to its original
  It is not rare that fuzzing researchers and enthusiasts fork an existing fuzzer to implement their own idea on top of it. As a matter of fact, a lot of academic works have showcased numerous AFL-based fuzzers reflecting their idea. By leveraging fuzzuf DSL's building block-like characteristics and reusing existing fuzzing primitives, users can highly accelerate their new fuzzer's development process. Moreover, by comparing diffs of DSLs between the original fuzzer and its derivatives, the enhancements can smoothly be spotted at a glance (not only for users themselves, but also for reviewers and other researchers).

• AFL fuzzer as a template
  On fuzzuf, AFL is available as a fuzzer (C++) template as well. This means that the cost to implement and review a new or existing AFL-based fuzzer has been lowered a lot by utilizing it. For example, fuzzuf's AFLFast is built upon this template. Only a few modifications in routines and a struct which records a fuzzer state are required to change, and it keeps its original's flow unchanged.

List of Currently Available Fuzzers

fuzzuf comes with the following fuzzers implemented by default. To see the overview and how to them from CLI, please follow the links provided below.
Note, when using fuzzuf from CLI, you have to separate global options (options available for all fuzzers) and local options (fuzzer specific options) with --.

Fuzzer	Type	Description	CLI Usage	Algorithm Overview	Frida mode
AFL	Greybox	A re-implementation of general purpose fuzzer, representing a CGF. Also available as a template for its derivatives.	How to use fuzzuf's AFL CLI	Algorithm Overview	✅
AFLFast	Greybox	An implementation of AFLFast, utilizing an AFL template. The algorithm tries to increase its performance by manipulating the power schedule.	CLI Usage	Algorithm Overview	✅
IJON	Greybox	A fuzzer that can fuzz PUTs in an internal-state-aware manner with manual annotations to PUTs.	CLI Usage	Algorithm Overview
VUzzer	Greybox	A mutation-based fuzzer guess data structures by analyzing the PUT control flow and the data flow.	Read Prerequisite first, then Usage on CLI	Algorithm Overview
libFuzzer	Greybox	CGF included in the LLVM project's compiler-rt libraries.	How to use libFuzzer on fuzzuf	What is libFuzzer?
Nezha	Greybox	A fuzzer originates from libFuzzer that tries to find defects in the program by executing programs having different implementations with the same input and compares its execution results (differential fuzzing).	How to use Nezha on fuzzuf	TBD
DIE	Greybox	A fuzzer for JavaScript engines preserving the aspect of the test cases through the mutation process	Usage on CLI	Overview of Algorithm
Nautilus	Greybox	A coverage-guided grammar-based fuzzer that generates test cases according to the user-defined grammar	Usage on CLI	Overview of Algorithm
MOpt	Greybox	Particle Swarm Optimization based algorithm on the top of AFL	Usage on CLI	Overview of Algorithm
SymCC	Concolic	Efficient Compiler-based Symblic Execution	TBA	TBA
Eclipser	Greybox Concolic	Greybox Concolic Testing	Usage on CLI	TBA

Why not Rust?

We have considered migrating the framework from C++ to Rust because it is safer and has a neat ecosystem during development. However, despite the attempts and the discussions, we concluded that we would not switch the language. The reason why is explained in detail here.

API Reference

API reference generated by doxygen is available here.

License

fuzzuf is licensed under the GNU Affero General Public License v3.0. Some codes originate from external projects are licensed under their own licenses. Please refer to LICENSE for details.

Acknowledgements

This project has received funding from the Acquisition, Technology & Logistics Agency (ATLA) under the Innovative Science and Technology Initiative for Security 2020 (JPJ004596).

fuzzuf's Issues

Implement WalkerDiscreteDistribution

Relation to existing issues

N/A

Relation to existing roadmaps

Unify the designs of RNG (random number generators) and probability distributions

Motivation

The current fuzzuf::utils::random does not implement a weighted random function.
It's preferable to have a general implementation of Walker's Alias Method because many fuzzers, including Nautilus which I'm working on, requires discrete distribution.

Description

Implement WalkerDiscreteDistribution class using Walker's Alias Method.
This algorithm costs O(n) for pre-processing and O(1) to choose a random index.

This feature is to be added in #15

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Implement WalkerDiscreteDistribution class
• Add test cases for this new feature

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

fuzzing failed for the specific instrumented binary

Relation to existing issues

#9

Relation to existing roadmaps

N/A

Bug explanation

If you try to fuzz a binary instrumented by afl-clang-fast with the -fsanitize=address option, it will fail with the following message if output directory already used in other fuzzing attempt.

[-]  SYSTEM ERROR : Fork server crashed

    Stop location : SetupForkServer(), /home/keymoon/ricsec/fuzzuf/executor/native_linux_executor.cpp:1055
       OS message : Success

If not, it will produce following message.

[-]  SYSTEM ERROR : Fork server crashed

    Stop location : SetupForkServer(), /home/keymoon/ricsec/fuzzuf/executor/native_linux_executor.cpp:1055
       OS message : No such file or directory

Note that fuzzing by afl-fuzz succeeds.

Steps to reproduce

Execute following script

cat > main.c << EOS
#include <stdio.h>

int main(){
    char buf[8];
    scanf("%4s", buf);
    if (buf[0] == '\xde' && buf[1] == '\xad' && buf[2] == '\xbe' && buf[3] == '\xef') {
        (*(int*)(0xdeadbeef)) = 0xcafebabe;
    }
    return 0;
}
EOS

AFL_CLANG_PATH=afl-clang-fast
FUZZUF_PATH=fuzzuf
AFL_FUZZ_PATH=afl-fuzz

mkdir seeds
echo 'A' > seeds/case_0

$AFL_CLANG_PATH -fsanitize=address -o bin main.c
# fail
$FUZZUF_PATH afl --in_dir=seeds --out_dir=out-fuzzuf-$(openssl rand -hex 3) -- ./bin
# success
$AFL_FUZZ_PATH -i seeds -o out-afl-$(openssl rand -hex 3) ./bin

or following steps.

#include <stdio.h>

int main(){
    char buf[8];
    scanf("%4s", buf);
    if (buf[0] == '\xde' && buf[1] == '\xad' && buf[2] == '\xbe' && buf[3] == '\xef') {
        (*(int*)(0xdeadbeef)) = 0xcafebabe;
    }
    return 0;
}

1. Compiling the above c code by afl-clang-fast with -fsanitize=address option
2. fuzzing with fuzzuf afl fails
3. fuzzing with afl-fuzz succeeds

Environment

• fuzzuf commit ID: 0412d20
• OS: Ubuntu 20.04.3 LTS on Windows 10 x86_64
• Kernel: 5.10.43.3-microsoft-standard-WSL2
• afl++ commit ID: AFLplusplus/AFLplusplus@1d4f1e4

Expected behaviors

Start fuzzing without a problem.

Error messages, stack traces, or logs

$ cat main.c
#include <stdio.h>

int main(){
    char buf[8];
    scanf("%4s", buf);
    if (buf[0] == '\xde' && buf[1] == '\xad' && buf[2] == '\xbe' && buf[3] == '\xef') {
        (*(int*)(0xdeadbeef)) = 0xcafebabe;
    }
    return 0;
}
$ ../afl++/afl-clang-fast -fsanitize=address -o bin main.c
afl-cc++4.01a by Michal Zalewski, Laszlo Szekeres, Marc Heuse - mode: GCC-GCC
[!] WARNING: You are using outdated instrumentation, install LLVM and/or gcc-plugin and use afl-clang-fast/afl-clang-lto/afl-gcc-fast instead!
main.c: In function ‘main’:
main.c:5:5: warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result [-Wunused-result]
    5 |     scanf("%4s", buf);
      |     ^~~~~~~~~~~~~~~~~
afl-as++4.01a by Michal Zalewski
[+] Instrumented 35 locations (64-bit, non-hardened mode, ratio 100%).
$ ../fuzzuf/build/fuzzuf afl --in_dir=seeds -- ./bin

[-]  SYSTEM ERROR : Fork server crashed

    Stop location : SetupForkServer(), /home/keymoon/ricsec/fuzzuf/executor/native_linux_executor.cpp:1055
       OS message : Success
$ ../afl++/afl-clang-fast -fsanitize=address -o bin main.c^C
$ ../afl++/afl-fuzz -i seeds -o out -- ./bin
afl-fuzz++4.01a based on afl by Michal Zalewski and a large online community
[+] afl++ is maintained by Marc "van Hauser" Heuse, Heiko "hexcoder" Eißfeldt, Andrea Fioraldi and Dominik Maier
[+] afl++ is open source, get it at https://github.com/AFLplusplus/AFLplusplus
[+] NOTE: This is v3.x which changes defaults and behaviours - see README.md
[+] No -M/-S set, autoconfiguring for "-S default"
[*] Getting to work...
[+] Using exponential power schedule (FAST)
[+] Enabled testcache with 50 MB
[+] Generating fuzz data with a a length of min=1 max=1048576
[*] Checking core_pattern...
[!] WARNING: Could not check CPU scaling governor
[+] You have 8 CPU cores and 2 runnable tasks (utilization: 25%).
[+] Try parallel jobs - see docs/parallel_fuzzing.md.
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Checking CPU core loadout...
[+] Found a free CPU core, try binding to #0.
[*] Scanning 'seeds'...
[+] Loaded a total of 1 seeds.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Spinning up the fork server...
[+] All right - fork server is up.
[*] No auto-generated dictionary tokens to reuse.
[*] Attempting dry run with 'id:000000,time:0,execs:0,orig:case_0'...
    len = 1, map size = 10, exec speed = 3413 us
[+] All test cases processed.
[+] Here are some useful stats:

    Test case count : 1 favored, 0 variable, 0 ignored, 1 total
       Bitmap range : 10 to 10 bits (average: 10.00 bits)
        Exec timing : 3413 to 3413 us (average: 3413 us)

[*] No -t option specified, so I'll use an exec timeout of 20 ms.
[+] All set and ready to roll!
^C

+++ Testing aborted by user +++
[+] We're done here. Have a nice day!

Supplementary information (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the bug
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged bug-fix, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the bug is going to be fixed, it has been commented
• If it is not going to be fixed and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps
• The minimum required information to reproduce the bug and spot the root cause is included

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Bug on Parsing Nautilus Grammar

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Bug explanation

The documentation of Nautilus says an array of strings in a rule represents the union of multiple rules.
However, the current implementation doesn't parse this rule correctly.

i.e.,

["LETTER", "a"], ["LETTER", "b"]

works fine but

["LETTER", ["a", "b"]]

is parsed to

["LETTER", "ab"]

since it recognizes this rule as a binary rule.

This bug is going to be fixed in #51.

Steps to reproduce

1. Define a rule like [["A", ["a", "b"]]]
2. Generate a testcase with the rule above
3. ab is generated but a or b is expected

Environment

• fuzzuf version or commit ID: 23b3e52
• OS: Ubuntu 20.04

Expected behaviors

Either a or b should be generated in the example above.

Error messages, stack traces, or logs

N/A

Supplementary information (optional)

N/A

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the bug
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged bug-fix, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the bug is going to be fixed, it has been commented
• If it is not going to be fixed and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps
• The minimum required information to reproduce the bug and spot the root cause is included

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Fix NautilusFuzzer::ParseAndAddRule

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

The first testcase is never used in the first cycle

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Bug explanation

The testcase ID begins from 0 as written in PivotInputs, for example:

fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_state.hpp

Line 1132 in 954e583

u32 id = 0;

current_entry indicates the ID of the testcase to be used and this value is initialized to 0:

fuzzuf/include/fuzzuf/algorithms/afl/afl_state.hpp

Line 250 in 954e583

u32 current_entry = 0; /* Current queue entry ID */

When selecting a seed from queue, this variable is incremented:

fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_other_hierarflow_routines.hpp

Line 78 in 954e583

state.current_entry++;

and is referenced after the increment:

fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_other_hierarflow_routines.hpp

Line 114 in 954e583

auto& testcase = state.case_queue[state.current_entry];

The first testcase, queue/id:000000,orig:XXX, is never used in the first cycle because of this increment.

Steps to reproduce

I wrote the following toy PUT to test the behavior.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv) {
  unsigned char buf[0x11] = { 0 };

  if (argc < 2) return 1;

  FILE *fp = fopen(argv[1], "r");
  fread(buf, 0x10, 1, fp);
  if (buf[0] != 'd' && memcmp(&buf[1], "ead", 3) == 0) {
    buf[0x114514] = 1;
  }
  for (int j = 0; j < 0x10; j++) {
    for (int i = 0; i < buf[j]; i++) {
      buf[j+1] += i;
    }
    if (buf[j+1] == 0x10) {
      buf[j] = 0;
    }
  }
  fclose(fp);
}

This program crashes if the file starts with ?ead but not dead. I prepared the following two seeds.
seeds/a:

deadbeefcafebabe
deadbeefcafebabe
deadbeefcafebabe
deadbeefcafebabe
deadbeefcafebabe
deadbeefcafebabe

seeds/b:

hogeh
ughuga
hogehog
ehughuga
hogehogehughuga
hogehogehughuga
hogehogehughuga
hogehogehughuga

seeds/a likely causes the crash but seeds/b will not.

When starting the fuzzing, you can confirm PivotInputs creates the two seeds:
seeds/a --> out/queue/id:000000,orig:a
seeds/b --> out/queue/id:000001,orig:b

You can see that only b is mutated during the first cycle if you check the files generated in out/queue. The crash only happens from the second cycle.

Environment

• fuzzuf version or commit ID: 954e583
• OS: Ubuntu 20.04

Expected behaviors

current_entry should be incremented after selecting the first testcase in the first cycle.

Suggestion for change: #8

Error messages, stack traces, or logs

Supplementary information (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the bug
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged bug-fix, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the bug is going to be fixed, it has been commented
• If it is not going to be fixed and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps
• The minimum required information to reproduce the bug and spot the root cause is included

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Build fails when nodejs is not installed

Relation to existing issues

Relation to existing roadmaps

Bug explanation

If Node.js is not installed on the system, the build of fuzzuf will fail.

Steps to reproduce

This error can be reproduced by modifying Dockerfile as follows and then executing ./scripts/dev_cli.sh build:

diff --git a/Dockerfile b/Dockerfile
index b468b70..c4df6ab 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -31,7 +31,6 @@ RUN apt-get update \
     mscgen \
     dia \
     wget \
-    nodejs \
     afl++-clang \
     libfdt-dev \
     libglib2.0-dev \

Environment

• fuzzuf version or commit ID: 70f46ea
• OS: Ubuntu 22.04.3 LTS
• (Optional) Other libraries and their versions:

Expected behaviors

The build should complete successfully without die algorithm.

Error messages, stack traces, or logs

+ cmake --build /src/fuzzuf/build -j64
[  0%] Installing npm-6.14.4...
/bin/sh: 1: npm: not found
gmake[2]: *** [tools/algorithms/die/CMakeFiles/die.dir/build.make:76: tools/algorithms/die/die-npm-installed] Error 127
gmake[1]: *** [CMakeFiles/Makefile2:7469: tools/algorithms/die/CMakeFiles/die.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

Supplementary information (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the bug
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged bug-fix, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the bug is going to be fixed, it has been commented
• If it is not going to be fixed and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps
• The minimum required information to reproduce the bug and spot the root cause is included

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Update Dockerfile for the build ease

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Motivation

As in AFL++, it is desirable that fuzzuf is built in Dockerfile ( see https://github.com/AFLplusplus/AFLplusplus/blob/534b3eba143c0532e600eb6da08ac2195fa24570/Dockerfile#L81-L92 ).
Now, our Dockerfile just prepares the environment for build and doesn't build fuzzuf itself.
I want to use fuzzuf only with docker build -t fuzzuf . under the root dir.

Description

Just add something like COPY . . \n cmake ... in Dockerfile.
Accordingly, we need to update this one (https://github.com/fuzzuf/fuzzuf/blob/37bb92a84e4cc6c337abdfb07c96fb3dbf612702/scripts/dev_cli.sh).

This issue is good to resolve when fuzzuf-cc is ready for open and we put it into Dockerfile to combine fuzzuf and fuzzuf-cc.

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Fuzzuf crashes with floating-point exception while fuzzing with aflfast/afl

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Bug explanation

Fuzzuf crashes with floating-point exception while fuzzing with aflfast or afl. I tested only these fuzzer, but maybe this is not the specific problem for these fuzzers.

Steps to reproduce

1. Execute fuzzuf with the aflfast fuzzer
   • fuzzuf aflfast --in_dir=seeds --out_dir=out -- ./put @@
   • If you want to, I will append the put that I tested.
2. Wait some times (10 min or so)

Environment

• fuzzuf version or commit ID: 0412d2
• OS: Ubuntu 20.04.3 LTS on Windows 10 x86_64
• Kernel: 5.10.43.3-microsoft-standard-WSL2

Expected behaviors

No error occurs.

Error messages, stack traces, or logs

For your information, 浮動小数点例外 means the "floating point exception".

$ fuzzuf aflfast --in_dir=seeds --out_dir=out -- ./put @@
[*] Scanning 'seeds'...
[*] Creating hard links for all input files...
[*] Attempting dry run with 'id:000000,orig:seed.md'...
    len = 103, map size = 581, exec speed = 4441 us
[+] All test cases processed.

                         fuzzuf american fuzzy lop (fast) 2.57b (put)

┌─ process timing ─────────────────────────────────────┬─ overall results ─────┐
│        run time : 0 days, 0 hrs, 11 min, 1 sec       │  cycles done : infty  │
│   last new path : 0 days, 0 hrs, 0 min, 45 sec       │  total paths : 1086   │
│ last uniq crash : none seen yet                      │ uniq crashes : 0      │
│  last uniq hang : none seen yet                      │   uniq hangs : 0      │
├─ cycle progress ────────────────────┬─ map coverage ─┴───────────────────────┤
│  now processing : 122.0 (11.23%)    │    map density : 0.93% / 5.52%         │
│ paths timed out : 0 (0.00%)         │ count coverage : 2.74 bits/tuple       │
├─ stage progress ────────────────────┼─ findings in depth ────────────────────┤
│  now trying : auto extras (over)    │ favored paths : 272 (25.05%)           │
│ stage execs : 84/99 (84.85%)        │  new edges on : 519 (47.79%)           │
│ total execs : 108k                  │ total crashes : 0 (0 unique)           │
│  exec speed : 169.5/sec             │  total tmouts : 0 (0)                  │
├─ fuzzing strategy yields ───────────┴───────────────┬─ path geometry ────────┤
│   bit flips : 85/3296, 37/3292, 16/3284             │    levels : 3          │
│  byte flips : 0/412, 0/408, 3/400                   │   pending : 1083       │
│ arithmetics : 79/23.0k, 0/1051, 0/0                 │  pend fav : 272        │
│  known ints : 10/2123, 1/11.3k, 0/17.6k             │ own finds : 1085       │
│  dictionary : 0/0, 0/0, 0/291                       │  imported : n/a        │
│       havoc : 854/32.8k, 0/0                        │ stability : 100.00%    │
│        trim : 0.00%/148, 0.00%                      ├────────────────────────┘
浮動小数点例外────────────────────────────────────────┘          [cpu000: 22%]
$ 

detailed gdb trace information

Program received signal SIGFPE, Arithmetic exception.
0x00007f467c544075 in fuzzuf::algorithm::afl::util::UR (limit=0, rand_fd=8) at /home/keymoon/ricsec/fuzzuf/algorithms/afl/afl_util.cpp:50
50          return random() % limit;
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
───────────────────────────────────────[ REGISTERS ]────────────────────────────────────────
*RAX  0x5e966345
*RBX  0x2
*RCX  0x0
*RDX  0x0
*RDI  0x7f467b8e0740 (unsafe_state) —▸ 0x7f467b8e0234 (randtbl+116) ◂— 0x8f1ca3625a60b629
*RSI  0x7ffca3249954 ◂— 0x2ae469005e966345
 R8   0x0
*R9   0x7f467b8e0240 (pa_next_type) ◂— 0x8
*R10  0x55f96b93e010 ◂— 0x7000300020004
*R11  0x7f467b8e0be0 (main_arena+96) —▸ 0x55f96bc84f30 ◂— 0x0
*R12  0xb
*R13  0x67
 R14  0x0
*R15  0x0
*RBP  0x7ffca32499a0 —▸ 0x7ffca32499c0 —▸ 0x7ffca3249a00 —▸ 0x7ffca3249ae0 —▸ 0x7ffca3249b60 ◂— ...
*RSP  0x7ffca3249970 ◂— 0x3fe0000000000000
*RIP  0x7f467c544075 ◂— idiv   rcx
─────────────────────────────────────────[ DISASM ]─────────────────────────────────────────
 ► 0x7f467c544075    idiv   rcx
    ↓
   0x7f467c544075    idiv   rcx
─────────────────────────────────────[ SOURCE (CODE) ]──────────────────────────────────────
In file: /mnt/c/Users/keymoon/ricsec/fuzzuf/algorithms/afl/afl_util.cpp
   45
   46         using option::AFLTag;
   47         using option::GetReseedRng;
   48         rand_cnt = (GetReseedRng<AFLTag>() / 2) + (seed[1] % GetReseedRng<AFLTag>());
   49     }
 ► 50     return random() % limit;
   51 }
   52
   53 /* Describe all the integers with five characters or less */
   54
   55 std::string DescribeInteger(u64 val) {
─────────────────────────────────────────[ STACK ]──────────────────────────────────────────
00:0000│ rsp 0x7ffca3249970 ◂— 0x3fe0000000000000
01:0008│     0x7ffca3249978 ◂— 0x8
02:0010│     0x7ffca3249980 ◂— 0x3ff0000000000000
03:0018│     0x7ffca3249988 ◂— 0x16789bf72ae46900
04:0020│     0x7ffca3249990 ◂— 0x2
05:0028│     0x7ffca3249998 ◂— 0xb /* '\x0b' */
06:0030│ rbp 0x7ffca32499a0 —▸ 0x7ffca32499c0 —▸ 0x7ffca3249a00 —▸ 0x7ffca3249ae0 —▸ 0x7ffca3249b60 ◂— ...
07:0038│     0x7ffca32499a8 —▸ 0x7f467cc8ba72 ◂— leave

#0  0x00007f467c544075 in fuzzuf::algorithm::afl::util::UR (limit=0, rand_fd=8) at /home/keymoon/ricsec/fuzzuf/algorithms/afl/afl_util.cpp:50
#1  0x00007f467cc8ba72 in fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::ChooseBlockLen(unsigned int)::{lambda(unsigned int)#1}::operator()(unsigned int) const (this=0x7ffca3249d70, limit=0) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_mutator.hpp:58
#2  0x00007f467cc8bafe in fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::ChooseBlockLen (this=0x7ffca3249d70, limit=102) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_mutator.hpp:61
#3  0x00007f467cc8877f in Mutator<fuzzuf::algorithm::aflfast::option::AFLFastTag>::Havoc<unsigned int (*)(std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&, std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&), fuzzuf::algorithm::afl::routine::mutation::HavocBaseTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::DoHavoc(fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, int, int)::{lambda(int, unsigned char*&, unsigned int&)#1}>(unsigned int, std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&, std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&, unsigned int (*)(std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&, std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&), fuzzuf::algorithm::afl::routine::mutation::HavocBaseTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::DoHavoc(fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, int, int)::{lambda(int, unsigned char*&, unsigned int&)#1}) (this=0x7ffca3249d70, stacking=16, extras=std::vector of length 0, capacity 0, a_extras=std::vector of length 1, capacity 1 = {...}, case_distrib=0x7f467c544ee8 <fuzzuf::algorithm::afl::util::HavocCaseDistrib(std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&, std::vector<fuzzuf::algorithm::afl::dictionary::AFLDictData, std::allocator<fuzzuf::algorithm::afl::dictionary::AFLDictData> > const&)>, custom_cases=...) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/mutator/mutator.hpp:501
#4  0x00007f467cc838a9 in fuzzuf::algorithm::afl::routine::mutation::HavocBaseTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::DoHavoc (this=0x55f96b956a10, mutator=..., stage_name="havoc", stage_short="havoc", perf_score=3200, stage_max_multiplier=1024, stage_idx=15) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_mutation_hierarflow_routines.hpp:415
#5  0x00007f467cc7e420 in fuzzuf::algorithm::afl::routine::mutation::HavocTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::operator() (this=0x55f96b956a10, mutator=...) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_mutation_hierarflow_routines.hpp:460
#6  0x00007f467cc809fe in HierarFlowNodeImpl<bool (fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&), bool (unsigned char const*, unsigned int)>::operator()(fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&) (this=0x55f96b956a60, args#0=...) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_node_impl.hpp:104
#7  0x00007f467cc86755 in HierarFlowRoutine<bool (std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>), bool (fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&)>::runAllChildren(fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&) (this=0x55f96b9561e0, args#0=...) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_routine.hpp:122
#8  0x00007f467cc80a96 in HierarFlowRoutine<bool (std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>), bool (fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&)>::CallSuccessors(fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&) (this=0x55f96b9561e0, args#0=...) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_routine.hpp:101
#9  0x00007f467cc80b42 in fuzzuf::algorithm::afl::routine::other::ApplyRandMutsTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::operator() (this=0x55f96b9561e0, testcase=std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase> (use count 3, weak count 0) = {...}) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_other_hierarflow_routines.hpp:504
#10 0x00007f467cc826b0 in HierarFlowNodeImpl<bool (std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>), bool (fuzzuf::algorithm::afl::AFLMutatorTemplate<fuzzuf::algorithm::aflfast::AFLFastState>&)>::operator()(std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>) (this=0x55f96b956240, args#0=std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase> (empty) = {...}) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_node_impl.hpp:104
#11 0x00007f467cc875cb in HierarFlowRoutine<void (), bool (std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>)>::runAllChildren(std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>) (this=0x55f96b953c70, args#0=std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase> (use count 3, weak count 0) = {...}) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_routine.hpp:122
#12 0x00007f467cc82bc3 in HierarFlowRoutine<void (), bool (std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>)>::CallSuccessors(std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>) (this=0x55f96b953c70, args#0=std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase> (empty) = {...}) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_routine.hpp:101
#13 0x00007f467cc82e6e in fuzzuf::algorithm::afl::routine::other::SelectSeedTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::operator() (this=0x55f96b953c70) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_other_hierarflow_routines.hpp:113
#14 0x00007f467cc82f8d in HierarFlowNodeImpl<void (), bool (std::shared_ptr<fuzzuf::algorithm::aflfast::AFLFastTestcase>)>::operator()() (this=0x55f96b955c70) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_node_impl.hpp:104
#15 0x00007f467cc49aee in HierarFlowRoutine<void (), void ()>::runAllChildren() (this=0x55f96b952e20) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_routine.hpp:122
#16 0x00007f467cc40fb4 in HierarFlowRoutine<void (), void ()>::CallSuccessors() (this=0x55f96b952e20) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_routine.hpp:101
#17 0x00007f467cc44e6b in fuzzuf::hierarflow::ProxyRoutine<void ()>::operator()() (this=0x55f96b952e20) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/utility.hpp:86
#18 0x00007f467cc45063 in HierarFlowNodeImpl<void (), void ()>::operator()() (this=0x55f96b952e80) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_node_impl.hpp:104#19 0x00007f467cc4a9c9 in HierarFlowNode<void (), void (), true>::operator()<void>() (this=0x55f96b952a30) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/hierarflow/hierarflow_node.hpp:277
#20 0x00007f467cc83092 in fuzzuf::algorithm::afl::AFLFuzzerTemplate<fuzzuf::algorithm::aflfast::AFLFastState>::OneLoop (this=0x55f96b952a20) at /home/keymoon/ricsec/fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_fuzzer.hpp:125
#21 0x000055f96a6323b1 in main (argc=7, argv=0x7ffca324b9c8) at /home/keymoon/ricsec/fuzzuf/cli/cli_entry_point.cpp:72
#22 0x00007f467b71c0b3 in __libc_start_main (main=0x55f96a631d10 <main(int, char const**)>, argc=7, argv=0x7ffca324b9c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffca324b9b8) at ../csu/libc-start.c:308
#23 0x000055f96a631ace in _start ()

Supplementary information (optional)

With debugging with gdb, I found that this is caused in afl_util.cpp:50 by the limit being 0.

fuzzuf/algorithms/afl/afl_util.cpp

Lines 39 to 51 in 0412d20

	u32 UR(u32 limit, int rand_fd) {
	static u32 rand_cnt;
	if (rand_fd != -1 && unlikely(!rand_cnt--)) {
	u32 seed[2];
	Util::ReadFile(rand_fd, &seed, sizeof(seed));
	srandom(seed[0]);
	using option::AFLTag;
	using option::GetReseedRng;
	rand_cnt = (GetReseedRng<AFLTag>() / 2) + (seed[1] % GetReseedRng<AFLTag>());
	}
	return random() % limit;
	}

This is called from mutator.hpp:58, which is also called from mutator.hpp:61. This indicates that rlim is also being 0 when this crash happens, which is most likely caused by the fact that state.queue_cycle is also being 0.

fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_mutator.hpp

Lines 50 to 65 in 0412d20

	u32 AFLMutatorTemplate<State>::ChooseBlockLen(u32 limit) {
	u32 min_value, max_value;
	u32 rlim = std::min(state.queue_cycle, 3ULL);
	if (!state.run_over10m) rlim = 1;
	// just an alias of afl::util::UR
	auto UR = [this](u32 limit) {
	return afl::util::UR(limit, state.rand_fd);
	};
	switch (UR(rlim)) {
	case 0: min_value = 1;
	max_value = option::GetHavocBlkSmall<Tag>();
	break;

Update: 02/18 20:20

The reason why this crash only occurs after 10 minutes is L54. I recommend deleting this line when you investigate this crash.

fuzzuf/include/fuzzuf/algorithms/afl/templates/afl_mutator.hpp

Lines 52 to 56 in 0412d20

	u32 rlim = std::min(state.queue_cycle, 3ULL);
	if (!state.run_over10m) rlim = 1;
	// just an alias of afl::util::UR

fuzzuf/include/fuzzuf/algorithms/afl/afl_state.hpp

Lines 215 to 217 in 838ef5d

	bool skip_requested = false; /* Skip request, via SIGUSR1 */
	bool run_over10m = false; /* Run time over 10 minutes? */
	bool persistent_mode = false; /* Running in persistent mode? */

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the bug
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged bug-fix, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the bug is going to be fixed, it has been commented
• If it is not going to be fixed and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps
• The minimum required information to reproduce the bug and spot the root cause is included

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Fuzzing Algorithm Documentation

This issue is to track tasks for fuzzing algorithm documentation.

Roadmap for Algorithm Implementation Documents:

• AFL
• AFLFast
• libFuzzer: #38
  • Cleanup Japanese documents
• Nezha: #39
  • Cleanup Japanese documents
• VUzzer: #60
• DIE
• IJON: #40

Implement K-scheduler

Relation to existing issues

#91

Motivation

As confirmed in #94, rezzuf successfully optimizes mutation operators and already has good performance.
But rezzuf currently does not optimize seed scheduling, and thus there is room for further improvement.

As optimization methods of seed scheduling, we considered several choices, such as AFL-HIER (https://www.ndss-symposium.org/ndss-paper/reinforcement-learning-based-hierarchical-seed-scheduling-for-greybox-fuzzing/) or Alphuzz (https://dl.acm.org/doi/abs/10.1145/3564625.3564660).
Among them, we see K-scheduler (https://www.computer.org/csdl/proceedings-article/sp/2022/131600b558/1FlQv2iyB7G) is the most decent and promising.
Therefore, we want to incorporate this into rezzuf.

Description

Basically, what we need to do is to replace the seed scheduler of rezzuf (that is, the one deriving from AFL++) with K-scheduler.
To this end, we have to accomplish the following two steps:

• Implement "$CC" for K-scheduler (say, rezzuf-cc) to be able to obtain the control flow graph of a targeted program.
  • This means #52 is blocking this issue.
• Implement K-scheduler, including the calculation of Katz centrality and the update of edge horizon graph).

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Executor should show detailed error message on crash

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Motivation

The current Native Linux Executor dies without detailed error messages when something went wrong, for example:

• PUT is not compiled by AFL
• Memory limit is not big enough to run PUT

The executor just randomly shows "Success" or "No such file or directory" as the reason of crash.
This is very confusing for the users and should be fixed.

Description

We want to show detailed error messages at least in the 2 cases I mentioned above.
The following part of code needs revised.

fuzzuf/executor/native_linux_executor.cpp

Lines 1052 to 1056 in 954e583

	// FIXME: There are various reason to fail fork server, and as the responses varies and identifiable, it is more decent to classify them.
	if (res == 0 || res > time_limit) {
	TerminateForkServer();
	ERROR("Fork server crashed");
	}

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Take benchmarks to know the performance of each fuzzer and improve rezzuf

Relation to existing issues

Relation to existing roadmaps

This issue is important to complete rezzuf because we've never taken enough benchmarks of fuzzers implemented in fuzzuf and it is unknown whether rezzuf actually has a good performance compared to other fuzzers (including ones not in fuzzuf).

By taking benchmarks, we can know if there's something wrong that should be fixed to complete rezzuf, or other possible improvement to enhance rezzuf.

Motivation

Written above.

Description

Because we have an internal benchmark system, running fuzzers on it is enough.
First, we should compare 4 fuzzers: the original AFL++, fuzzuf aflplusplus, fuzzuf aflplusplus --slopt, fuzzuf rezzuf.
rezzuf should be the best or at least comparable to the others.

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Deploy fuzzuf on the internal benchmark system.
• Take benchmarks.

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

A roadmap to introduce fuzzuf-cc

Relation to existing issues

(For insiders) See related notion task.

Relation to existing roadmaps

(For insiders) See related notion task.

Motivation

• fuzzuf-cc updates AFL/AFL's compile-time instrumentation. Renewal scope is broken down as following phases.
• Phase 1: Notation to describe what features available in the PUT
  • https://github.com/RICSecLab/fuzzuf-cc-private/issues/1
  • PR: N/A (NOTE: There're no changes to fuzzuf at this time.)
  • PR: https://github.com/RICSecLab/fuzzuf-cc-private/pull/5
• Phase 2: Renewal of forkserver mode
  • https://github.com/RICSecLab/fuzzuf-cc-private/issues/2
  • PR: #53
  • PR: https://github.com/RICSecLab/fuzzuf-cc-private/pull/6
• Phase 3: On handling PUT process
  • https://github.com/RICSecLab/fuzzuf-cc-private/issues/3 (No information)
  • PR: #64
  • PR: https://github.com/RICSecLab/fuzzuf-cc-private/pull/7
• Phase 4: AFL++との連携可能性模索
• Phase 5: Reproduce IJON as a motivating example
• Phase 6: Code coverage
• Phase n-1: Support forkserver and non-forkserver in LinuxForkServerExecutor.
  • This change might results in renaming LinuxForkServerExecutor to LinuxExecutor.
• Phase n: Add CI test for LinuxExecutor
  • 最終的にはこれNativeLinuxExecutor使ってるテストを、これに全部置き換えたそう
• // Later phases is to be defined on going...

Description

• See related fuzzuf-cc's GitHub Issue.

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Build fails when using a specific architecture

Overview

The instruction for the building in tutorial.md and building.md failed for my environment when executing the cmake --build build command with the following error:

error: bad value (‘tigerlake’) for ‘-march=’ switch
error: bad value (‘tigerlake’) for ‘-mtune=’ switch

This is due to the gcc that can be installed by apt for Ubuntu-20.04, which is gcc 9.3.0, is not supporting tigerlake architecture.
This issue can be resolved by specifying the binary of gcc/g++ during the configuration process, such as:

$ cmake -D CMAKE_C_COMPILER=gcc-10 -D CMAKE_CXX_COMPILER=g++-10 -B build -DCMAKE_BUILD_TYPE=Release

Environment Information

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.3 LTS"
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 140
model name      : 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
stepping        : 1
microcode       : 0xffffffff
cpu MHz         : 2803.207
cache size      : 12288 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 27
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2intersect flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest ept_mode_based_exec tsc_scaling
bugs            : spectre_v1 spectre_v2 spec_store_bypass swapgs
bogomips        : 5606.41
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:
...

Reduce NativeLinuxExecutor Dependencies

Relation to existing issues

Generally N/A, but this request is also related to #12.

Relation to existing roadmaps

This feature request is to support the item in the TODO.md.

Motivation

The current algorithms deeply depend on NativeLinuxExecutor. This implementation was the right decision in the early development stage as it simplify the codebase. However, as the code is getting larger and has other executors like QEMUExecutor, this dependency is a blocking issue to support other executors with small changes.

Description

This issue proposes refactoring the executors and algorithms to reduce NativeLinuxExecutor dependencies. One key idea to make it possible is introducing Rust trait object-like classes to represent the executor's minimal interface requirements by using type-erasure.
The PoC code is located in https://github.com/retrage/fuzzuf/tree/feature/executor-trait-objects.
I would like to clean up and split down above the PoC branch to small PRs because there are multiple topics in the branch and it's hard to review in a single PR.
This issue will be a tracking issue to show an overview of all the related PRs.

Roadmaps

• Split CPU related operations from the executors: #32
• Introduce coverage classes for the executors: #34
• Introduce executor "traits" for algorithms: #41
• Add CLI support for other executors (e.g. QEMUExecutor): #47
• Add CLI tests: #56
• Update related documents: #55

Alternatives (optional)

There are other candidates on the design decision to implement the executor "trait". The typical alternative way to represent Rust-like traits in C++ is class, but complicated class inheritance is often problematic.

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Need for our own fuzzer: rezzuf

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Motivation

Recently, our paper has been accepted and published at ACSAC 2022 (https://dl.acm.org/doi/abs/10.1145/3564625.3564659).
While we can legitimately say our PoC fuzzer, SLOPT-AFL++ is SOTA as written in the paper, it can be accessible only via our artifact repository (https://github.com/RICSecLab/SLOPTAFLpp) at this moment and we are not going to update the repo.
Because we don't know if the original AFL++ is going to or even wants to implement our optimization method, the current situation is quite wasteful in the sense that virtually no one can make good use of our method even if one wants to do that.

Then, why not to have our own fuzzer that we can modify freely to some extent?
I understand that originally fuzzuf doesn't aim at being a SOTA fuzzer, but being a flexible framework that can express a wide range of fuzzing algorithms.
However, this time I found that, to correctly appreciate some researches (e.g., of optimization) , there should be a high-performance fuzzer that can make effective use of them. It's almost meaningless to apply recent optimization methods to dumb fuzzers.

Description

Here, I propose implementing rezzuf, our own fuzzer whose performance is comparable to AFL++ or honggfuzz.
Unlike the other fuzzing algorithms implemented in fuzzuf, we are free to tune and optimize rezzuf and, on the other hand, should be careful about its performance.
Hence, features that are known to be unnecessary for good performance, such as the deterministic stage of AFL, should be never incorporated into rezzuf (there is no need to provide options for enabling them).
In contrast, promising features should be incorporated at all costs.
Of course, SLOPT is one of such features.

Currently, I'm considering implementing the following features in rezzuf:

• Optimizing the selection of mutation operators with SLOPT
  • It would improve the performance without doubt.
  • Probably we can go further by tackling its future work.
• Optimizing seed scheduling with AFL-HIER or Alphuzz
  - However, it's debatable whether we should implement them as they are. Some experiments should be conducted.
• Implementing some more heuristics that we found are effective in internal experiments.

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed

Support Intel PT-based Feedback

Relation to existing issues

N/A

Relation to existing roadmaps

N/A

Motivation

fuzzuf already supports CoreSight via fork server implementation derived from ProxyExecutor. It is natural to support Intel PT as well.

Description

This issue requests Intel PT-based feedback executor for Linux and Windows. There are several Intel PT-based fuzzers, but we focus on user-space application and PTrix-like path coverage feedback.

Alternatives (optional)

Additional context (optional)

---

Authors of this issue must fill the checklist below when they submit it

Mandatory entries

• The title of this issue clearly summarizes the feature request
• The relations to existing issues and roadmaps are stated if they exist
• Each entry above has been filled

---

A repository maintainer will set up an asignee for each issue.
Asignee must check this issue from the perspective of the checklist below before going through a full-fledged feature addition, and leave the initial comment.
Copy to your comment and fill out the checklist on that occasion.

Optional entries

• If the feature request is going to be accepted, it has been commented
• If it is not going to be accepted and this issue is closed, it has been commented

Mandatory entries

• Have checked relationships to existing issues and roadmaps

---

If an assignee is going to solve the task for this issue, consider the policy and divide the procedures into the checklist.
Once divided, write down the checklist to the comment.
Each step for the procedures must correspond to one single pull request. Once the PR is made, update the checklist.
If the procedures are remained undecided, or need additional reviews, update the checklist appropriately with the discussion here.

Procedure checklist

• Write down the step 1
  • If you have choices rejected, add as an item here with the reasons of rejection
• Write down the step 2
  • Ditto
• ...

---

If an assignee finishes solving the task for this issue, copy the following checklist to the comment and fill it out.

Optional entries

• If you have remaining tasks, relating issues have been created or updated
• If the changes against this issue affect the milestone (e.g. TODO.md), the necessity of version upgrading has already been discussed
• If new tests are required to guarantee the changes against this issue, they have been split to the checklist
• If entries in the checklist are hard to understand, that has been pointed out
• If the discussion concludes that the design concept should be documented appropriately, an assignee has checked additional documents and source codes
• If there were uncertainties during the discussion, all of them have been resolved

Mandatory entries

• The procedure checklist is not required to update any longer
• The PRs correspond to each entries of the checklist have adopted the best way to solve the problems as long as an assignee can come up with
• All the PRs correspond to each entries of the checklist have already been merged
• This issue can be closed

--

If an assignee agrees to close the issue without solving the tasks relating it, describe the reasons in the comment.
Then, copy the following checklist to the comment and fill them out.

Mandatory entries

• The reason to close the issue has been agreed among assignees
• This issue can be closed