/ctf-rev

name: ctf-rev
description: Solve CTF reverse engineering challenges using systematic analysis to find flags, keys, or passwords. Use for crackmes, binary bombs, key validators, obfuscated code, algorithm recovery, or any challenge requiring program comprehension to extract hidden information.

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. Refe