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.

## Qu'est-ce que TinyInst ?

TinyInst est une bibliothèque légère d'instrumentation dynamique qui peut être utilisée pour instrumenter uniquement certains modules sélectionnés dans le processus, tout en laissant le reste du processus s'exécuter de manière native. Elle est conçue pour être facile à comprendre, facile à modifier et facile à utiliser pour le hacking. Elle n'est pas conçue pour être compatible avec toutes les cibles (plus de détails ci-dessous).

### Comment se compare-t-elle à [DynamoRIO](https://dynamorio.org/) et [PIN](https://software.intel.com/en-us/articles/pintool) ?

TinyInst n'est pas destinée à remplacer des frameworks d'instrumentation complexes tels que DynamoRIO et PIN, mais plutôt une alternative pour les scénarios où une solution plus légère suffit. TinyInst suppose que la cible est bien comportée (au sens expliqué ci-dessous), ce qui n'est pas le cas pour les frameworks plus complexes. Ainsi, vous ne pourrez probablement pas exécuter TinyInst avec succès contre des logiciels malveillants comme [cela a été fait avec DynamoRIO précédemment](https://www.slideshare.net/MaximShudrak/fuzzing-malware-for-fun-profit-applying-coverageguided-fuzzing-to-find-bugs-in-modern-malware). D'un autre côté, si une cible ne fonctionne pas avec d'autres frameworks en raison du module qui n'a pas besoin d'être instrumenté, et que le module instrumenté est bien comporté, elle pourrait fonctionner avec TinyInst. Parce qu'avec TinyInst, la majeure partie du processus s'exécutera de manière native, le temps de démarrage du processus sera plus court, et elle pourrait surpasser d'autres solutions dans les cas où le processus cible passe beaucoup de temps dans les modules où l'instrumentation n'est pas nécessaire.

### Comment se compare-t-elle à [Mesos](https://github.com/gamozolabs/mesos) et [TrapFuzz](https://github.com/googleprojectzero/p0tools/tree/master/TrapFuzz) ?

TinyInst est une solution complète de réécriture binaire, donc tout comportement arbitraire peut être modifié dans le module cible. Cela lui permet, par exemple, d'extraire la couverture des arêtes au lieu de seulement des blocs de base. De plus, TinyInst ne dépend pas d'autres logiciels, tels qu'IDA Pro, pour identifier les blocs de base.

### Quel système d'exploitation TinyInst prend-elle en charge ?

TinyInst fonctionne sur Windows (x86 et x64), macOS (x64 et ARM64), Linux (x64 et ARM64) et Android (ARM64). Veuillez consulter le README dans le répertoire correspondant pour chaque système d'exploitation pour des notes supplémentaires et des limitations.

### Quelles cibles sont compatibles avec TinyInst ?

TinyInst suppose que tous les modules instrumentés sont bien comportés, dans le sens où

- Il n'y a pas de code auto-modifiant
- L'adresse de retour sur la pile n'est jamais directement accédée par le programme
OU/ET (selon les paramètres)
- Aucune donnée n'est jamais stockée avant le sommet de la pile (sur des adresses inférieures à celles pointées par ESP/RSP). Cette condition peut être assouplie en "aucune donnée avant (ESP/RSP - décalage_arbitraire)" en utilisant le drapeau `-stack_offset`.

TinyInst nécessite également que DEP/NX soit activé pour le processus cible. Si ce n'est pas déjà le cas, vous pouvez utiliser le drapeau `-force_dep` pour le forcer. Cependant, dans le cas (peu probable) où la cible a réellement besoin de DEP désactivé pour fonctionner correctement, le forcer pourrait entraîner un mauvais comportement.

### Quel est le surcoût de performance ?

Selon des premières mesures sur le décodage d'images, sur une cible 64 bits bien comportée avec les paramètres par défaut de TinyInst, le surcoût de performance était d'environ 15 % sans client et d'environ 20 % avec l'exemple de client collectant la couverture. Notez que cela n'inclut pas le temps d'initialisation introduit par l'instrumentation initiale des modules. Voir les conseils de performance ci-dessous pour plus de détails.

## Construction de TinyInst

1. Ouvrez un terminal et configurez votre environnement de construction (par exemple, sur Windows, exécutez vcvars64.bat / vcvars32.bat)

2. Naviguez vers le répertoire contenant les sources

3. Exécutez les commandes suivantes (modifiez le générateur selon la version de l'IDE et la plateforme pour laquelle vous voulez construire) :

#### 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

Compilation croisée pour 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

Note #1 : La version 64 bits fonctionnera également sur des cibles 32 bits sous Windows et Linux.

Note #2 : Vous rencontrez des problèmes pour créer une version 32 bits sur Windows 64 bits en raison d'un environnement mal configuré et de bibliothèques manquantes ? Ouvrez le fichier .sln généré dans Visual Studio et compilez à partir de là au lieu d'exécuter cmake --build. Notez également que la version 64 bits fonctionnera sur des cibles 32 bits, il n'est donc peut-être pas nécessaire de créer une version 32 bits.

## Utiliser TinyInst

TinyInst est principalement conçu pour être utilisé comme bibliothèque dans d'autres programmes.

Un client TinyInst est écrit en tant que sous-classe de la classe TinyInst. Le client peut ensuite surcharger les méthodes de l'API dont il a besoin. Les méthodes de l'API sont définies ci-dessous.

Une fois le client créé, il doit être initialisé avec des options de ligne de commande en appelant

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

Les options de ligne de commande sont définies ci-dessous et un client peut également définir les siennes. Ensuite, pour exécuter et contrôler un programme instrumenté, les fonctions suivantes peuvent être utilisées.

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

Ces fonctions exécutent un programme (en utilisant la ligne de commande spécifiée) ou s'attachent à un programme déjà en cours d'exécution. Si aucune méthode cible n'est spécifiée, la cible continuera de s'exécuter jusqu'à ce que le programme se termine, plante, ou que le délai d'attente (en millisecondes) expire. Si une méthode cible est définie, TinyInst reviendra chaque fois que la méthode cible est entrée et chaque fois qu'elle retourne, permettant à l'appelant d'effectuer des tâches supplémentaires.

Lorsque `Run` et `Attach` retournent alors que le processus cible est toujours actif, les fonctions suivantes peuvent être utilisées pour terminer le processus ou continuer l'exécution.

`DebuggerStatus Kill();`

`DebuggerStatus Continue(uint32_t timeout);`

TinyInst est fourni avec un exemple de binaire de couverture, qui peut être invoqué en utilisant

`<options> -- <ligne de commande cible>`

Exemple sous Windows :

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


## API d'instrumentation

### Callbacks d'événements du débogueur