# Partial Instrumentation

One of the advantages of using an evolutionary coverage-guided fuzzer is that it's capable of finding new execution paths all by itself. However, this can often also be a _disadvantage_. This is particularly true when we face software with a _highly modular architecture_ (as in the case of VLC media player), where each module performs a specific task.

So, let's assume we fed the fuzzer with a valid MKV file. But after several mutations of the input file, the file _"magic bytes"_ have changed and now the input file is viewed as an AVI file by our program. Therefore, this "mutated MKV file" is now processed by AVI Demux. After some time, the file magic bytes change once again and now the file is viewed as an MPEG file. In both cases, the potential of this newly mutated file to increase our code coverage is very poor because this new file won't have any valid syntax structure.

**In short, if we don't put constraints on code coverage, the fuzzer can easily choose a wrong path which in turn makes the fuzzing process less effective.**

To address this problem, AFL++ includes a **Partial Instrumentation** feature that allows you to specify which functions/files should be compiled with or without instrumentation. This helps the fuzzer focus on the important parts of the program, avoiding undesired noise and disturbance by exercising uninteresting code paths.

To use it, we set the environment `AFL_LLVM_ALLOWLIST` variable when compiling. This environment variable must point to a file containing all the functions/filenames that should be instrumented.

You can find more information about AFL++ partial instrumentation at:

{% embed url="https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.instrument_list.md" %}
Using AFL++ with partial instrumentation - AFL++ documentation&#x20;
{% endembed %}
