Initial commit
This commit is contained in:
Zhongwei Li
323
skills/ctf-crypto/SKILL.md
Normal file
323
skills/ctf-crypto/SKILL.md
Normal file
@@ -0,0 +1,323 @@
|
||||
---
|
||||
name: ctf-crypto
|
||||
description: Solve CTF cryptography challenges by identifying, analyzing, and exploiting weak crypto implementations in binaries to extract keys or decrypt data. Use for custom ciphers, weak crypto, key extraction, or algorithm identification.
|
||||
---
|
||||
|
||||
# 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**:
|
||||
- `search-strings-regex` for crypto keywords
|
||||
- `get-strings-by-similarity` 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 standard**: Recognize despite code obfuscation
|
||||
|
||||
**What CTF crypto is NOT**:
|
||||
- Pure mathematical cryptanalysis (breaking AES-256 mathematically)
|
||||
- Side-channel attacks on hardware (timing, power analysis)
|
||||
- Network protocol attacks (though may combine with binary crypto)
|
||||
- Breaking modern TLS/SSL implementations
|
||||
|
||||
### Time Management
|
||||
|
||||
**Prioritize based on difficulty**:
|
||||
1. Hardcoded keys (minutes): Search .data, extract bytes
|
||||
2. Weak RNG (10-15 min): Analyze seed, predict sequence
|
||||
3. Simple custom cipher (20-30 min): Frequency analysis, known-plaintext
|
||||
4. Implementation bugs (15-30 min): Find logic errors, test edge cases
|
||||
5. Complex custom cipher (30-60 min): Full reverse engineering and breaking
|
||||
|
||||
**Know when to move on**: If you've spent 30 minutes without progress, step back and reassess or try a different challenge.
|
||||
|
||||
## Tool Usage Patterns
|
||||
|
||||
### Discovery Phase
|
||||
```
|
||||
search-strings-regex pattern="(AES|RSA|encrypt|decrypt|crypto|cipher|key)"
|
||||
get-symbols includeExternal=true → Check for crypto API imports
|
||||
search-decompilation pattern="(xor|sbox|round|block)"
|
||||
```
|
||||
|
||||
### Analysis Phase
|
||||
```
|
||||
get-decompilation includeIncomingReferences=true includeReferenceContext=true
|
||||
find-cross-references direction="both" includeContext=true
|
||||
read-memory at suspected key/S-box locations
|
||||
```
|
||||
|
||||
### Improvement Phase
|
||||
```
|
||||
rename-variables: {"var_1": "key", "var_2": "plaintext", "var_3": "sbox"}
|
||||
change-variable-datatypes: {"key": "uint8_t*", "block": "uint8_t[16]"}
|
||||
apply-data-type: uint8_t[256] to S-box constants
|
||||
set-decompilation-comment: Document crypto operations
|
||||
```
|
||||
|
||||
### Documentation Phase
|
||||
```
|
||||
set-bookmark type="Analysis" category="Crypto" → Mark crypto functions
|
||||
set-bookmark type="Note" category="Key" → Mark key locations
|
||||
set-comment → Document assumptions and findings
|
||||
```
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### After Binary Triage
|
||||
If binary-triage identified crypto indicators, start investigation at bookmarked locations:
|
||||
```
|
||||
search-bookmarks type="Warning" category="Crypto"
|
||||
search-bookmarks type="TODO" category="Crypto"
|
||||
```
|
||||
|
||||
### With Deep Analysis
|
||||
Use deep-analysis investigation loop for systematic crypto function analysis:
|
||||
- READ → Get decompilation
|
||||
- UNDERSTAND → Match to crypto patterns
|
||||
- IMPROVE → Rename/retype for clarity
|
||||
- VERIFY → Re-read to confirm
|
||||
- FOLLOW → Trace key sources
|
||||
- TRACK → Document findings
|
||||
|
||||
### Standalone Usage
|
||||
User explicitly asks about crypto:
|
||||
- "What encryption is used?"
|
||||
- "Find the hardcoded key"
|
||||
- "How does the custom cipher work?"
|
||||
- "Extract the encryption key"
|
||||
|
||||
## Output Format
|
||||
|
||||
Return structured findings:
|
||||
|
||||
```
|
||||
Crypto Analysis Summary:
|
||||
- Algorithm: [Identified algorithm or "custom cipher"]
|
||||
- Confidence: [high/medium/low]
|
||||
- Key Size: [bits/bytes]
|
||||
- Mode: [ECB, CBC, CTR, etc. if applicable]
|
||||
|
||||
Evidence:
|
||||
- [Specific addresses, constants, code patterns]
|
||||
|
||||
Key Material:
|
||||
- Location: [address of key]
|
||||
- Source: [hardcoded/derived/user-input]
|
||||
- Value: [key bytes if extracted]
|
||||
|
||||
Weaknesses Found:
|
||||
- [List of exploitable weaknesses]
|
||||
|
||||
Exploitation Strategy:
|
||||
- [How to break/bypass crypto to get flag]
|
||||
|
||||
Database Improvements:
|
||||
- [Variables renamed, types fixed, comments added]
|
||||
|
||||
Unanswered Questions:
|
||||
- [Further investigation needed]
|
||||
```
|
||||
|
||||
## Remember
|
||||
|
||||
- **Generic approach**: Apply conceptual framework to any crypto implementation
|
||||
- **Pattern matching**: Use patterns.md for algorithm recognition
|
||||
- **Implementation focus**: Look for weaknesses in implementation, not mathematical breaks
|
||||
- **Key extraction**: Most CTF challenges have extractable or derivable keys
|
||||
- **Document as you go**: Crypto analysis benefits from clear variable naming
|
||||
- **Time-box your work**: Don't spend hours on cryptanalysis if key extraction is simpler
|
||||
- **Test assumptions**: Verify your understanding by replicating crypto logic
|
||||
|
||||
Your goal is to **extract the flag**, not to become a cryptographer. Use implementation weaknesses, not mathematical attacks.
|
||||
630
skills/ctf-crypto/patterns.md
Normal file
630
skills/ctf-crypto/patterns.md
Normal file
@@ -0,0 +1,630 @@
|
||||
# Cryptographic Pattern Recognition Reference
|
||||
|
||||
This document provides pattern recognition guides for identifying and analyzing cryptographic implementations in compiled binaries. These patterns are generic and apply across different algorithms - focus on conceptual characteristics, not specific implementations.
|
||||
|
||||
## General Crypto Recognition
|
||||
|
||||
### Crypto Presence Indicators
|
||||
|
||||
**High-confidence indicators:**
|
||||
- Crypto-related strings: "encrypt", "decrypt", "cipher", "AES", "RSA", "key", "hash"
|
||||
- Crypto library imports: CryptEncrypt, OpenSSL functions, libcrypto
|
||||
- Large constant arrays (256+ bytes) with seemingly random data
|
||||
- Heavy use of XOR operations
|
||||
- Bitwise rotation patterns: `(x << n) | (x >> (32-n))`
|
||||
- Fixed iteration counts (rounds): 8, 10, 12, 14, 16, 32, 64, 80
|
||||
- Modular arithmetic on large integers
|
||||
|
||||
**Medium-confidence indicators:**
|
||||
- Nested loops with array manipulations
|
||||
- Byte-level array indexing patterns
|
||||
- S-box style lookups: `output = table[input]`
|
||||
- State transformation in fixed-size blocks
|
||||
|
||||
**What to check:**
|
||||
```
|
||||
search-strings-regex pattern="(encrypt|decrypt|crypto|cipher|AES|DES|RSA|RC4|key|hash|salt|iv)"
|
||||
get-symbols includeExternal=true → Look for crypto API imports
|
||||
search-decompilation pattern="(xor|sbox|round|permut)"
|
||||
```
|
||||
|
||||
## Block Cipher Patterns
|
||||
|
||||
### Conceptual Characteristics
|
||||
|
||||
**Core concept**: Transform fixed-size data blocks through multiple rounds of substitution and permutation.
|
||||
|
||||
**Key identifying features:**
|
||||
1. **Fixed block size**: Data processed in chunks (64 bits, 128 bits, etc.)
|
||||
2. **Round structure**: Outer loop with fixed iteration count
|
||||
3. **Substitution**: Table lookups (S-boxes) replacing input bytes
|
||||
4. **Permutation**: Bit shuffling, rotation, mixing operations
|
||||
5. **Key schedule**: Function deriving per-round keys from master key
|
||||
|
||||
**Generic code structure:**
|
||||
```c
|
||||
// Simplified conceptual pattern
|
||||
void block_cipher_encrypt(uint8_t* data, uint8_t* key) {
|
||||
uint8_t round_keys[NUM_ROUNDS][KEY_SIZE];
|
||||
generate_round_keys(key, round_keys);
|
||||
|
||||
for (int round = 0; round < NUM_ROUNDS; round++) {
|
||||
substitute_bytes(data); // S-box lookups
|
||||
permute_bits(data); // Bit shuffling
|
||||
mix_columns(data); // Linear transformation
|
||||
add_round_key(data, round_keys[round]); // XOR with round key
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Substitution-Permutation Network (SPN)
|
||||
|
||||
**What it is**: Most modern block ciphers (AES, PRESENT, etc.)
|
||||
|
||||
**Recognition pattern:**
|
||||
```
|
||||
Loop structure:
|
||||
for round in 0..NUM_ROUNDS:
|
||||
1. SubBytes (S-box lookup)
|
||||
2. ShiftRows/PermuteBits (positional change)
|
||||
3. MixColumns (linear transformation)
|
||||
4. AddRoundKey (XOR with round key)
|
||||
|
||||
Characteristics:
|
||||
- Large constant arrays (S-boxes, typically 256 bytes)
|
||||
- Heavy XOR usage
|
||||
- Byte/word array indexing
|
||||
- State array (16+ bytes)
|
||||
```
|
||||
|
||||
**AES-specific signatures:**
|
||||
- S-box starting: 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5...
|
||||
- Round counts: 10 (AES-128), 12 (AES-192), 14 (AES-256)
|
||||
- 128-bit state (16 bytes, often as 4x4 matrix)
|
||||
- Rcon (round constant) array for key expansion
|
||||
|
||||
**DES-specific signatures:**
|
||||
- 64-bit blocks (8 bytes)
|
||||
- 16 rounds
|
||||
- Permutation tables (IP, FP)
|
||||
- S-box arrays (8 boxes of 64 entries each)
|
||||
- Feistel structure (see below)
|
||||
|
||||
### Feistel Network
|
||||
|
||||
**What it is**: Older block cipher design (DES, Blowfish, TEA)
|
||||
|
||||
**Recognition pattern:**
|
||||
```
|
||||
Loop structure:
|
||||
Split data into left and right halves
|
||||
for round in 0..NUM_ROUNDS:
|
||||
temp = right
|
||||
right = left XOR F(right, round_key[round])
|
||||
left = temp
|
||||
Swap and combine halves
|
||||
|
||||
Characteristics:
|
||||
- Data split in half
|
||||
- Swap operation each round
|
||||
- F-function (round function) operating on half the data
|
||||
- Other half XORed with F-function output
|
||||
```
|
||||
|
||||
**Telltale code patterns:**
|
||||
```c
|
||||
// Feistel structure
|
||||
uint32_t left = data[0];
|
||||
uint32_t right = data[1];
|
||||
|
||||
for (int i = 0; i < rounds; i++) {
|
||||
uint32_t temp = right;
|
||||
right = left ^ f_function(right, key[i]);
|
||||
left = temp;
|
||||
}
|
||||
```
|
||||
|
||||
### Block Cipher Investigation Strategy
|
||||
|
||||
1. **Count rounds**: Outer loop iterations → Indicates cipher type and key size
|
||||
2. **Measure block size**: How much data processed per iteration → 64-bit (DES) or 128-bit (AES)
|
||||
3. **Identify S-boxes**: Large constant arrays → `read-memory` and compare to known S-boxes
|
||||
4. **Check key schedule**: Look for function deriving multiple round keys from master key
|
||||
5. **Recognize structure**: SPN (parallel operations) vs Feistel (swap pattern)
|
||||
|
||||
**Useful tools:**
|
||||
```
|
||||
get-decompilation limit=50 includeIncomingReferences=true
|
||||
read-memory at constant array addresses
|
||||
rename-variables: var_1 → sbox, var_2 → state, var_3 → round_key
|
||||
```
|
||||
|
||||
## Stream Cipher Patterns
|
||||
|
||||
### Conceptual Characteristics
|
||||
|
||||
**Core concept**: Generate pseudo-random keystream from key, then XOR with plaintext.
|
||||
|
||||
**Key identifying features:**
|
||||
1. **State-based generation**: Internal state evolves to produce keystream bytes
|
||||
2. **Simple combination**: `ciphertext = plaintext XOR keystream`
|
||||
3. **No fixed blocks**: Can encrypt arbitrary lengths
|
||||
4. **Smaller code**: Less complex than block ciphers (no large S-boxes)
|
||||
5. **Initialization**: State setup from key (KSA - Key Scheduling Algorithm)
|
||||
|
||||
**Generic code structure:**
|
||||
```c
|
||||
// Simplified conceptual pattern
|
||||
void stream_cipher(uint8_t* data, size_t len, uint8_t* key) {
|
||||
uint8_t state[STATE_SIZE];
|
||||
initialize_state(state, key); // KSA
|
||||
|
||||
for (size_t i = 0; i < len; i++) {
|
||||
uint8_t keystream_byte = generate_next_byte(state); // PRGA
|
||||
data[i] ^= keystream_byte;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### RC4 Pattern (Most Common in CTFs)
|
||||
|
||||
**Recognition pattern:**
|
||||
```
|
||||
Initialization (KSA):
|
||||
state = [0, 1, 2, ..., 255] // 256-byte array
|
||||
j = 0
|
||||
for i in 0..255:
|
||||
j = (j + state[i] + key[i % key_len]) % 256
|
||||
swap(state[i], state[j])
|
||||
|
||||
Keystream generation (PRGA):
|
||||
i = 0; j = 0
|
||||
for each byte:
|
||||
i = (i + 1) % 256
|
||||
j = (j + state[i]) % 256
|
||||
swap(state[i], state[j])
|
||||
keystream_byte = state[(state[i] + state[j]) % 256]
|
||||
output ^= keystream_byte
|
||||
```
|
||||
|
||||
**Telltale signs:**
|
||||
- 256-byte state array
|
||||
- Swap operations: `temp = a[i]; a[i] = a[j]; a[j] = temp`
|
||||
- Modulo 256 (`% 256` or `& 0xFF`)
|
||||
- Index computations with running totals
|
||||
- Two-phase structure (init, then generate)
|
||||
|
||||
### ChaCha/Salsa Pattern
|
||||
|
||||
**Recognition pattern:**
|
||||
- 512-bit state (16 words of 32 bits)
|
||||
- Quarter-round function (ARX: Add-Rotate-XOR)
|
||||
- Magic constants: "expand 32-byte k" or "expand 16-byte k"
|
||||
- 20 rounds (10 double-rounds) for ChaCha20
|
||||
- Heavy use of 32-bit rotation
|
||||
|
||||
### Stream Cipher Investigation Strategy
|
||||
|
||||
1. **Find state initialization**: Look for array setup from key
|
||||
2. **Identify update function**: How state evolves (swap, ARX, LCG, etc.)
|
||||
3. **Locate XOR operation**: Simple `output = input ^ keystream`
|
||||
4. **Check for reuse**: Is same keystream used multiple times? (weakness)
|
||||
5. **Analyze state size**: 256 bytes (RC4), 64 bytes (ChaCha), variable (custom)
|
||||
|
||||
**Useful tools:**
|
||||
```
|
||||
search-decompilation pattern="swap|xor"
|
||||
get-decompilation to see state evolution loop
|
||||
rename-variables: var_1 → state, var_2 → keystream, var_3 → index
|
||||
```
|
||||
|
||||
## Public Key Cryptography Patterns
|
||||
|
||||
### Conceptual Characteristics
|
||||
|
||||
**Core concept**: Asymmetric encryption using mathematical trapdoor functions.
|
||||
|
||||
**Key identifying features:**
|
||||
1. **Large integer arithmetic**: Numbers hundreds or thousands of bits
|
||||
2. **Modular exponentiation**: `result = base^exponent mod modulus`
|
||||
3. **Very slow**: Orders of magnitude slower than symmetric crypto
|
||||
4. **Multi-precision arithmetic**: Arrays representing big integers
|
||||
|
||||
**Generic code structure:**
|
||||
```c
|
||||
// Simplified modular exponentiation (square-and-multiply)
|
||||
bigint modexp(bigint base, bigint exponent, bigint modulus) {
|
||||
bigint result = 1;
|
||||
while (exponent > 0) {
|
||||
if (exponent & 1) {
|
||||
result = (result * base) % modulus; // Multiply
|
||||
}
|
||||
base = (base * base) % modulus; // Square
|
||||
exponent >>= 1;
|
||||
}
|
||||
return result;
|
||||
}
|
||||
```
|
||||
|
||||
### RSA Pattern
|
||||
|
||||
**Recognition pattern:**
|
||||
```
|
||||
Key components:
|
||||
- Large modulus N (1024, 2048, 4096+ bits)
|
||||
- Public exponent e (often 65537 = 0x10001)
|
||||
- Private exponent d
|
||||
|
||||
Encryption: c = m^e mod N
|
||||
Decryption: m = c^d mod N
|
||||
|
||||
Operations:
|
||||
- Modular exponentiation (square-and-multiply)
|
||||
- Multi-precision multiplication
|
||||
- Barrett or Montgomery reduction for modulo
|
||||
```
|
||||
|
||||
**Telltale signs:**
|
||||
- Very large buffers (128, 256, 512 bytes+)
|
||||
- Magic constant 0x10001 (common RSA public exponent)
|
||||
- Bit-by-bit processing of exponent
|
||||
- Slow execution (many iterations)
|
||||
- Functions for add/subtract/multiply on arrays
|
||||
|
||||
### Elliptic Curve Pattern
|
||||
|
||||
**Recognition pattern:**
|
||||
- Point addition/doubling operations
|
||||
- Affine or projective coordinates (x, y) or (x, y, z)
|
||||
- Field arithmetic (modular arithmetic over prime field)
|
||||
- Curve parameters (a, b, p, G, n)
|
||||
- Scalar multiplication (point added to itself k times)
|
||||
|
||||
### Public Key Investigation Strategy
|
||||
|
||||
1. **Identify big integer operations**: Look for array-based arithmetic
|
||||
2. **Find exponentiation pattern**: Square-and-multiply loop
|
||||
3. **Extract parameters**: Modulus, exponent values from constants
|
||||
4. **Check key size**: Buffer sizes indicate security level
|
||||
5. **Look for weak parameters**: Small exponents, factorable moduli (CTF tricks)
|
||||
|
||||
**CTF-specific weaknesses:**
|
||||
- Small modulus (factorizable)
|
||||
- Small private exponent (Wiener's attack)
|
||||
- Reused primes across multiple keys
|
||||
- Textbook RSA (no padding, malleable)
|
||||
|
||||
## Hash Function Patterns
|
||||
|
||||
### Conceptual Characteristics
|
||||
|
||||
**Core concept**: One-way compression of arbitrary data to fixed-size digest.
|
||||
|
||||
**Key identifying features:**
|
||||
1. **Initialization constants**: Fixed magic numbers unique to algorithm
|
||||
2. **Block processing**: Data processed in chunks (512 bits typical)
|
||||
3. **State accumulation**: Running state updated with each block
|
||||
4. **Padding**: Append bits to make input multiple of block size
|
||||
5. **Heavy mixing**: Lots of bitwise operations (irreversible)
|
||||
|
||||
**Generic code structure:**
|
||||
```c
|
||||
// Simplified hash structure
|
||||
void hash(uint8_t* data, size_t len, uint8_t* digest) {
|
||||
uint32_t state[STATE_SIZE];
|
||||
initialize_state(state); // Magic constants
|
||||
|
||||
// Process each block
|
||||
for (each block in data) {
|
||||
process_block(state, block); // Compression function
|
||||
}
|
||||
|
||||
finalize(state, digest); // Output transformation
|
||||
}
|
||||
```
|
||||
|
||||
### MD5/SHA Recognition
|
||||
|
||||
**MD5 initialization constants:**
|
||||
```c
|
||||
state[0] = 0x67452301;
|
||||
state[1] = 0xefcdab89;
|
||||
state[2] = 0x98badcfe;
|
||||
state[3] = 0x10325476;
|
||||
```
|
||||
|
||||
**SHA-1 initialization constants:**
|
||||
```c
|
||||
state[0] = 0x67452301;
|
||||
state[1] = 0xefcdab89;
|
||||
state[2] = 0x98badcfe;
|
||||
state[3] = 0x10325476;
|
||||
state[4] = 0xc3d2e1f0;
|
||||
```
|
||||
|
||||
**SHA-256 initialization constants:**
|
||||
```c
|
||||
// First 32 bits of fractional parts of square roots of first 8 primes
|
||||
state[0] = 0x6a09e667;
|
||||
state[1] = 0xbb67ae85;
|
||||
state[2] = 0x3c6ef372;
|
||||
// ... 5 more
|
||||
```
|
||||
|
||||
**Telltale signs:**
|
||||
- Characteristic initialization constants (search for these!)
|
||||
- Fixed round counts: 64 (MD5, SHA-256), 80 (SHA-1, SHA-512)
|
||||
- Bitwise rotations: `(x << n) | (x >> (32-n))`
|
||||
- Message schedule expansion (W array)
|
||||
- Mixing functions (F, G, H functions in MD5)
|
||||
|
||||
### Hash Investigation Strategy
|
||||
|
||||
1. **Search for magic constants**: Hash functions have unique initializers
|
||||
2. **Count rounds**: 64 or 80 iterations → Specific hash function
|
||||
3. **Check block size**: 512 bits (MD5, SHA-1, SHA-256) or 1024 bits (SHA-512)
|
||||
4. **Identify mixing operations**: AND, OR, XOR, NOT, rotation patterns
|
||||
5. **Find padding logic**: Append 0x80, then zeros, then length
|
||||
|
||||
**Useful tools:**
|
||||
```
|
||||
search-decompilation pattern="0x67452301|0xefcdab89|0x98badcfe"
|
||||
get-decompilation to see round structure
|
||||
read-memory at initialization constants
|
||||
```
|
||||
|
||||
## Simple Obfuscation Patterns
|
||||
|
||||
### XOR Cipher
|
||||
|
||||
**What it is**: Trivial encryption used for obfuscation, not security.
|
||||
|
||||
**Recognition pattern:**
|
||||
```
|
||||
Single-byte key:
|
||||
for (i = 0; i < len; i++)
|
||||
data[i] ^= 0x42; // Fixed constant
|
||||
|
||||
Multi-byte key:
|
||||
for (i = 0; i < len; i++)
|
||||
data[i] ^= key[i % keylen]; // Repeating key
|
||||
|
||||
Rolling key (LCG-based):
|
||||
key = seed;
|
||||
for (i = 0; i < len; i++) {
|
||||
data[i] ^= key;
|
||||
key = (key * A + C) % M; // Linear congruential generator
|
||||
}
|
||||
```
|
||||
|
||||
**Telltale signs:**
|
||||
- Very short functions (5-10 lines)
|
||||
- XOR with constants or simple patterns
|
||||
- Often applied to strings or config data
|
||||
- No complex state or multiple rounds
|
||||
|
||||
**Breaking approach:**
|
||||
- Single-byte: Brute-force (256 possibilities)
|
||||
- Multi-byte: Frequency analysis or known-plaintext
|
||||
- Rolling key: If LCG parameters known, reproduce sequence
|
||||
|
||||
### Substitution Cipher
|
||||
|
||||
**Recognition pattern:**
|
||||
```
|
||||
Simple substitution:
|
||||
for (i = 0; i < len; i++)
|
||||
output[i] = substitution_table[input[i]];
|
||||
|
||||
Caesar cipher (special case):
|
||||
for (i = 0; i < len; i++)
|
||||
output[i] = (input[i] + shift) % 256;
|
||||
```
|
||||
|
||||
**Breaking approach:**
|
||||
- Frequency analysis (if sufficient ciphertext)
|
||||
- Known-plaintext attack
|
||||
- Brute-force substitution table
|
||||
|
||||
### Custom Cipher Pattern
|
||||
|
||||
**What it is**: Challenge-specific encryption scheme not based on standards.
|
||||
|
||||
**Recognition indicators:**
|
||||
- No match to known crypto patterns
|
||||
- Unusual operations or data flow
|
||||
- Mix of arithmetic, XOR, bit shifts in non-standard way
|
||||
- Often simpler than real crypto (for solvability)
|
||||
|
||||
**Investigation strategy:**
|
||||
1. **Document operations**: What transformations are applied, in what order?
|
||||
2. **Identify invertibility**: Can operations be reversed?
|
||||
3. **Look for weaknesses**:
|
||||
- Reduced keyspace (brute-forceable)
|
||||
- Linear operations (algebraically solvable)
|
||||
- Repeated patterns (exploitable structure)
|
||||
4. **Known-plaintext**: If you have plaintext-ciphertext pairs, work backwards
|
||||
5. **Replicate in Python**: Reproduce encryption logic, then reverse it
|
||||
|
||||
**Common CTF custom cipher weaknesses:**
|
||||
- Insufficient mixing (partially recoverable plaintext)
|
||||
- Weak key derivation (predictable)
|
||||
- Reversible operations (decrypt by inverting)
|
||||
- Small state space (brute-forceable)
|
||||
|
||||
## Recognition Workflow
|
||||
|
||||
### Step 1: Initial Detection
|
||||
```
|
||||
1. Search for crypto strings
|
||||
search-strings-regex pattern="(encrypt|decrypt|aes|rsa|md5|sha|key)"
|
||||
|
||||
2. Check for crypto API imports
|
||||
get-symbols includeExternal=true → Look for OpenSSL, Windows Crypto API
|
||||
|
||||
3. Search for crypto patterns in code
|
||||
search-decompilation pattern="(xor|sbox|round)"
|
||||
```
|
||||
|
||||
### Step 2: Pattern Matching
|
||||
```
|
||||
4. Get decompilation of suspected function
|
||||
get-decompilation includeIncomingReferences=true
|
||||
|
||||
5. Compare to pattern categories:
|
||||
- Block cipher? (rounds, S-boxes, fixed blocks)
|
||||
- Stream cipher? (state, swap, XOR)
|
||||
- Hash? (magic constants, compression)
|
||||
- Public key? (big integers, modexp)
|
||||
- Simple obfuscation? (short, simple XOR)
|
||||
```
|
||||
|
||||
### Step 3: Detailed Analysis
|
||||
```
|
||||
6. Read constant arrays
|
||||
read-memory at suspected S-box/constant locations
|
||||
|
||||
7. Compare to known values
|
||||
- AES S-box: 63 7c 77 7b...
|
||||
- MD5 init: 67452301 efcdab89...
|
||||
- RSA exponent: 0x10001
|
||||
|
||||
8. Count iterations
|
||||
- 10/12/14 rounds → AES
|
||||
- 16 rounds → DES
|
||||
- 64/80 rounds → Hash function
|
||||
```
|
||||
|
||||
### Step 4: Verification
|
||||
```
|
||||
9. Rename variables for clarity
|
||||
rename-variables: var_1 → sbox, var_2 → key, var_3 → state
|
||||
|
||||
10. Document findings
|
||||
set-bookmark type="Analysis" category="Crypto"
|
||||
set-decompilation-comment line=N "AES encryption round"
|
||||
|
||||
11. Cross-check with usage
|
||||
find-cross-references → See where crypto is called, what data it processes
|
||||
```
|
||||
|
||||
## CTF-Specific Patterns
|
||||
|
||||
### Key Management Anti-Patterns
|
||||
|
||||
**Hardcoded keys (most common):**
|
||||
```c
|
||||
uint8_t key[] = {0x41, 0x42, 0x43, ...}; // Key in .data section
|
||||
encrypt(data, key);
|
||||
```
|
||||
**Finding**: `read-memory` at key array address
|
||||
|
||||
**Weak derivation:**
|
||||
```c
|
||||
// Time-based (predictable)
|
||||
srand(time(NULL));
|
||||
for (i = 0; i < keylen; i++)
|
||||
key[i] = rand() % 256;
|
||||
|
||||
// Constant seed (always same key)
|
||||
srand(12345);
|
||||
...
|
||||
```
|
||||
**Finding**: Analyze RNG initialization, predict or replicate
|
||||
|
||||
**User input as key (brute-force candidate):**
|
||||
```c
|
||||
scanf("%s", key); // Short password
|
||||
if (strlen(key) < 8) ...
|
||||
```
|
||||
**Finding**: Small keyspace, brute-forceable
|
||||
|
||||
### Implementation Bugs to Exploit
|
||||
|
||||
**ECB mode (block patterns visible):**
|
||||
```c
|
||||
for (i = 0; i < len; i += BLOCK_SIZE)
|
||||
encrypt_block(data + i, key); // No chaining
|
||||
```
|
||||
**Weakness**: Identical plaintext blocks → identical ciphertext blocks
|
||||
|
||||
**IV reuse or zero IV:**
|
||||
```c
|
||||
uint8_t iv[16] = {0}; // Should be random!
|
||||
```
|
||||
**Weakness**: Breaks CBC security, enables attacks
|
||||
|
||||
**Reduced rounds (weak variant):**
|
||||
```c
|
||||
#define ROUNDS 4 // Should be 10+ for AES
|
||||
```
|
||||
**Weakness**: May be breakable with cryptanalysis tools
|
||||
|
||||
**Debug backdoor:**
|
||||
```c
|
||||
if (strcmp(password, "DEBUG") == 0)
|
||||
return decrypt_without_key(data);
|
||||
```
|
||||
**Finding**: Search for debug strings, test/admin backdoors
|
||||
|
||||
## Using This Reference
|
||||
|
||||
### Quick Lookup Process
|
||||
|
||||
1. **Identify general category**: Block/stream/hash/public-key/simple
|
||||
2. **Match to specific pattern**: Compare code structure to examples
|
||||
3. **Verify with evidence**: Check constants, round counts, operations
|
||||
4. **Document in Ghidra**: Rename, retype, comment for clarity
|
||||
5. **Investigate weaknesses**: Look for CTF-specific anti-patterns
|
||||
|
||||
### Example Investigation Flow
|
||||
|
||||
```
|
||||
Observation: Function with loop, array access, XOR
|
||||
|
||||
1. Compare to patterns:
|
||||
- Block cipher? (Check for S-boxes, rounds)
|
||||
- Stream cipher? (Check for swap, state evolution)
|
||||
- Simple XOR? (Check function length)
|
||||
|
||||
2. Verify:
|
||||
- Read memory at constant array (if exists)
|
||||
- Count loop iterations
|
||||
- Check for characteristic operations
|
||||
|
||||
3. Identify:
|
||||
- Found 256-byte array with specific pattern
|
||||
- Swap operations in initialization
|
||||
- Simple XOR in second phase
|
||||
|
||||
4. Conclude: RC4 stream cipher
|
||||
|
||||
5. Improve:
|
||||
rename-variables: state, keystream, plaintext
|
||||
set-comment: "RC4 encryption with hardcoded key"
|
||||
|
||||
6. Exploit:
|
||||
Extract key from initialization
|
||||
Replicate RC4 in Python to decrypt
|
||||
```
|
||||
|
||||
### Progressive Refinement
|
||||
|
||||
**First pass**: "This looks like crypto (XOR, loops, constants)"
|
||||
**Second pass**: "Probably a block cipher (rounds, S-box pattern)"
|
||||
**Third pass**: "Matches AES pattern (S-box signature, 10/12/14 rounds)"
|
||||
**Fourth pass**: "AES-128 with hardcoded key at 0x405000"
|
||||
**Fifth pass**: "Extracted key, successfully decrypted flag"
|
||||
|
||||
Each pass narrows down understanding and guides next investigation steps.
|
||||
|
||||
## Remember
|
||||
|
||||
- **Patterns are guidelines**, not rigid rules - CTF challenges may have variations
|
||||
- **Constants are your friends** - Magic numbers uniquely identify algorithms
|
||||
- **Structure reveals intent** - Loop patterns indicate algorithm type
|
||||
- **CTF crypto is about implementation** - Look for weaknesses, not mathematical breaks
|
||||
- **Document as you learn** - Rename variables to reflect your understanding
|
||||
- **Verify with evidence** - Don't guess - compare constants, count rounds, check operations
|
||||
|
||||
Use this reference alongside the conceptual framework in SKILL.md to systematically identify and analyze cryptographic implementations.
|
||||
Reference in New Issue
Block a user