DEV Community

Aditya Raj
Aditya Raj

Posted on Originally published at omegaabot.hashnode.dev

Day 5: Catching Up — CLI Investigation, OS Security, and How Computers Represent Data

27-07-2026

What I Did

Catching up on five rooms that didn't make it into a post yet: Linux CLI Basics, Windows CLI Basics, and Operating System Security (closing out Module 3), plus Data Representation and Data Encoding, the first two rooms of Module 4: Software Basics.

Linux CLI Basics

What clicked was realizing the terminal isn't a pile of commands to memorize — it's a repeatable investigation workflow. Finding a specific file broke down into a natural sequence: pwd to figure out where I am, ls/ls -al to see what's around me, find to actually locate the file, cd to get to it, cat to read it. Beyond navigation, commands like whoami, uname -a, df -h, and cat /etc/os-release build a quick picture of the machine itself — exactly the kind of thing you'd want first when investigating any system.

The one thing that needed a second look: Linux is case-sensitive, so cd documents fails silently if the real folder is Documents. A small detail, but the kind of thing that makes an otherwise-correct command just not work.

Windows CLI Basics

The big realization here was that Windows CMD and Linux solve almost the exact same problems with different command names. The same workflow — locate yourself, explore, search, navigate, read, investigate — just uses dir, cd, type, whoami, hostname, systeminfo, and ipconfig instead. That meant learning Windows CLI wasn't starting from zero; the investigative mindset carried straight over.

Two things needed sorting out: cd on its own shows the current directory, while cd moves into one — same command, two jobs depending on how it's used. And whoami vs hostname answer genuinely different questions (who I'm logged in as, vs. which computer I'm actually on), which matters once you're enumerating a system you don't fully know yet.

Operating System Security

This room made it click that OS security isn't one feature — it's the fact that the OS sits between every application and the hardware, so compromising it exposes everything. The CIA triad became much easier to hold onto with a simple framing: confidentiality is who can see something, integrity is who can change it, availability is whether it can actually be used when needed.

The lab's real lesson was watching a chain of small, individually unremarkable mistakes — weak credentials, more exposed credentials, sensitive data sitting in shell history — compound step by step into full root access. Authentication vs privilege was the one distinction worth slowing down on: getting into a normal account doesn't mean getting full control — that only happens once access actually escalates to root.

Data Representation

The core shift here was realizing binary, decimal, hex, and octal aren't different values — they're different ways of writing the exact same value. Once that clicked, base conversion stopped feeling like four separate skills and became one idea viewed through different lenses. The RGB example made it concrete: three 8-bit channels, each with 256 possible levels, multiplying out to 16,777,216 colors. And hexadecimal's usefulness finally made sense too — 4 bits per hex digit means a full byte compresses neatly into just 2 hex characters, which is exactly why hex shows up everywhere data gets displayed compactly.

The confusing part: 8 bits gives 256 possible values, but the actual range is 0–255 — easy to mix up until you remember zero counts as one of those 256 values.

Data Encoding

This room separated two ideas I'd been quietly merging: representation (how numbers are stored) and encoding (what those numbers actually mean). 01000001 in binary is 65 in decimal, and ASCII is the standard that says "65 means the letter A." The computer never stores the shape of a letter — just a number, with a meaning attached by an agreed-upon standard.

The other piece that clicked: Unicode and UTF aren't the same layer. Unicode assigns a character its universal code point (like U+0041 for "A"); UTF-8, UTF-16, and UTF-32 are just different ways of actually encoding that code point into bytes. Seeing a webpage render as garbled Arabic text was a good reminder that the underlying data usually isn't gone — it's just being interpreted through the wrong encoding.

The mix-up worth flagging: UTF-8 and UTF-16 are variable-length (1–4 bytes, and 2 or 4 bytes respectively), while only UTF-32 is a fixed 4 bytes per character — the names make all three sound like fixed-width systems, and only one actually is.

Visuals

The investigation workflow shared across Linux and Windows CLI:

Flowchart of a system investigation: locate yourself, explore directories, search for a file, navigate to it, read it, then investigate the system

How a character actually becomes stored bytes:

Flowchart showing a character converted to a Unicode code point, then a UTF encoding, then bytes, then bits

What's Next

Python: Simple Demo, JavaScript: Simple Demo, and Database SQL Basics to close out Module 4.

Top comments (0)