Module 2: Crystal Palace — The PIC Linker

The spec-driven linker that transforms compiled COFF objects into flat position-independent shellcode — no PE headers, no import tables, just executable machine code.

1. What Is Crystal Palace?

Crystal Palace is a Java-based linker and linker-script language designed by Raphael Mudge specifically for building PIC (position-independent code) DLL loaders. It was released in 2025 as part of the Tradecraft Garden project and is designed for building PIC DLL loaders, including User-Defined Reflective Loaders (UDRLs) for Cobalt Strike.

Crystal Palace takes compiled COFF object files (.o) produced by MinGW and transforms them into flat PIC shellcode with embedded resources. The transformation is driven by .spec files — declarative specifications that describe how to assemble, transform, and link the final payload.

The key insight is that Crystal Palace replaces the traditional Windows linker entirely. Instead of producing a PE with headers, section tables, and import directories, it produces a single contiguous block of executable bytes that can run from any memory address.

2. The Build Pipeline

The Crystal-Loaders build process follows a two-stage pipeline. First the C compiler produces COFF objects, then Crystal Palace links them into PIC shellcode:

The Makefile uses MinGW to cross-compile the C source into a COFF object file:

MakefileCC_64 = x86_64-w64-mingw32-gcc
$(CC_64) -DWIN_X64 -shared -masm=intel -Wall -Wno-pointer-arith -c src/loader.c -o bin/loader.x64.o

Compiler Flags Explained

The -c flag is the critical one. It tells GCC to stop after compilation and produce a .o object file instead of calling the linker. Crystal Palace handles everything from that point forward.

3. The Spec Language

Crystal Palace specs are declarative scripts that describe the complete linking and transformation process. Here is the actual loader.spec from Crystal-Loaders, annotated line by line:

loader.specname     "Beacon BUD Loader"
describe "PIC loader to pass memory allocation information via Beacon User Data"
author   "Daniel Duggan (@_RastaMouse)"

x64:
    load "bin/loader.x64.o"
        make pic +gofirst +optimize +disco
        dfr "resolve" "ror13"
        mergelib "../libgate.x64.zip"
        mergelib "../libtcg.x64.zip"

    generate $KEY 128

    push $DLL
        xor $KEY
        preplen
        link "dll"

    push $KEY
        preplen
        link "key"

    export

The spec reads top-down like a recipe. First it loads and transforms the compiled code, then it generates a random XOR key, encrypts the DLL payload, and links everything together into the final output. Let's break down each block:

4. Directive Reference

Every Crystal Palace directive available in the spec language, with its purpose and usage:

5. Dynamic Function Resolution (DFR)

DFR is the mechanism that makes PIC code possible. In normal PE executables, the loader resolves API imports at load time using the Import Address Table. PIC shellcode has no IAT, so API addresses must be resolved at runtime by the shellcode itself.

The Problem

In the C source, Windows API functions are declared as DLL imports using the MODULE$Function naming convention:

C// These declarations tell the compiler: "this function comes from an external DLL"
// The '$' separator tells Crystal Palace: module = KERNEL32, function = VirtualAlloc
DECLSPEC_IMPORT LPVOID WINAPI KERNEL32$VirtualAlloc(LPVOID, SIZE_T, DWORD, DWORD);
DECLSPEC_IMPORT BOOL   WINAPI KERNEL32$VirtualProtect(LPVOID, SIZE_T, DWORD, PDWORD);
DECLSPEC_IMPORT int    WINAPI MSVCRT$strncmp(const char *, const char *, SIZE_T);

After compilation, these become __imp_KERNEL32$VirtualAlloc symbols in the COFF object's symbol table. In a normal linking process, these would be resolved against import libraries (.lib files). Crystal Palace does something fundamentally different.

The Solution: DFR Rewriting

The dfr "resolve" "ror13" directive tells Crystal Palace to:

1. Find every instruction in the code that references an __imp_MODULE$Function symbol
2. Extract the module name and function name from the symbol
3. Compute the ROR13 hash of both the module name and function name
4. Rewrite each reference to instead call the user-supplied resolve() function, passing the two hash values as DWORD arguments

The resolve() function that Crystal Palace calls into is defined in loader.c:

C (loader.c)char * resolve(DWORD modHash, DWORD funcHash)
{
    char * mod = findModuleByHash(modHash);
    return findFunctionByHash(mod, funcHash);
}

findModuleByHash walks the PEB InMemoryOrderModuleList (the linked list of loaded DLLs maintained by the Windows loader), hashes each module name using the ROR13 algorithm, and compares against moduleHash. findFunctionByHash then walks the found module's Export Address Table, hashes each exported function name, and returns the matching function pointer.

Two Resolution Methods

6. The PIC Transformation

The make pic directive is where the real magic happens. It converts a standard COFF object file — which assumes fixed memory addresses — into a position-independent blob that can execute from any address.

What make pic Actually Does

1. Resolve all internal relocations — Function calls between different .text sections within the same object are patched to use relative offsets
2. Flatten all sections — The separate .text, .data, and .rdata sections are merged into a single contiguous byte stream
3. Convert absolute addresses to RIP-relative — Any remaining absolute address references are rewritten to use x64 RIP-relative addressing so the code works regardless of where it is loaded
4. Place go() at offset 0 — With the +gofirst flag, the entry point function is positioned at the very start of the blob so the caller can simply jump to byte 0
5. Optimize — With +optimize, Crystal Palace removes dead code and minimizes the output size
6. Randomize function order — With +disco, Crystal Palace randomizes the order of functions in the PIC blob (the first function is preserved when used with +gofirst)

This is why Crystal Palace-based loaders evade static analysis tools that look for PE artifacts. The payload is not a PE file at any point during execution — it is raw machine code with embedded encrypted data.