ctf-rev

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 81890607feb9 · 21 Oct 2026Report an issue or request a re-scan

• Publishercyberkaida GitHub userOwner of the repository this skill is read from
• Source foldercyberkaida/reverse-engineering-assistant/ReVa/skills/ctf-revThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict81890607feb9A new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its 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…

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

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/cyberkaida/reverse-engineering-assistant
git -C reverse-engineering-assistant checkout 81890607feb9

Works in

1. 2026-10-21
   ✓SAFE B 89 / 100

   first audit · source 81890607feb9

Questions about ctf-rev

• github.com/cyberkaida/reverse-engineering-assistant/tree/main/Re — the audited source at commit 81890607feb9 and every finding aboveObserved · 21 Oct 2026

Spotted something wrong? Report a correction · Methodology