Week 04 · lesson

From GUI to CLI: Read the System Directly

Most people meet a computer through windows, icons, menus, and buttons.

That is the graphical user interface, or GUI.

Cybersecurity work also relies heavily on the command-line interface, or CLI. A terminal lets you describe an action as text, inspect exact output, repeat steps, and record what happened.

The CLI is not automatically more powerful or more dangerous than a GUI. It is another interface to the operating system.

The security advantage is precision.

The shell is an interpreter

When you type a command into a terminal, a shell interprets the text and asks the operating system to perform an action.

A simplified path looks like this:

student → terminal → shell → operating system → output

If you understand that path, the terminal stops looking like magic.

Start with location

A command-line session always has a current working directory.

Three foundational Linux commands are:

pwd
ls
cd
  • pwd shows the current working directory.
  • ls lists directory contents.
  • cd changes directories.

Imagine the fictional lab filesystem:

/home/student
├── evidence
│   ├── login-events.txt
│   └── notes.md
├── samples
│   └── suspicious-message.txt
└── projects
    └── robot-status.txt

If the prompt begins in /home/student, then:

cd evidence
pwd

should place you in:

/home/student/evidence

The important habit is knowing where you are before you act.

Relative and absolute paths

An absolute path starts from the filesystem root:

/home/student/evidence/login-events.txt

A relative path starts from your current location:

evidence/login-events.txt

If you are already inside /home/student/evidence, the relative path can be simply:

login-events.txt

Cybersecurity investigations fail when analysts confuse paths and inspect, modify, or submit the wrong artifact.

Read before you change

Early security work should favor observation.

Useful read-oriented commands include:

ls -l
cat notes.md
head login-events.txt
tail login-events.txt
  • ls -l shows a detailed file listing.
  • cat prints a file's contents.
  • head shows the beginning of a file.
  • tail shows the end.

For large logs, printing the entire file may be less useful than viewing a smaller portion.

Command output is evidence

Suppose the lab gives you this synthetic output:

$ ls -l evidence
-rw-r--r-- 1 student student 842 Sep 10 09:14 login-events.txt
-rw-r--r-- 1 student student 318 Sep 10 09:20 notes.md

What can you observe?

  • two files are listed
  • both are owned by student
  • file sizes differ
  • timestamps differ

What can you not conclude?

  • who created the files
  • whether the files are trustworthy
  • whether the contents are malicious

The terminal gives evidence. You still have to interpret it carefully.

Build a command map

Create a table:

GoalCommandWhat it returnsRisk if misunderstood
Find current directorypwdcurrent pathLow
List fileslsdirectory entriesLow
Move into directorycdchanges shell locationCan lead to acting in wrong place
Read textcatfile contentsCan expose sensitive information if scope is wrong
View start of fileheadfirst linesSame evidence-handling boundary
View end of filetaillast linesSame evidence-handling boundary

Add at least four additional safe commands from the teacher-approved command reference.

Lab: navigate without guessing

Use the embedded classroom terminal or teacher-provided VM.

Do not use a real school system as a target.

Complete these tasks:

  1. identify the starting directory
  2. list the available folders
  3. navigate to the supplied evidence directory
  4. inspect the filenames without opening anything yet
  5. read the first five lines of the supplied login log
  6. return to the parent directory
  7. record every command you used

Your command record should be reproducible. Another student should be able to follow it and reach the same location.

Explain the prompt

A prompt might look like:

student@labvm:~/evidence$

Break it apart:

  • student: current user
  • labvm: host name
  • ~/evidence: current location
  • $: normal user shell prompt in this example

Do not assume every prompt uses this exact format. Learn to read the information that the environment provides.

GUI versus CLI comparison

Choose one task that can be done in both interfaces, such as locating a file.

Compare:

  • speed
  • precision
  • repeatability
  • evidence capture
  • risk of acting on the wrong object

The point is not to declare one interface better. The point is to understand why defenders often use both.

Evidence for Lesson 1

Submit:

  • your command map
  • your navigation command record
  • a labeled explanation of the terminal prompt
  • your GUI-versus-CLI comparison

Finish with:

The command-line habit that reduces the most mistakes for me is ________ because ________.

The terminal becomes useful when you can predict what a command should do before you press Enter.

decision flow

Systems Defenders Protect: Defensive Evidence Flow

  1. Authorize

    Confirm the classroom boundary and permitted evidence.

  2. Observe

    Inspect a provided artifact or isolated system state.

  3. Assess

    Connect evidence to risk, limitation, and control.

  4. Defend

    Document a safeguard and how it would be safely verified.

Read this concept flow as plain text
  1. Authorize. Confirm the classroom boundary and permitted evidence.
  2. Observe. Inspect a provided artifact or isolated system state.
  3. Assess. Connect evidence to risk, limitation, and control.
  4. Defend. Document a safeguard and how it would be safely verified.