Module 6: Encryption & Obfuscation

Key Management

The encryption key is generated randomly at build time and embedded in the generated Go source code alongside the ciphertext. Both key and ciphertext are stored as byte arrays in the binary. While this means the key is technically recoverable by a skilled analyst who reverse-engineers the binary, the primary goal is to defeat automated static scanning — not to resist manual analysis. The key is never transmitted externally.

--enc aes

AES is the most widely recommended option and the default for serious loaders. Hooka uses AES in CBC mode with a randomly generated 256-bit key. A random Initialization Vector (IV) is prepended to the ciphertext so each encryption produces unique output even with the same key and plaintext.

• Key size: 256 bits (32 bytes)
• Block size: 128 bits (16 bytes)
• Mode: CBC (Cipher Block Chaining)
• IV: Random, prepended to ciphertext

AES produces high-entropy output that is indistinguishable from random data. Go's crypto/aes and crypto/cipher packages provide the implementation.

--enc 3des

Triple DES applies the legacy DES algorithm three times with different keys (encrypt-decrypt-encrypt). While considered obsolete for protecting sensitive data, it is still effective for obfuscating shellcode against pattern matching. The triple-round application makes it significantly stronger than single DES.

• Key size: 168 bits (three 56-bit keys)
• Block size: 64 bits (8 bytes)
• Rounds: 3 (EDE — encrypt, decrypt, encrypt)

3DES is slower than AES but adds variety — defenders tuning detection for AES patterns may miss 3DES-encrypted payloads.

--enc rc4

RC4 is a stream cipher that generates a pseudorandom keystream from a variable-length key and XORs it with the plaintext byte by byte. It is extremely fast and simple to implement, with minimal code footprint in the generated loader.

• Key size: Variable (typically 128 bits)
• Type: Stream cipher (no block padding needed)
• Speed: Very fast — single-pass XOR operation

RC4 has known cryptographic weaknesses (key scheduling biases), but these are irrelevant for shellcode obfuscation where the goal is static evasion, not long-term secrecy.

--enc xor

The simplest encryption: each byte of shellcode is XORed with the corresponding byte of a repeating key. XOR is its own inverse, so the same operation encrypts and decrypts. This produces the smallest decryption stub in the generated code.

• Key size: Variable (typically 16–32 bytes)
• Type: Substitution cipher
• Speed: Fastest possible — single XOR per byte

XOR encryption is trivially breakable by frequency analysis or known-plaintext attacks, but it still defeats automated signature matching. Best combined with other obfuscation layers.

--strings Flag

The --strings flag applies a Caesar cipher shift to all string literals in the generated source code. Each character is shifted by N positions in the ASCII table. At runtime, the strings are decoded by shifting back before use.

Go// Without --strings:
dll, _ := windows.LoadDLL("ntdll.dll")

// With --strings (shift by 3):
dll, _ := windows.LoadDLL(decryptStr("qwgoo1goo"))  // Each char shifted +3
// 'n'+3='q', 't'+3='w', 'd'+3='g', etc.

This prevents tools like strings, FLOSS, or YARA string rules from finding meaningful API names in the binary.

-r / --rand Flag

The random naming flag replaces all variable and function names in the generated Go code with random strings before compilation. This defeats:

• Source-level pattern matching (if the source is recovered)
• Symbol table analysis of the compiled binary
• YARA rules targeting specific variable name patterns in Go binaries

Go// Without -r:
func decryptShellcode(key []byte, encrypted []byte) []byte { ... }
shellcode := decryptShellcode(encKey, encPayload)

// With -r:
func aK7mNxQ2(xR9pLw []byte, bT4vHn []byte) []byte { ... }
jM3cYs := aK7mNxQ2(wE8dFq, nU6gRk)

--compress Flag

When --compress is specified, Hooka runs UPX on the compiled binary after the Go build completes. Combined with Go's linker flags (-s -w to strip debug info and symbols), this typically reduces binary size by 60–70%.

UPX also adds an obfuscation layer: the compressed binary has a different structure than the original, which can confuse some static analysis tools. However, UPX-packed binaries have a recognizable header that some security tools specifically flag.

PFX Certificate Signing (-c)

If you have a valid code signing certificate in PFX format, the -c flag applies it to the generated binary using osslsigncode. This produces a legitimately signed binary that passes Windows signature verification.

Bash# Sign with a real PFX certificate
hooka -i shellcode.bin -o loader.exe -c /path/to/cert.pfx

Fake Signature Domain (-d)

The -d flag generates a self-signed certificate with a specified domain name (e.g., www.microsoft.com) and signs the binary with it. The signature will not pass rigorous verification, but it adds metadata that can fool some automated tools that only check for the presence of a signature rather than its validity chain.

Bash# Sign with a fake Microsoft signature
hooka -i shellcode.bin -o loader.exe -d www.microsoft.com

Additional Crypto Functions

These functions are primarily useful when building custom loaders via the Go library (Module 7) rather than through the CLI. They enable advanced encryption chains like ChaCha20 + Base64 encoding or multi-layer encryption with different algorithms.