Module 8: The Linker Script & Section Layout

Why section order is everything when your code is its own loader.

Why Section Order Matters

Stardust's position-independent code relies on precise spatial relationships between code and data:

• RipStart must be at the very beginning (byte 0) — this is the shellcode entry point. When an injector calls the shellcode, it jumps to the first byte.
• Main C++ code comes next — the bulk of the implant logic.
• String data (.rdata) must be sandwiched between the main code and RipData — this is where all the embedded strings live.
• RipData must be last, immediately after the data — symbol<T> uses it as an anchor point to calculate string addresses (as covered in Module 7).

The Linker Script: linker.ld

Stardust uses a custom linker script at scripts/linker.ld to enforce this layout. The MinGW toolchain's linker reads this script and places sections in exactly the specified order:

Linker ScriptSECTIONS
{
    .text :
    {
        *( .text$A )    /* RipStart - entry point, must be byte 0 */
        *( .text$B )    /* Main C++ code (start(), resolve, etc.) */
        *( .rdata* )    /* Read-only data: strings, constants */
        *( .text$C )    /* RipData - anchor for symbol<T> */
    }
}

Why This Specific Order?

1. .text$A first: The injector calls byte 0 of the shellcode. RipStart must be here.
2. .text$B second: The main implant code. Section ordering is alphabetical within .text sub-sections, so $B naturally follows $A.
3. .rdata* third: String data is sandwiched between code sections. By placing it inside the .text section (not as a separate PE section), it becomes part of the executable code blob. This is unconventional but necessary — shellcode is extracted as a single flat binary.
4. .text$C last: RipData() must be physically adjacent to the data it references. Placing it immediately after .rdata means the compile-time distance to any string is small and predictable.

The declfn Attribute

To place a function in a specific section, Stardust uses compiler attributes (via a declfn macro or direct section attributes). This tells the compiler which sub-section a function belongs to:

C++// Place RipStart in .text$A (first in the binary)
__attribute__(( section(".text$A") ))
void RipStart() {
    // Entry point code...
}

// Place RipData in .text$C (last, after data)
__attribute__(( section(".text$C") ))
auto RipData() -> uintptr_t {
    return (uintptr_t)&RipData;
}

// Regular functions go in .text$B by default
// (or explicitly placed there via attribute)

Comparison: AceLdr vs Stardust Section Layout

AceLdr needs more sections because its C-based design uses explicit section placement for different categories of code (hooks, loader logic, data). Stardust's C++ approach consolidates most logic into .text$B, relying on templates and the type system instead of manual section separation.

Extracting the Shellcode

After compilation, the shellcode blob is extracted from the PE using objcopy. This strips all PE headers and metadata, leaving just the raw contents of the merged .text section:

Shell# Extract the .text section as a flat binary blob
objcopy -O binary -j .text stardust.exe stardust.bin

# The result is raw shellcode:
# - Starts at RipStart (byte 0)
# - Contains all code, data, and the RipData anchor
# - No PE headers, no section table, no imports
# - Ready to inject and execute