0xrootpls/fritterGénérateur de shellcode polymorphe pour l'exécution en mémoire d'EXE, DLL, .NET, VBScript et JScript avec randomisation par sortie et par build pour l'évasion et la résistance aux signatures.
Le cousin furtif de Donut.
Fritter est un fork fortement modifié du générateur de shellcode Donut de TheWover et Odzhan. Il génère des shellcodes indépendants de la position pour l'exécution en mémoire de scripts VBScript, JScript, d'EXE, de DLL et d'assemblies .NET, avec un accent sur l'évasion et la résistance aux signatures. Le codebase est exclusivement x64.
Beaucoup. Fritter supprime les fonctionnalités rarement nécessaires et remplace les composants internes dont la signature est devenue bien connue au fil des ans. Les couches de chiffrement, de compression, de hachage et de résolution d'API ont toutes été retravaillées, parmi de nombreux autres domaines.
Le polymorphisme et l'évasion sont l'objectif de conception. Chaque résultat est unique, et chaque compilation de l'outil est elle-même unique. Il y a deux couches distinctes :
Randomisation par sortie : appliquée à chaque invocation de fritter. Le stub d'entrée, le décodeur polymorphe, les clés de chiffrement et de nombreux éléments structurels du shellcode généré sont régénérés à partir d'une nouvelle entropie à chaque construction PIC.
Randomisation par compilation : appliquée à chaque compilation de fritter lui-même. Les constantes de rotation de chiffrement et de hachage, la disposition de la table de résolution d'API, le brouillage des chaînes côté shim, les directions de parcours du PEB, les motifs d'effacement post-exécution et plusieurs axes structurels à l'intérieur du loader et du shim sont figés au moment de la compilation.
Au moment de l'exécution, Fritter minimise l'empreinte exécutable du loader. Le loader est partitionné en fonctions individuellement chiffrées, chacune avec sa propre section PE, sa clé XOR et son dispatcher. Les octets d'une seule fonction sont en clair à un instant donné. L'ancien modèle VEH à fenêtre coulissante a été abandonné au profit de ce modèle de dispatch.
C'est important. Les binaires précompilés disponibles pour les tests dans releases partagent leurs constantes par compilation entre tous les utilisateurs du binaire.
Construisez votre propre copie. Les axes par compilation sont ré-randomisés à chaque invocation de make :
# Linux, static-musl ELF, no runtime libc dependency
# Requires: build-essential, mingw-w64, musl-tools
make -f Makefile.linux release
# Windows (MSVC), recommended on Windows
nmake -f Makefile.msvc
Sous Windows, MSVC est la chaîne d'outils recommandée. Elle place chaque fonction du loader dans sa propre section PE alignée sur la page, ce dont le modèle de dispatch par fonction N>1 a besoin. mingw émet actuellement tout dans un seul .text et exécute donc une entrée couvrant l'ensemble du loader avec une seule clé XOR (fonctionnellement identique à la sortie MSVC, mais avec un seul dispatcher de polymorphisme au lieu de plusieurs). Si vous n'avez pas Visual Studio, compilez sous WSL avec Makefile.linux ; il compile le loader Windows en croisé via mingw-w64.
Chaque make exécute tools/gen_poly pour générer de nouvelles constantes par compilation et tools/gen_api_shuffle pour permuter la table de résolution d'API. Le binaire fritter qui en résulte est lui-même unique : différentes constantes de chiffrement, différentes constantes de hachage, une disposition de table d'API différente, un brouillage des chaînes côté shim différent, etc. Chaque shellcode généré par ce binaire partagera alors ces constantes par compilation, mais variera sur les axes par sortie.
Un dossier /test est inclus avec calc.exe et inject_local64.exe pour tester Fritter. Pour reconstruire vous-même les hôtes de test : nmake -f Makefile.msvc harness, ou make -f Makefile.linux harness sous WSL.
fritter [options] -i <EXE/DLL/VBS/JS>
INPUT
-i, --input <path> Input file to execute in-memory
-p, --args <args> Parameters / command line for target
-c, --class <name> Class name (required for .NET DLL)
-m, --method <name> Method or function for DLL
-r, --runtime <ver> CLR runtime version
-w, --unicode Pass command line as UNICODE
-t, --thread Run unmanaged EXE entrypoint as thread
OUTPUT
-o, --output <path> Output file (default: loader.bin)
-f, --format <1-8> 1=Bin 2=B64 3=C 4=Ruby 5=Py 6=PS 7=C# 8=Hex
-x, --exit <1-3> 1=Thread (default) 2=Process 3=Block
-y, --fork <offset> Fork thread, continue at RVA offset
LOADER
-e, --entropy <1-3> 1=None 2=Random names 3=Names+Crypto (default)
-k, --headers <1-2> 1=Overwrite (default) 2=Keep all
-g, --chunked <0-1> (deprecated; dispatch shim is always used)
-d, --domain <name> AppDomain name for .NET
-j, --decoy <path> Decoy module for Module Overloading
STAGING
-n, --modname <name> Module name for HTTP staging
-s, --server <url> Server URL (supports basic auth)
fritter -i payload.exe
fritter -i implant.dll -m RunMain -p "arg1 arg2"
fritter -i payload.exe -g 0 -k 2 -o out.bin
Une charge utile de shellcode Fritter est structurée en couches imbriquées, chacune déchiffrant ou préparant la suivante :
Stub d'entrée. Un préfixe aléatoire de bourrage de longueur variable, une routine d'alignement du RSP générée par sortie, et un trampoline génératif. Basé sur la discipline de Shikata Ga Nai.
Décodeur XOR polymorphe. Assemblé en deux passes. Allocation des registres tirée d'un pool par mélange de Fisher-Yates. Longueur de clé choisie par sortie. Des déchets insérés entre chaque instruction réelle. Les groupes d'instructions déplaçables de la boucle chaude sont réordonnés dans le respect des contraintes de correction.
Shim de dispatch. Remplace l'ancien shim VEH à fenêtre coulissante. Bascule la région du loader de RW->RWX, puis passe le contrôle au point d'entrée du loader. Avec un dispatch N>1, chaque appel est acheminé via un thunk par fonction vers un dispatcher par fonction qui déchiffre, exécute et efface au retour. La disposition des opcodes de chaque dispatcher varie à chaque compilation (voir CHANGELOG v1.3).
Loader. Mappeur de PE en mémoire. Résout les API par hachage, mappe le PE intégré via les API de sections, applique les imports / relocations / callbacks TLS, invoque le point d'entrée, puis efface. La direction du parcours du PEB, l'octet d'effacement post-exécution, et les emplacements de sel structurels dans MainProc sont tous randomisés à chaque compilation.
Nettoyage. Efface les pages du loader avec un motif d'octets propre à chaque compilation, efface l'instance et se termine par l'arrêt du thread ou du processus selon -x. Aucun gestionnaire VEH ni structure de contexte à nettoyer.
L'empreinte résiduelle après l'exécution est une petite page RWX là où le shim de dispatch s'est exécuté. En mode thread, la section PE mappée est intentionnellement laissée intacte afin que les callbacks CRT disposent de continuations.
Fritter est construit sur le travail de TheWover et Odzhan, dont le projet original Donut a rendu la génération de shellcode indépendant de la position accessible et pratique. Leur architecture, la conception du loader et le framework PIC constituent la fondation sur laquelle tout ici est bâti. Le mappage PE, l'hébergement .NET et les chemins d'exécution de scripts sont en grande partie leur travail, conservé et respecté.
BSD 3-Clause. Voir LICENSE.