Chapter 4: Computer Systems

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome to the Deep Dive, your shortcut to really getting a handle on complex topics.

You provide the sources, we do the digging, and make even dense stuff, well, pretty engaging.

Think of it like we're building you a mental map, taking you from feeling a bit lost in the technical jargon to seeing the whole landscape clearly.

Today we're tackling a really foundational chapter.

It's chapter four, computer systems, from Learn Computer Forensics, second at head.

Now this might sound super technical,

but understanding how a computer actually works from the ground up is just so critical, especially if you're dealing with digital evidence.

It's like knowing the rules of chess before you play.

Our mission today is to sort of peel back the layers.

We'll start right when you hit that power button and follow through to how data actually gets stored.

This chapter, it's really the bedrock for digital investigations.

Right.

We're going to walk through the whole startup sequence, get into the nuts and bolts of different file systems.

We'll focus a lot on FAT and NTFS.

Yeah, the big ones.

And also how drives get divided up using MBR and GPT.

We'll even look at those less obvious hitting spots on a drive and crucially link it all back to actual forensic work.

And that's the key takeaway, really.

Getting these fundamentals right is what allows investigators to handle evidence properly.

If you don't grasp the boot process or how files are organized, you could easily accidentally change things.

Which could be disastrous.

Absolutely.

It undermines the whole case.

Okay.

Let's start unpacking this.

The boot process.

Why is understanding this the absolute first step?

Well, it's fundamental because it dictates that initial state of the machine.

As investigators, our number one job is to control that environment, right?

To stop any changes to potential evidence.

So knowing that sequence, how it boots, lets us step in safely and use our own tools, our own controlled environment.

The book uses this latter analogy, a series of steps leading to the OS loading up.

Let's talk about that first rung the PSD, power on self -test.

What's actually going on?

Okay, so POST, that's the very first checkup.

You hit power, the CPU wakes up, looks at the ROM read -only memory, which holds the BIOS, the basic input -output system.

And POT does this quick health check, motherboard components, basic hardware.

That single beep you usually hear.

That's P -A -S -T saying,

all clear.

And what if you hear, like, a bunch of beeps,

or maybe no beep?

What's that telling you?

Ah, that's where it gets interesting.

Those beep codes, they're error signals.

Specific patterns mean specific hardware problems.

So if you run into a machine doing weird beeps, the book points out, a quick online search for that code could give you clues.

Maybe a RAM issue, maybe something else.

It's crucial info before you dive in.

Good tip.

So POST finishes, hopefully successfully, then the BIOS kicks in.

Yep, BIOS takes over.

And remember, at this point, we haven't used the hard drive yet.

BIOS is all about the motherboard.

It gathers basic info, how much RAM, what CPU, what drives are connected, the system date and time.

The book strongly suggests photographing the BIOS screen.

For documentation.

Exactly.

Creates a baseline record of the system config before you do anything else.

Really important.

And this is where we can take control, right?

Changing the boot sequence, why is that so vital?

Absolutely vital.

See, the BIOS usually looks for an OS in a set order, maybe CD drive, then USB, then the main hard drive.

Right.

But in forensics, we almost never want to boot from the suspect's drive.

That could change files, logs, everything.

Okay.

So we go into the BIOS setup, change that order, and tell it, boot from my forensic USB drive first.

That way, we create a safe space, leaving the original evidence untouched.

Now, BIOS is kind of the old way, right?

The book mentions UEFI replacing it since around 2010.

What are the key differences we need to know?

Yeah, UEFI Unified Extensible Firmware Interface is the modern successor.

It does the same basic job of initializing hardware, but with upgrades.

Like what?

Better security before the OS loads, faster startup, support for those huge hard drives over two terabytes.

Ah, important.

Support for 64 -bit drivers,

and crucially, it uses GPT, the GID partition table, instead of the older MBR for organizing the drive.

We'll get to GPT.

Okay.

One of those security features is Secure Boot.

Sounds good, but the book says it can cause headaches for forensics.

It can, yeah.

Secure Boot is designed to only load operating systems and drivers that have a trusted digital signature.

Good for security, but...

But our forensic tools might not have that signature.

Exactly.

Our custom Linux boot disk or WinFi environment might get blocked.

So often, we need to go into the UEFI settings, the replacement for the old BIOS setup screens, and disable Secure Boot.

And document everything.

Meticulously.

Document if it was on, if you disabled it, even if you tried and failed.

It all affects the process.

Okay, so BIOS often looks for the MBR master boot record.

UEFI usually uses GPT.

Let's define those.

What's an MBR?

The MBR, master boot record, lives right at the very beginning of a hard drive.

Physical sector zero.

For older BIOS systems, it's critical.

What's in it?

It holds info about partitions, those logical drive divisions.

It tells the system what file systems are on those partitions, and it contains the bootloader, a tiny program that kicks off loading the main operating system.

And GPT, how's that different?

GPT, G -I -T partition table, is the newer standard used with UEFI.

It gets around MBR's limits, like the four primary partition maximum.

GPT can handle way more partitions, the book says, up to 128 typically in Windows.

Wow, okay.

And for compatibility, it puts a protective MBR in sector zero.

This just tells older systems, hey, this is a GPT disk, don't mess with it.

The real GPT partition info is stored a bit further into the drive, including a backup copy for safety.

So the bottom line is, whether it's MBR BIOS or GPT UEFI, we need to understand this basic drive layout before we touch anything.

Precisely.

Knowing how it starts up, how it's organized, that's step one for sound forensic work.

Okay, let's talk more about that forensic boot media.

When is it absolutely essential?

It's essential whenever you can't or shouldn't physically pull the hard drive out of the machine to image it elsewhere.

The whole goal is to create that clean, controlled forensic environment without altering the original source device one bit, booting from our own trusted CD,

DVD, or more likely now, a USB drive, lets us access the suspect drive without running its own potentially compromised OS.

And USB is becoming the standard, right?

Fewer optical drives these days.

What tools do investigators use to make these bootable USBs?

Linux is a really common choice.

The book specifically calls out Paladin.

It's a free Linux distribution built just for forensics.

You can even get it preloaded on a USB.

Convenient.

What about for folks who prefer Windows, the book mentions WinFE.

Yeah, WinFE winters forensic environment.

It gives you a bootable, lightweight Windows environment.

Great for running familiar Windows forensic tools like X -Ways or FTK Imager in a safe way.

That may be not the super heavy duty suites.

Right.

The book cautions against trying to run, say, the full end case or FTK suites within WinFE.

They need more resources than WinFE typically provides.

You want lean and mean for boot environment.

Makes sense.

Now, the book really stresses validating this boot media in the lab before using it in the field.

Why is that so critical?

Non -negotiable.

You absolutely have to test your forensic boot disk on known hardware in your lab first.

To make sure.

To make absolutely sure it boots correctly,

recognizes hardware, and most importantly, does not write anything to the connected drives unless you specifically tell it to.

Using untested media risks contaminating the very evidence you're trying to preserve.

Huge mistake.

The chapter also lists some common challenges with using bootable USBs.

What kind of things can go wrong?

Oh, plenty.

First hurdle is just getting the machine to see the USB and boot from it.

You often have to quickly hit a key to get into biosufi and change the boot order.

And the timing can be tricky.

Very tricky sometimes.

Plus, some really old systems might not support USB booting at all.

Then you need to know if your boot media can actually write protect the file systems on the suspect drive properly.

Right.

Can it mount NTFS or FAT read -only?

Exactly.

And then there's dealing with secure boot in UEFI, which we already mentioned.

Lots of potential little roadblocks.

And again,

documentation is key, even for failed attempts.

Absolutely.

If you tried to get into bios but missed the window or if the system started booting the wrong OS for a second, write it down.

Those actions could have changed timestamps or logs.

You need a full record.

OK, so we've booted safely.

Now, the storage itself.

The book distinguishes physical drive from logical device or partition.

Why is that important?

It's fundamental.

The physical drive is the hardware,

the actual HDD or SSD unit.

The thing you hold in your hand.

Right.

The logical device or volume or partition.

That's how the physical space is organized.

One physical drive can be split into multiple logical drives like CD, etc.

When people say C drive, they mean a logical partition, not the whole physical disk.

Got it.

The chapter peeks inside a traditional spinning hard drive platters, heads.

What's the forensic relevance there?

Understanding the mechanics spinning platters, read -write heads hovering microns above the surface, highlights their physical fragility.

Right.

Dropping one is bad news.

Very bad news.

A shock can cause a head crash, destroying data.

Knowing how they work emphasizes careful handling.

It also explains why rotational speed affects performance.

And the interfaces, SCSI, IDE, SATA, SAS.

This is different ways drives talk to the computer.

Pretty much.

SCSI and IDE are older standards you might see on legacy systems.

SATA is the common one now for most computers.

SAS is more high end, often in servers.

So investigators need the right cables and adapters depending on the drive they encounter.

Exactly.

Need to be prepared for different connection types.

Shifting to solid state drives SSDs.

No moving parts.

Big implications for forensics.

Huge implications.

SSDs use flash memory chips.

They're faster, tougher, lighter, use less power.

All good things.

That's it.

But the way they manage data internally, things like wear leveling, trim, and garbage collection, dramatically affects data recovery.

Explain those.

Wear leveling.

Wear leveling spreads rights evenly across all the memory chips.

So they wear out at roughly the same rate.

Extends the drive's life.

Trim is a command the OS sends to the SSD saying, hey, the user deleted these files, you don't need the data in these blocks anymore.

And garbage collection.

Garbage collection is the SSD's internal cleanup crew.

It finds those trimmed blocks or blocks with stale data, moves any still needed data elsewhere, and then completely erases the entire block to make it ready for new writes.

And the forensic impact is?

The impact is massive.

Once trim and garbage collection have done their job on unallocated space, the original data is likely gone.

Wiped.

Making recovery of deleted files from SSD free space incredibly difficult.

Often impossible with standard methods.

Wow, a game changer compared to traditional drives where deleted data might linger.

Okay, let's talk drive geometry heads, tracks, cylinders, sectors.

Sounds old school, still relevant.

It's mostly historical context now, but good to know.

Especially if you hit older systems or use very low level tools.

Manufacturers do a low level format, creating tracks, circles, and sectors.

Pie slices on the tracks.

Sectors being the smallest physical unit.

Smallest physical storage unit, yeah.

Traditionally 512 bytes, now often 4096 bytes, 4K sectors.

And the addressing change from CHS to LBA.

Right.

CHS, cylinder, head, sector, directly use that physical geometry.

But it couldn't handle the massive drives we have now.

Ran out of numbers.

Kind of, yeah.

LBA logical block addressing just assigns a sequential number to every single sector, starting from zero.

Much simpler and scalable.

It's what everything uses today.

Okay, so we have the physical drive, maybe with LBA addressing.

Then comes partitioning.

Let's start with the older MBR scheme.

Key features.

Limits.

MBR, master boot record, as we said, lives in sector zero.

It's big limitation.

Only four primary partitions allowed.

So if you wanted Windows, Linux, and maybe a data partition.

You'd use three primary partitions.

If you needed more, you hit the limit.

One partition has to be marked active for the bios to boot from it.

And the workaround for the limit was extended partitions.

Exactly.

You could designate one of those four primary slots as an extended partition.

Then, inside that extended container, you could create multiple logical drives.

It was a way to get more drive letters, basically.

So inside that 512 -byte MBR sector, what's stored?

First, 440 bytes or so are typically boot code.

Then four bytes for a unique disk signature.

Then the crucial 64 -byte partition table.

64 bytes, 16 bytes per partition entry.

That's where the four partition limit comes from.

Bingo.

And the last two bytes are the MBR signature.

Xanadity check, 0x55AA.

Can we tell anything else from that partition table?

Like, what kind of file system is on a partition?

Yes.

Each 16 -byte entry has a system ID byte.

Hexo 7 usually means NTFS.

Hex 0B or 0C often means FAT32.

Hexo 5 or 0F indicates an extended partition.

It gives you a quick map of the intended layout.

You can also see which partition is marked active, bootable.

And where does the volume boot VBR fit in?

Okay, the MBR describes the whole disk.

The VBR says at the start of each individual partition, logical sector 0 of that partition.

It's created when you format the partition.

And it's specific to the file system in that partition.

Exactly.

FAT32 VBR is different from an NTFS VBR.

It contains the info needed to understand and boot the OS within that specific volume.

Removable drives, like USB sticks,

often have a VBR even if they aren't partitioned in the MBR sense.

Okay, MBR covered.

Now, GPT partitions.

It starts with GAY.

Yeah, GODs globally unique identifiers.

These are 128 -bit hexadecimal numbers.

The idea is they're unique across space and time, like a serial number for, well, almost anything digital.

Extremely unlikely to get duplicates.

Vanishingly small probability.

GPT uses them to identify the disk itself and each partition on it.

Much more robust than MBR.

The book mentions different GEOID versions.

Is that super important?

Probably not for everyday analysis, but good to be aware.

Version 1 includes a timestamp and MAC address, which could be interesting forensically.

Others use hashing or random numbers.

Just different ways to generate that unique ID.

So, GPT goes with UEFI.

How is it structured differently from MBR?

GPT uses LBA exclusively.

It has that protective MBR in sector 0 just for backward compatibility, tells old tools, this is GPT.

No boot code in that protective MBR?

Nope.

Its partition type is set to EE, hex.

The real action starts at physical sector 1 with the GPT header.

You can spot it by the EFI part signature.

And the actual list of partitions?

Usually starts right after the header, often in sector 2.

Each partition entry is 128 bytes long.

Way more space than MBR's 16 bytes per partition.

Loads more.

It stores the partition type GEOID, a unique GEOID for this specific partition, the start and end LBA sectors, attribute flags, and even a partition name in Unicode.

And remember, GPT supports way more partitions.

Up to 128 is common in Windows.

No need for extended logical tricks.

The chapter then mentions potential hiding spots outside normal partitions, HPA and DCO.

Host protected area, HPA, and device configuration overlay, DCO.

These are areas usually set up by the drive manufacturer.

HPA often holds recovery tools or diagnostics.

DCO lets manufacturers tweak the reported drive size.

Maybe make a batch of 500GB drives appear as 480GB for a specific customer,

usually hidden from the OS and user.

But could someone misuse them?

Potentially.

Utilities exist that might allow access, so someone could theoretically hide data there.

Forensic tools are usually aware of HPA and DCO, though.

Yeah, the book shows screenshots from X -ways and FTK imager indicating these areas, so something else to check.

Definitely.

Don't assume the partitions are the whole story.

Okay, physical drives, partitioning, now file systems.

Each partition usually has one.

It's job.

The file system is the organizer.

It tracks where files are, what space is free, all the metadata like names, dates, sizes.

It works with clusters.

Clusters, not sectors.

Right.

The disk works with sectors, physical.

The file system groups one or more sectors into a cluster.

Logical.

A cluster is the smallest chunk of space the file system will allocate to a file.

Different OC's like different file systems, FAT, NTFS, HFS plus X, XT4, etc.

Let's dive into FAT.

Very old, but still common on removable media.

Very common.

FAT32 especially.

Broad compatibility is its strength.

USB drives, SD cards, often FAT32.

So, yeah, still very relevant.

The book breaks FAT down into a system area and a data area.

What's in each?

System area comes first.

It has the BBR volume boot record with all the critical volume parameters.

Bytes per sector, sectors per cluster, etc.

Exactly.

And it has the FATs that the file allocation tables, usually two copies for redundancy.

This is the map of cluster usage.

And the data area.

That's where the actual files and directory structures live, including the root directory in FAT32.

Let's zoom in on that VBR and FAT partition.

What key forensic info is there?

Oh, loads.

Besides the geometry stuff, byte it, sector, sectors, cluster, it tells you how many FATs there are.

It should be two.

Total sectors, size of each FAT, location of the root directory cluster, usually cluster two for FAT32.

Volume serial number.

The book has a great diagram mapping it all out.

And the file allocation table itself, the map.

Yep.

The FAT follows the VBR.

It's just a big list of entries, one for each cluster in the data area.

And the value in each entry tells you.

Tells you the status.

Zero means the cluster is free, unallocated.

A non -zero number usually points to the next cluster used by the same file.

A special value marks the last cluster of a file.

Another special value marks a bad cluster.

So it chains clusters together to form a file.

Even if the clusters aren't physically next to each other, that's fragmentation.

The FAT links them up correctly.

Okay.

Then in the data area we find directories and files.

How are they represented?

By 32 byte directory entries.

Every file, every folder has one.

What's in the 32 bytes?

Key stuff.

The file name or part of it.

File attributes like hidden read -only, timestamps, create, modify, access, the starting cluster number where the file's data begins, and the file size in bytes.

In the file name part, the book talks about short versus long file names.

Right.

The original FAT standard only allowed short file names to classic 8 .3 format.

Eight characters, dot, three characters, uppercase, no spaces.

Very limiting.

Totally.

So later versions added support for long file names.

Elephants.

How does that work with the 32 byte entry?

Clever trick.

When you save a file with a long name, like myvacationphotos .jpg, the system still creates an 8 .3 alias, like myvaca1 .jpg.

That goes into standard 32 byte entry.

Okay.

Then it creates additional 32 byte entries before the main one.

These LFN entries store chunks of the long file name in Unicode.

They use a special attribute flag, 00F, to identify themselves as LFN entries.

A sequence number links them together.

So multiple entries build up the long name, pointing back to the main short name entry.

You got it.

Now the crucial part, recovering deleted FAT files.

Deleting doesn't wipe the data immediately.

Not usually.

When you delete a file in FAT, two main things happen.

One, the first character of its file name in the directory entry gets changed to a special marker, usually hex E5.

Signaling deleted.

Right.

Two, the entries in the FAT table corresponding to the file's clusters get zeroed out, marking those clusters as free.

The actual data in the clusters is untouched until those clusters get reused for a new file.

So recovery is possible if the clusters haven't been overwritten?

Potentially, yes.

The basic idea is to reverse the process.

Find the directory entry starting with E5.

Note its starting cluster and file size.

Okay.

Go to the FAT, find the entry for that starting cluster, which will be zero, change it to the last cluster of file marker.

If it was a multi -cluster file, you might need to try and rebuild the chain, which gets much harder if it was fragmented or partially overwritten.

Tricky.

Can be very tricky.

Then go back to the directory entry and change that E5 first character back to something valid.

The book suggests using an underscore or dash to avoid guessing the original letter and introducing bias.

Good practice.

And for LFNs.

Need to relink those LFN entries, too, using the same replacement character.

And Slackspace, what's that?

Slackspace is the wasted space at the end of the last cluster allocated to a file.

Files rarely fill clusters perfectly.

Right, if a cluster's 4KB and the file ends after 1KB into it.

You have 3KB of Slackspace in that cluster.

That Slackspace might still contain old data fragments from whatever was stored in that cluster previously.

Documents, chats, emails.

Could be anything.

Yeah.

Another place to look for residual data.

Fascinating.

Okay, let's shift to NTFS.

Modern Windows Default.

More complex than FAT.

Oh, yeah.

Significantly more complex.

Yeah.

But designed for better reliability, security, and handling large volumes.

It serves the same core purpose.

Tracking files, metadata -free space, but uses a very different structure.

The book lists key NTFS system files, which is the most important one to understand.

The MFT.

The Master File Table.

It's the heart of NTFS.

Like a database.

Essentially, yes.

Yeah.

It contains a record, a file record for every file and directory in the volume, including itself.

Okay.

Each file gets an MFT record.

Yeah, a 1024 -byte record, uniquely numbered.

It starts with a signature file.

It contains all the metadata about that file stored in the structures called attributes.

Attributes, like?

Like standard information, timestamps, flags, file name.

The file name, often multiple copies, like long and short, and data, the actual file content or pointers to it.

Let's unpack those attributes.

Standard information.

Contains the basic metadata.

Timestamps are key here.

Created, accessed, written, MFT -modified.

Also, file flags, read -only, hidden, et cetera.

Owner ID, security info.

File name.

Stores the file name, obviously.

Up to 255 Unicode characters.

Can have multiple file name attributes in one record, e .g.

the long name and the 8 .3 DOS alias.

Also has its own set of timestamps, which can sometimes differ from the standard information ones.

Yeah.

Important forensic detail.

Interesting.

And data.

This is the actual content.

It can be.

This is where resident versus non -resident data comes in.

Okay.

If the file state is small enough, the small text file, maybe it can be stored directly inside the data attribute within the 1024 -byte MFT record itself.

That's resident data.

Convenient.

Very.

But if the file is larger.

Then it's non -resident.

Exactly.

The data lives out in the main volume area.

In clusters.

The data attribute then doesn't hold the data itself, but instead holds pointers called run lists.

Telling the system where to find those data clusters.

So the run list maps out where the files pieces are.

Precisely.

It'll say something like start at cluster X, run for Y clusters, then jump to cluster Z, run for W clusters, and so on.

This handles fragmentation.

Decoding these run lists is key to finding all the data for non -resident files.

And once data goes non -resident, it stays that way.

Generally, yes.

Even if you shrink the file later, it usually won't become resident again.

NTFS definitely sounds deep.

The book says entire books are written just on NTFS.

Absolutely.

We've just scratched the surface.

But understanding the MFT file records, attributes,

and resident non -resident data gives you a solid foundation for NTFS analysis.

Okay, what an overview.

We've gone from the power button through POST, BIOS UEFI, MBR GPT partitioning, deep into FAT and NTFS file systems, even HPA DCO and Slackspace.

It really covers the essential building blocks of how computer systems store and manage data.

And you can see how understanding each layer is critical for forensics.

Knowing how it works is the only way to know how to investigate it without breaking anything or missing evidence.

Precisely.

It's about respecting the system's structure to preserve the integrity of the digital evidence.

The chapter wraps up with some review questions.

Definitely worth trying those out to check your understanding.

We'll put them in the show notes, too, without answers, of course.

Good idea.

And it recommends Brian Carrier's File System Forensic Analysis book for a much deeper dive.

Excellent resource.

We'll link that, too, and the link to our Discord community if you want to discuss the stuff further.

Yeah, please join the conversation there.

So we've covered the whole chapter on computer systems.

Boot process, partitioning, FAT, NTFS, hidden areas,

the works,

foundational knowledge for anyone in digital forensics, or really, anyone just curious about how computers handle our data.

It really is.

From the simple act of turning it on to the complex structures of NTFS, it's all interconnected.

Here's a final thought to leave you with.

Think about how this evolution,

BIOS to UEFI, FAT to NTFS,

HDDs to SSDs with trim, keeps changing the game for forensic investigators.

What might the next storage technology look like, and what new challenges or opportunities will it present?

Good question.

Always something new on the horizon.

Thanks for diving deep with us today.

We hope you found this exploration of computer systems insightful.