OverTheWire Bandit 0–14: What 15 Levels of CTF Taught Me About Linux

Apr 9, 2026 8 min

I’ve been wanting to get into cyber security for a while. The theory is interesting, but there’s a gap between reading about it and actually doing something. OverTheWire Bandit turned out to be the perfect starting point — a CTF wargame that teaches Linux fundamentals through progressively harder challenges.

I’ve just finished levels 0–14. This isn’t a walkthrough — no solutions, no passwords. Just the concepts I picked up and why they matter.

The Shell Will Trip You Up Before the Challenge Does

The first few levels aren’t really about security. They’re about learning that the shell has opinions about your input and will silently do the wrong thing if you don’t understand its rules.

A filename starting with - gets interpreted as a command flag. A filename with spaces in it gets split into multiple arguments. A file starting with . is hidden from ls. These aren’t tricks — they’re the shell doing exactly what it’s designed to do. The “trick” is knowing how the shell parses input.

The fix in every case: ./ prefix for dash problems, quotes or backslash escaping for spaces, -a flag to reveal hidden files. Once you understand why each problem exists, the solution is obvious.

Takeaway: Before you can hack anything, you need to understand how your own tools interpret what you type.

STDIN, STDOUT, STDERR — Everything Is a Stream

Unix has three standard streams: STDIN (0), STDOUT (1), and STDERR (2). Every command reads from STDIN and writes to STDOUT or STDERR. Pipes (|) connect one command’s STDOUT to the next command’s STDIN.

This concept unlocked a whole class of problems. Need to suppress error messages flooding your terminal? Redirect STDERR to /dev/null. Need to chain three commands together? Pipe them. Need to find a unique line in a file full of duplicates? sort | uniq -u — sort makes duplicates adjacent, then uniq -u filters to lines that appear exactly once.

The pipe pattern — small tools chained together — is the Unix philosophy in action. Each tool does one thing well. You compose them to solve complex problems.

Takeaway: Learn the streams. Once pipes click, you stop thinking in terms of individual commands and start thinking in terms of data flow.

file Is Your Compass

When you don’t know what you’re looking at, file tells you. It inspects the actual content of a file, ignoring the filename and extension entirely. A .txt file that’s actually gzip-compressed? file will tell you. A binary file hiding readable text? file flags it.

This became essential in the compression challenge — a file wrapped in multiple layers of different compression formats. The process was always the same: run file, identify the format, decompress, repeat. Without file, you’re guessing. With it, you always know the next step.

Takeaway: Never trust filenames. Trust file.

find vs grep — Searching for Different Things

Two search tools, two different purposes:

  • find searches for files by their properties — name, size, owner, permissions
  • grep searches inside files for text patterns

Knowing which one to reach for saves a lot of time. Looking for a file that’s exactly 1033 bytes and not executable? That’s find. Looking for the word “millionth” inside a data file? That’s grep.

find also has size units that will catch you out — c for bytes, k for kilobytes, b for 512-byte blocks (the default, which nobody expects). Getting the unit wrong means getting zero results and wondering why.

Takeaway: find for file properties, grep for file contents. And always specify c for bytes.

Encoding Is Not Encryption

Base64 decoding is a one-liner. ROT13 is a character substitution you can reverse with tr. Neither provides any security. They’re encoding schemes — designed for compatibility and transport, not confidentiality.

The distinction matters: encoding is reversible by design, no secret required. Encryption requires a key to reverse. If someone tells you their data is “encrypted” with base64, they’re wrong in a way that has consequences.

The == padding at the end of a string is a dead giveaway for base64. ROT13 is its own inverse — apply it twice and you get the original text back, because shifting 13 positions on a 26-letter alphabet wraps around perfectly.

Takeaway: Recognising encoding formats on sight is a useful skill. Don’t confuse encoding with security.

Compression Layers as Obfuscation

One challenge involved a file wrapped in something like eight layers of compression — gzip inside bzip2 inside tar inside gzip, and so on. Legitimate use? Almost never. Each compression pass after the first captures very little additional redundancy.

But stacking compression is a real technique in malware obfuscation. Each layer adds friction for anyone trying to analyse the payload. The approach to unpacking is mechanical — file to identify, rename if needed, decompress, repeat — but it’s tedious by design.

Takeaway: If you see deeply nested compression, ask why. The answer is rarely “for efficiency.”

SSH Keys and Netcat

The later levels introduce network concepts. SSH key authentication (-i flag) replaces passwords with cryptographic key pairs — and SSH is strict about file permissions. If your key file is readable by anyone other than you, SSH refuses to use it. chmod 600 is non-negotiable.

Netcat (nc) is the opposite of SSH — no encryption, no authentication, just a raw TCP connection to a port. It’s the simplest possible way to talk to a network service. In a CTF context, it’s how you interact with challenges running on specific ports. In the real world, it’s a diagnostic tool for checking whether services are listening and responding.

Takeaway: SSH keys need chmod 600. Netcat is telnet without the legacy baggage.

What I’m Taking Forward

Fifteen levels in and the biggest shift isn’t in what commands I know — it’s in how I think about problems. Every challenge follows the same pattern: understand what you’re looking at, identify the right tool, apply it. The commands are just vocabulary. The real skill is the process.

Next up: levels 15 onwards, where things apparently get properly difficult. I’m looking forward to it.

~Dan Starr