Difficulty: Beginner

Module 1: Why Stardust Exists

The problem with old-school shellcode loaders, and a modern answer.

Context Check

If you completed the AceLdr course, you already know how reflective DLL loaders work. Stardust takes a radically different approach. Instead of loading a DLL reflectively, Stardust IS the implant — pure position-independent C++ code compiled directly into shellcode. No PE headers, no DLL, no loader stub. Just raw code.

The Problem with Reflective Loaders

Traditional reflective DLL injection (like AceLdr) works well but leaves artifacts:

Reflective DLL Loader (Traditional)

Full PE still exists in memory (headers, sections, IAT)
Loader stub + DLL = larger payload
Must parse PE headers, process relocations, resolve IAT
PE signatures detectable by PE-sieve, Moneta
Two components: the loader and the payload

Stardust (PIC Template)

No PE headers in memory at all
~752 bytes (x64) / ~672 bytes (x86) base size
No PE parsing, no relocations, no IAT
Nothing for PE scanners to find
One component: the shellcode IS the implant

What Stardust Actually Is

Stardust is a template — a skeleton you fill in with your implant logic. Out of the box, it demonstrates:

Position-independent code that works at any memory address
Compile-time DJB2 hashing using modern C++ constexpr/consteval
Dynamic API resolution via PEB walking + export table parsing
Dual architecture support (x86 and x64 from the same codebase)
Raw string support with the symbol<T> template
Module stomping test harness for injection

Stardust at a Glance

Metric	Value
Author	Cracked5pider (C5), also creator of Havoc C2 Framework
Language	C++ + Assembly
Compiler	MinGW cross-compilation toolchain
x64 Release Size	~752 bytes
x86 Release Size	~672 bytes
Dependencies	None (nostdlib)
Blog Post	5pider.net/blog/2024/01/27/modern-shellcode-implant-design

Architecture Comparison

Traditional: Reflective DLL Loader

Shellcode (Loader Stub)

PE Headers (MZ, NT, Sections)

.text - Beacon Code

.rdata - Import Table (IAT)

.reloc - Base Relocations

Stardust: Pure PIC Shellcode

.text$A - Entry + RipStart (ASM)

.text$B - All C++ implant code

.rdata - Strings (position-independent)

.text$C - RipData utility (ASM)

That's it. No headers. No tables. Just code.

Pop Quiz: Why Stardust?

Q1: What is the fundamental difference between a reflective loader and Stardust?

Stardust is written in C++ instead of C Stardust supports more Windows versions Stardust compiles directly to PIC shellcode with no PE structure in memory Stardust uses encryption while reflective loaders don't

Reflective loaders take a full DLL and manually map it into memory, leaving PE artifacts. Stardust eliminates this entirely — C++ code compiles directly into position-independent shellcode. The final binary is extracted from the .text section with no PE headers, no IAT, no relocations.

Q2: Approximately how large is the Stardust x64 release binary?

~50 KB ~752 bytes ~4 KB ~15 KB

The base template compiles to approximately 752 bytes on x64 and 672 bytes on x86. This tiny size is achieved through aggressive optimization flags (-Os, -nostdlib, -s) and the elimination of all standard library dependencies.

Next: C++ for Shellcode →