TryHackMe: Inside a Computer System — Learning Notes

These are my personal learning notes as I work through TryHackMe — honest notes, not an authoritative guide. Corrections welcome.

On sources & TryHackMe’s material: These are independent learning notes in my own words. They describe my experience of the room and deliberately reproduce none of TryHackMe’s room text, task content, screenshots, flags, or answers — go do the room to get those. Room names and the linked URL are used for reference only. TryHackMe and its content are the property of TryHackMe Ltd; this post is not affiliated with, authorised by, or endorsed by them.

Overview

• Room: Inside a Computer System — link
• Difficulty: Info / Easy
• What it teaches: The core components of a computer system, and the sequence of events between pressing the power button and arriving at a working operating system.

I’ll be honest about my starting point: I’ve been inside a PC case plenty of times. But I learned these components as a gamer, not as someone thinking about security, and going back over them with a different question in mind was more useful than I expected.

The components, as I already knew them

Everything I knew about computer hardware, I learned by asking one question: will this run the game?

• RAM — whether the game ran smoothly. The perennial upgrade, always for better performance.
• GPU — more memory, for higher resolution and smoother output. Purely about what came out of the screen.
• HDD → SSD — the HDD upgrade was about size, to fit bigger games. Moving to an SSD was about two things: avoiding the corruption risk of spinning, moving parts, and raw speed — which is why it’s the natural home for the boot drive.
• CPU — faster processing. The upgrade I did least often, because it usually meant replacing the whole machine. The most expensive move.
• PSU — the one that taught me a lesson the hard way. I tend to leave the machine on overnight (asleep rather than off), and every so often a power surge took the PSU out. I was replacing it every couple of years.
• Network adapter — I only really thought about this when consumer internet speeds jumped and the adapter became the bottleneck.

Reading that list back, every item is framed as a performance decision. None of them is framed as a component that could be attacked, or that needs to be inventoried, owned, or protected. That’s the shift this room started.

Genuinely new: the boot process

This was the part I’d never actually looked at. In my own words, the sequence runs:

1. Press the power button. The PSU lets electricity reach the components.
2. Firmware starts. The UEFI (or the older BIOS it largely replaced) starts up. One detail that turns out to matter: this firmware doesn’t live on your disk — it sits on a chip on the motherboard. It runs before any operating system exists.
3. POST — Power-On Self Test. The firmware checks that the required components are present, correctly configured, and functioning.
4. Select the boot device. The firmware holds an ordered list of devices to search for a bootloader, and works down it by priority.
5. Run the bootloader. The bootloader pulls the operating system off the chosen device and into RAM. Control of the hardware is then handed from the firmware to the OS.

Written out, one thing stands out: a whole sequence of decisions, code and handovers happens before the operating system exists at all.

What this reframed for me

Two things, and the second is why I’m glad I did an “easy” room properly rather than skipping it.

First: components aren’t just performance dials. They’re surface area. The more components a system has, the more places there are for something to go wrong or be attacked. Obvious once said, but not how I used to look at a spec sheet.

Second: while working through the Security+ syllabus I remember coming across malware that abuses the boot process to hide itself. At the time it was just a term. Now I can see why it works. If firmware runs before the OS and hands control to the OS, then anything that establishes itself at that level sits underneath the operating system — and underneath most of the security tooling, which runs inside the OS. Your defences are looking around a room they were handed, without being able to see who handed it to them.

The room mentions in passing that attackers target the boot process. It doesn’t explain how. But it gave me enough of the sequence that the shape of the attack now makes sense, which is more than I expected from an introductory room.

Connects to my bigger goal

The room opens with an argument I found familiar: you cannot defend what you don’t understand.

I’ve been spending time in compliance frameworks lately, and they say the same thing in bureaucratic language — that before any of the interesting security work can happen, you need an inventory: what devices you have, what’s on them, who owns each one, how sensitive it is. It usually reads like paperwork. After this room it reads less like paperwork. You can’t reason about risk to a system you haven’t enumerated, for the same reason you can’t defend a building you’ve never walked through.

Same argument, two settings. One version is a beginner room, the other a national regulation. I didn’t expect those to line up.

Where I got stuck

Nothing, honestly. This is an introductory room and it’s clearly written. I’d rather say that than invent a difficulty.

The one place I slowed down and re-stated in my own words was step 5 — the handover, where the firmware gives up control of the hardware to the OS. Not because it’s hard, but because it’s the step that makes the rest of the picture click, and skimming it would have cost me the point above.

Revisit

• Bootkits and firmware-level malware — what running below the OS actually buys an attacker, and what it costs them.
• Secure Boot — the defensive counterpart. If the boot chain is the weakness, what verifies each link?
• The firmware/OS trust boundary in general. This feels like the first genuinely important boundary I’ve met, and probably not the last.

Lessons Learned

• The reframe: I knew every one of these components already, but only as performance dials. Meeting them as attack surface is a different subject wearing the same words.
• The boot process is a sequence of trust handovers, and the operating system is absent for most of it.
• “You can’t defend what you don’t understand” is not a slogan. It’s the reason asset inventories exist, and why they’re the first thing every serious framework asks for.

References

• The room’s guided tasks and static site on TryHackMe