EINRICHTUNG

Die Einrichtungsanweisungen findest du hier: GCC-Clang-Setup-Windows

Bitte beachte, dass dieses Projekt MSYS2 verwendet.

FUNKTIONEN

Shellcode in höheren Programmiersprachen zu schreiben, ist nichts Neues, und unzählige Blogbeiträge und Forschungsarbeiten wurden seit 2010 darüber veröffentlicht. Was ist also neu an SILVERPICK?

Nun, ich bin froh, dass du fragst.

SILVERPICK hat ein nettes kleines Bündel an Tricks im Ärmel, aber vor allem ist dies meine Herangehensweise an das Thema.

Also, ohne weitere Umschweife, präsentiere ich dir meinen ersten Trick.

TRICK 01

Seitdem Matt Graeber das Schreiben von Shellcode in C populär gemacht hat, verwenden die meisten Leute seinen 16-Byte-Stack-Ausrichtungs-Stub, geschrieben in Assembly.

Obwohl dies kein Problem darstellt, da wir nicht IKEA sind, sollte Assembly nicht notwendig sein, und tatsächlich ist es das auch nicht.

Es gibt ein GCC-Funktionsattribut, das den Stack-Ausrichtungs-Stub für dich erzeugt.

Hier ist das force_align_arg_pointer-Funktionsattribut in Form eines hilfreichen ALIGN_STACK-Makros, das die folgende Assembly erzeugt:

Was ist die .init-Sektion, fragst du? Nun, das dient als schöner Übergang zu meinem zweiten Trick.

TRICK 02

Matt Graeber hat vielleicht irgendwann das Schreiben von Shellcode in C populär gemacht, aber wirklich war es Paul Ungur, der diese schwarze Kunst mit Stardust wiederbelebt hat.

Nun verwendet Stardust ein Binutils-Linker-Skript, um die Platzierung von Funktionen und Daten in der entsprechenden PE-Sektion in der richtigen Reihenfolge zu steuern. Diese Technik selbst stammt aus der Arbeit von Austin Hudson, und viele Leute verwenden eine Variante seiner Linker-Skripte.

Während Linker-Skripte großartig für die Linker-Sektionsreihenfolge sind, sind sie unnötig, wenn du nur eine bestimmte Funktion an den Anfang der Code-Sektion setzen musst.

Hier kommt das section-Funktionsattribut mit einem speziellen Sektionsnamen namens .init ins Spiel, das dem Linker mitteilt, dass die Funktion Vor-main()-Laufzeitinitialisierungscode enthält und als erstes in der Link-Reihenfolge stehen muss.

Zu diesem Zweck wurde das CODE_BEGIN-Makro erstellt.

TRICK 03

Für meinen dritten Trick präsentiere ich dir das STACK_STRING-Makro.

In C kannst du einen Stack-String (einen String, der dynamisch auf dem Stack aufgebaut wird) erstellen, indem du das String-Literal als ein Array von ANSI-Zeichen deklarierst:

In C++ kannst du einen Stack-String erstellen, indem du ein char-Array einfach als constexpr markierst:

Beide Techniken werden jedoch angesichts von Compiler-Optimierungen nutzlos, wenn die String-Literale ausreichend groß sind, anders als unsere Lösung, die unabhängig von der String-Länge und dem Grad der Compiler-Optimierungen funktioniert, dank eines cleveren C++-Template-Metaprogrammierungs-Hacks, mit freundlicher Genehmigung von Can Bölük.

Die Verwendung dieses Makros ist ziemlich einfach:

Dies erzeugt die folgende Assembly:

TRICK 04

Da wir gerade von C++ sprechen, präsentiere ich dir für meinen vierten Trick Compile-Zeit-String-Hashing.

Obwohl dies kein neuartiges Konzept ist, bietet SILVERPICK einige Verbesserungen gegenüber bestehenden öffentlichen Implementierungen.

Erstens verwenden wir die 64-Bit-Variante der beliebten nicht-kryptografischen Hash-Funktion FNV-1a, um die Wahrscheinlichkeit eines erfolgreichen Hash-Kollisionsangriffs zu verringern.

Zweitens verwenden wir einen modifizierten Parameter für die Hash-Funktion, um uns gegen vorberechnete Hash-Tabellen-Lookups wie HashDB zu verteidigen. Entscheidend ist, dass dies die Eigenschaften der Hash-Funktion nicht verändert.

Um einen kurzen String zur Laufzeit zu hashen, verwende einfach das HASH_STRING_RUN_TIME-Makro.

Um ein kurzes String-Literal zur Compile-Zeit zu hashen, verwende einfach das HASH_STRING_COMPILE_TIME-Makro. Die reine Compile-Zeit-Auswertung wird über consteval garantiert.

TRICK 05

Es stellt sich heraus, dass man eine ganze Reihe von C-Runtime-Library (CRT)-Funktionen mit x86-String-Anweisungen implementieren kann. Also musste ich sie natürlich mit einer Mischung aus Compiler-Intrinsics und Inline-Assembly implementieren.

Möchtest du die Funktion msvcrt!memset in deinem Code verwenden? Verwende stattdessen das ZERO_MEMORY-Makro, das die über ein Compiler-Intrinsic emittierte rep stosb-Anweisung verwendet.

Wie wäre es mit der Funktion msvcrt!memcpy oder der Funktion msvcrt!memmove, fragst du? Lerne das COPY_MEMORY-Makro als Ersatz kennen, das die über ein Compiler-Intrinsic emittierte rep movsb-Anweisung verwendet.

Aber was ist mit einer Alternative zur Funktion msvcrt!memcmp? Es stellt sich heraus, dass es nicht genau ein Compiler-Intrinsic gibt, um die repe cmpsb-Anweisung zu emittieren. Also schreiben wir stattdessen eine compare_memory-Funktion mit Inline-Assembly.

Wenn du schließlich einen Ersatz für die Funktion msvcrt!memchr suchst, lerne die scan_memory-Funktion kennen, die erneut Inline-Assembly verwendet, da kein Compiler-Intrinsic verfügbar ist, um die repne scasb-Anweisung zu emittieren.

Oh, und habe ich erwähnt, dass du deine eigene sicherere Version der Funktion msvcrt!strlen mit der scan_memory-Routine schreiben kannst, wie folgt:

Bitte beachte, dass diese Implementierungen je nach Ziel-CPU-Mikroarchitektur möglicherweise nicht den leistungsfähigsten Code erzeugen. Sie sind jedoch garantiert in der Lage, die Aufgabe zu erledigen.

TRICK 06

Interessiert an weiteren Salon-Tricks?

Es gibt viele andere kleine Makros in Common.h, die dazu dienen, einige der Komplexitäten der Compiler-Beeinflussung zu abstrahieren.

Eine abhängigkeitsfreie Implementierung der Funktion GetModuleHandle wird in UserModuleBase.cpp bereitgestellt. Um die Benutzerfreundlichkeit zu vereinfachen, wurde ein hilfreiches Makro namens GET_USER_MODULE_BASE erstellt.

Ähnlich wird eine abhängigkeitsfreie Implementierung der Funktion GetProcAddress in PEParse.cpp bereitgestellt, die dann in ein praktisches Makro mit dem treffenden Namen GET_EXPORTED_SYMBOL_ADDRESS verpackt wird. Darüber hinaus werden zwei weitere Makros bereitgestellt, um das dynamische Linken zur Laufzeit zu unterstützen - INITIALIZE_FUNCTION_POINTER zum Deklarieren und Initialisieren eines Funktionszeigers auf 0 und RESOLVE_FUNCTION_POINTER zum Auflösen dieses Funktionszeigers.

Die Visual-Studio-Code-Integration ist in das Projekt integriert, sodass Entwickler die Tastenkombination Ctrl+Shift+B für einen problemlosen Build-Prozess verwenden können.

Die GitHub-Actions-Integration ist ebenfalls in das Projekt integriert, um CI-Builds zu ermöglichen.

Das Projekt ist stolz auf seine gut organisierte Struktur sowie auf den gründlich kommentierten und relativ sauberen Code.

Wirf schließlich einen Blick auf das Makefile des Projekts, das die erlesenste Auswahl an Compiler- und Linker-Flags enthält, die kleinen, sicheren und OPSEC-freundlichen Code erzeugen. Darüber hinaus bieten eine ausführliche Protokollierung und eine erzeugte Linker-Map-Datei Einblick in den Build-Prozess, um ein tieferes Verständnis der Toolchain zu ermöglichen. Zusätzlich erzeugt jede Übersetzungseinheit eine Disassembly-Datei, die bei der Untersuchung oft dazu führt, dass man Dinge sagt wie "Was hat der Compiler jetzt gemacht?", usw.

VERWENDUNG

Wenn dich das Framework überzeugt hat, beschreibt dieser Abschnitt, wie du es nutzen würdest.

Das Folgende ist ein Auszug aus PicMain.cpp:

Scheint einfach genug, oder?

Beim Schreiben von PIC in C/C++ mit dem SILVERPICK-Framework musst du die folgenden Regeln berücksichtigen:

1. Behandle die payload-Funktion so, wie du die main-Funktion eines traditionellen Programms behandeln würdest, d. h. als (Pseudo-)Einstiegspunkt.
2. Alle String-Literale müssen als Stack-Strings deklariert werden.
3. Globale Variablen dürfen an keiner Stelle im Code verwendet werden.
4. Windows-API- oder Native-API-Funktionen dürfen nur über dynamisches Linken zur Laufzeit verwendet werden, nachdem sichergestellt wurde, dass der Funktionsprototyp in der entsprechenden Header-Datei verfügbar ist.

ZUKÜNFTIGE ERWEITERUNGEN

Dieser Abschnitt enthält eine nicht erschöpfende Liste geplanter Erweiterungen, die in ein zukünftiges Projekt integriert werden.

• Wechsel zur Clang/LLVM-Toolchain.
• Wechsel zu einem anderen Build-System.
• Compile-Zeit-String-Verschleierung, die mit Stack-Strings funktioniert und gegen FLOSS resistent ist.
• Compile-Zeit-String-Hashing unter Verwendung einer gesalzenen, nicht-kryptografischen, benutzerdefinierten Hash-Funktion.
• Alternative Methode zum Abrufen der Basisadresse des GS-Segments.
• Fähigkeit, die Exploit-Mitigation Export Address Filtering (EAF) zu umgehen.

REFERENZEN

Das Folgende ist eine Liste von Referenzen in chronologischer Reihenfolge, die sich für mich während meiner Forschung als unschätzbar wertvoll erwiesen und ausgiebig als Inspiration für dieses Projekt dienten:

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

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

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

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

5. ShellcodeStdio von Jack Ullrich (2016)

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

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

8. Writing and Compiling Shellcode in C von Aleksandra Doniec und Mantvydas Baranauskas (2021)

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

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

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

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

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

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

15. relocatable von Tijme Gommers (2025)

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

17. scfw von Petr Beneš (2026)

ERRATA

VirusTotal

Was mir als seltsam auffiel, war die Einstufung VirTool:Win64/Silepesz.A durch Microsoft Defender.

Dies sind die Bytes, die die Signatur abdeckt:

Dies lässt sich auf den folgenden Quellcode zurückführen:

Unnötig zu erwähnen, dass dies eine äußerst fragile Erkennung ist und nur den genauen Beispielcode erkennt, der im Beispiel gezeigt wird. Es unterstreicht jedoch, wie wichtig die Verwendung polymorpher API-Hashes ist.