TinyInst```

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 TinyInst?

TinyInst ist eine leichtgewichtige dynamische Instrumentierungsbibliothek, mit der nur ausgewählte Module im Prozess instrumentiert werden können, während der Rest des Prozesses nativ ausgeführt wird. Sie soll leicht zu verstehen, leicht zu hacken und leicht mit ihr zu hacken sein. Sie ist nicht dafür ausgelegt, mit allen Zielen kompatibel zu sein (dazu später mehr).

### Wie schneidet es im Vergleich zu [DynamoRIO](https://dynamorio.org/) und [PIN](https://software.intel.com/en-us/articles/pintool) ab?

TinyInst ist nicht als Ersatz für komplexe Instrumentierungsframeworks wie DynamoRIO und PIN gedacht, sondern eher als Alternative für Szenarien, in denen eine leichtgewichtigere Lösung ausreicht. TinyInst setzt voraus, dass das Ziel wohlverhalten ist (im unten erläuterten Sinne), was bei komplexeren Frameworks nicht der Fall ist. Daher werden Sie TinyInst wahrscheinlich nicht erfolgreich gegen Malware einsetzen können, wie es [zuvor mit DynamoRIO gemacht wurde](https://www.slideshare.net/MaximShudrak/fuzzing-malware-for-fun-profit-applying-coverageguided-fuzzing-to-find-bugs-in-modern-malware). Wenn ein Ziel dagegen aufgrund des Moduls, das nicht instrumentiert werden muss, nicht mit anderen Frameworks funktioniert und das instrumentierte Modul wohlverhalten ist, könnte es mit TinyInst funktionieren. Da bei TinyInst der größte Teil des Prozesses nativ ausgeführt wird, ist die Prozessstartzeit kürzer, und es könnte andere Lösungen in Fällen übertreffen, in denen der Zielprozess viel Zeit in den Modulen verbringt, in denen keine Instrumentierung erforderlich ist.

### Wie schneidet es im Vergleich zu [Mesos](https://github.com/gamozolabs/mesos) und [TrapFuzz](https://github.com/googleprojectzero/p0tools/tree/master/TrapFuzz) ab?

TinyInst ist eine vollständige Binärumschreibungslösung, sodass beliebiges Verhalten im Zielmodul geändert werden kann. Dadurch kann sie beispielsweise Kantenabdeckung anstelle von nur Basisblöcken extrahieren. Darüber hinaus ist TinyInst nicht auf andere Software wie IDA Pro angewiesen, um Basisblöcke zu identifizieren.

### Welche Betriebssysteme unterstützt TinyInst?

TinyInst funktioniert unter Windows (x86 und x64), macOS (x64 und ARM64), Linux (x64 und ARM64) und Android (ARM64). Weitere Hinweise und Einschränkungen finden Sie in der README-Datei im entsprechenden Verzeichnis für jedes Betriebssystem.

### Mit welchen Zielen ist TinyInst kompatibel?

TinyInst setzt voraus, dass alle instrumentierten Module in dem Sinne wohlverhalten sind, dass

- Es gibt keinen selbstmodifizierenden Code
- Auf die Rücksprungadresse auf dem Stack wird vom Programm nie direkt zugegriffen
ODER/UND (je nach Einstellung)
- Es werden nie Daten unterhalb der Stackspitze gespeichert (auf Adressen, die niedriger sind als die von ESP/RSP angezeigte Adresse). Diese Bedingung kann mit dem `-stack_offset`-Flag zu „keine Daten vor (ESP/RSP - arbitrary_offset)“ gelockert werden.

TinyInst erfordert außerdem, dass DEP/NX für den Zielprozess aktiviert ist. Falls das nicht bereits der Fall ist, können Sie das `-force_dep`-Flag verwenden, um es zu erzwingen. Sollte das Ziel jedoch in dem unwahrscheinlichen Fall tatsächlich DEP deaktiviert benötigen, um ordnungsgemäß zu funktionieren, könnte das Erzwingen dazu führen, dass es sich fehlverhält.

### Wie hoch ist der Performance-Overhead?

Nach frühen Messungen beim Bilddecodieren lag der Performance-Overhead bei einem wohlverhaltenen 64-Bit-Ziel mit den Standardeinstellungen von TinyInst bei etwa 15 % ohne Client und bei etwa 20 % mit dem Beispiel-Client zur Abdeckungserfassung. Beachten Sie, dass dies das Timeout nicht einschließt, das durch die anfängliche Instrumentierung der Module entsteht. Weitere Details finden Sie in den Leistungstipps unten.

## TinyInst erstellen

1. Öffnen Sie ein Terminal und richten Sie Ihre Build-Umgebung ein (z. B. führen Sie unter Windows vcvars64.bat / vcvars32.bat aus)

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

3. Führen Sie die folgenden Befehle aus (ändern Sie den Generator entsprechend der Version der IDE und der Plattform, für die Sie erstellen möchten):

#### Windows```
mkdir build
cd build
cmake -G "Visual Studio 16 2019" -A x64 ..
cmake --build . --config Release

macOS```

mkdir build cd build cmake -G Xcode .. cmake --build . --config Release

#### Linux```
mkdir build
cd build
cmake ..
cmake --build . --config Release

Cross-Kompilierung für Android```

mkdir build cd build cmake -DCMAKE_TOOLCHAIN_FILE=</path/to/android/ndk>build/cmake/android.toolchain.cmake -DANDROID_NDK=</path/to/android/ndk> -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM= .. cmake --build . --config Release

Hinweis #1: Ein 64-Bit-Build läuft auch gegen 32-Bit-Ziele unter Windows- und Linux-Betriebssystemen.

Hinweis #2: Probleme beim Erstellen eines 32-Bit-Builds unter 64-Bit-Windows, weil die Umgebung nicht richtig eingerichtet ist und Bibliotheken fehlen? Öffnen Sie die generierte .sln-Datei in Visual Studio und bauen Sie von dort aus, anstatt cmake --build auszuführen. Beachten Sie außerdem, dass ein 64-Bit-Build auch mit 32-Bit-Zielen funktioniert, sodass ein 32-Bit-Build möglicherweise nicht erforderlich ist.

## TinyInst verwenden

TinyInst ist in erster Linie dazu gedacht, als Bibliothek innerhalb anderer Programme verwendet zu werden.

Ein TinyInst-Client wird als Unterklasse der TinyInst-Klasse geschrieben. Der Client kann dann die von ihm benötigten API-Methoden überschreiben. Die API-Methoden sind unten definiert.

Nachdem der Client erstellt wurde, muss er durch Aufruf von

`void init(int argc, char **argv);`

mit Befehlszeilenoptionen initialisiert werden.

Die Befehlszeilenoptionen sind unten definiert, und ein Client kann auch eigene definieren. Danach können die folgenden Funktionen verwendet werden, um ein instrumentiertes Programm auszuführen und zu steuern.

`DebuggerStatus Run(int argc, char **argv, uint32_t timeout);`
`DebuggerStatus Attach(unsigned int pid, uint32_t timeout);`

Diese Funktionen führen entweder ein Programm aus (mithilfe der angegebenen Befehlszeile) oder hängen sich an ein bereits laufendes Programm an. Wenn keine Zielmethode angegeben ist, läuft das Ziel weiter, bis entweder das Programm beendet wird, das Programm abstürzt oder das Timeout (in Millisekunden angegeben) abläuft. Wenn eine Zielmethode definiert ist, gibt TinyInst die Kontrolle jedes Mal zurück, wenn die Zielmethode betreten wird und wenn die Zielmethode zurückkehrt, sodass der Aufrufer zusätzliche Aufgaben ausführen kann.

Wenn `Run` und `Attach` zurückkehren, während der Zielprozess noch lebt, können die folgenden Funktionen verwendet werden, um den Prozess entweder zu beenden oder die Ausführung fortzusetzen.

`DebuggerStatus Kill();`

`DebuggerStatus Continue(uint32_t timeout);`

TinyInst enthält eine Beispiel-Coverage-Binary, die wie folgt aufgerufen werden kann:

`<options> -- <target command line>`

Beispiel unter Windows:

`litecov.exe -instrument_module notepad.exe -coverage_file coverage.txt -- notepad.exe`

## Instrumentierungs-API

### Debugger-Ereignis-Callbacks

Diese Callbacks dienen nur der Information, und der Client sollte während diesen keinen instrumentierten Code emittieren. Clients müssen denselben in der Oberklasse definierten Handler aufrufen, bevor sie diese Ereignisse selbst behandeln.