CTF Reverse

Analyze and solve reverse engineering challenges.

When to Use

Use this command for challenges involving:

• ELF/PE binaries requiring analysis
• Algorithm understanding
• Key/password finding
• Malware analysis
• Obfuscated code

Bundled Scripts

• check-tools.sh — Verify required reversing tools are installed
• run-radare2.sh — Initial binary analysis with structured output. Lists functions, strings, and flags interesting functions (main, flag, win, check, verify, password, secret). Outputs JSON with function list and analysis suggestions.

Instructions

1. First check tool availability: bash scripts/check-tools.sh

2. Start with radare2 analysis (outputs structured JSON):

   bash scripts/run-radare2.sh $ARGUMENTS
   bash scripts/run-radare2.sh <binary> main    # disassemble specific function

   JSON output includes:

   • functions[]: all functions with address, size, name
   • interesting_functions[]: functions matching CTF keywords (main, flag, win, check, verify, password, secret, decrypt)
   • strings[]: strings found in binary
   • info: binary metadata (arch, format, etc.)
3. Based on JSON findings, focus analysis:
   • interesting_functions found → decompile them: r2 -c "aa; pdc @ <function>" <binary>
   • Strings with flag patterns → trace cross-references
   • Multiple check/verify functions → trace validation logic

4. For different binary types:

   ELF (Linux): Use radare2 or Ghidra for analysis PE (Windows): Check for .NET (use dnSpy) Java/Android: jadx app.jar or jadx app.apk Python: uncompyle6 file.pyc or pycdc file.pyc

Analysis Workflow

1. run-radare2.sh binary → identify interesting functions from JSON
2. Decompile target functions → understand algorithm
3. Write keygen or patch binary
4. Test solution

Common Patterns

macOS / Apple Silicon

For dynamic analysis of Linux ELF binaries on macOS, use the pwn skill's container wrapper ../pwn/scripts/pwn-docker.sh. ltrace/strace and plain gdb do not work under emulation; debug via qemu-x86_64 -g 1234 ./binary + pwndbg -ex 'target remote :1234' ./binary and trace syscalls with qemu-x86_64 -strace ./binary.

Team Roles

When using /ctf-kit:team-solve with a reverse engineering challenge, the lead spawns 3 specialists:

Workflow coordination

Reverse engineering has a natural pipeline:

1. Static analyst maps the binary → identifies key functions and algorithm structure
2. Dynamic analyst confirms behavior → finds actual values, bypasses anti-debug
3. Algorithm solver writes the solution → uses both static and dynamic findings

But all 3 can start in parallel — static and dynamic analysis are independent.

When to broadcast

• Static: "Main calls check_password() which XORs input with key at 0x4020" — algo solver starts reimplementing
• Dynamic: "strcmp compares against runtime-computed string, anti-debug detected (ptrace)" — static analyst looks for the check
• Algo solver: "Constraint solver found valid input: PASSWORD" — others verify
• Any: "Found the flag" — immediate broadcast, all stop

Example Usage

/ctf-kit:reverse ./crackme
/ctf-kit:reverse ./challenge.exe
/ctf-kit:reverse app.apk