Maverick

Maverick

An Adaptix C2 agent built with Crystal Palace — a custom PIC (Position Independent Code) linker and PICO module system. Demonstrates how to build modular shellcode agents where each component (transport, tasks, obfuscation) is a separate PICO blob loaded at runtime.

Note

This agent does not include any evasion techniques and is not meant to be used as-is in engagements. It is a reference implementation for building agents with Crystal Palace and the PICO module system.

Crystal Palace & PICO System

**Crystal Palace** is a PIC linker that takes compiled COFF objects and produces position-independent executables. Key concepts:

• Core PIC (make pic +gofirst) — The main executable shellcode. Contains the bootstrap code, DFR resolver, and section markers where PICO modules get linked. Called directly by the loader.
• PICO Modules (make object) — Self-contained code blobs with their own code and data sections. Loaded at runtime via PicoLoad() from libtcg. Each PICO has an entry point (go()) callable via function pointer.
• DFR (Dynamic Function Resolution) — Crystal Palace replaces MODULE$Function syntax (e.g. KERNEL32$VirtualAlloc) with calls to resolve(mod_hash, func_hash) using ROR13 hashing. No import table. All string arguments (DLL names, function names) are built on the stack as char arrays to avoid plaintext in the binary.
• Section Linking — PICO blobs are embedded into the Core PIC at named sections (entry_module, transport_module, etc.) via the link directive in the .spec file.
• IMPORTFUNCS — Crystal Palace struct {LoadLibraryA, GetProcAddress} passed to PicoLoad() so PICO modules can resolve their own DFR symbols.

Build Pipeline

C source → mingw-gcc → COFF objects → Crystal Palace link → raw PIC shellcode → loader (Exe/Dll/Svc)

agent.spec

The `.spec` file defines how Crystal Palace links