Jackalope

Copyright 2020 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Was ist Jackalope

Jackalope ist ein anpassbarer, verteilter, coverage-gesteuerter Fuzzer, der mit Black-Box-Binärdateien arbeiten kann.

Warum ein weiterer Fuzzer?

Obwohl es viele gute coverage-gesteuerte Fuzzer gibt, die auf Targets mit verfügbarem Quellcode funktionieren, gibt es relativ wenige, die auf Black-Box-Binärdateien arbeiten, insbesondere unter Windows- und macOS-Betriebssystemen, und diejenigen, die existieren, basieren hauptsächlich auf Codebasen, die nicht sehr einfach anzupassen sind. Die ursprünglichen Ziele von Jackalope sind:

• Einfache Anpassung für Targets, bei denen generische Fuzzer möglicherweise nicht gut funktionieren. Dies kann Folgendes umfassen:
  • Benutzerdefinierte Mutatoren
  • Benutzerdefinierte Mechanismen zur Sample-Übermittlung
  • Benutzerdefinierte Instrumentierung usw.
• Einfache Parallelisierung, sowohl auf einer einzelnen Maschine als auch über mehrere Maschinen hinweg

Was macht es?

Jackalope kann eigenständig verwendet werden, ist aber leistungsfähiger, wenn es als Bibliothek genutzt wird, bei der Benutzer benutzerdefinierte Komponenten einbinden können, die das Standardverhalten ersetzen. Standardmäßig wird Jackalope mitgeliefert mit:

• Binärinstrumentierung unter Verwendung von TinyInst
• Einem einfachen Satz generischer Mutatoren für Binärformate sowie einer grammatikbasierten Mutations-Engine
• Sample-Übermittlung über Datei oder über Shared Memory

Jackalope kann parallel ausgeführt werden

• Auf einer einzelnen Maschine: durch Angabe der Anzahl der Fuzzing-Threads über den Kommandozeilenparameter -nthreads
• Über mehrere Maschinen hinweg: durch Ausführen einer Instanz als Server (Kommandozeilen-Flag -start_server) und Verbinden der Fuzzer auf den Worker-Maschinen mit diesem Server (Kommandozeilen-Flag -server). Der Server sammelt und verteilt dann Samples, Crashes und Coverage über die Worker hinweg.

Was macht es nicht?

Jackalope enthält derzeit keine fortgeschrittenen Mutationsstrategien. Stattdessen wird es mit einem Satz generischer Mutatoren ausgeliefert, die für viele Targets funktionieren. Benutzer werden jedoch ermutigt, benutzerdefinierte Mutatoren und Mutationsstrategien entsprechend den Targets zu schreiben, die sie fuzzen möchten.

Welche Plattformen werden unterstützt?

Derzeit wird das Fuzzing von Black-Box-Binärdateien auf den Betriebssystemen Windows, macOS, Linux und Android unterstützt.

Unter Linux kann Jackalope auch mit Sanitizer Coverage ausgeführt werden (Quellcode des Targets erforderlich). Dieser Modus ist in einem separaten Dokument dokumentiert.

Jackalope bauen

Voraussetzung: Python 3

1. Öffnen Sie ein Terminal und richten Sie bei Bedarf Ihre Build-Umgebung ein. Unter Windows sollten Sie anstelle einer generischen Eingabeaufforderung die Visual Studio-Eingabeaufforderung für die Plattform öffnen, für die Sie bauen, oder vcvars64.bat / vcvars32.bat ausführen.

2. Navigieren Sie zu dem Verzeichnis, das den Quellcode enthält.

3. Führen Sie die folgenden Befehle aus:

cd Jackalope
git clone --recurse-submodules [email protected]:googleprojectzero/TinyInst.git
(alternately: git clone --recurse-submodules https://github.com/googleprojectzero/TinyInst.git)
mkdir build
cd build
cmake <generator arguments> ..
cmake --build . --config Release

Die Generator-Argumente hängen von Ihrer Umgebung ab. Unter macOS würden Sie -G Xcode verwenden, während Sie beispielsweise unter Windows mit Visual Studio 2019 und für einen 64-Bit-Build -G "Visual Studio 16 2019" -A x64 verwenden würden. Unter Linux sind keine Generator-Argumente erforderlich. Beim Cross-Compiling für Android sind zusätzliche cmake-Argumente erforderlich; diese sind dieselben wie in den TinyInst-Build-Anweisungen für Android beschrieben. Wenn Sie Android auf einer VM fuzzen, die Shared Memory über /dev/shm unterstützt, aktiviert -DANDROID_TARGET=VM die Sample-Übermittlung über Shared Memory.

Informationen zum Bauen für die Ausführung gegen arm64e-Binärdateien unter macOS finden Sie hier.

Erhalten Sie unter macOS den Fehler No CMAKE_C_COMPILER could be found? Versuchen Sie, cmake zu aktualisieren. Stellen Sie außerdem sicher, dass Xcode installiert ist und Sie es mindestens einmal ausgeführt haben (es installiert beim ersten Ausführen einige Komponenten).

Jackalope ausführen

Verwendung:

./fuzzer <fuzzer arguments> <instrumentation and other components arguments> -- <target command line>

Die folgenden Kommandozeilenargumente werden unterstützt:

-in - Eingabeverzeichnis (Verzeichnis, das den anfänglichen Sample-Satz enthält). Wenn das Eingabeverzeichnis "-" ist, versucht der Fuzzer, die vorherige Sitzung wiederherzustellen (dasselbe wie die Verwendung des -restore-Flags).

-out - Ausgabeverzeichnis

-t - Sample-Timeout in ms

-t1 - Timeout für die Target-Initialisierung (z. B. bevor die Zielmethode erreicht wird, falls definiert). Standardmäßig entspricht dies dem Sample-Timeout.

-nthreads - Anzahl der Fuzzer-Threads. Standard ist 1.

-delivery <file|shmem> - Zu verwendender Mechanismus zur Sample-Übermittlung. Bei file wird jedes Sample als Datei ausgegeben und "@@" in den Target-Argumenten wird durch einen Pfad zur Datei ersetzt. Bei shmem erstellt der Fuzzer stattdessen Shared Memory und ersetzt "@@" in den Target-Argumenten durch den Namen des Shared Memory. In diesem Fall liegt es in der Verantwortung des Targets, den Shared Memory zu öffnen und das Sample zu extrahieren. Standard ist file.

-file_extension - Hängt bei Verwendung der file-Sample-Übermittlung die angegebene Erweiterung an den Dateinamen an. Nützlich, wenn das Target erwartet, dass Eingabedateien eine bestimmte Erweiterung haben.

-restore oder -resume - Stellt eine vorherige Fuzzing-Sitzung wieder her und setzt sie fort. Sowohl der Fuzzer- als auch der Server-Prozess unterstützen die Wiederherstellung.

-server - Gibt den zu verwendenden Coverage-Server an.

-start_server - Führt einen Server-Prozess anstelle eines Fuzzing-Prozesses aus.

-crash_retry - Anzahl der Versuche, einen Crash zu reproduzieren. Standard ist 10. Crashes, die innerhalb dieser Anzahl von Wiederholungen nicht reproduziert werden können oder die nicht reproduziert werden, wenn sie ohne Instrumentierung ausgeführt werden, werden als flaky markiert.

-coverage_retry - Anzahl der Versuche, neue Coverage zu reproduzieren. Coverage, die innerhalb dieser Anzahl von Wiederholungen nicht zuverlässig reproduziert werden kann, gilt als flaky. Samples, die nur flaky Coverage enthalten, werden nicht gespeichert.

-clean_target_on_coverage - Startet das Target neu, wenn Coverage reproduziert wird. Standard ist true.

-minimize_samples - Versucht, neue Samples zu minimieren, bevor sie im Korpus gespeichert werden. Standard ist true.

-iterations_per_round - Anzahl der Male, die ein Sample aus dem Korpus mutiert und ausgeführt wird, bevor zum nächsten Sample übergegangen wird. Standard ist 1000. Bei sehr langsamen Targets könnte eine Verringerung dieses Werts in Betracht gezogen werden.