Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence.

Related tags

Cryptography jazzer

Jazzer logo


Maven Central GitHub Actions

Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM.

The JVM bytecode is executed inside the fuzzer process, which ensures fast execution speeds and allows seamless fuzzing of native libraries.


The preferred way to install Jazzer is to compile it from source using Bazel, but binary distributions are also available. At the moment Jazzer is only available for x64 Linux.

Using Bazel

Jazzer has the following dependencies when being built from source:

  • JDK 8 or later (e.g. OpenJDK)
  • Clang 9.0 or later (using a recent version is strongly recommended)

Jazzer uses Bazelisk to automatically download and install Bazel. Building Jazzer from source and running it thus only requires the following assuming the dependencies are installed:

git clone https://github.com/CodeIntelligenceTesting/jazzer
cd jazzer
# If Bazel is installed, use (note the double dash):
bazel run //:jazzer -- <arguments>
# If Bazel is not installed, use (note the double dash):
./bazelisk-linux-amd64 run //:jazzer -- <arguments>

Using the provided binaries

Binary releases are available under Releases and are built using an LLVM 11 Bazel toolchain.

The binary distributions of Jazzer consists of the following components:

  • jazzer_driver - native binary that interfaces between libFuzzer and the JVM fuzz target
  • jazzer_agent_deploy.jar - Java agent that performs bytecode instrumentation and tracks coverage
  • jazzer_api_deploy.jar - contains convenience methods for creating fuzz targets and defining custom hooks
  • jazzer - convenience shell script that runs the Jazzer driver with the local JRE shared libraries added to LD_LIBRARY_PATH

The additional release artifact examples.jar contains most of the examples and can be used to run them without having to build them (see Examples below).

After unpacking the archive, run Jazzer via

./jazzer <arguments>

If this leads to an error message saying that libjvm.so has not been found, the path to the local JRE needs to be specified in the JAVA_HOME environment variable.


Multiple examples for instructive and real-world Jazzer fuzz targets can be found in the examples/ directory. A toy example can be run as follows:

# Using Bazelisk:
./bazelisk-linux-amd64 run //examples:ExampleFuzzer
# Using the binary release and examples_deploy.jar:
./jazzer --cp=examples_deploy.jar

This should produce output similar to the following:

INFO: Loaded 1 hooks from com.example.ExampleFuzzerHooks
INFO: Instrumented com.example.ExampleFuzzer (took 81 ms, size +83%)
INFO: libFuzzer ignores flags that start with '--'
INFO: Seed: 2735196724
INFO: Loaded 1 modules   (65536 inline 8-bit counters): 65536 [0xe387b0, 0xe487b0),
INFO: Loaded 1 PC tables (65536 PCs): 65536 [0x7f9353eff010,0x7f9353fff010),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
#2      INITED cov: 2 ft: 2 corp: 1/1b exec/s: 0 rss: 94Mb
#1562   NEW    cov: 4 ft: 4 corp: 2/14b lim: 17 exec/s: 0 rss: 98Mb L: 13/13 MS: 5 ShuffleBytes-CrossOver-InsertRepeatedBytes-ShuffleBytes-CMP- DE: "magicstring4"-
#1759   REDUCE cov: 4 ft: 4 corp: 2/13b lim: 17 exec/s: 0 rss: 99Mb L: 12/12 MS: 2 ChangeBit-EraseBytes-
#4048   NEW    cov: 6 ft: 6 corp: 3/51b lim: 38 exec/s: 0 rss: 113Mb L: 38/38 MS: 4 ChangeBit-ChangeByte-CopyPart-CrossOver-
#4055   REDUCE cov: 6 ft: 6 corp: 3/49b lim: 38 exec/s: 0 rss: 113Mb L: 36/36 MS: 2 ShuffleBytes-EraseBytes-
#4266   REDUCE cov: 6 ft: 6 corp: 3/48b lim: 38 exec/s: 0 rss: 113Mb L: 35/35 MS: 1 EraseBytes-
#4498   REDUCE cov: 6 ft: 6 corp: 3/47b lim: 38 exec/s: 0 rss: 114Mb L: 34/34 MS: 2 EraseBytes-CopyPart-
#4764   REDUCE cov: 6 ft: 6 corp: 3/46b lim: 38 exec/s: 0 rss: 115Mb L: 33/33 MS: 1 EraseBytes-
#5481   REDUCE cov: 6 ft: 6 corp: 3/44b lim: 43 exec/s: 0 rss: 116Mb L: 31/31 MS: 2 InsertByte-EraseBytes-
#131072 pulse  cov: 6 ft: 6 corp: 3/44b lim: 1290 exec/s: 65536 rss: 358Mb

== Java Exception: java.lang.IllegalStateException: mustNeverBeCalled has been called
        at com.example.ExampleFuzzer.mustNeverBeCalled(ExampleFuzzer.java:38)
        at com.example.ExampleFuzzer.fuzzerTestOneInput(ExampleFuzzer.java:32)
DEDUP_TOKEN: eb6ee7d9b256590d
== libFuzzer crashing input ==
MS: 1 CMP- DE: "\x00C"-; base unit: 04e0ccacb50424e06e45f6184ad45895b6b8df8f
artifact_prefix='./'; Test unit written to crash-efea1e8fc83a15217d512e20d964040a68a968c3
Base64: bWFnaWNzdHJpbmc0dHJpbmc0dGlnNHsAAEM0CgAAAA==
reproducer_path='.'; Java reproducer written to Crash_efea1e8fc83a15217d512e20d964040a68a968c3.java

Here you can see the usual libFuzzer output in case of a crash, augmented with JVM-specific information. Instead of a native stack trace, the details of the uncaught Java exception that caused the crash are printed, followed by the fuzzer input that caused the exception to be thrown (if it is not too long). More information on what hooks and Java reproducers are can be found below.

See examples/BUILD.bazel for the list of all possible example targets.


Jazzer has so far uncovered the following vulnerabilities and bugs:

Project Bug Status CVE found by
OWASP/json-sanitizer Output can contain and ]]>, which allows XSS fixed CVE-2021-23899 Code Intelligence
OWASP/json-sanitizer Output can be invalid JSON and undeclared exceptions can be thrown fixed CVE-2021-23900 Code Intelligence
JSONParser#parse throws an undeclared exception reported CVE-2021-27568 @GanbaruTobi
FasterXML/jackson-dataformats-binary CBORParser throws an undeclared exception due to missing bounds checks when parsing Unicode fixed Code Intelligence
FasterXML/jackson-dataformats-binary CBORParser throws an undeclared exception on dangling arrays fixed Code Intelligence
alibaba/fastjon JSON#parse throws undeclared exceptions reported Code Intelligence
Apache/commons-imaging Parsers for multiple image formats throw undeclared exceptions reported Code Intelligence

If you find bugs with Jazzer, we would like to hear from you! Feel free to open an issue or submit a pull request.


Creating a fuzz target

Jazzer requires a JVM class containing the entry point for the fuzzer. This is commonly referred to as a "fuzz target" and may be as simple as the following Java example:

package com.example.MyFirstFuzzTarget;

class MyFirstFuzzTarget {
    public static void fuzzerTestOneInput(byte[] input) {
        // Call the function under test with arguments derived from input and
        // throw an exception if something unwanted happens.

A Java fuzz target class needs to define exactly one of the following functions:

  • public static void fuzzerTestOneInput(byte[] input): Ideal for fuzz targets that naturally work on raw byte input (e.g. image parsers).
  • public static void fuzzerTestOneInput(com.code_intelligence.api.FuzzedDataProvider data): A variety of types of "fuzzed data" is made available via the FuzzedDataProvider interface (see below for more information on this interface).

The fuzzer will repeatedly call this function with generated inputs. All unhandled exceptions are caught and reported as errors.

The optional functions public static void fuzzerInitialize() or public static void fuzzerInitialize(String[] args) can be defined if initial setup is required. These functions will be called once before the first call to fuzzerTestOneInput.

The optional function public static void fuzzerTearDown() will be run just before the JVM is shut down.

Running the fuzzer

The fuzz target needs to be compiled and packaged into a .jar archive. Assuming that this archive is called fuzz_target.jar and depends on libraries available as lib1.jar and lib2.jar, fuzzing is started by invoking Jazzer with the following arguments:

--cp=fuzz_target.jar:lib1.jar:lib2.jar --target_class=com.example.MyFirstFuzzTarget <optional_corpus_dir>

The fuzz target class can optionally be specified by adding it as the value of the Jazzer-Fuzz-Target-Class attribute in the JAR's manifest. If there is only a single such attribute among all manifests of JARs on the classpath, Jazzer will use its value as the fuzz target class.

Bazel produces the correct type of .jar from a java_binary target with create_executable = False and deploy_manifest_lines = ["Jazzer-Fuzz-Target-Class: com.example.MyFirstFuzzTarget"] by adding the suffix _deploy.jar to the target name.

Fuzzed Data Provider

For most non-trivial fuzz targets it is necessary to further process the byte array passed from the fuzzer, for example to extract multiple values or convert the input into a valid java.lang.String. We provide functionality similar to atheris' FuzzedDataProvider and libFuzzer's FuzzedDataProvider.h to simplify the task of writing JVM fuzz targets.

If the function public static void fuzzerTestOneInput(FuzzedDataProvider data) is defined in the fuzz target, it will be passed an object implementing com.code_intelligence.jazzer.api.FuzzedDataProvider that allows consuming the raw fuzzer input as values of common types. This can look as follows:

package com.example.MySecondFuzzTarget;

import com.code_intelligence.jazzer.api.FuzzedDataProvider;

class MySecondFuzzTarget {
    public satic void callApi(int val, String text) {

    public static void fuzzerTestOneInput(FuzzedDataProvider data) {
        callApi1(data.consumeInt(), data.consumeRemainingAsString());
        return false;

The FuzzedDataProvider interface definition is contained in jazzer_api_deploy.jar in the binary release and can be built by the Bazel target //agent:jazzer_api_deploy.jar. It is also available from Maven Central. For additional information, see the javadocs.

It is highly recommended to use FuzzedDataProvider for generating java.lang.String objects inside the fuzz target instead of converting the raw byte array to directly via a String constructor as the FuzzedDataProvider implementation is engineered to minimize copying and generate both valid and invalid ASCII-only and Unicode strings.

Reproducing a bug

When Jazzer manages to find an input that causes an uncaught exception or a failed assertion, it prints a Java stack trace and creates two files that aid in reproducing the crash without Jazzer:

  • crash- contains the raw bytes passed to the fuzz target (just as with libFuzzer C/C++ fuzz targets). The crash can be reproduced with Jazzer by passing the path to the crash file as the only positional argument.
  • Crash-.java contains a class with a main function that invokes the fuzz target with the crashing input. This is especially useful if using FuzzedDataProvider as the raw bytes of the input do not directly correspond to the values consumed by the fuzz target. The .java file can be compiled with just the fuzz target and its dependencies in the classpath (plus jazzer_api_deploy.jar if using `FuzzedDataProvider).

Minimizing a crashing input

Every crash stack trace is accompanied by a DEDUP_TOKEN that uniquely identifies the relevant parts of the stack trace. This value is used by libFuzzer while minimizing a crashing input to ensure that the smaller inputs reproduce the "same" bug. To minimize a crashing input, execute Jazzer with the following arguments in addition to --cp and --target_class:

-minimize_crash=1 <path/to/crashing_input>

Parallel execution

libFuzzer offers the -fork=N and -jobs=N flags for parallel fuzzing, both of which are also supported by Jazzer.


Jazzer currently maintains coverage information in a global variable that is shared among threads. This means that while fuzzing multi-threaded fuzz targets is theoretically possible, the reported coverage information may be misleading.

Advanced Options

Various command line options are available to control the instrumentation and fuzzer execution. Since Jazzer is a libFuzzer-compiled binary, all positional and single dash command-line options are parsed by libFuzzer. Therefore, all Jazzer options are passed via double dash command-line flags, i.e., as --option=value (note the = instead of a space).

A full list of command-line flags can be printed with the --help flag. For the available libFuzzer options please refer to its documentation for a detailed description.

Coverage Instrumentation

The Jazzer agent inserts coverage markers into the JVM bytecode during class loading. libFuzzer uses this information to guide its input mutations towards increased coverage.

It is possible to restrict instrumentation to only a subset of classes with the --instrumentation_includes flag. This is especially useful if coverage inside specific packages is of higher interest, e.g., the user library under test rather than an external parsing library in which the fuzzer is likely to get lost. Similarly, there is --instrumentation_excludes to exclude specific classes from instrumentation. Both flags take a list of glob patterns for the java class name separated by colon:

--instrumentation_includes=com.my_com.**:com.other_com.** --instrumentation_excludes=com.my_com.crypto.**

By default, JVM-internal classes and Java as well as Kotlin standard library classes are not instrumented, so these do not need to be excluded manually.

Trace Instrumentation

The agent adds additional hooks for tracing compares, integer divisions, switch statements and array indices. These hooks correspond to clang's data flow hooks. The particular instrumentation types to apply can be specified using the --trace flag, which accepts the following values:

  • cov: AFL-style edge coverage
  • cmp: compares (int, long, String) and switch cases
  • div: divisors in integer divisions
  • gep: constant array indexes
  • indir: call through Method#invoke
  • all: shorthand to apply all available instrumentations

Multiple instrumentation types can be combined with a colon.

Value Profile

The run-time flag -use_value_profile=1 enables libFuzzer's value profiling mode. When running with this flag, the feedback about compares and constants received from Jazzer's trace instrumentation is associated with the particular bytecode location and used to provide additional coverage instrumentation. See ExampleValueProfileFuzzer.java for a fuzz target that would be very hard to fuzz without value profile.

As passing the bytecode location back to libFuzzer requires inline assembly and may thus not be fully portable, it can be disabled via the flag --nofake_pcs.

Custom Hooks

In order to obtain information about data passed into functions such as String.equals or String.startsWith, Jazzer hooks invocations to these methods. This functionality is also available to fuzz targets, where it can be used to implement custom sanitizers or stub out methods that block the fuzzer from progressing (e.g. checksum verifications or random number generation). See ExampleFuzzerHooks.java for an example of such a hook.

Method hooks can be declared using the @MethodHook annotation defined in the com.code_intelligence.jazzer.api package, which is contained in jazzer_api_deploy.jar (binary release) or built by the target //agent:jazzer_api_deploy.jar (Bazel). It is also available from Maven Central. See the javadocs of the @MethodHook API for more details.

To use the compiled method hooks they have to be available on the classpath provided by --cp and can then be loaded by providing the flag --custom_hooks, which takes a colon-separated list of names of classes to load hooks from. This list of custom hooks can alternatively be specified via the Jazzer-Hook-Classes attribute in the fuzz target JAR's manifest.

Suppressing stack traces

With the flag --keep_going=N Jazzer continues fuzzing until N unique stack traces have been encountered.

Particular stack traces can also be ignored based on their DEDUP_TOKEN by passing a comma-separated list of tokens via --ignore=,.

Advanced fuzzed targets

Fuzzing with Native Libraries

Jazzer supports fuzzing of native libraries loaded by the JVM, for example via System.load(). For the fuzzer to get coverage feedback, these libraries have to be compiled with -fsanitize=fuzzer-no-link.

Additional sanitizers such as AddressSanitizer are often desirable to uncover bugs inside the native libraries. This requires compiling the library with -fsanitize=fuzzer-no-link,address and using the asan-ified driver available as the Bazel target //:jazzer_asan.

Note: Sanitizers other than AddressSanitizer are not yet supported. Furthermore, due to the nature of the JVM's GC, LeakSanitizer reports currently too many false positives to be useful and are thus disabled.

The fuzz target ExampleFuzzerWithNative in the examples/ directory contains a minimal working example for fuzzing with native libraries. Also see TurboJpegFuzzer for a real-world example.

Fuzzing with Custom Mutators

LibFuzzer API offers two functions to customize the mutation strategy which is especially useful when fuzzing functions that require structured input. Jazzer does not define LLVMFuzzerCustomMutator nor LLVMFuzzerCustomCrossOver and leaves the mutation strategy entirely to libFuzzer. However, custom mutators can easily be integrated by compiling a mutator library which defines LLVMFuzzerCustomMutator (and optionally LLVMFuzzerCustomCrossOver) and pre-loading the mutator library:

# Using Bazel:
LD_PRELOAD=libcustom_mutator.so ./bazelisk-linux-amd64 run //:jazzer -- <arguments>
# Using the binary release:
LD_PRELOAD=libcustom_mutator.so ./jazzer <arguments>


The following developers have contributed to Jazzer:

Sergej Dechand, Christian Hartlage, Fabian Meumertzheim, Sebastian Pöplau, Mohammed Qasem, Simon Resch, Henrik Schnor, Khaled Yakdan

The LLVM-style edge coverage instrumentation for JVM bytecode used by Jazzer relies on JaCoCo. Previously, Jazzer used AFL-style coverage instrumentation as pioneered by kelinci.

Code Intelligence logo

  • Undocumented build issues on macOS

    Undocumented build issues on macOS

    same to issue-21

    MacOS version


    java -version

    java version "1.8.0_241"
    Java(TM) SE Runtime Environment (build 1.8.0_241-b07)
    Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode)

    bazel --version


    clang --version

    Apple clang version 11.0.3 (clang-1103.0.32.29)
    Target: x86_64-apple-darwin19.6.0
    Thread model: posix
    InstalledDir: /Library/Developer/CommandLineTools/usr/bin

    run :

    git clone https://github.com/CodeIntelligenceTesting/jazzer
    cd jazzer
    bazel run //:jazzer -- --cp=target.jar


    INFO: Options provided by the client:
      Inherited 'common' options: --isatty=1 --terminal_columns=149
    INFO: Reading rc options for 'run' from /Users/xxx/jazzer/.bazelrc:
      Inherited 'build' options: --incompatible_strict_action_env -c opt --cxxopt=-std=c++17 --action_env=CC=clang --java_language_version=8 --tool_java_language_version=9
    ERROR: Unrecognized option: --java_language_version=8
    opened by LandGrey 19
  • JUnit integration usage

    JUnit integration usage


    I've been trying to use jazzer-junit with my unit test suite and gradle and it didn't work for me. Couldn't find any documentation on how to make it work with gradle (not bazel). Am I missing some junit configuration? I imported jazzer-junit and synced gradle so it sees all dependencies. But when i try to run i'm getting > No tests found for given includes message. Please, give some brief explanation on how to integrate @FuzzTest annotations to existing junit/gradle setup.

    opened by yarikbratashchuk 15
  • slow-unit does not reproduce and hangs jazzer

    slow-unit does not reproduce and hangs jazzer

    I'm currently testing GZIPInputStream and a portion of the Jackson library. My fuzzer ends up writing a slow-unit to disk, but never writes the reproducer .java. It also never finishes and just sits in futex syscall when I look through /proc/pid/syscall.

    I'm basically asking to see is this an issue with jazzer or did I find a not reproducible bug in my fuzz test. I can post my testcase and whatever else is needed. Just didn't want to end up disclosing a 0-day in the library here if it exists.

    What kind of information would be beneficial to your team to see if it's jazzer?

    opened by thapr0digy 11
  • Jazzer does not use libc++

    Jazzer does not use libc++

    I tried adding jazzer test rules as a http_archive to my WORKSPACE file:

        name = "rules_jazzer",
        sha256 = "c2b26f80618f51fd7d75e2e8067084f3776f321b596ca2fb19c585f836739bf9",
        strip_prefix = "jazzer-0.9.1",
        urls = ["https://github.com/CodeIntelligenceTesting/jazzer/archive/refs/tags/v0.9.1.tar.gz"],

    and then using java_fuzz_target_test as a test in one of my BUILD files

    load("@rules_jazzer//bazel:fuzz_target.bzl", "java_fuzz_target_test")
        name = "gateway_controller_fuzz",

    However, it seems that java_fuzz_target_test adds dependencies on internal targets (e.g. //agent/src/main/java/com/code_intelligence/jazzer/api), which means that it can't be used in this way.

    FWIW, I also suggested that jazzer rules could be added to bazelbuild/rules_fuzzing, so that might be a better place to fix this problem.

    opened by chrismgrayftsinc 8
  • Java Jazzer class seams to does not honor the --jvm_args nor JAVA_OPTS

    Java Jazzer class seams to does not honor the --jvm_args nor JAVA_OPTS

    When using the new Java-Style com.code_intelligence.jazzer.Jazzer main. The code seams to not honor JVM options, which should be passed to child processes either with --jvm_args or JAVA_OPTS.

    I could not find any code except of the Native launcher to check for these arguments. In the Jazzer class the method javaBinaryArgs() constructs the JVM args, but it does not copy the args into it.

    opened by AndreasTu 7
  • Add support for `compile_command.json` generation

    Add support for `compile_command.json` generation

    compile_command.json, as specified at JSONCompilationDatabase, is used by many tools to provide C++ support. This file can easily be created using the added bazel rule.

    C++ support is particular helpful when changing code in the driver module.

    opened by bertschneider 7
  • Split crash reproducer data

    Split crash reproducer data

    If the recorded FuzzedDataProvider invocation data gets too long it can not be assigned to one String variable in the crash reproducer template anymore. More concretely one constant pool CONSTANT_Utf8_info entry can only hold data of a size up to uint16. This PR splits up the recorded data into multiple chunks to always generate valid crash reproducers.

    Furthermore, a tests directory is introduced to hold an explicit Jazzer integration test to verify this issue (#269). The integration test compiles and executes the generated crash reproducer to verify it's functionality.

    Fixes #269

    opened by bertschneider 6
  • AutofuzzError: popGroup must be called exactly once for every pushGroup

    AutofuzzError: popGroup must be called exactly once for every pushGroup

    The exception below is encountered when using autofuzz functionality in jazzer-macos-x86_64 release 0.13.0 with the following options: --keep_going=20 -timeout=500 -max_total_time=1000 -detect_leaks=1 --autofuzz_ignore=java.lang.NullPointerException

    Exception: Unexpected exception encountered during autofuzz

    == Java Exception: com.code_intelligence.jazzer.api.FuzzerSecurityIssueHigh: Remote Code Execution Unrestricted class loading based on externally controlled data may allow remote code execution depending on available classes on the classpath. at jaz.Zer.(Zer.java:54) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) DEDUP_TOKEN: 369a3531317dd2b8 == libFuzzer crashing input == MS: 2 ChangeASCIIInt-InsertByte-; base unit: 45af2ab87417b6ba33c8466209734092926d6091 0x1,0x0,0x2f,0x32,0x5d,0x1,0x3a,0x0,0x2f,0x31,0x5d,0xa,0x30,0xff,0xff,0xd2,0x25,0x6e,0xff,0xff,0xff,0xff,0x8,0x73,0xdb,0x3f,0xf4, \001\000/2]\001:\000/1]\0120\377\377\322%n\377\377\377\377\010s\333?\364 artifact_prefix='./'; Test unit written to ./crash-874c731d9350679a19dfce7cf0fc3b244704f7e9 Base64: AQAvMl0BOgAvMV0KMP//0iVu/////whz2z/0 Exception in thread "main" com.code_intelligence.jazzer.autofuzz.AutofuzzError: popGroup must be called exactly once for every pushGroup: [[], [((java.util.function.Supplier) (() -> {redactedClass autofuzzVariable0 = new redactedClass(); return autofuzzVariable0;})).get()], [], [], [], [], [new com.fasterxml.jackson.databind.node.JsonNodeFactory(false)], [], [(org.assertj.core.internal.bytebuddy.description.method.MethodDescription.InDefinedShape) new org.assertj.core.internal.bytebuddy.description.method.MethodDescription.ForLoadedMethod((java.lang.reflect.Method) null), (java.util.List) new jaz.Zer("", (java.lang.Throwable) null)]] Please file an issue at: https://github.com/CodeIntelligenceTesting/jazzer/issues/new/choose at com.code_intelligence.jazzer.autofuzz.AutofuzzCodegenVisitor.generate(AutofuzzCodegenVisitor.java:55) at com.code_intelligence.jazzer.autofuzz.FuzzTarget.dumpReproducer(FuzzTarget.java:238) at com.code_intelligence.jazzer.driver.FuzzTargetRunner.dumpReproducer(FuzzTargetRunner.java:341) at com.code_intelligence.jazzer.driver.FuzzTargetRunner.runOne(FuzzTargetRunner.java:253) at com.code_intelligence.jazzer.runtime.FuzzTargetRunnerNatives.startLibFuzzer(Native Method) at com.code_intelligence.jazzer.driver.FuzzTargetRunner.startLibFuzzer(FuzzTargetRunner.java:409) at com.code_intelligence.jazzer.driver.FuzzTargetRunner.startLibFuzzer(FuzzTargetRunner.java:282) at com.code_intelligence.jazzer.driver.Driver.start(Driver.java:88) at com.code_intelligence.jazzer.Jazzer.start(Jazzer.java:90) at com.code_intelligence.jazzer.Jazzer.main(Jazzer.java:69)

    opened by csulliv9 5
  • Add support for --coverage_report equivalent in JUnit integration

    Add support for --coverage_report equivalent in JUnit integration

    I'd love to be able to run fuzz tests more easily via the JUnit integration, but still receive a coverage report like the one that the binary is able to generate.

    In the future I could also see myself needing equivalents for --coverage_dump, -merge, and -runs so I'm not sure if a one-to-one mapping to annotation parameters is ideal, or if something more generic (e.g. a "libFuzzerArgs" parameter and/or a "args" parameter) would be better.

    opened by gredler 5
  • Minimize bootstrap class path

    Minimize bootstrap class path

    Previously, we appended the entire Jazzer agent with all its dependencies to the bootstrap classpath, which resulted in a number of classes being loaded both in the system and bootstrap class loader when the agent wasn't initialized right after the JVM had been started. This made it impossible to load the agent e.g. in a JUnit test engine.

    With this PR, the agent JAR bundles a separate bootstrap JAR that only includes the classes that strictly must be available on the bootstrap class loader's classpath: Classes defining callbacks called by our instrumentation as well as the native driver library which these callbacks call into.

    The new AgentInstaller class takes care of extracting and appending this JAR to the bootstrap search path. For the sake of consistency, it does this even if --nohooks is specified, but doesn't enable the agent in that case.

    opened by fmeum 5
  • Ctrl + c not working with -fork and -ignore_crashes=1

    Ctrl + c not working with -fork and -ignore_crashes=1

    Using the Libfuzzer flags -fork and -ignore_crashes sending ctrl + c is regarded as a crash and the threads restart. I fixed it in my own fork with a small patch from https://github.com/google/oss-fuzz/issues/4547. Since the diskussion there implies no real maintenance of Libfuzzer anymore, maybe there is interest in fixing it in the fork used by jazzer ?

    opened by SyrasX 5
  • Junit jupiter not picking up any

    Junit jupiter not picking up any "jazzer" tagged tests


    I'm trying to retrofit Jazzer to an existing project (often a mistake!), just to get some familiarity with the software. Having seen that the new Junit jupiter integration is in play, I thought I would try and use that.

    So, I have a new fuzz test task in my gradle build script:

    	val fuzzTest = task<Test>("fuzztest") {
    		description = "Runs fuzz tests."
    		group = "verification"
    	testClassesDirs = sourceSets["test"].output.classesDirs
    	classpath = sourceSets["test"].runtimeClasspath + sourceSets.main.get().output
    	useJUnitPlatform {

    and I have tagged my fuzz test with the required tag (which is also included in the @FuzzTest annotation)

    class ByteFuzzTest {
        @FuzzTest(maxDuration = "2m")
        void byteFuzz(byte[] data) {
            if (data.length < 1) {
            if (data[0] % 2 == 0) {

    with JAZZER_FUZZ=1, I always get this error message:

    org.junit.platform.launcher.core.EngineDiscoveryOrchestrator lambda$logTestDescriptorExclusionReasons$7
    INFO: 18 containers and 14 tests were excluded because tags do not match tag expression(s): [jazzer]

    Probably my configuration or junit jupiter libraries, perhaps? I have these in my build script:

        testImplementation(group = "org.junit.jupiter", name = "junit-jupiter", version = "5.9.1")
        testImplementation(group = "org.junit.jupiter", name = "junit-jupiter-api", version = "5.9.1")
        testImplementation(group = "org.junit.jupiter", name = "junit-jupiter-params", version = "5.9.1")
        testImplementation(group = "com.code-intelligence", name="jazzer-junit", version="0.13.1")

    Pretty sure this is on me, but any suggestions would be gratefully received.

    opened by stephengardiner 3
  • Add script engine injection sanitizer with real life example

    Add script engine injection sanitizer with real life example

    This merge request adds a sanitiser to detect data flows of user input into the javax.script.ScriptEngine#eval sink which often results in arbitrary code execution (CWE-94) using a registered scripting engine.

    JVM script engines (JSR-223 implementations) can be registered under multiple arbitrary names and they can implement any language (although ECMAScript is probably the most widely used one in real applications).

    This sanitizer implementation only confirms data flow, it does not require successful script execution with a registered script engine (similarly to how the OsCommandInjection sanitizer does not guide the fuzzer into running the actual command). As soon as an input produces an execution that reaches the evaluation of the “1+1” expression by a javax.script.ScriptEngine implementation, we report a finding.

    I have added a test that demonstrates the sanitizer by rediscovering the CVE-2022-42889 in Apache Commons Text using minimal assumptions of the library and the finding. (It does however limit the length of the input taken from the fuzzer and it adds a hook to avoid the ${const:…} interpolation which can be used to read public static members of any loadable class - not remotely as promising as the ${script:…} payload.)

    bazel clean && bazel run --local_cpu_resources=8 //examples:CommonsTextFuzzer
    INFO: Build completed successfully, 443 total actions
    exec ${PAGER:-/usr/bin/less} "$0" || exit 1
    Executing tests from //examples:CommonsTextFuzzer
    INFO: Loaded 125 hooks from com.code_intelligence.jazzer.runtime.TraceCmpHooks
    INFO: Loaded 4 hooks from com.code_intelligence.jazzer.runtime.TraceDivHooks
    INFO: Loaded 2 hooks from com.code_intelligence.jazzer.runtime.TraceIndirHooks
    INFO: Loaded 4 hooks from com.code_intelligence.jazzer.runtime.NativeLibHooks
    INFO: Loaded 1 hooks from com.example.CommonsTextFuzzerHooks
    INFO: Loaded 8 hooks from com.code_intelligence.jazzer.sanitizers.Deserialization
    INFO: Loaded 5 hooks from com.code_intelligence.jazzer.sanitizers.ExpressionLanguageInjection
    INFO: Loaded 70 hooks from com.code_intelligence.jazzer.sanitizers.LdapInjection
    INFO: Loaded 46 hooks from com.code_intelligence.jazzer.sanitizers.NamingContextLookup
    INFO: Loaded 1 hooks from com.code_intelligence.jazzer.sanitizers.OsCommandInjection
    INFO: Loaded 52 hooks from com.code_intelligence.jazzer.sanitizers.ReflectiveCall
    INFO: Loaded 8 hooks from com.code_intelligence.jazzer.sanitizers.RegexInjection
    INFO: Loaded 16 hooks from com.code_intelligence.jazzer.sanitizers.RegexRoadblocks
    INFO: Loaded 19 hooks from com.code_intelligence.jazzer.sanitizers.SqlInjection
    INFO: Loaded 5 hooks from com.code_intelligence.jazzer.sanitizers.ScriptEngineInjection
    INFO: Instrumented com.example.CommonsTextFuzzer (took 17 ms, size +10%)
    INFO: libFuzzer ignores flags that start with '--'
    INFO: Running with entropic power schedule (0xFF, 100).
    INFO: Seed: 3229358036
    INFO: Loaded 1 modules   (512 inline 8-bit counters): 512 [0x160278000, 0x160278200),
    INFO: Loaded 1 PC tables (512 PCs): 512 [0x15a660e00,0x15a662e00),
    INFO: -fork=8: fuzzing in separate process(s)
    INFO: -fork=8: 0 seed inputs, starting to fuzz in /var/folders/j7/bry6w71d1jl97rd7s3cy3yrm0000gn/T//libFuzzerTemp.FuzzWithFork68681.dir
    #24988: cov: 0 ft: 0 corp: 0 exec/s 12494 oom/timeout/crash: 0/0/0 time: 7s job: 1 dft_time: 0
    #73551: cov: 278 ft: 843 corp: 109 exec/s 16187 oom/timeout/crash: 0/0/0 time: 11s job: 2 dft_time: 0
    #177135: cov: 308 ft: 1068 corp: 241 exec/s 25896 oom/timeout/crash: 0/0/0 time: 13s job: 3 dft_time: 0
    #295530: cov: 338 ft: 1314 corp: 391 exec/s 23679 oom/timeout/crash: 0/0/0 time: 16s job: 4 dft_time: 0
    #464996: cov: 341 ft: 1365 corp: 436 exec/s 28244 oom/timeout/crash: 0/0/0 time: 19s job: 5 dft_time: 0
    #668737: cov: 415 ft: 1617 corp: 547 exec/s 29105 oom/timeout/crash: 0/0/0 time: 22s job: 6 dft_time: 0
    #895854: cov: 637 ft: 2369 corp: 625 exec/s 28389 oom/timeout/crash: 0/0/0 time: 26s job: 7 dft_time: 0
    #453559	REDUCE cov: 745 ft: 4257 corp: 1474/25Kb lim: 661 exec/s: 5335 rss: 924Mb L: 21/68 MS: 1 EraseBytes-
    Warning: Nashorn engine is planned to be removed from a future JDK release
    Warning: Nashorn engine is planned to be removed from a future JDK release
    #455106	REDUCE cov: 745 ft: 4257 corp: 1474/25Kb lim: 670 exec/s: 5354 rss: 924Mb L: 12/68 MS: 2 CopyPart-EraseBytes-
    #455172	REDUCE cov: 745 ft: 4257 corp: 1474/25Kb lim: 670 exec/s: 5354 rss: 924Mb L: 13/68 MS: 1 EraseBytes-
    Warning: Nashorn engine is planned to be removed from a future JDK release
    Warning: Nashorn engine is planned to be removed from a future JDK release
    #456349	REDUCE cov: 745 ft: 4257 corp: 1474/25Kb lim: 679 exec/s: 5368 rss: 924Mb L: 14/68 MS: 2 CopyPart-EraseBytes-
    #456545	REDUCE cov: 745 ft: 4257 corp: 1474/25Kb lim: 679 exec/s: 5371 rss: 924Mb L: 12/68 MS: 1 EraseBytes-
    Warning: Nashorn engine is planned to be removed from a future JDK release
    Warning: Nashorn engine is planned to be removed from a future JDK release
    == Java Exception: com.code_intelligence.jazzer.api.FuzzerSecurityIssueCritical: Possible script execution
    	at com.code_intelligence.jazzer.sanitizers.ScriptEngineInjection.checkScriptEngineExecute(ScriptEngineInjection.java:114)
    	at org.apache.commons.text.lookup.ScriptStringLookup.lookup(ScriptStringLookup.java:86)
    	at org.apache.commons.text.lookup.InterpolatorStringLookup.lookup(InterpolatorStringLookup.java:135)
    	at org.apache.commons.text.StringSubstitutor.resolveVariable(StringSubstitutor.java:1067)
    	at org.apache.commons.text.StringSubstitutor.substitute(StringSubstitutor.java:1433)
    	at org.apache.commons.text.StringSubstitutor.substitute(StringSubstitutor.java:1308)
    	at org.apache.commons.text.StringSubstitutor.replace(StringSubstitutor.java:816)
    	at com.example.CommonsTextFuzzer.fuzzerTestOneInput(CommonsTextFuzzer.java:24)
    DEDUP_TOKEN: f10483b167fba3d6
    == libFuzzer crashing input ==
    MS: 2 ChangeASCIIInt-CMP- DE: "1+1"-; base unit: 6931eff51adba2b80c902e62511ee20b7fe8b3ae
    artifact_prefix='/private/var/tmp/_bazel_gyorgydemarcsek/071a3ae2fb95e15eb05d82d6a2a2dd28/execroot/jazzer/bazel-out/darwin_arm64-opt/testlogs/examples/CommonsTextFuzzer/test.outputs/'; Test unit written to /private/var/tmp/_bazel_gyorgydemarcsek/071a3ae2fb95e15eb05d82d6a2a2dd28/execroot/jazzer/bazel-out/darwin_arm64-opt/testlogs/examples/CommonsTextFuzzer/test.outputs/crash-7b8a90d41dff830e912476dbe9304d2b56e9235e
    Base64: JHtzY3JpcHQ6anM6MSsxfQTn
    stat::number_of_executed_units: 456787
    stat::average_exec_per_sec:     5373
    stat::new_units_added:          3165
    stat::slowest_unit_time_sec:    0
    stat::peak_rss_mb:              924
    Warning: Nashorn engine is planned to be removed from a future JDK release
    reproducer_path='/private/var/tmp/_bazel_gyorgydemarcsek/071a3ae2fb95e15eb05d82d6a2a2dd28/execroot/jazzer/bazel-out/darwin_arm64-opt/testlogs/examples/CommonsTextFuzzer/test.outputs'; Java reproducer written to /private/var/tmp/_bazel_gyorgydemarcsek/071a3ae2fb95e15eb05d82d6a2a2dd28/execroot/jazzer/bazel-out/darwin_arm64-opt/testlogs/examples/CommonsTextFuzzer/test.outputs/Crash_7b8a90d41dff830e912476dbe9304d2b56e9235e.java
    INFO: exiting: 19712 time: 2686s

    I have managed to reproduce this a couple of times in reasonable running times on a laptop.

    opened by gdemarcsek 0
  • Work around missing JUnit reporting entry support in Gradle

    Work around missing JUnit reporting entry support in Gradle

    I tried to get a basic test running with gradle but it seems like jazzer is trying to instrument the gradle workers and fails somewhere.

    $ gradle build
    INFO: Instrumented org.gradle.api.internal.tasks.testing.processors.DefaultStandardOutputRedirector$DiscardAction with custom hooks only (took 1 ms, size +0%)
    > Task :app:test
    DummyFuzzTest > dummyFuzz(FuzzedDataProvider) > dummy.DummyFuzzTest.initializationError FAILED
        java.lang.IllegalStateException at AgentInstaller.java:55
            Caused by: java.lang.reflect.InvocationTargetException at NativeMethodAccessorImpl.java:-2
                Caused by: java.lang.VerifyError at InstrumentationImpl.java:-2


    plugins {
        // Apply the application plugin to add support for building a CLI application in Java.
        id 'application'
    repositories {
        // Use Maven Central for resolving dependencies.
    dependencies {
        testImplementation 'org.junit.jupiter:junit-jupiter:5.8.2'
        testImplementation 'com.code-intelligence:jazzer-api:0.13.0'
        testImplementation 'com.code-intelligence:jazzer-junit:0.13.0'
    application {
        // Define the main class for the application.
        mainClass = 'dummy.App'
    tasks.named('test') {
        // Use JUnit Platform for unit tests.


    package dummy;
    public class App {
        public int add(int a, int b) {
            return a+b;
        public static void main(String[] args) {
            System.out.println(new App().add(1, 2));


    package dummy;
    import com.code_intelligence.jazzer.api.FuzzedDataProvider;
    import com.code_intelligence.jazzer.junit.FuzzTest;
    class DummyFuzzTest {
        void dummyFuzz(FuzzedDataProvider data) {
            new App().add(data.consumeInt(), data.consumeInt());

    Any idea how to get this running?

    opened by CodeLowSky 12
  • Reproducers for mutation graph entries

    Reproducers for mutation graph entries

    Currently, the reproducers are only created for the crashes. Would it be possible to have an option for also including the mutation graph or all of the inputs? Currently I've tweaked the code locally to get reproducers for every test case when I only want the mutation graph entries. For longer fuzzing runs, storage problems can be expected.

    opened by McLarney 2
  • v0.13.1(Nov 24, 2022)

    What's Changed

    • autofuzz: Fix exclusion of Jazzer-internal classes (https://github.com/CodeIntelligenceTesting/jazzer/pull/528)
    • deps: Update rules_jvm_external to preserve directories in JARs (https://github.com/CodeIntelligenceTesting/jazzer/pull/532)
    • Fix sanitizers not being loaded with jazzer_standalone_deploy.jar (https://github.com/CodeIntelligenceTesting/jazzer/pull/533)

    Full Changelog: https://github.com/CodeIntelligenceTesting/jazzer/compare/v0.13.0...v0.13.1

    Source code(tar.gz)
    Source code(zip)
    jazzer-linux.tar.gz(8.67 MB)
    jazzer-macos-arm64.tar.gz(8.12 MB)
    jazzer-macos-x86_64.tar.gz(8.12 MB)
    jazzer-windows.tar.gz(8.49 MB)
  • v0.13.0(Oct 25, 2022)

    What's Changed

    • Breaking change: A JUnit @FuzzTest now runs on inputs in a ClassNameInputs rather than a ClassNameSeedCorpus directory.
    • Breaking change: Removed the seedCorpus attribute from @FuzzTest. Following the ClassNameInputs convention allows for better integration with the fuzzer.
    • Breaking change: --autofuzz no longer enables --keep_going by default, but instead prints suggestions on how to skip uninteresting findings.
    • Major feature: JUnit @FuzzTests can now take any parameters and will use Autofuzz if not using the standard byte[] or FuzzedDataProvider signatures (https://github.com/CodeIntelligenceTesting/jazzer/pull/476)
    • Major feature: Jazzer is now available as a jar, using the native launcher is no longer required. (https://github.com/CodeIntelligenceTesting/jazzer/pull/492)
    • Major feature: Jazzer now supports native library fuzzing with release builds. See Fuzzing with Native Libraries. (https://github.com/CodeIntelligenceTesting/jazzer/pull/500)
    • junit: Do not leak fuzzer startup into first seed test (https://github.com/CodeIntelligenceTesting/jazzer/pull/491)
    • junit: Fixed Windows failure when running with corpus (https://github.com/CodeIntelligenceTesting/jazzer/pull/467)
    • Fixed Java reproducer not compiling when referencing non-visible superclasses or interfaces (https://github.com/CodeIntelligenceTesting/jazzer/pull/471)
    • Fixed DEDUP_TOKEN and --ignore behavior (https://github.com/CodeIntelligenceTesting/jazzer/pull/472)
    • Fixed JaCoCo coverage measurements (https://github.com/CodeIntelligenceTesting/jazzer/pull/479)
    • Improved fuzz test class not found error message (https://github.com/CodeIntelligenceTesting/jazzer/pull/481)
    • Cleaned up stack traces (https://github.com/CodeIntelligenceTesting/jazzer/pull/485)
    • Added docs and source JAR for jazzer-junit (https://github.com/CodeIntelligenceTesting/jazzer/pull/477)
    • Ignore regex pattern syntax exceptions caused by stack overflows (https://github.com/CodeIntelligenceTesting/jazzer/pull/488)
    • Added --version flag (https://github.com/CodeIntelligenceTesting/jazzer/pull/502)
    • Improved @FuzzTest docs and increased default duration (https://github.com/CodeIntelligenceTesting/jazzer/pull/509)
    • Improved jar stripping to fix various packaging issues (https://github.com/CodeIntelligenceTesting/jazzer/pull/515)

    Full Changelog: https://github.com/CodeIntelligenceTesting/jazzer/compare/v0.12.0...v0.13.0

    Source code(tar.gz)
    Source code(zip)
    jazzer-linux.tar.gz(8.67 MB)
    jazzer-macos-arm64.tar.gz(8.11 MB)
    jazzer-macos-x86_64.tar.gz(8.12 MB)
    jazzer-windows.tar.gz(8.49 MB)
  • v0.12.0(Aug 30, 2022)

    What's Changed

    • Breaking change: Autofuzz API methods (consume and autofuzz) have moved from the Jazzer class to the dedicated Autofuzz class
    • Major feature: Added JUnit 5 integration for fuzzing and regression tests using the @FuzzTest annotation (available as com.code-intelligence:jazzer-junit)
    • Feature: Added sanitizer for SQL injections
    • Feature: Hooks can be selectively disabled by specifying their full class name using the new --disabled_hooks flag
    • Fix: Remove memory leaks in native code
    • Fix: Don't instrument internal Azul JDK classes
    • Fix: Classes with local variable annotations are now instrumented without errors

    This release also includes smaller improvements and bugfixes, as well as a major refactoring and Java rewrite of native components.

    New Contributors

    • @vargen made their first contribution in https://github.com/CodeIntelligenceTesting/jazzer/pull/416
    • @henryrneh made their first contribution in https://github.com/CodeIntelligenceTesting/jazzer/pull/439

    Full Changelog: https://github.com/CodeIntelligenceTesting/jazzer/compare/v0.11.0...v0.12.0

    Source code(tar.gz)
    Source code(zip)
    jazzer-api.jar(24.07 KB)
    jazzer-junit.jar(9.93 MB)
    jazzer-linux-x86_64.tar.gz(8.53 MB)
    jazzer-macos-arm64.tar.gz(7.96 MB)
    jazzer-macos-x86_64.tar.gz(7.98 MB)
    jazzer-windows-x86_64.tar.gz(8.37 MB)
  • v0.11.0(Apr 28, 2022)

    • Feature: Add sanitizer for context lookups
    • Feature: Add sanitizer for OS command injection
    • Feature: Add sanitizer for regex injection
    • Feature: Add sanitizer for LDAP injections
    • Feature: Add sanitizer for arbitrary class loading
    • Feature: Guide fuzzer to generate proper map lookups keys
    • Feature: Generate standalone Java reproducers for autofuzz
    • Feature: Hooks targeting interfaces and abstract classes hook all implementations
    • Feature: Enable multiple BEFORE and AFTER hooks for the same target
    • Feature: Greatly improve performance of coverage instrumentation
    • Feature: Improve performance of interactions between Jazzer and libFuzzer
    • Feature: Export JaCoCo coverage dump using --coverage_dump flag
    • Feature: Honor JAVA_OPTS
    • API: Add exploreState to help the fuzzer maximize state coverage
    • API: Provide additionalClassesToHook field in MethodHook annotation to hook dependent classes
    • Fix: Synchronize coverage ID generation
    • Fix: Support REPLACE hooks for constructors
    • Fix: Do not apply REPLACE hooks in Java 6 class files

    This release also includes smaller improvements and bugfixes.

    Source code(tar.gz)
    Source code(zip)
    jazzer-0.11.0.tar.gz(199.82 KB)
    jazzer-api-0.11.0.jar(20.23 KB)
    jazzer-linux-0.11.0.tar.gz(5.92 MB)
    jazzer-macos-0.11.0.tar.gz(5.57 MB)
    jazzer-windows-0.11.0.tar.gz(5.72 MB)
  • v0.10.0(Oct 21, 2021)

  • v0.9.1(Mar 10, 2021)

    • Breaking change: The static fuzzerTestOneInput method in a fuzz target now has to return void instead of boolean. Fuzz targets that previously returned true should now throw an exception or use assert.
    • Fixed: jazzer wrapper can find jazzer_driver even if not in the working directory
    • Fixed: Switch instrumentation no longer causes an out-of-bounds read in the driver
    • Feature: assert can be used in fuzz targets
    • Feature: Coverage is now collision-free and more fine-grained (based on JaCoCo)
    • API: Added pickValue(Collection c) and consumeChar(char min, char max) to FuzzedDataProvider
    • API: Added FuzzerSecurityIssue* exceptions to allow specifiying the severity of findings
    Source code(tar.gz)
    Source code(zip)
    examples_deploy.jar(3.28 MB)
    jazzer_release.tar.gz(5.48 MB)
OSS-Sydr-Fuzz - OSS-Fuzz fork for hybrid fuzzing (fuzzer+DSE) open source software.

OSS-Sydr-Fuzz: Hybrid Fuzzing for Open Source Software This repository is a fork of OSS-Fuzz project. OSS-Sydr-Fuzz contains open source software targ

Ivannikov Institute for System Programming of the Russian Academy of Sciences 41 Nov 28, 2022
Linux rootkit used to hide a cryptominer process and CPU usage.

Linux rootkit used to hide a cryptominer process and CPU usage.

Alfon 40 Sep 15, 2022
Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.

Tink A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Ubuntu

Google 12.8k Nov 27, 2022
XMRig is a high performance, open source, cross platform RandomX, KawPow, CryptoNight and AstroBWT unified CPU/GPU miner

XMRig is a high performance, open source, cross platform RandomX, KawPow, CryptoNight and AstroBWT unified CPU/GPU miner and RandomX benchmark. Official binaries are available for Windows, Linux, macOS and FreeBSD.

null 7.3k Nov 28, 2022
A useful tool for identifying the architecture, platform type, compiler, and operating system specifications by preprocessor feature support.

Platform-Detector Cross-Platform Information Detector It is a useful tool for identifying the architecture, platform type, compiler, and operating sys

Kambiz Asadzadeh 10 Jul 27, 2022
A Powerful, Easy-to-Use, Compact, Cross-Platform and Installation-Free Crypto Tool. 一个强大,易用,小巧,跨平台且免安装的加密解密签名工具。

GpgFrontend GpgFrontend is a Powerful, Easy-to-Use, Compact, Cross-Platform, and Installation-Free OpenPGP Crypto Tool. By using GpgFrontend, you can

Saturn&Eric 194 Dec 4, 2022
obfuscated any constant encryption in compile time on any platform

oxorany 带有混淆的编译时任意常量加密 English 介绍 我们综合了开源项目ollvm、xorstr一些实现思路,以及c++14标准中新加入的constexpr关键字和一些模板的知识,完成了编译时的任意常量的混淆(可选)和加密功能。

Chase 121 Nov 25, 2022
High-level build system for distributed, multi-platform C/C++ projects.

fips fips is a highlevel build system wrapper written in Python for C/C++ projects. (this project has nothing to do with the Federal Information Proce

Andre Weissflog 425 Nov 25, 2022
vulnerability in zam64.sys, zam32.sys allowing ring 0 code execution. CVE-2021-31727 and CVE-2021-31728 public reference.

CVE-2021-31727 and CVE-2021-31728 Public Reference for CVE-2021-31727 Exposes unrestricted disk read/write capabilities. Public Reference for CVE-2021

null 65 Nov 9, 2022
This repository contains commercially licensed wolfSSL products and example code for use on specified Renesas platforms.

wolfSSL Product for Renesas This repository contains commercially licensed wolfSSL product code for use on specified Renesas platforms. This code is o

wolfSSL 7 Sep 9, 2022
LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code.

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code.

OpenBSD LibreSSL Portable 1.2k Dec 3, 2022
wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows.

wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows.

Axel Souchet 1.1k Nov 28, 2022
A coverage-guided and memory-detection enabled fuzzer for windows applications.

WDFuzzer Manual 中文手册见 README_CN.md WDFuzzer:winafl + drmemory WDFuzzer is an A coverage-guided and memory detection abled fuzzer for for windows softw

Jingyi Shi 27 Nov 15, 2022
Coverage-guided grammar aware fuzzer that uses grammar automatons

Gramatron Gramatron is a coverage-guided fuzzer that uses grammar automatons to perform grammar-aware fuzzing. Technical details about our framework a

HexHive 42 Oct 26, 2022
Sloth 🦥 is a coverage guided fuzzing framework for fuzzing Android Native libraries that makes use of libFuzzer and QEMU user-mode emulation

Sloth ?? Sloth is a fuzzing setup that makes use of libFuzzer and QEMU’s user-mode emulation (qemu/linux-user) on x86_64/aarch64 host to emulate aarch

Chaithu 82 Nov 3, 2022
CMake module to enable code coverage easily and generate coverage reports with CMake targets.

CMake-codecov CMake module to enable code coverage easily and generate coverage reports with CMake targets. Include into your project To use Findcodec

HPC 82 Oct 25, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.5k Dec 4, 2022
A demonstration of various different techniques for implementing 'threaded code,' a technique used in Forth and in virtual machines like the JVM.

Threaded code is a technique used in the implementation of virtual machines (VMs). It avoids the overhead of calling subroutines repeatedly by 'thread

null 25 Nov 4, 2022
Tool that generates unit test by C/C++ source code, trying to reach all branches and maximize code coverage

What is UTBotCpp? UTBotCpp generates test cases by code, trying to cover maximum statements and execution paths. We treat source code as source of tru

null 51 Dec 4, 2022
jvm-monitor is a lightweight monitoring tool that logs all the local variables whenever exceptions occur.

jvm-monitor jvm-monitor is a Java agent attached to a Java VM (virtual machine), which logs all the local variables when exceptions occur. Rationales

Barosl Lee 13 Nov 21, 2021