||3 years ago|
|in-32||3 years ago|
|in-64||3 years ago|
|Makefile||3 years ago|
|README.md||3 years ago|
|bdshemu_fuzzer.c||3 years ago|
Bitdefender Shellocde Emulator Fuzzer
This assumes that you have AFL in your path.
It collects the
bdshemu sources into a single executable, built with AFL instrumentation.
Build it with
Start fuzzing with
make fuzz32 (for 32-bit mode samples) or
make fuzz64 (for 64-bit mode samples).
If you're in a hurry you can fuzz in the quick and dirty mode with
make fuzz32 DIRTY=y or
make fuzz64 DIRTY=y.
Activate support for address sanitizer with
AFL_USE_ASAN=1 make shfuzz. This can uncover more bugs, but it is a lot slower and requires more memory.
Input files are in the
in-64 directories, crashes will be in
out-64/crashes, hangs will be in
AFL_COMPILER variable is not set, the build process looks for
afl-clang-fast and if it is available, the tool is compiled with that. If not, it tries to choose between
If you want to use a certain compiler simply set
AFL_COMPILER before invoking make:
afl-clang-fast is not compiled by default when compiling AFL. See llvm mode in the AFL repository.
Run the fuzzer in 32-bit mode with
make fuzz32, or in 64-bit mode with
If you want to take advantage of multiple cores see parallel fuzzing.
afl-clang-fast is used, we try to use AFL in persistent mode, which should provide better performance.
Note that both
fuzz64 assume that the tool was compiled with
ASAN builds will have increased memory requirements. You may need to tweak the
-m parameter (or set
afl-fuzz (see notes for ASAN).
By default, all logging is disabled, as it is already not visible while AFL is running. Compile with
LOG=y in order to enable some minimal logging.
Using the tool
shfuzz tool is a simplified version of
disasmtool. It takes 3 positional arguments:
shfuzz file mode use_logging
- file - the path to a input file that contains instructions to be disassembled and emulated;
- mode - the mode in which to run:
32for 32-bit instructions,
64for 64-bit instruction;
- use_logging - if present, will actually log everything that
bdshemuwants to log; even if absent, the
ShemuLogimplementation will still try to access every character in the string it should normally print, so if you want to find bugs related to logging you can still do, but it is a lot faster when the strings don't get printed. This is ignored if you compile
Any errors encountered while parsing the arguments, trying to open the input file, or allocate memory are handled by calling
abort(). This makes it easier to detect these problems.