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.
Ever stop and think what your computer is actually doing, like right this second.
Not just the file saved on the drive, but all the stuff happening,
well, behind the scenes.
Exactly.
There's this whole temporary world of data, this sort of fleeting snapshot that can hold incredible clues.
We're talking about RAM.
Random access memory, yeah.
And what kind of secrets might be just sitting there, things you didn't even save?
Well, that's what we're diving into today.
Welcome, everyone.
We're exploring RAM forensics, drawing from the chapter on RAM memory forensic analysis in Learn Computer Forensics, second edition.
So our mission really is to help you get a solid grasp on RAM forensics.
You know, why it's so powerful for finding evidence, what tools you use, and just why it matters so much now.
Exactly.
We want to cover the fundamentals, how you actually capture this data, the analysis tools, even the legal side and best practices, all pulled from the chapter.
Okay, let's unpack that idea of RAM first, temporary storage.
The chapter uses a great analogy, like your computer's workbench or kitchen table.
Yeah, it's where everything active hangs out.
Programs you're running, websites you're browsing, background stuff.
It's all using RAM.
Which means a surprising amount of info just flows through constantly.
Absolutely.
And the kind of digital breadcrumbs you might find, well, it's quite a list.
Running programs, good ones, and maybe malware you don't even know about.
Network connections too, like who the computer's talking to.
Definitely.
Potentially unencrypted, sensitive stuff.
Maybe images or documents that were just viewed, not saved.
Even cloud service activity that might only exist in RAM.
Wow.
And things like mouse clicks, keystrokes.
Sometimes, yeah.
Recovered file fragments, clipboard text, even passwords or those critical encryption keys.
That reminds me of the case mentioned in the chapter, Rajiv Mitra back in 2004.
The real break came later, right?
Yeah, Detective Cindy Murphy went back to the RAM image years later.
She suspected the encryption keys might still be there.
And they were.
She recovered the keys, unlocked encrypted files, found illicit images.
It just shows evidence you thought was gone might just be hiding in memory.
It's a perfect example and it really highlights the difference between RAM and hard drive analysis.
The hard drive is more like a static archive.
Right, saved files over time.
But RAM is live, it's dynamic, what's happening now.
And it's incredibly transient, power off, and poof, it's mostly gone.
Even capturing it changes it.
Exactly, the active capturing RAM alters the state.
It's like trying to photograph something really fast, taking the picture itself affects the scene.
So when we talk RAM, what are the main types?
Chapter breaks it down, there's SRAM.
Static RAM, yeah.
Super fast, used for cache memory mostly.
Doesn't need constant power refresh like DRAM does.
And DRAM, dynamic RAM, that's the main memory.
Figure 7 .1 in the chapter actually shows a DRAM chip.
And important not to mix RAM up with ROM, read -only memory.
That's for boot up stuff, permanent.
Correct.
ROM holds the essential startup instructions.
And think about the amount of RAM now.
A modern 64 -bit Windows system could be up to 128 gigs.
That's a massive amount of potential evidence space.
How does the computer keep track of it all?
Addresses.
Right.
Physical addresses are the actual chip locations.
But programs use virtual addresses, which the OS translates.
Data gets moved around in these blocks called pages, usually four kilobytes.
Understanding that structure helps analysis.
Okay, and to really understand what we find, we need some OS concepts.
The chapter mentions privilege separation.
Yeah, that's key for security.
Kernel mode versus user mode.
The kernel, the core OS has full access, user apps run with fewer privileges.
Stops a rogue app from crashing everything.
Pretty much.
And apps need a way to ask the kernel for things, like file access.
That's where system calls come in.
They're like controlled requests.
Like asking the librarian, not just wandering into the back rooms.
Good analogy.
The chapter also covers process management, how the OS juggles all those running programs.
A RAM dump shows you these active processes.
And within processes, you have threads, like little workers doing specific tasks.
Exactly.
Threads are the basic unit doing the work.
Seeing processes and threads helps piece together what was happening.
So pulling it together, artifacts and RAM could be?
System info, type commands, maybe passwords?
Potentially, yes.
Encryption keys, unencrypted data being processed, IP addresses, web history, chat logs, emails, even bits of malware.
It's a digital echo.
Okay, but what if the computer's already off?
Live RAM is gone.
Are there other places to look?
Thankfully, yes.
The chapter points to the hibernation file, hyperfill .sys.
Ah, when Windows hibernates, it saves the RAM state to the disk.
Precisely.
Takes a snapshot, compresses it, saves it, allows a full power down but quick resume.
Laptops often do it when you close the lid.
And desktops if you choose hibernate.
It has headers like hyper or wake.
It does, but the chapter notes, those often get zeroed out on power up.
And because it's compressed, you need tools to decompress it.
But it's potential goldmine if live capture wasn't possible.
Definitely.
The chapter suggests forcing hibernation on scene could be a way to preserve that memory state if live capture is problematic.
Interesting.
What else?
The page file.
Page file .sys.
Right, that's virtual memory.
When physical RAM is full, less used data gets swapped out to the page file on the hard drive.
So it extends your RAM capacity,
essentially.
Slower, but lets you run more stuff.
Exactly.
Usually one to three times the size of the screen.
And then there's the swap file.
Swap file .sys that came in with Windows 8.
Yeah, similar idea, but specifically for those modern Windows apps when they're suspended.
Helps free up physical RAM quickly.
Okay, and finally crash dumps.
Memory .dmp.
The blue screen of death files.
Right.
If the system crashes, it can save a memory snapshot.
Invaluable for figuring out what went wrong.
Different types, though.
Complete, kernel, small dump.
Yeah, complete is but huge.
Kernel is just OS data.
Small dumps have limited info like processes and drivers.
And can check the registry to see if dumps are even enabled.
You can.
The system highs has a key crash dump enable under current control, crash control, tells you if they're on and where they're saved.
But these dump files need special tools to read.
They're proprietary.
Usually, yes.
The chapter mentions commie .com as a place that might have tools for that.
Okay, so let's talk actually RAM.
The chapter really stresses something critical here.
It does.
The act of capturing RAM changes the system.
You can't get around that entirely.
SWGDE, the scientific work group on digital evidence, has guidelines on this, right?
Yes.
Things to consider.
The capture tool itself uses memory, potentially overwriting evidence.
If you boot from USB, that loads drivers, might change the registry.
And the tool itself shows up in logs, like most recently used lists.
Absolutely.
Plus, there's always a risk, especially on order systems, that the capture process can make the system unstable or even crash it.
So the investigator really needs to know their tools and how they affect different OCs, weigh the risks and benefits.
Crucial.
And if you go ahead, you need a few things.
A clean capture device, usually a USB stick.
Physical access to the machine and admin rights, usually.
Right.
And prepare that USB drive format as NTFS, avoids file size limits, because the RAM image will be about the size of the installed RAM.
Okay, capture successful.
Now, analysis,
making sense of that raw data dump.
The chapter gets into the tools,
open source and commercial options, like with disk forensics.
Exactly.
The chapter focuses on a couple of powerful open source ones.
First up is bulk extractor.
Bulk extractor.
How does that work?
It sounds like you just pull stuff out in bulk.
Sort of.
It ignores the file system structure and just scans the raw data disk image, RAM dump, whatever, for patterns, like email addresses, URLs, credit card numbers, things like that.
And it's fast.
Very fast.
It processes chunks in parallel.
It creates histograms, too, showing how often it found certain types of data.
Figure 7 .9 shows output options.
How do you use it?
Basic use in the viewer.
Point it at the memory image.
Pick an output folder.
Figure 7 .11 shows the huge list of scanners it uses.
You can even pick and choose which ones to run.
And the output.
Figure 7 .33 shows the viewer.
The example uses an email histogram file, finding jCloudy1 like 8 ,000 times.
Its real strengths is quickly finding interesting strings in a huge data set for you to investigate further.
Okay, speed and broad scanning.
What's next?
Volatility.
Ah, volatility.
That's a big one.
It's an open source framework, really comprehensive, built for incident response and malware analysis.
And it works on different systems, Windows, Linux, Mac.
Yes, and even Android memory dumps.
It has tons of plugins for analyzing specific things, finding malware traces, process information, network stuff, you name it.
Very powerful, very flexible.
Sounds powerful, but maybe requires some command line skill.
It often does.
Which leads to the next tool the chapter mentions,
Volikes2v2.
Volikes1.
What's that?
It's basically a graphical front end for volatility.
Makes it more user friendly if you're not keen on the command line.
Point and click interface for volatility's power.
So it makes volatility easier to use?
That's the idea.
Figure 7 .42 shows the setup you tell it where volatility is.
Choose your language.
It can even link up with VirusTotal to check findings or John the Ripper to try and crack passwords found in the dump.
How does the point it to the memory file, setup reporting.
Then there's a wizard, Figure 7 .16, that asks what you want to find or offers preset scripts like for virus detection or decrypting SAM hashes.
SAM hashes, Windows password stuff.
Exactly.
Figure 7 .17 shows some sample results like extracted SIDs, user identifiers.
The chapter notes scan time depends on what you ask to look for, but it's generally quite quick.
A nice GUI option.
Okay, so wrapping up this deep dive on the chapter.
It's crystal clear RAM is just packed with potential evidence, stuff you won't find elsewhere.
Absolutely.
We've covered the basics of how it works, where else you might find memory data like hibernation files or page files and looked at tools to capture and analyze it.
Like bulk extractor for fast scanning and volatility, maybe via VOLIIGX for deeper dives.
Right.
And the chapter makes a key point.
This field changes fast, tools evolve, OS updates can cause issues, always need to stay current, have backup plans.
But equipped with what we've discussed, you should have a really good foundation now.
You understand the why, the where, the how of capturing RAM using best practices and where to start with analysis.
And the potential findings are exciting user activity, social media traces, passwords, those crucial encryption keys, email info, which as the chapter notes, tees up the next topic on email forensics.
The chapter also has review questions, recommends the art of memory forensics for a deeper dive and even points to a discord community.
Lots of resources.
So as you think about your own digital world, remember RAM,
that fleeting temporary space.
How often is critical information, sensitive data, maybe even a key decision only existing there for a moment.
What does that mean for privacy, for security, for how we trace digital footprints?
Something to really think about.
Thanks for joining us on this deep dive into the fascinating world of RAM forensics.