ctf-crypto

What this skill does

# CTF Cryptography

## Purpose

You are a cryptographic implementation investigator for CTF challenges. Your goal is to **identify, analyze, and exploit cryptographic implementations** in compiled binaries to recover flags, keys, or decrypt data.

Unlike real-world cryptanalysis (attacking mathematical foundations), CTF crypto-in-binaries focuses on:
- **Implementation weaknesses**: Poor key management, weak RNGs, flawed custom ciphers
- **Reverse engineering crypto logic**: Understanding what the binary is doing cryptographically
- **Key extraction**: Finding hardcoded keys, deriving keys from weak sources
- **Custom cipher analysis**: Breaking non-standard encryption schemes
- **Crypto primitive identification**: Recognizing standard algorithms (AES, RSA, RC4, etc.)

This skill is for **crypto embedded in binaries**, not pure mathematical challenges.

## Conceptual Framework

Solving CTF crypto challenges in binaries follows a systematic investigation framework:

### Phase 1: Crypto Detection
**Goal**: Determine if and where cryptography is used

**Investigation approach:**
- Search for crypto-related strings and constants
- Identify mathematical operation patterns (XOR, rotation, substitution)
- Recognize standard algorithm signatures (S-boxes, key schedules, magic constants)
- Find crypto API imports (CryptEncrypt, OpenSSL functions, etc.)

**Key question**: "Is there crypto, and if so, what kind?"

### Phase 2: Algorithm Identification
**Goal**: Determine what cryptographic algorithm is being used

**Investigation approach:**
- Compare constants to known crypto constants (initialization vectors, S-boxes)
- Analyze operation patterns (rounds, block sizes, data flow)
- Match code structure to known algorithm patterns
- Check for library usage vs. custom implementation

**Key question**: "What algorithm is this, or is it custom?"

### Phase 3: Implementation Analysis
**Goal**: Understand how the crypto is implemented and find weaknesses

**Investigation approach:**
- Trace key material sources (hardcoded, derived, user input)
- Analyze key generation/derivation logic
- Identify mode of operation (ECB, CBC, CTR, etc.)
- Look for implementation mistakes (IV reuse, weak RNG, etc.)
- Check for custom modifications to standard algorithms

**Key question**: "How is it implemented, and where are the weaknesses?"

### Phase 4: Key Extraction or Breaking
**Goal**: Recover the key or break the implementation to decrypt data

**Investigation approach:**
- Extract hardcoded keys from binary data
- Exploit weak key derivation (predictable RNG, poor entropy)
- Break custom ciphers (frequency analysis, known-plaintext, etc.)
- Leverage implementation flaws (timing, side channels, logic errors)
- Reverse engineer decryption routines to understand transformation

**Key question**: "How do I recover the plaintext or key?"

## Core Methodologies

### Methodology 1: String and Constant Analysis

**When to use**: Initial discovery phase

**Approach**:
1. Search for crypto keywords in strings
2. Search for URLs, API endpoints that might receive encrypted data
3. Locate large constant arrays (potential S-boxes, lookup tables)
4. Compare constants to known crypto constants databases
5. Follow cross-references from strings/constants to crypto functions

**Tools**:
- `get-strings` with `regexPattern` for crypto keywords
- `get-strings` with `searchString` for algorithm names
- `read-memory` to inspect constant arrays
- `find-cross-references` to trace usage

### Methodology 2: Pattern Recognition

**When to use**: Identifying algorithm type

**Approach**:
1. Look for characteristic loop structures (round counts)
2. Identify substitution operations (table lookups)
3. Recognize permutation patterns (bit shuffling)
4. Spot modular arithmetic (public-key crypto)
5. Match to known algorithm patterns (see patterns.md)

**Tools**:
- `get-decompilation` with context to see algorithm structure
- `search-decompilation` for operation patterns
- Pattern reference (patterns.md) for recognition

### Methodology 3: Data Flow Analysis

**When to use**: Understanding key management and data flow

**Approach**:
1. Trace where plaintext/ciphertext enters the system
2. Follow key material from source to usage
3. Identify transformation steps (encrypt, decrypt, derive)
4. Map data dependencies between functions
5. Find where decrypted output is used or stored

**Tools**:
- `find-cross-references` with context for data flow
- `rename-variables` to clarify data roles (plaintext, key, iv)
- `change-variable-datatypes` to reflect crypto types (uint8_t*, etc.)

### Methodology 4: Weakness Discovery

**When to use**: Finding exploitable flaws in implementation

**Common implementation weaknesses in CTF challenges**:
- Hardcoded keys in binary (directly extractable)
- Weak key derivation (time-based seeds, simple XOR)
- Poor random number generation (predictable, seeded with constant)
- ECB mode (enables block analysis and manipulation)
- IV reuse or predictable IVs
- Custom ciphers with mathematical weaknesses
- Incomplete key schedules or reduced rounds
- Debug/test modes that bypass crypto

**Investigation strategy**:
1. Check if key is hardcoded (read memory at key pointer)
2. Analyze RNG initialization (is seed predictable?)
3. Check for mode of operation weaknesses (ECB patterns)
4. Look for test/debug backdoors
5. Identify custom modifications to standard algorithms

### Methodology 5: Reverse Engineering Decryption

**When to use**: When you need to understand or replicate crypto logic

**Approach**:
1. Find decryption routine (may be encryption run backwards)
2. Rename variables systematically (key, plaintext, ciphertext, state)
3. Apply correct data types (byte arrays, word arrays)
4. Document each transformation step with comments
5. Replicate logic in Python script to test understanding
6. Use binary's own decryption routine if possible

**Tools**:
- `rename-variables` for clarity
- `change-variable-datatypes` for correctness
- `set-decompilation-comment` to document understanding
- `set-bookmark` to mark important crypto functions

## Flexible Workflow

CTF crypto challenges vary widely, so adapt this workflow to your specific challenge:

### Quick Triage (5 minutes)
1. **Detect**: Search for crypto strings, imports, constants
2. **Identify**: Quick pattern match to known algorithms
3. **Assess**: Is it standard crypto or custom? Strong or weak?

### Deep Investigation (15-30 minutes)
4. **Understand**: Decompile crypto functions, trace data flow
5. **Improve**: Rename variables, fix types, document behavior
6. **Analyze**: Find key sources, check for weaknesses
7. **Exploit**: Extract keys, break weak implementations, or replicate logic

### Exploitation (varies)
8. **Extract**: Pull hardcoded keys from binary data
9. **Break**: Exploit weak RNG, custom cipher flaws, or poor key derivation
10. **Decrypt**: Use recovered keys or replicated logic to get flag

### Verification
11. **Test**: Verify decryption produces readable flag
12. **Document**: Save findings in bookmarks and comments

## Pattern Recognition

For detailed cryptographic algorithm patterns and recognition techniques, see **patterns.md**.

Key pattern categories:
- **Block ciphers**: AES, DES, Blowfish (S-boxes, rounds, key schedules)
- **Stream ciphers**: RC4, ChaCha (state evolution, keystream generation)
- **Public key**: RSA, ECC (modular arithmetic, large integers)
- **Hash functions**: MD5, SHA family (compression, magic constants)
- **Simple schemes**: XOR, substitution, custom ciphers

## CTF-Specific Considerations

### CTF Challenge Design Patterns

**Common CTF crypto scenarios**:
1. **Weak custom cipher**: Break via cryptanalysis (frequency, known-plaintext)
2. **Hardcoded key**: Extract from .data section
3. **Weak RNG**: Predict key from time-based or constant seed
4. **Standard crypto, weak key**: Brute-force small keyspace
5. **Implementation bug**: Exploit logic error to bypass crypto
6. **Obfuscated sta