ofasgard/execute-assembly-picoUn PICO pour Crystal Palace qui implémente l'hébergement CLR pour exécuter un assembly .NET en mémoire.
Un PICO pour Crystal Palace qui implémente l'hébergement CLR natif pour exécuter en mémoire un assembly .NET ajouté, en utilisant la même technique que le générateur de shellcode donut. Cela vous permet de charger des outils .NET comme Rubeus ou Seatbelt à partir de code indépendant de la position sans les déposer sur le disque.
Vous aurez besoin de MinGW GCC, de l'utilitaire zip et des exécutables CPL nécessaires pour lier le projet. Modifiez config.spec pour spécifier l'assembly .NET que vous voulez lier au projet et les arguments de ligne de commande que vous souhaitez passer. Modifiez Makefile pour spécifier l'emplacement de crystalpalace.jar.
Pour compiler le PICO seul (en tant que COFF), exécutez make pico. Pour compiler l'exécuteur d'exemple et le lier au PICO, exécutez make runner.
L'exécuteur d'exemple est écrit dans out/runner.bin. La configuration par défaut invoque un assembly Rubeus ajouté pour exécuter "asktgt" avec des identifiants factices génériques lorsque vous l'exécutez :
La signature du point d'entrée du PICO est :
HRESULT (*EXECUTE_ASSEMBLY_PICO)(char *assembly, size_t assembly_len, WCHAR *argv[], int argc);
Les deux premiers arguments doivent contenir un pointeur vers un assembly .NET brut et sa taille. Les deux seconds arguments servent à passer des paramètres de chaîne à l'assembly lors de son invocation.
Ce PICO se contente d'invoquer l'assembly avec les arguments que vous avez fournis. Il ne tente pas de capturer la sortie.
Si vous devez fournir une entrée via STDIN ou capturer la sortie de STDOUT, vous devez modifier votre chargeur pour utiliser des appels d'API WIN32 comme CreatePipe() et SetStdHandle() et connecter les périphériques d'E/S standard de votre processus à un tube anonyme. Ensuite, vous pouvez lire et écrire comme d'habitude.
clr.h directement dans le PICO.