INSTALLATION

Vous trouverez les instructions d'installation ici : GCC-Clang-Setup-Windows

Veuillez noter que ce projet utilise MSYS2.

FONCTIONNALITÉS

Écrire du shellcode dans des langages de programmation de haut niveau n'a rien de nouveau, et d'innombrables articles de blog et documents de recherche ont été publiés sur le sujet depuis 2010. Alors, qu'y a-t-il de nouveau dans SILVERPICK ?

Eh bien, je suis ravi que vous posiez la question.

SILVERPICK cache un joli petit sac d'astuces dans sa manche, mais surtout, c'est ma vision du sujet.

Sans plus attendre, je vous présente ma première astuce.

ASTUCE 01

Depuis que Matt Graeber a popularisé l'écriture de shellcode en C, la plupart des gens utilisent son stub d'alignement de pile de 16 octets écrit en langage Assembly.

Bien que cela ne soit pas un problème, étant donné que nous ne sommes pas IKEA, l'assembleur ne devrait pas être nécessaire, et il ne l'est effectivement pas.

Il existe un attribut de fonction GCC qui émet le stub d'alignement de pile pour vous.

Voici l'attribut de fonction force_align_arg_pointer sous la forme d'une macro pratique ALIGN_STACK, qui génère l'assembleur suivant :

Qu'est-ce que la section .init, demanderez-vous ? Eh bien, cela constitue une belle transition vers ma deuxième astuce.

ASTUCE 02

Matt Graeber a peut-être popularisé l'écriture de shellcode en C à un moment donné, mais c'est en réalité Paul Ungur qui a ravivé cet art noir avec Stardust.

Stardust utilise un script de liaison Binutils pour contrôler le placement des fonctions et des données dans la section PE appropriée, dans le bon ordre. Cette technique est elle-même dérivée des travaux d'Austin Hudson, et de nombreuses personnes utilisent une variante de ses scripts de liaison.

Bien que les scripts de liaison soient parfaits pour ordonner les sections du lieur, ils sont inutiles si tout ce dont vous avez besoin est de placer une fonction donnée au début de la section de code.

C'est ici qu'intervient l'attribut de fonction section avec un nom de section spécial appelé .init, qui indique au lieur que la fonction contient du code d'initialisation d'exécution pré-main() et qu'elle doit être première dans l'ordre de liaison.

À cette fin, la macro CODE_BEGIN a été créée.

ASTUCE 03

Pour ma troisième astuce, je vous présente la macro STACK_STRING.

En C, vous pouvez créer une chaîne de pile (une chaîne construite dynamiquement sur la pile) en déclarant la chaîne littérale comme un tableau de caractères ANSI :

En C++, vous pouvez créer une chaîne de pile en marquant simplement un tableau char comme constexpr :

Cependant, ces deux techniques deviennent inutiles face aux optimisations du compilateur si les chaînes littérales sont suffisamment grandes, contrairement à notre solution, qui fonctionnera quelle que soit la longueur de la chaîne et le niveau d'optimisation du compilateur, grâce à une astuce intelligente de métaprogrammation de templates C++ offerte par Can Bölük.

L'utilisation de cette macro est assez simple :

Cela générera l'assembleur suivant :

ASTUCE 04

En parlant de C++, je vous présente le hachage de chaînes à la compilation pour ma quatrième astuce.

Bien que ce ne soit pas un concept nouveau, SILVERPICK offre quelques améliorations par rapport aux implémentations publiques existantes.

Premièrement, nous utilisons la variante 64 bits de la célèbre fonction de hachage non cryptographique FNV-1a afin de réduire la probabilité d'une attaque par collision de hachage réussie.

Deuxièmement, nous utilisons un paramètre modifié pour la fonction de hachage afin de nous défendre contre les recherches de tables de hachage précalculées, comme HashDB. Point crucial, cela ne change pas les propriétés de la fonction de hachage.

Pour hacher une chaîne courte au moment de l'exécution, utilisez simplement la macro HASH_STRING_RUN_TIME.

Pour hacher une chaîne littérale courte à la compilation, utilisez simplement la macro HASH_STRING_COMPILE_TIME. L'évaluation uniquement à la compilation est garantie via consteval.

ASTUCE 05

Il s'avère que l'on peut implémenter pas mal de fonctions de la C Runtime Library (CRT) à l'aide des instructions de chaîne x86. Alors, bien sûr, j'ai dû les implémenter en utilisant un mélange d'intrinsèques du compilateur et d'assembleur inline.

Vous voulez utiliser la fonction msvcrt!memset dans votre code ? Utilisez plutôt la macro ZERO_MEMORY, qui utilise l'instruction rep stosb émise via un intrinsèque du compilateur.

Et pour la fonction msvcrt!memcpy ou msvcrt!memmove, demanderez-vous ? Voici la macro COPY_MEMORY comme remplaçant, qui utilise l'instruction rep movsb émise via un intrinsèque du compilateur.

Mais qu'en est-il d'une alternative à la fonction msvcrt!memcmp ? Il s'avère qu'il n'existe pas vraiment d'intrinsèque du compilateur permettant d'émettre l'instruction repe cmpsb. Nous écrivons donc une fonction compare_memory utilisant de l'assembleur inline à la place.

Enfin, si vous cherchez un remplaçant pour la fonction msvcrt!memchr, voici la fonction scan_memory, qui utilise là encore de l'assembleur inline, car aucun intrinsèque du compilateur n'est disponible pour émettre l'instruction repne scasb.

Oh, et ai-je oublié de mentionner que vous pouvez écrire votre propre version plus sûre de la fonction msvcrt!strlen en utilisant la routine scan_memory comme ceci :

Veuillez noter que ces implémentations ne produisent pas forcément le code le plus performant, selon la microarchitecture du CPU cible. Cependant, elles sont garanties pour faire le travail.

ASTUCE 06

Intéressé par d'autres tours de passe-passe ?

Il existe beaucoup d'autres petites macros dans Common.h qui servent à abstraire certaines complexités liées au contrôle du compilateur.

Une implémentation sans dépendance de la fonction GetModuleHandle est fournie dans UserModuleBase.cpp. Pour simplifier l'utilisation, une macro pratique nommée GET_USER_MODULE_BASE a été créée.

De même, une implémentation sans dépendance de la fonction GetProcAddress est fournie dans PEParse.cpp, puis encapsulée dans une macro pratique judicieusement nommée GET_EXPORTED_SYMBOL_ADDRESS. De plus, deux autres macros sont fournies pour faciliter la liaison dynamique à l'exécution : INITIALIZE_FUNCTION_POINTER pour déclarer et initialiser un pointeur de fonction à 0, et RESOLVE_FUNCTION_POINTER pour résoudre ce pointeur de fonction.

L'intégration de Visual Studio Code est intégrée au projet afin que les développeurs puissent utiliser le raccourci clavier Ctrl+Shift+B pour un processus de compilation sans tracas.

L'intégration de GitHub Actions est également intégrée au projet pour permettre les builds CI.

Le projet tire une certaine fierté de sa structure bien organisée, ainsi que de son code abondamment commenté et relativement propre.

Enfin, jetez un œil au Makefile du projet, qui contient la sélection la plus fine d'options de compilation et d'édition de liens générant un code petit, sécurisé et respectueux de l'OPSEC. Parallèlement, une journalisation verbeuse et un fichier de carte de liaison généré offriront une visibilité sur le processus de compilation pour faciliter une compréhension plus approfondie de la chaîne d'outils. De plus, chaque unité de traduction produit également un fichier de désassemblage qui, à l'inspection, vous fera souvent dire des choses comme « le compilateur a fait quoi, là ? », etc.

UTILISATION

Si vous êtes convaincu par ce framework, cette section décrit comment l'utiliser.

L'extrait suivant provient de PicMain.cpp :

Ça a l'air assez facile, non ?

Lorsque vous écrivez du PIC en C/C++ avec le framework SILVERPICK, vous devez prendre en considération les règles suivantes :

1. Traitez la fonction payload comme vous le feriez avec la fonction main d'un programme traditionnel, c'est-à-dire comme le (pseudo) point d'entrée.
2. Toutes les chaînes littérales doivent être déclarées comme des chaînes de pile.
3. Les variables globales ne peuvent être utilisées nulle part dans le code.
4. Les fonctions Windows API ou Native API ne peuvent être utilisées que via la liaison dynamique à l'exécution, après avoir vérifié que le prototype de la fonction est disponible dans le fichier d'en-tête correspondant.

AMÉLIORATIONS FUTURES

Cette section contient une liste non exhaustive d'améliorations planifiées qui seront intégrées dans un futur projet.

• Passer à la chaîne d'outils Clang/LLVM.
• Passer à un autre système de construction.
• Obfuscation de chaînes à la compilation compatible avec les chaînes de pile et résistante à FLOSS.
• Hachage de chaînes à la compilation utilisant une fonction de hachage personnalisée non cryptographique avec graine.
• Méthode alternative pour récupérer l'adresse de base du segment GS.
• Capacité à contourner l'atténuation des exploits Export Address Filtering (EAF).

RÉFÉRENCES

Voici une liste de références classées par ordre chronologique qui m'ont été d'une valeur inestimable au cours de mes recherches et m'ont largement servi d'inspiration pour ce projet :

1. Writing Shellcode with a C Compiler par Nick Harbour (2010)

2. Shellcode with a C-compiler par Didier Stevens (2010)

3. Writing Optimized Windows Shellcode in C par Matt Graeber (2013)

4. Shellcode the better way, or how to just use your compiler par Justin Fisher (2016)

5. ShellcodeStdio par Jack Ullrich (2016)

6. Shellcode: A Windows PIC using RSA-2048 key exchange, AES-256, SHA-3 par Odzhan (2016)

7. Writing Optimized Windows Shellcode par Dimitri Fourny (2017)

8. Writing and Compiling Shellcode in C par Aleksandra Doniec et Mantvydas Baranauskas (2021)

9. Creating Shellcode from any Code Using Visual Studio and C++ par Hamid Memar (2021)

10. Writing Optimized Windows Shellcode in C par Philip Woldhek (2021)

11. From C, with inline assembly, to shellcode par Steve Salinas (2023)

12. How To Craft Your Own Windows x86/64 Shellcode with Visual Studio par Yazid Benjamaa (2023)

13. Modern implant design: position independent malware development par Paul Ungur (2024)

14. From C to shellcode (simple way) par Print3M (2024)

15. relocatable par Tijme Gommers (2025)

16. PIC Development Crash Course par Raphael Mudge (2025)

17. scfw par Petr Beneš (2026)

ERRATA

VirusTotal

Ce qui m'a paru étrange, c'est la classification VirTool:Win64/Silepesz.A par Microsoft Defender.

Voici les octets couverts par la signature :

Ceci correspond au code source suivant :

Inutile de dire qu'il s'agit d'une détection extrêmement fragile qui ne détectera que l'exemple de code exact présenté ci-dessus. Elle souligne néanmoins l'importance d'utiliser des hachages API polymorphes.