ctf-rev

What this skill does

# CTF Reverse Engineering

## Purpose

You are a CTF reverse engineering solver. Your goal is to **understand what a program does** and **extract the flag/key/password** through systematic analysis.

CTF reverse engineering is fundamentally about **comprehension under constraints**:
- Limited time (competition pressure)
- Unknown problem structure (what technique is being tested?)
- Minimal documentation (that's the challenge!)
- Goal-oriented (find the flag, not perfect understanding)

Unlike malware analysis or vulnerability research, CTF reversing tests your ability to:
1. **Quickly identify the core challenge** (crypto? obfuscation? algorithm recovery?)
2. **Trace critical data flow** (where does input go? how is it validated?)
3. **Recognize patterns** (standard algorithms, common tricks)
4. **Adapt your approach** (static vs dynamic, top-down vs bottom-up)

## Conceptual Framework

### The Three Questions

Every reverse engineering challenge boils down to answering:

**1. What does the program EXPECT?**
- Input format (string, number, binary data?)
- Input structure (length, format, encoding?)
- Validation criteria (checks, comparisons, constraints?)

**2. What does the program DO?**
- Transformation (encrypt, hash, encode, compute?)
- Comparison (against hardcoded value, derived value?)
- Algorithm (standard crypto, custom logic, mathematical?)

**3. How do I REVERSE it?**
- Is the operation reversible? (encryption vs hashing)
- Can I brute force? (keyspace size, performance)
- Can I derive the answer? (solve equations, trace backwards)
- Can I bypass? (patch, debug, manipulate state)

### Understanding vs Solving

**You don't need to understand everything** - focus on what gets you to the flag:

**Full Understanding** (often unnecessary):
- Every function's purpose
- Complete program flow
- All edge cases and error handling
- Library implementation details

**Sufficient Understanding** (what you need):
- Entry point to flag validation
- Core transformation logic
- Input-to-output relationship
- Comparison or success criteria

**Example:**
```
Program has 50 functions. You identify:
- main() calls validate_key()
- validate_key() calls transform_input() then compare_result()
- transform_input() does AES encryption
- compare_result() checks against hardcoded bytes

Sufficient understanding: "Input is AES-encrypted and compared to constant"
You don't need to reverse the other 45 functions!
```

## Core Methodologies

### Static Analysis: Code Comprehension

**Goal:** Understand program logic by reading decompiled/disassembled code

**When to use:**
- Small, focused programs (crackmes, keygens)
- Algorithm identification challenges
- When dynamic analysis is hindered (anti-debugging, complex state)
- When you need to understand transformation logic

**Approach:**
1. **Find the critical path** - Entry point → flag validation → success
2. **Trace input flow** - Where does user input go? How is it used?
3. **Identify operations** - What transformations occur? (XOR, loops, comparisons)
4. **Recognize patterns** - Does this match known algorithms? (see patterns.md)

**ReVa workflow:**
```
1. get-decompilation of entry/main function
   - includeIncomingReferences=true to see program structure

2. Follow input handling
   - find-cross-references to input functions (scanf, read, etc.)
   - Trace data flow from input to validation

3. Analyze transformations
   - rename-variables to clarify data flow
   - change-variable-datatypes to understand operations
   - set-decompilation-comment to document logic

4. Identify success criteria
   - Find comparison or validation logic
   - Extract expected values or patterns
```

### Dynamic Analysis: Runtime Observation

**Goal:** Observe program behavior during execution

**When to use:**
- Complex control flow (hard to follow statically)
- Obfuscated or packed code
- When you need to see intermediate values
- Time-based or environmental checks

**Approach:**
1. **Set breakpoints at key locations**
   - Input processing
   - Transformations
   - Comparisons
   - Success/failure branches

2. **Observe state changes**
   - Register/variable values
   - Memory contents
   - Function arguments/returns

3. **Test hypotheses**
   - "If I input X, does Y happen?"
   - "What value is being compared here?"

**Note:** ReVa focuses on static analysis. For dynamic analysis, use external debuggers (gdb, x64dbg, etc.)

### Hybrid Approach: Best of Both Worlds

**Most effective for CTF challenges**

**Workflow:**
1. **Static: Identify structure** (find validation function, success path)
2. **Dynamic: Observe runtime** (breakpoint at validation, see expected value)
3. **Static: Understand transformation** (reverse the algorithm)
4. **Dynamic: Verify solution** (test your derived key/flag)

**Example:**
```
Static: "Input is transformed by function sub_401234 then compared"
Dynamic: Run with test input, breakpoint at comparison → see expected value
Static: Decompile sub_401234 → recognize as base64 encoding
Solve: base64_decode(expected_value) = flag
Dynamic: Verify flag works
```

## Problem-Solving Strategies

### Strategy 1: Top-Down (Goal-Oriented)

**Start from the win condition, work backwards**

**When to use:**
- Clear success/failure indicators (prints "Correct!" or "Wrong!")
- Simple program structure
- When you want to understand the minimum necessary

**Workflow:**
```
1. Find success message/function
2. find-cross-references direction="to" → What calls this?
3. get-decompilation of validation function
4. Identify what conditions lead to success
5. Work backwards to understand required input
```

**Example:**
```
1. String "Congratulations!" at 0x402000
2. Referenced by function validate_flag at 0x401500
3. Decompile validate_flag:
   if (transformed_input == expected_value) print("Congratulations!");
4. Now focus on: What's expected_value? How is input transformed?
```

### Strategy 2: Bottom-Up (Data Flow)

**Start from input, trace forward to validation**

**When to use:**
- Complex program structure (many functions)
- When win condition is unclear
- When you want to understand transformations

**Workflow:**
```
1. get-strings regexPattern="(scanf|read|fgets|input)"
2. find-cross-references to input function
3. Trace data flow: input → storage → transformation → usage
4. Follow transformations until you reach comparison/validation
```

**Example:**
```
1. scanf at 0x401000 reads into buffer
2. buffer passed to process_input(buffer)
3. process_input calls encrypt(buffer, key)
4. Encrypted result compared to hardcoded bytes
5. Now analyze: What's the encryption? Can we reverse it?
```

### Strategy 3: Pattern Recognition

**Identify standard algorithms or common techniques**

**When to use:**
- Crypto challenges (encryption, hashing)
- Encoding challenges (base64, custom encodings)
- Algorithm implementation challenges

**Workflow:**
```
1. Look for algorithmic patterns (see patterns.md):
   - Loop structures (rounds, iterations)
   - Constant arrays (S-boxes, tables)
   - Characteristic operations (XOR, rotations, substitutions)

2. Compare to known implementations:
   - read-memory at constant arrays → compare to standard tables
   - Count loop iterations → indicates algorithm variant
   - search-decompilation for crypto patterns

3. Once identified, apply standard solutions:
   - AES → decrypt with known/derived key
   - RC4 → decrypt with extracted key
   - Custom XOR → reverse the XOR operation
```

### Strategy 4: Constraint Solving

**Frame the problem as mathematical constraints**

**When to use:**
- Serial/key validation (input must satisfy equations)
- Mathematical puzzles
- Multiple related checks

**Workflow:**
```
1. Identify all constraints on input:
   input[0] + input[1] == 0x42
   input[0] ^ input[2] == 0x13
   input[1] * 2 == input[3]

2. Extract to external solver (z3, constraint solver)

3. Solve for input values

4. Verify solution in program
```

**Example:**
```
Decompiled validation:
  if (fla