RedTeam Nexus Labs
Module 02 · Lesson 01 // Linux Basics for CTF

Files

Linux Basics for CTF · CTF

Freereading · 10 min
On this page
LESSON

Overview

Almost every Linux CTF challenge begins with a file. A downloaded artifact, a suspicious script sitting in a home directory, a flag hidden in a place you would not expect — the first skill you need is the ability to see what files exist, learn what they are, and read their contents. This lesson covers how Linux thinks about files and the everyday commands that let you inspect them during authorized, isolated practice.

Learning objectives

  • Explain how Linux represents everything as a file and what a path is.
  • List and inspect files with ls, including hidden files.
  • Determine a file's type and read its contents with the right tool.
  • Recognize where flags are commonly stashed in a CTF filesystem.

Core concept

On Linux, almost everything is a file: regular documents, directories, devices, and even some kernel interfaces are exposed through the filesystem. Files live in a single tree that starts at the root, written /. A path is the address of a file within that tree. An absolute path starts at root, like /home/player/notes.txt. A relative path is interpreted from your current directory, like notes.txt or ../loot.

Two special names appear in every directory: . means "this directory" and .. means "the parent directory." Files whose names begin with a dot, such as .bash_history or .secret, are hidden by default — a detail that matters enormously in CTFs, because authors love to hide flags in dotfiles.

How it works

The core inspection commands are simple and composable:

  • ls lists the files in a directory. ls -l shows a long listing with permissions, owner, size, and modification time. ls -a includes hidden dotfiles. ls -la combines both.
  • file <name> examines a file's contents and reports what it actually is — a text file, an ELF executable, a PNG image, a gzip archive — regardless of its extension.
  • cat <name> prints a file's contents to the screen. It is best for short text files.
  • less <name> opens a file in a scrollable pager, which is safer for large files (press q to quit).
  • head and tail show the first or last lines of a file, useful for peeking without dumping everything.
  • stat <name> shows detailed metadata: exact size, timestamps, and inode.

A key idea: the extension does not define the type. A file named image.png might really be a text file, and a file with no extension at all might be an executable. Always confirm with file before assuming.

Practical example

You are dropped into a challenge directory and told a flag is "somewhere here." A methodical sweep looks like this:

$ ls -la
total 24
drwxr-xr-x 2 player player 4096 Sep 25 10:00 .
drwxr-xr-x 4 player player 4096 Sep 25 09:58 ..
-rw-r--r-- 1 player player   66 Sep 25 10:00 .hidden_note
-rw-r--r-- 1 player player  512 Sep 25 10:00 readme.txt
-rw-r--r-- 1 player player 1024 Sep 25 10:00 puzzle

$ file puzzle
puzzle: ASCII text

$ cat .hidden_note
Nice, you remembered to run ls -a. flag{d0tfiles_are_not_invisible}

Notice what happened: ls alone would have missed .hidden_note entirely, and file confirmed that puzzle — despite having no extension — was just text you could safely cat. The habit of running ls -la first is one of the most reliable moves in Linux CTFs.

Cybersecurity relevance

File inspection is the foundation of both offense and defense. During an authorized assessment or an incident response, an analyst constantly asks what is this file, who owns it, and what does it contain? Attackers hide payloads in dotfiles, name malware to look benign, and rely on defenders not checking a file's true type. Being fluent with ls -la, file, and safe readers like less means you notice the odd artifact, avoid executing something by accident, and understand what you are looking at before you act — exactly the discipline CTFs are training.

Common mistakes

  • Running ls without -a and never seeing hidden dotfiles where flags often live.
  • Trusting the extension instead of checking the real type with file.
  • cat-ing a huge or binary file, which floods the terminal and can garble it; use less or file first.
  • Confusing relative and absolute paths, then wondering why a file "is not there" when you are simply in the wrong directory.

Key takeaways

  • On Linux nearly everything is a file, addressed by a path within a single tree rooted at /.
  • ls -la reveals hidden dotfiles and shows permissions, owner, size, and time — make it your first move.
  • file tells you what a file truly is; never trust the extension alone.
  • Use cat for short text, less for large files, and head/tail to peek — CTF flags frequently hide in dotfiles.

Check your understanding

  • Why can running ls without -a cause you to miss a flag in a CTF directory?
  • If a challenge gives you a file named data.jpg, how would you confirm what it really is before opening it?
  • What is the difference between an absolute path and a relative path, and when might a relative path lead you astray?
FINISH THIS LESSON

Sign in to save your progress.