You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`-DENABLE_FUZZ_TEST`| Builds two fuzzing wrappers for `AFL++`. Use **only with the `afl-c++` compiler** or its variations |
47
-
|`DENABLE_FUZZ_TEST_LIBFUZZER`| Builds two fuzzing wrappers for `libfuzzer`. Use **with the `clang` compiler or variations of `afl-c++`**|
48
47
|`-DENABLE_FUZZ_TEST_DESOCK`| This option allows modifying the behavior of the standard `socket` function. Now data will come from the input stream instead of the network socket. **Instruments the original `fastnetmon` executable**|
49
48
|`-DCMAKE_BUILD_TYPE=Debug`| Debugging option required for proper debugger functionality. **Do not use on release builds or during tests - false positives may occur with sanitizer functions like `assert()`**|
|`/scripts/`| Directory containing scripts for automating fuzzing. ||
82
79
|`/scripts/minimize_out.sh`| Script for minimizing, verifying, and clustering crash outputs. |`./minimize_out.sh <path_to_out_directory> <./binary>`|
83
80
|`/scripts/start_fuzz_conf_file.sh`| Script for running fuzzing on configuration files. Launches several tmux sessions. Uses options `./fastnetmon --configuration_check --configuration_file`. | Run from the current directory without additional options. The environment is automatically set up. |
84
81
|`/scripts/start_fuzz_harness.sh`| Script for testing binary files compiled from wrappers into separate executables. Designed for wrappers compiled for `AFL++`. It sets up the environment, creates folders, and launches two tmux sessions with fuzzer instances. After fuzzing ends, it runs the `minimize_out.sh` script for crash clustering. |`./start_fuzz_harness.sh <path/to/bin>` The script will stop if no new paths are found within a certain time. By default, the time is 1 hour. To change it, modify the `TIME` variable (in seconds) inside the script. |
82
+
|`/scripts/afl_pers_mod_instr.sh`| A script that adds `AFL++` instrumentation for fuzzing in `persistent mode`. **Important! Currently used only with `netflow_collector.cpp` and `sflow_collector.cpp`**|`./afl_pers_mod_instr.sh <netflow_plugin/netflow_collector.cpp>`|
85
83
86
84
87
-
## Example of Fuzzing Run
88
-
--------------------------------
85
+
## Example of manual fuzzing launch for individual fuzzing wrappers
86
+
--------------------------------
87
+
Run the container:
88
+
```bash
89
+
docker run --privileged -it fuzz /bin/bash
90
+
```
91
+
To run AFL++ fuzzing with multi-threading enabled:
89
92
90
-
Run the container:
91
93
```bash
92
-
docker run --privileged -it fuzz /bin/bash
94
+
echo core | tee /proc/sys/kernel/core_pattern
93
95
```
96
+
**Don't forget to collect the data corpus in the in folder**
94
97
95
-
To enable multi-threaded fuzzing with AFL++, we set up core dumping:
98
+
For a test run, use a single sed with a '1':
96
99
```bash
97
-
echo core | tee /proc/sys/kernel/core_pattern
100
+
mkdir in
101
+
echo"1">> in/1
98
102
```
99
-
With the standard `docker image` build, the `build_fuzz` directory will be created, inside which the fuzzing wrappers will be compiled:
103
+
104
+
With a standard docker image build, there will be a folder build_fuzz_harness where the following fuzzing wrappers will be compiled:
105
+
100
106
-`parse_sflow_v5_packet_fuzz`
101
107
-`process_netflow_packet_v5_fuzz`
102
108
103
-
To run fuzzing, we use the `start_fuzz_harness` script:
109
+
**Start fuzzing:**
110
+
```bash
111
+
afl-fuzz -i in -o out -- ./parse_sflow_v5_packet_fuzz
112
+
```
113
+
Or
114
+
115
+
```bash
116
+
afl-fuzz -i in -o out -- ./process_netflow_packet_v5_fuzz
117
+
```
118
+
- The `build_netflow_pers_mod` folder will contain the code for fuzzing the `process_netflow_packet_v5` function via `AFL++ persistent mode`.
119
+
- The `build_sflow_pers_mod` folder will contain the code for fuzzing the `parse_sflow_v5_packet` function via `AFL++ persistent mode`.
120
+
If the build is done manually, use the `afl_pers_mod_instr.sh` script to instrument the files.
121
+
122
+
The fuzzing launch for these functions is the same, as the final executable file fastnetmon is instrumented:
123
+
124
+
```bash
125
+
afl-fuzz -i in -o out -- ./fastnetmon
126
+
```
127
+
128
+
**IMPORTANT!**
129
+
For multi-thread fuzzing of the fastnetmon file, you need to provide a separate configuration file for each instance of the fuzzer for `fastnetmon`, specifying different ports for protocols, otherwise, the instances will conflict, and multiple threads will not be able to run.
130
+
131
+
132
+
## Example of fuzzing launch via automation script
133
+
--------------------------------
134
+
*All actions take place inside the container, where the working directory is `src`, so paths are constructed relative to this folder.*
135
+
136
+
For fuzzing, we use the `start_fuzz_harness` script.
|`AFLNet`| The characteristics of the protocol (lack of feedback) prevent the use of this fuzzer. |
143
196
|`desock`| Code instrumentation is successful, but the fuzzer does not start and cannot collect feedback. I consider this method **promising**, but the fuzzer requires adjustments. |
197
+
| `libfuzzer` | Wrappers for `libfuzzer` were written and implemented into cmake, but due to the peculiarities of the build and the project's focus on fuzzing via `AFL++`, they were removed from the project. Commit with a working [`libfuzzer`] wrappers (https://github.com/pavel-odintsov/fastnetmon/commit/c3b72c18f0bc7f43b535a5da015c3954d716be22)
198
+
199
+
200
+
## Fuzzing Launch in Docker Container
201
+
202
+
### A Few Words for Context
203
+
204
+
Each fuzzer thread requires one system thread.
205
+
206
+
The `start_fuzz_harness.sh` script includes a time limit for fuzzing.
207
+
The `TIME` variable is responsible for the "last path found" time parameter.
208
+
If this parameter stops resetting, it means the fuzzer has hit a deadlock and there's no point in continuing fuzzing.
209
+
From empirical experience, this parameter should be set to 2 hours. The project has it set to 1 hour.
210
+
If shallow testing is needed, this parameter can be reduced to 10-15 minutes, making the total fuzzing time last a few hours.
This method can be used to launch any wrapper / binary file by simply providing the command from the *Example of fuzzing launch via automation script* section in quotes after the `-c` argument.
228
+
229
+
After fuzzing is completed, the results will be placed in the host system's work folder—both the results folder and the clustering folder will be there.
230
+
231
+
The container will have a status exit. It can be manually restarted to check for crashes.
0 commit comments