Audience
Individuals wanting a solution to detect bugs and security issues
About Jazzer
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. You can use Docker to try out Jazzer's autofuzz mode, which automatically generates arguments to a given Java function and reports unexpected exceptions and detected security issues. You can also use GitHub release archives to run a standalone Jazzer binary that starts its own JVM configured for fuzzing.
Pricing
Starting Price:
Free
Free Version:
Free Version available.
Integrations
Company Information
Code Intelligence
Germany
github.com/CodeIntelligenceTesting/jazzer
ToothPicker
ToothPicker is an in-process, coverage-guided fuzzer for iOS. It was developed to specifically target iOS's Bluetooth daemon and to analyze various Bluetooth protocols on iOS. As it is built using FRIDA, it can be adapted to target any platform that runs FRIDA. This repository also includes an over-the-air fuzzer with an exemplary implementation to fuzz Apple's MagicPairing protocol using InternalBlue. Additionally, it contains the ReplayCrashFile script that can be used to verify crashes the in-process fuzzer has found. This is a very simple fuzzer that only flips bits and bytes of inactive connections. No coverage, no injection, but nice as a demo and stateful. Runs just with Python and Frida, no modules or installation are required. ToothPicker is built on the codebase of frizzer. It is recommended to set up a virtual Python environment for frizzer. Starting from the iPhone XR/Xs, PAC has been introduced.
Learn more
go-fuzz
Go-fuzz is a coverage-guided fuzzing solution for testing Go packages. Fuzzing is mainly applicable to packages that parse complex inputs (both text and binary) and is especially useful for hardening systems that parse inputs from potentially malicious users (anything accepted over a network). go-fuzz has recently added preliminary support for fuzzing Go Modules. If you encounter a problem with modules, please file an issue with details. Data is a random input generated by go-fuzz, note that in most cases it is invalid. The function must return 1 if the fuzzer should increase the priority of the given input during subsequent fuzzing if the input must not be added to the corpus even if it gives new coverage, and 0 otherwise; other values are reserved for future use. The fuzz function must be in a package that go-fuzz can import. This means the code you want to test can't be in package main. Fuzzing internal packages is supported, however.
Learn more
LibFuzzer
LibFuzzer is an in-process, coverage-guided, evolutionary fuzzing engine. LibFuzzer is linked with the library under test, and feeds fuzzed inputs to the library via a specific fuzzing entry point (or target function); the fuzzer then tracks which areas of the code are reached, and generates mutations on the corpus of input data in order to maximize the code coverage. The code coverage information for libFuzzer is provided by LLVM’s SanitizerCoverage instrumentation. LibFuzzer is still fully supported in that important bugs will get fixed. The first step in using libFuzzer on a library is to implement a fuzz target, a function that accepts an array of bytes and does something interesting with these bytes using the API under test. Note that this fuzz target does not depend on libFuzzer in any way so it is possible and even desirable to use it with other fuzzing engines like AFL and/or Radamsa.
Learn more
syzkaller
syzkaller is an unsupervised coverage-guided kernel fuzzer. Supports FreeBSD, Fuchsia, gVisor, Linux, NetBSD, OpenBSD, and Windows. Initially, syzkaller was developed with Linux kernel fuzzing in mind, but now it's being extended to support other OS kernels as well. Once syzkaller detects a kernel crash in one of the VMs, it will automatically start the process of reproducing this crash. By default, it will use 4 VMs to reproduce the crash and then minimize the program that caused it. This may stop the fuzzing, since all of the VMs might be busy reproducing detected crashes. The process of reproducing one crash may take from a few minutes up to an hour depending on whether the crash is easily reproducible or non-reproducible at all.
Learn more
You Might Also Like
Product Details
Platforms Supported
Windows
Mac
Linux
Training
Documentation
Live Online
Webinars
In Person
Videos
Support
Online