Computer Fundamentals & Data Representation

Start here — what this course is, and where it leads

Welcome. Before the first technical page, take two minutes on what you have walked into: what this course does, what it deliberately does not do, and where it sits in a longer path.

What this course is

This is a primer — the ground floor under everything else. It does not teach you to attack systems. It teaches the everyday facts that security work is built on: what a computer and an operating system are, how networks carry data, how the web really talks, how to read code, and how a security consultancy does the job.

There is nothing to install. Every section is something to read, a few diagrams, sometimes a small thing to try in the browser you already have, and a short quiz so you can check yourself.

The promise is worth stating plainly. We call it field literacy, and it buys you two things:

• You can start hands-on security training without drowning. When the trainer says "look at the HTTP request", you know what that is.
• You are not caught off guard on a client site. Someone says "pull the firewall config", "check which subnet you are on", "that one is an Oracle database" — and you follow the conversation.

Where it sits — the first step on a path

The work you are heading towards has a name in the industry: VAPT, short for Vulnerability Assessment and Penetration Testing. Finding the weaknesses in a system, then proving what an attacker could actually do with them. Becoming a VAPT professional is the destination, and this course is step one of three:

• Pre-Security — this course. The ground floor: no labs, no tools, just the vocabulary and the mental models.
• Beginner — where the real work starts. Hands-on network testing, compliance and configuration auditing, and a full web-application course against a practice bank application, with labs you break into yourself.
• Intermediate — the specialisms that come after: APIs, mobile apps, thick clients.

This is the only one of the three you can finish without touching a lab. That is on purpose — you should not be fighting a toolset while you are still learning what a port is.

How it complements the Beginner course

Here is the honest reason this course exists. The Beginner course assumes a set of things and never stops to teach them. It assumes you know what an HTTP request looks like before it shows you how to tamper with one. It assumes you can read a SQL query before it teaches SQL injection. It assumes you know what a config file is before it asks you to review one. A fresher who starts there spends the first week quietly lost — not because the material is too hard, but because the floor underneath it was missing.

So every topic here had to pass one of two tests to earn its place:

• The Beginner course assumes it but never teaches it.
• A consultant gets caught off guard by it in the field — these are real gaps, noticed on real client visits.

That is what makes this a complement rather than a separate subject. Nothing here is padding, and nothing here is a shortened copy of Beginner. It is the missing ground floor beneath it. Finish this and Beginner stops feeling like a foreign language: your attention goes to the testing instead of the words.

And if you have already begun the Beginner course and parts of it felt slippery, you are exactly who this course is for. Coming here first is not a step backwards.

What you will be able to do at the end

• Read a file path, reason about permissions, and open a terminal on Windows or Linux without hesitating.
• Explain how data gets from one machine to another — and why being on a network does not mean you can reach everything on it.
• Read an HTTP request and its response, and tell logging in apart from being allowed in.
• Read HTML, JavaScript and SQL well enough to work out what a piece of code is doing.
• Talk about the job the way the industry does: the services, the frameworks, the risk words, the tools — and why the report is the real product.

How to work through it

Take the modules in order; each one leans on the one before it. Read the section, try the browser exercises where they appear, then answer the quiz. Every module closes with a glossary and a recap so the new words stay put. Expect around seven hours in total. It is not a race, and re-reading a section is completely normal.

1.1 · What a computer and an operating system are

Strip away the screens and apps and a computer does just three plain things: it stores data, it moves data, and it follows instructions to change data. Those instructions are a program. A program sitting on your disk is doing nothing — it is only a recipe. The moment you open it, the computer loads it into memory and starts running it, and that running copy is called a process. One program can become many processes: open three windows of the same browser and the system may run three separate processes from one program on disk.

The hardware underneath

The physical parts are the hardware. Three matter to you now:

• The CPU (Central Processing Unit) is the part that actually does the calculating — it follows the instructions, billions of tiny steps a second.
• RAM (memory) is fast, temporary working space. It is wiped the instant power is lost.
• The disk (storage) is slower but permanent — it keeps your data through a reboot.

A picture that sticks: RAM is your desk — big enough to spread out the work you are doing right now, but cleared every night. The disk is the filing cabinet — slower to reach into, but it keeps things for years. This is exactly why unsaved work vanishes in a power cut: it was only ever on the desk (RAM), never filed away (disk).

Where the operating system fits

You never speak to the hardware directly. Sitting between you and it is the operating system (OS) — Windows, Linux, macOS, Android. Think of it as the building manager. Dozens of processes all want the CPU, all want memory, all want to open files at once. The OS decides who gets what, keeps them from trampling each other, and gives every program one common way to reach the disk, the screen and the network.

As a security tester you will meet two OS families constantly. Windows runs most corporate desktops and the Active Directory systems that manage them. Linux runs most web servers on the internet — and it will be the system on your own testing machine. You do not need to master either yet; you need to know which world you are standing in.

1.2 · Files, folders, paths and permissions

Everything on a disk is stored as files kept inside folders (also called directories). Because a folder can hold other folders, the whole disk forms a tree that branches down from a single starting point. The exact address that says where one file lives in that tree is its path.

Reading a path

Windows and Linux write paths a little differently, and you will read both every week:

Read the Linux example aloud: "inside root, inside var, inside www, inside html, the file index.php." That last path is worth remembering — /var/www/html is the classic home of a website's files on a Linux server, so you will see it constantly once you start testing web apps.

Permissions — who may do what

A file does not belong to everyone equally. For every file, the OS records three kinds of allowance: who may read it (r), who may write to it — that is, change it (w), and who may execute it — run it as a program (x). And it records those three for three groups of people: the file's owner, the owner's group, and everyone else (often called "world" or "other").

On Linux you will see this written as a nine-character string:

Permissions are the beating heart of a large share of security findings, so this pays off fast. A configuration file that everyone can read might hand a database password to any user on the machine. A folder that everyone can write to might let an attacker drop a malicious file where the server will run it. When you later hear a report say "this directory was world-writable," you will know it means the third group had a w — and why that is dangerous.

1.3 · Meeting the command line

Everything so far, you have done by clicking. Consultants type. A terminal — also called a console, a shell or simply the command line — is a plain text window where you type one instruction, press Enter, and the computer runs it and prints its answer back as text. No icons, no mouse, no menus.

It looks unfriendly at first and it is worth pushing past that, because three facts of the job make it unavoidable:

• Most servers have no desktop at all. A Linux web server you are asked to test will give you a text prompt and nothing else. There is no window to click.
• Almost every security tool is a command-line tool. The scanners and testing tools you will meet are run by typing their name and options.
• A command is repeatable evidence. You can paste the exact command and its exact output into your report, and the client can run the same line and see the same result. A screenshot of a mouse click proves much less.

The prompt

Before it will accept anything, the terminal prints a prompt — a short line that tells you where you are standing. Learning to read it removes most of the early confusion:

Notice what sits in the middle of that prompt: a path, exactly as you learned to read it in the last section. That is the real shift. In a file explorer the folder you are in is something you see; on the command line it is something you steer by, and half of all early mistakes are simply running a good command in the wrong folder.

Two families — Windows and Linux

You will meet two dialects, and clients run both. On Windows the older one is Command Prompt (cmd.exe) and the modern, far more powerful one is PowerShell. On Linux and Mac you are in a shell — usually bash or zsh — opened through an app called Terminal.

The ideas are identical; only the words change. These eight cover most of what a beginner ever needs:

One of those closes a loop from the previous section. Run ls -l on Linux and the first thing printed against every file is the nine-character permission string — rwxr-xr-- and friends. The thing you just learned to read is the thing the terminal shows you first.

Ordinary user, or administrator?

The terminal obeys whichever account started it, and that account has limits. On Linux the all-powerful account is called root; an ordinary user borrows its power for one command at a time by putting sudo in front (sudo cat /etc/shadow). On Windows the equivalent is Administrator, and you start the whole window with "Run as administrator".

Hold on to that distinction, because a large part of this career lives inside it. Testers very often get in as some ordinary, boring account and then hunt for a way up to root or Administrator. That hunt has a name you will hear constantly: privilege escalation.

This is a first look, not the full tour. The Beginner course puts you inside a real Linux shell for hours and teaches these commands properly — the aim here is only that the black window already feels familiar when you get there.

1.4 · Binary and hexadecimal — counting like a computer

Underneath every photo, password and web page, a computer stores only two states: on and off, written as 1 and 0. A single 1-or-0 is a bit — the smallest possible piece of data. On its own a bit says almost nothing, so we group them.

Group eight bits together and you get a byte. Eight on/off switches can be arranged in 2×2×2×2×2×2×2×2 = 256 different patterns, so one byte can hold any value from 0 to 255. This is why so many limits in computing stop at 255 or 256 — that is simply one byte's worth of room.

Binary is base 2

Counting with only two digits is called binary, or base 2. You already count in base 10 — ten digits, 0 to 9, and when you run out you add a column (9 → 10). Binary works the same way with only two digits, so it runs out of room faster: 0, 1, then straight to 10 (which means two), 11 (three), 100 (four). You will never have to do this by hand on the job; the point is to recognise a string of 1s and 0s as a number.

Why hexadecimal shows up everywhere

Long runs of 1s and 0s are miserable to read and easy to miscount, so we compress them with hexadecimal — base 16. Hex uses the digits 0–9 and then, because it needs six more, the letters A, B, C, D, E, F for the values ten to fifteen. The magic is that each hex digit stands for exactly four bits, so a whole byte becomes just two neat hex digits.

You will meet hex the moment you start: colours on a web page (#00b4ff is this course's blue), memory addresses in tool output (often marked with a leading 0x, as in 0x1F), and the random flags in a lab such as SESMO{a3f9c2e1...} — those braces are full of hex characters. You do not convert them in your head; you recognise them so nothing looks like a mystery.

1.5 · Text as numbers — ASCII, Unicode, URL-encoding and base64

If a computer only stores numbers, how does it store the letter A? By everyone agreeing on a table that maps each character to a number. The old, simple table is ASCII, in which A is 65, a is 97, and the digit 0 is 48. ASCII only covers English, so the modern, far larger table is Unicode, which has a number for every character in every language, plus emoji. Hold onto one idea from this: text is just numbers wearing a costume. That is why the byte in the last section's diagram (97) was also the letter "a".

Two encodings you will see every day

An encoding is a reversible way of rewriting data so it can travel through a channel that would otherwise mangle it. Two encodings matter enormously in web security:

• URL-encoding (also called percent-encoding) rewrites characters that are unsafe in a web address by replacing each with a % followed by its hex code. A space becomes %20; a slash becomes %2F; a single quote becomes %27. So when a request contains %27, an attacker (or you) may simply be sending a quote mark that would otherwise break the URL.
• Base64 rewrites any data — even a picture — using only 64 "safe" characters (A–Z, a–z, 0–9, and + and /). A base64 string often ends in one or two = signs used as padding. You will see base64 carrying login tokens and small files inside web traffic. For example YWRtaW4= is simply the word admin rewritten in base64.

Here is the point that everything later depends on: encoding hides nothing. Anyone can turn base64 or URL-encoding back into the original in a second, with no password. It changes how data looks, never whether it is secret. It is a costume, not a lock — and the next section makes that difference sharp.

atob("YWRtaW4=")

1.6 · Encoding vs Encryption vs Hashing

These three words get mixed up constantly, and confusing them will trip you up on your very first day. They are genuinely different jobs done for different reasons. The fastest way to keep them straight is to ask two questions of each: can you reverse it? and do you need a key?

Why the difference decides a real finding

Picture a website that stores your password. If it merely encodes it, then anyone who steals the database reads every password instantly — a serious flaw, because encoding is not protection. If it encrypts the passwords, a thief also needs the key, which is better but still means the plain passwords exist somewhere. The right answer is to hash them: the site stores only a one-way fingerprint, and at login it hashes what you typed and compares fingerprints. It never keeps your actual password at all — so even the site, and even a thief with the whole database, cannot turn a good hash back into your password.

That is why, when you read a finding that says "passwords were stored base64-encoded," you now know in one beat why it is bad and what the fix is: encoding is not protection; passwords must be hashed. This single distinction quietly underlies a large slice of the web security you will learn next.

1.7 · Signing & digital signatures

One more idea from the same family, and it trips people up even more than the last three — often for years. In the previous section, encryption used a key to hide something. A digital signature does almost the opposite job: it does not hide anything, it proves something. It answers two very ordinary questions about any file: who made this, and has it been changed since?

Here is the everyday version. Imagine you seal a letter with a wax stamp pressed from a ring that only you own. Anyone can look at the sealed letter and recognise your stamp, so they know it came from you — and if someone steams it open and edits it, the broken seal gives the tampering away. A digital signature is that wax seal, done with maths instead of wax.

The new idea: a pair of keys

The encryption in the last section used a single key — the same secret both locks and unlocks. Signing uses something different: a matched pair of keys that belong together. This one idea is the whole trick, so hold on to it:

So you sign with the private key that only you hold, and the rest of the world verifies with the public key you handed out. Because only your private key could have produced a signature your public key accepts, a valid signature proves two things at once: it came from you, and not a single byte has changed since you signed it.

Why a changed byte breaks the seal

This is where the last section pays off. Under the hood, signing leans on hashing. To sign a file, the maker first takes its hash — that one-way fingerprint you just met — and then seals that fingerprint with the private key. To verify, your device hashes the file again for itself and checks the sealed fingerprint against it. Change even one byte of the file and its fingerprint comes out different, so it no longer matches the sealed one, and the signature fails. That is how a signature notices tampering without needing to know what the file was “supposed” to say.

Where you already meet signatures

You rely on signatures every day without seeing them:

• The padlock on a website. When your browser shows HTTPS, part of what is happening is your browser checking a signed certificate — an ID card carrying the site's public key — to confirm you really are talking to your bank and not an impostor. For public websites a trusted outside body (a Certificate Authority) signs that certificate, which is why the browser believes it.
• Software and app updates. Your phone or laptop will install an update only if it is signed by the same maker who signed the original. An update signed by anyone else is refused — which is how your device knows the update is genuine and not swapped out along the way.
• Signed documents and emails. A signed PDF or email lets the reader confirm it really came from the sender and was not altered in transit.

Module 1 glossary

The words from this module, in one place. If any feel shaky, re-read that section before moving on.

Process

A program while it is actually running in memory. One program can be several processes.

CPU / RAM / Disk

The calculator; fast temporary memory (lost on power-off); slow permanent storage (kept).

Operating system (OS)

The manager between you and the hardware — shares CPU, memory and files among processes.

Path

A file's full address in the folder tree, e.g. /var/www/html/index.php.

Permissions (r/w/x)

Who may read, write (change) or execute (run) a file — set for owner, group and everyone else.

Terminal / shell

A text window where you type commands and read text replies. Windows uses Command Prompt or PowerShell; Linux and Mac use bash or zsh.

root / Administrator

The all-powerful account on Linux / on Windows. Borrowed one command at a time with sudo, or by "Run as administrator".

Privilege escalation

Getting from an ordinary account up to root or Administrator — a goal on most engagements.

Bit / Byte

A single 1-or-0; eight bits grouped together, holding a value 0–255.

Binary / Hexadecimal

Base 2 (only 1s and 0s); base 16 (0–9 then A–F) — a short way to write bytes.

ASCII / Unicode

Tables mapping characters to numbers — small/English vs large/all-languages.

Encoding

A reversible rewrite for safe transport (base64, URL-encoding). No secrecy.

Encryption

A reversible scramble that needs a key. Provides secrecy.

Hashing

A one-way fingerprint. Used to check passwords without storing them.

Public / private key

A matched pair: the private key (kept secret) creates a signature; the public key (shared) only checks one.

Digital signature

A sealed stamp on a file proving who made it and that no byte has changed since.

Signing

Attaching a digital signature to a file using the maker's private key.

Certificate

An ID card carrying a public key plus its owner's details — how a website proves who it is.