Speaker 1: Imagine this. You're watching a crime drama, right, and the
Speaker 1: detective they're dusting for fingerprints. Classic stuff.
Speaker 2: Yeah, you see it all the time, but honestly.
Speaker 1: In the real world today that's almost quaint, like a
Speaker 1: rotary phone. Today, the fingerprints, they're digital and they're.
Speaker 2: Everywhere, absolutely everywhere.
Speaker 1: We're talking the smartphone in your pocket, the sat NAV
Speaker 1: in your car, even your home CCTV that's running twenty
Speaker 1: four to seven. These digital traces, they used to be
Speaker 1: just for specific cybercrimes, but now now they're found in
Speaker 1: almost every case. It's not just evidence anymore. It's really
Speaker 1: an explosion of it.
Speaker 2: It truly is. The sheer amount and well the variety
Speaker 2: of digital devices mean pretty much any incident, you know,
Speaker 2: from a minor theft all the way up to a
Speaker 2: major criminal investigation, it leaves a digital footprint something that
Speaker 2: wasn't even really conceivable a few decades back, exactly.
Speaker 1: And for you listening in this deep dive, it's your
Speaker 1: shortcut to getting properly well informed about this hidden world.
Speaker 1: We're not just going to scrap it's the surface of
Speaker 1: what information is found, No, definitely not. Our mission here
Speaker 1: is to pull back the curtain on how it stored,
Speaker 1: how it gets retrieved, and maybe most importantly, why understanding
Speaker 1: those hidden mechanics, Well, why it fundamentally reshapes an investigation
Speaker 1: and maybe even our idea of digital truth.
Speaker 2: Yeah, and our deep dive today it's built from sources
Speaker 2: that really focus on file system forensics. So we're going
Speaker 2: to give you a detailed look at how data is
Speaker 2: organized write down at its most fundamental level. We'll look
Speaker 2: at the essential tools investigators used to uncover it and
Speaker 2: the fascinating, sometimes pretty complex challenges that lie ahead in
Speaker 2: this field because it's evolving so fast.
Speaker 1: Okay, so we've painted this picture digital evidence exploding everywhere.
Speaker 1: But here's where it starts to get tricky. The very
Speaker 1: basic rules for collecting this evidence they've been shifting under
Speaker 1: our feet. Let's dig into what we're calling the shifting
Speaker 1: sands of digital evidence, because what worked maybe ten years
Speaker 1: ago could actually compromise an entire case.
Speaker 2: Now, that's right.
Speaker 1: For years, the standard advice for seizing a computer and
Speaker 1: an investigation was just dead simple, pull the plug, just
Speaker 1: cut the power immediately. Yep, that was the gold standard.
Speaker 2: But today doing that can be a huge mistake. Why
Speaker 2: is that old rule suddenly so well dangerous.
Speaker 1: What's fascinating, I think is that modern operating systems, in hardware,
Speaker 1: they've introduced features that directly conflict with that old advice.
Speaker 1: Think of it like this. For encrypted storage, right, the
Speaker 1: decryption keys often only live in the computer's volatile memory.
Speaker 1: It's RAM, basically, it's short term digital brain. Okay, So
Speaker 1: you pull the plug, those keys just vanish instantly, and
Speaker 1: all that data becomes a locked box, you know, permanently inaccessible.
Speaker 1: It's like trying to open a safe after the combination's
Speaker 1: just been wiped from the manager's memory.
Speaker 2: Right gone forever. And people aren't just saving things locally anymore,
Speaker 2: are they. They're using remote storage, cloud services, email, social.
Speaker 1: Media constantly connects.
Speaker 2: So if you yank the power, all those live connections,
Speaker 2: all that access to potentially crucial data, it's instantly.
Speaker 1: Lost, exactly. And this is why live data forensics or
Speaker 1: LDF has become so critical. It lets analysts capture that
Speaker 1: live data from a running computer system before it disappears.
Speaker 1: But hang on, that sounds like it completely contradicts one
Speaker 1: of the most fundamental principles of forensics, doesn't it.
Speaker 2: It absolutely does, And this raises a really critical point.
Speaker 2: The first principle in digital forensics. It's often called ACPO
Speaker 2: principle one. It states that no action taken by law
Speaker 2: enforcement agencies should change data which may subsequently be relied
Speaker 2: upon in court. Okay, LDF, well, it inherently breaks this principle.
Speaker 2: I mean, even just moving a mouse on a running
Speaker 2: system leaves digital traces. So the tension there, it's very real.
Speaker 1: So, Okay, if you're altering the data, how on earth
Speaker 1: can it be admissible in court? Doesn't that just open
Speaker 1: the evidence up to immediate challenge, Say you changed it?
Speaker 2: Well, not necessarily the principles themselves, they're actually still fit
Speaker 2: for purpose, but they kind of adapt. So while LDF
Speaker 2: does alter data, it can be admissible in court when
Speaker 2: you combine it with ACPO principle two, which emphasizes investigator competence,
Speaker 2: and principle three, which demands a really thorough audit trail.
Speaker 1: Ah okay, the paperwork.
Speaker 2: Essentially, yeah, it means every single step taken, every command run,
Speaker 2: every change made, it has to be meticulously documented. And
Speaker 2: it's that meticulous record keeping that allows the court to
Speaker 2: understand and hopefully trust, the context of the altered data.
Speaker 2: The integrity of the whole investigation now relies on understanding
Speaker 2: that fundamental shift in collection and then just rigorously documenting
Speaker 2: every single step.
Speaker 1: Right. Speaking of integrity, let's talk about maybe an unsung
Speaker 1: hero of digital forensics. Linux. It's often called an open
Speaker 1: source powerhouse in this field. But what does open source
Speaker 1: actually mean? Is it just about software you don't have
Speaker 1: to pay for.
Speaker 2: That's a common misconception. To really get open source, it
Speaker 2: helps to contrast it with closed source software. So imagine
Speaker 2: I write a simple Hello World program and see.
Speaker 1: Right, okay.
Speaker 2: With closed source, i'd give you the compile executable file.
Speaker 2: You can run it, sure, but you can't see the
Speaker 2: underlying code. You can't change it. It's like a mystery
Speaker 2: box that just well does its thing right.
Speaker 1: You just trust it works exactly.
Speaker 2: With open source, though, I give you the actual c
Speaker 2: program file, the source code. You can read it, you
Speaker 2: can understand exactly what it does, and you can even
Speaker 2: modify it if you've got the skills. Richard Stallman, the
Speaker 2: founder of the Free Software Foundation. He famously said that
Speaker 2: free in open source means free as in free speech,
Speaker 2: not free as in free beer.
Speaker 1: Ah. That's a great distinction.
Speaker 2: It is so while it's often free of costs because
Speaker 2: of the lightnsing, the core idea is really the freedom
Speaker 2: to examine, use, and modify the code.
Speaker 1: That distinction is key. So why is this open source model,
Speaker 1: particularly Linux, such an advantage for forensics. It seems a
Speaker 1: bit counterintuitive that something anyone can tinker with would be
Speaker 1: more trustworthy.
Speaker 2: Maybe well, it's precisely because anyone can modify it, or
Speaker 2: at least examine it, that it's often seen as more trustworthy.
Speaker 2: There are a few big reasons. First, there's community power.
Speaker 2: Open source projects often have these huge communities of users, developers, testers,
Speaker 2: all working together. This collective effort often leads to new
Speaker 2: features being introduced faster and crucially, issues being resolved much
Speaker 2: quicker than with small proprietary teams.
Speaker 1: So it's not just about speed then, does that community
Speaker 1: scrutiny also directly help with the trustworthiness and accuracy of
Speaker 1: the tools, which must be absolutely paramount when potentially lives
Speaker 1: depend on them.
Speaker 2: That's exactly it. More eyes on the code, more brain
Speaker 2: solving problems. This leads directly to greater trust and correctness.
Speaker 2: With closed source software, you're essentially relying on the developers
Speaker 2: having got everything right, and we've all seen the infamous
Speaker 2: blue screen of death in Windows. For example, With open source,
Speaker 2: the community can review and fix the code at any point.
Speaker 2: That provides a lot more confidence in the tool's accuracy, which,
Speaker 2: as you say, is vital when people's lives might depend
Speaker 2: on the investigation's outcome. Makes sense, and yes, cost effectiveness
Speaker 2: is a major advantage too. Because of copyleft licensing requirements,
Speaker 2: it's actually quite difficult to sell open source software directly,
Speaker 2: so it's often free of cost. Now, companies can still
Speaker 2: offer services like training or customization around these products, but
Speaker 2: the core software itself is usually freely available. And lastly,
Speaker 2: specifically for forensics, Linux offers great support for many file
Speaker 2: systems by default, often much more than Windows or Mac
Speaker 2: OS natively support, which makes it a really ideal forensic
Speaker 2: workstation right out of the box.
Speaker 1: So when we talk about Linux as an operating system,
Speaker 1: what are its main parts? You hear about the kernel,
Speaker 1: but what else makes it a functioning OS?
Speaker 2: Yeah, good question. At its very heart is the kernel,
Speaker 2: which was created by Linus Torvold's that's the bit that
Speaker 2: directly controls the hardware and manages the software. Then layered
Speaker 2: on top of that are the GNU utilities. These are
Speaker 2: standard programs that let users control files, run programs, that
Speaker 2: sort of thing. It's really the combination of the Linux
Speaker 2: kernel and these GENU utilities that forms the functional operating
Speaker 2: system we commonly just call Linux. Beyond that core, you've
Speaker 2: got graphical desktop environments, the visual interface most people see,
Speaker 2: and of course all the application software the end users
Speaker 2: are most familiar with, including those powerful forensic tools we've
Speaker 2: been mentioning.
Speaker 1: Okay, let's get practical then. What are some basic, really
Speaker 1: fundamental forensic commands in Linux that investigators are using day
Speaker 1: to day. These must be like the digital equivalent of
Speaker 1: a magnifying glass and dusting powder.
Speaker 2: Definitely, one of the most fundamental is hashing. This is
Speaker 2: absolutely crucial for ensuring data integrity.
Speaker 1: Okay, how did that work? Well?
Speaker 2: Hashing algorithms like say MD five or the Saha family.
Speaker 2: They create a unique digital fingerprint for any piece of data.
Speaker 2: If even a single bit is changed in a file,
Speaker 2: its hash value will change traumatically. It's like if you
Speaker 2: change just one letter in the entire collected works of Shakespeare,
Speaker 2: the hash would completely change instantly, confirming even the tiniest alteration.
Speaker 1: Wow. So if someone sends you a file and you
Speaker 1: calculate its hash, you can instantly verify it hasn't been
Speaker 1: tampered with since they calculated their ash. Yeah, that's powerful.
Speaker 2: It is very powerful. Now. While some smaller hashes like
Speaker 2: CRC threety two maybe can sometimes experience hash collisions, that's
Speaker 2: where different inputs accidentally produce the same hash, using larger
Speaker 2: outputs like SAHA five twelve, or maybe using multiple different
Speaker 2: algorithms together, that greatly reduces that probability to almost zero.
Speaker 1: Got it? What else?
Speaker 2: Another really useful tool is hex viewers like XXD. This
Speaker 2: lets analysts examine raw binary data, bite by byte, things
Speaker 2: like a discs partition table for example. It's like looking
Speaker 2: at the absolute purest form of the computer's language, the
Speaker 2: ones and zeros represented compactly. This often requires root access, though,
Speaker 2: using the pseudo command.
Speaker 1: Okay, and then there's strings I've heard that's a really
Speaker 1: really powerful one for investigators. What makes it so special?
Speaker 1: It really is?
Speaker 2: The strings command is deceptively simple but incredibly useful. It
Speaker 2: displays all the printable as key carecharacters it finds within
Speaker 2: any file, even binary file, so even.
Speaker 1: In like an image file or a program exactly.
Speaker 2: Even if a file is an image or an executable program,
Speaker 2: strings can pull out any plain text that happens to
Speaker 2: be embedded within it. And when you combine it with
Speaker 2: EGREP for text searching, it becomes a very powerful forensic
Speaker 2: tool for quickly finding keywords or phrases within potentially massive
Speaker 2: amounts of raw data. That sounds incredibly useful, and the
Speaker 2: AT option is particularly useful. It displays the bite offset,
Speaker 2: basically the address where the text is found. This lets
Speaker 2: an investigator navigate directly to that specific spot within the
Speaker 2: file or the disc image using other tools.
Speaker 1: So it's not just about finding a keyword, it's about
Speaker 1: the context, seeing what's around it. I imagine that's crucial
Speaker 1: when you're dealing with huge amounts of data where a
Speaker 1: word might appear harmlessly in one place, but maybe sinatraily
Speaker 1: in another, all hidden away in binary code.
Speaker 2: Precisely, it's not just finding the needle in the haystack.
Speaker 2: It's like finding a specific pollen grain on that needle,
Speaker 2: and it's precise digital address. It's truly granular work.
Speaker 1: That's incredible. Okay, that's a great segue into understanding the
Speaker 1: hidden language, how computers speak in ones and zeros. I mean,
Speaker 1: at the end of the day, it's all just zeros
Speaker 1: and ones, right, But how do they turn that into
Speaker 1: something we actually understand, like text or numbers.
Speaker 2: It is all zeros and ones. But how those zeros
Speaker 2: and ones are interpreted? That's the key. Computers, as you say,
Speaker 2: use the binary number system base two. Humans we generally
Speaker 2: use decimal base ten, but in computing you'll very often
Speaker 2: encounter hexadecimal or hex, which is base sixteen. It uses
Speaker 2: the digits zero through nine and then the letters A
Speaker 2: through F to represent the values ten to fifteen. Hexadeesimal
Speaker 2: is simply a much more compact way to represent binary
Speaker 2: data for human eyes.
Speaker 1: Okay, so it's like a shorthand exactly.
Speaker 2: For example, the binary number ten eleven that's one zero,
Speaker 2: one one is equivalent to eleven in our decimal system.
Speaker 2: In hex, it would be b. It just makes reading
Speaker 2: long strings of binary data much easier.
Speaker 1: Okay, that makes sense. Then there's text. My computer understands
Speaker 1: what I type, But how does it turn the letter
Speaker 1: a into numbers and then back again.
Speaker 2: Ah, that's where character encodings come in. They basically assign
Speaker 2: a unique numerical code to each character. Letter's numbers, symbols
Speaker 2: everything like a secret codebook kind of Older encodings like
Speaker 2: ASE and ISO eight eight five nine, they were quite limited.
Speaker 2: They worked well for English, but struggled with special characters
Speaker 2: like maybe the A character in Spanish or other European languages.
Speaker 2: They simply didn't have enough codes assigned for every symbol
Speaker 2: used across.
Speaker 1: The world, Which is where Unicode and UTF eight step in,
Speaker 1: I guess correct.
Speaker 2: Unicode is this huge standard that supports a vast range
Speaker 2: of characters from pretty much all the world's writing systems.
Speaker 2: It covers virtually every character you could imagine, and UTF
Speaker 2: eight is a specific encoding method for Unicode. It's a
Speaker 2: variable width encoding, which cleverly solves the storage inefficiency you'd
Speaker 2: get if every single character took up say four bites.
Speaker 2: UTF eight uses anywhere from one to four bytes per character,
Speaker 2: so it adapts exactly. This makes it the de facto
Speaker 2: standard for web pageing coding and much more. What's really
Speaker 2: clever about UTF eight is that standard English ACI characters
Speaker 2: ABC one, two three, they are represented identically to their
Speaker 2: original ACI form, taking up just one byte, but more
Speaker 2: complex characters like emojis or characters from other alphabets, they
Speaker 2: might take two, three, or four bytes. So it's incredibly
Speaker 2: efficient for common text, but flexible enough for global communication.
Speaker 1: That's smart. And what about time? How do computers keep
Speaker 1: track of that down to the you know, the millisecond
Speaker 1: or even nanosecond, which must be crucial for an investigation
Speaker 1: and timeline.
Speaker 2: Time representation in computing is another fascinating area. Many systems,
Speaker 2: especially Unix like systems like Linux and mac os, use
Speaker 2: what's called Unix time.
Speaker 1: Right, I've heard of that.
Speaker 2: It's measured as a number of seconds that have elapsed
Speaker 2: since midnight UTC on January first, nineteen seventy. That specific
Speaker 2: moment is known as the epoch.
Speaker 1: Okay, so just a big counter of seconds. But what
Speaker 1: if two things happen really fast, like within the same second,
Speaker 1: would they have the exact same time stamp? That could
Speaker 1: be a real problem for investigators trying to figure out
Speaker 1: the exact order of events, especially if automated processes are involved.
Speaker 2: It absolutely could be, and it was a limitation. While
Speaker 2: maybe not an issue for things happening at human speed,
Speaker 2: automated processes can access or modify many files within a
Speaker 2: single second. This meant older filesystems like say x two
Speaker 2: to two, which only had second level granularity, couldn't always
Speaker 2: definitively say which isn't happened first if they occurred in
Speaker 2: the same second.
Speaker 1: So how do they fix that?
Speaker 2: Well, most modern implementations of UNIX time, like you find
Speaker 2: in the XT four filesystem, for example, they now include
Speaker 2: a nanosecond subcomponent. Nanosecond yeah, billions of a second. This
Speaker 2: significantly improves the granularity, allowing for incredibly precise ordering of
Speaker 2: events and file creation timestamps that can be absolutely crucial
Speaker 2: for building an accurate forensic timeline.
Speaker 1: That's a huge leap in precision. Okay, one more weird
Speaker 1: term before we move on. Indian thiss. That sounds like
Speaker 1: something out of Gulliver's Travels or I don't know, a
Speaker 1: really obscure technical debate. What's that about?
Speaker 2: Huh? It does sound a bit strange, doesn't it, But
Speaker 2: it's actually crucial for correctly interpreting raw Heck's data off
Speaker 2: a disc. Indianness is just about the order in which
Speaker 2: computers store or read multi byte numbers. Okay, how so
Speaker 2: imagine writing down a date. Do you write month, day
Speaker 2: year like in the US or day month year like
Speaker 2: in Europe. It's the same information, right, just a different order.
Speaker 1: Gotcha.
Speaker 2: Computers have a similar choice for numbers. Big Indian is
Speaker 2: like writing one twenty three. The most significant bite, the
Speaker 2: one hundred's part, comes first. Little Indian, which is more
Speaker 2: common on PCs, is like writing three twenty one. The
Speaker 2: least significant bite, the ones part, comes first.
Speaker 1: So why does that matter for forensics?
Speaker 2: Because if you pull raw data off a disc, maybe
Speaker 2: from a critical system boot file or a timestamp field,
Speaker 2: and you don't know the reading order, the indianness of
Speaker 2: the system that wrote it, you'll completely misinterpret what those
Speaker 2: bites actually report. It could be the difference between seeing
Speaker 2: December fifth and May twelfth in a critical timestamp, just
Speaker 2: based on reading the bytes in the wrong order.
Speaker 1: Okay, crucial detail. Then, with that secret language sort of decoded,
Speaker 1: let's zoom out a bit from the individual bits and
Speaker 1: bytes to the actual landscape where all this data lives.
Speaker 1: We're moving to the disks, partitions, and file system fundamentals,
Speaker 1: the very architecture of digital storage. Starting with how computers
Speaker 1: organize information physically, What are the different types of storage
Speaker 1: and which ones are most relevant for forensics?
Speaker 2: Right? Computer storage is usually classified into a few tiers, primary, secondary, tertiary,
Speaker 2: and offline. Primary storage is typically RAM random access memory,
Speaker 2: and the key thing about RAM is that it's volatile,
Speaker 2: meaning all the information stored in it is lost as
Speaker 2: soon as the power is removed. This is exactly why
Speaker 2: live data forensics LDF is so critical. As we've discussed,
Speaker 2: RAM holds so many ephemeral details about what was just
Speaker 2: happening on the system's story, open documents, running processes, network connections,
Speaker 2: those encryption keys we mentioned.
Speaker 1: Stuff you lose if you just pull.
Speaker 2: A plug precisely. Then you have secondary storage. This includes
Speaker 2: your traditional hard disk drives HDDs and the now very
Speaker 2: common solid state drives SSDs. This is where most of
Speaker 2: our persistent data resides, the stuff that stays when the
Speaker 2: power is off.
Speaker 1: And SSDs would you're everywhere now. Because they're so fast
Speaker 1: and efficient, they bring their own unique forensic headaches, don't they.
Speaker 1: I've heard they can be kind of a forensic investigator's
Speaker 1: nightmare compared to the old spinning hard drives.
Speaker 2: They absolutely do post some unique SSD specific challenges because
Speaker 2: of how they work fundamentally differently from HDDs see. Unlike HDDs,
Speaker 2: the flash memory components inside an SSD can only be
Speaker 2: written to a limited number of times before they wear out,
Speaker 2: so to extend the drives lifespan, the SSD controller employs
Speaker 2: techniques like were leveling. This involves intelligently moving data around
Speaker 2: independently of the operating system just to make sure all
Speaker 2: the memory cells get written to roughly the same amount.
Speaker 1: So the controller is shuffling data behind the.
Speaker 2: Scenes exactly, which makes predicting the precise physical location of
Speaker 2: a specific piece of data for forensic analysis much harder.
Speaker 2: You can't just assume data stays put in one physical
Speaker 2: spot like you mostly could on an HDD.
Speaker 1: So data might not be where the operating system thinks
Speaker 1: it is. That sounds like a constant game of digital
Speaker 1: hide and seek.
Speaker 2: It can be, and it gets worse even more critically
Speaker 2: when the operating system marks data as unallocated, which happens
Speaker 2: when you delete a file. Modern SSDs use a function
Speaker 2: called trim. The OS basically tells the SSD controller, Hey,
Speaker 2: we don't need the data in these.
Speaker 1: Blocks anymore, and the controller.
Speaker 2: The controller can then internally mark those blocks for erasure,
Speaker 2: often almost immediately, as part of its garbage collection routines.
Speaker 2: This means that deleted files are much less likely to
Speaker 2: be present and recoverable on SSDs than on traditional HDDs,
Speaker 2: where the data just sat there until overwritten.
Speaker 1: Wow, so deleting really means deleting much more often on
Speaker 1: ans sat often.
Speaker 2: Yes, And here's the real kicker for forensics. These SSD
Speaker 2: controllers run their garbage collection routines in the background while
Speaker 2: the drive is powered on. This means that potentially data
Speaker 2: is changing on the device in question, even if it's
Speaker 2: just sitting there, plugged in as evidence doing nothing.
Speaker 1: From the OS perspective, WHOA, So the evidence is potentially
Speaker 1: altering itself.
Speaker 2: Exactly, which, as you can imagine, directly breaks the principle
Speaker 2: of not altering evidence. It's a fundamental conflict that investigators
Speaker 2: have to be acutely aware of when dealing with SSDs.
Speaker 1: That's a huge, huge challenge to the core ideas of forensics. Okay,
Speaker 1: so physical discs, whether HDD or SSD, they're often divided
Speaker 1: into partitions. Why do we do that? What's the purpose
Speaker 1: of these logical divisions?
Speaker 2: Partitions are essentially logical divisions of a single physical disc.
Speaker 2: They allow that one physical disc to be split into
Speaker 2: multiple logical areas, each of These areas can then contain
Speaker 2: a different file system or even a different operating system.
Speaker 2: For you might have one partition for Windows and another
Speaker 2: for Linux on the same drive, or maybe a separate
Speaker 2: partition just for your user data.
Speaker 1: Okay, and there are different ways these partitions are laid
Speaker 1: out on the disc. Right, Like MBR versus GPT. What's
Speaker 1: the practical difference there for someone investigating a system.
Speaker 2: Yes, MBR Master Boot Record and GPTGII Partition Table are
Speaker 2: the two main schemes used to define how partitions are
Speaker 2: organized on a disc. MBR is the older standard. GPT
Speaker 2: is more modern and allows for well far more partitions
Speaker 2: on a single disk, and also provides greater space for
Speaker 2: storing partition information compared to the very limited.
Speaker 1: Space in the MBR, so more robust.
Speaker 2: Generally, Yes, For an investigator, knowing which scheme is used
Speaker 2: tells you where to look on the disc for critical
Speaker 2: boot information and how that disc is logically structured overall.
Speaker 1: Got it. Let's zoom in again now to the core
Speaker 1: filesystem concepts. These are the real nuts and bolts of
Speaker 1: how files actually live on a disc, and understanding them
Speaker 1: can reveal hidden data. What's a cluster or block, and
Speaker 1: why does that basic unit mate or so much?
Speaker 2: Right? A cluster, sometimes called a block, is the basic,
Speaker 2: smallest allocatable unit of storage within a file system. Think
Speaker 2: of it like building blocks. Even if you have a
Speaker 2: tiny file that's only say, one byte in size, the
Speaker 2: filesystem has to alligate an entire cluster to store it.
Speaker 2: That cluster might be, for instance, forty ninety six bytes, so.
Speaker 1: One byte of data, except forty ninety six bytes of.
Speaker 2: Space exactly the remaining forty ninety five bytes in that cluster.
Speaker 2: The space between the end of the actual file data
Speaker 2: and the end of the cluster. That's known as slack space.
Speaker 1: And that's interesting because.
Speaker 2: Because this slack space isn't necessarily empty, it can contain
Speaker 2: data from previous files that happen to occupy this cluster
Speaker 2: before the current file was written there. It might hold
Speaker 2: fragments of old documents, emails, chatlogs, religual evidence that was
Speaker 2: never fully overwritten. It can be a real gold mine
Speaker 2: for investigators.
Speaker 1: Wow, okay, and unallocated space. That sounds like just empty space,
Speaker 1: But I have a feeling it's not always truly empty either.
Speaker 2: You're right, it often isn't. Unallocated space is simply disk
Speaker 2: space that isn't currently assigned to any active file by
Speaker 2: the filesystem. But crucially, when a file is deleted, especially
Speaker 2: on older hgds, less so on trim abled SSDs, its
Speaker 2: content often isn't wiped immediately. The space is just marked
Speaker 2: as available. The actual data might still be physically present
Speaker 2: in that unallocated space, just waiting to be overwritten by
Speaker 2: new data eventually.
Speaker 1: Which is why you need a full copy exactly.
Speaker 2: This is precisely why forensic investigators always aim to create
Speaker 2: a bit by bit image of the device. This ensures
Speaker 2: that all the unallocated space is captured and can be
Speaker 2: analyzed later. If you just copied the active files, you'd
Speaker 2: miss all that potential evidence of deleted but still recoverable files.
Speaker 1: Makes sense, What about file fragmentation? Does that just make
Speaker 1: file slow to load or does it complicate forensics too?
Speaker 2: File fragmentation happens when there isn't a single large enough
Speaker 2: continuous area on the disc to store an entire file
Speaker 2: when it's first written or when it grows, so the
Speaker 2: file system has to split the file into multiple pieces
Speaker 2: or fragments, and store them in different physical locations on
Speaker 2: the disc. Okay, while it can definitely affect performance for forensics.
Speaker 2: It means that to recover or analyze that file, you
Speaker 2: first have to find and correctly reassemble all those scattered fragments.
Speaker 2: It's like putting together a jigsaw puzzle, sometimes with missing
Speaker 2: pieces or pieces from different puzzles mixed in.
Speaker 1: It adds complexity, right, and something called copy on write
Speaker 1: or COWW. That sounds like maybe a way to preserve
Speaker 1: data rather than lose it.
Speaker 2: It is in a way copy on righte. COWW is
Speaker 2: a strategy used in many modern file systems like APFS
Speaker 2: and others. When a resource like a file block is
Speaker 2: about to be modified. Instead of overwriting the original data directly,
Speaker 2: the filesystem first makes a copy of the original block
Speaker 2: and then writes the changes to the new block.
Speaker 1: Ah, so the old version sticks around for a while.
Speaker 2: Potentially yes, it means the original data might still be
Speaker 2: present somewhere on the disc, offering the potential to discover
Speaker 2: earlier versions of artifacts or files. This is also fundamental
Speaker 2: to how filesystem snapshots work. The preserve a view of
Speaker 2: the filesystem at a specific point in time by referencing
Speaker 2: these older, unmodified blocks. These snapshots are great for backups
Speaker 2: but also incredibly valuable for forensic analysis to see what
Speaker 2: the system look like at a previous state.
Speaker 1: Very cool. Finally, in this section, what's RAID? I usually
Speaker 1: hear that mentioned in the context of big server storage
Speaker 1: or maybe backups.
Speaker 2: RAID stands for a redundant array of independent discs. It's
Speaker 2: a technology that combines multiple physical disc drives into a
Speaker 2: single logical unit that the operating system sees as one
Speaker 2: big disc.
Speaker 1: Why do that?
Speaker 2: It can be done for various reasons. Sometimes it's just
Speaker 2: to create one large, consolidated filesystem from several smaller discs.
Speaker 2: That's RAID zero, which focuses on performance or size but
Speaker 2: offers no redundancy. Or more commonly, it's done for redundancy
Speaker 2: and fault tolerance. For instance, RAD one marrors data exactly
Speaker 2: across two or more drives. If one fails, the data
Speaker 2: is safe on the other. RAT five uses parity information
Speaker 2: striped across drives, allowing for a single drive to fail
Speaker 2: without any data.
Speaker 1: Loss and for forensics.
Speaker 2: For forensics, analyzing a RATE array means understanding how the
Speaker 2: data is striped or mirrored across those multiple physical discs.
Speaker 2: You often need to image all the member discs and
Speaker 2: then use specialized software to reconstruct the original logical volume
Speaker 2: before you can even start analyzing the filesystem on top
Speaker 2: of it. It adds another layer of complexity.
Speaker 1: Fascinating. Okay, let's move on and take a quick tour
Speaker 1: of con file systems. These are like the different languages
Speaker 1: or organizational schemes and operating systems used to manage all
Speaker 1: these bits, bytes, clusters and partitions we've been talking about.
Speaker 1: We'll start with the old, reliable FAT and its newer
Speaker 1: cousin x fat sure.
Speaker 2: The FAT file Allocation Table filesystem is well, very old
Speaker 2: and relatively simple in its structure. It basically consists of
Speaker 2: only three main components, the boot sector, the file allocation
Speaker 2: table itself which tracks cluster usage, and the directory entries.
Speaker 2: Because of its simplicity and wide compatibility, you still find
Speaker 2: it very commonly on removable media like USB drives and
Speaker 2: older SD cards, but it.
Speaker 1: Had limitations, especially with file size.
Speaker 2: Big Time FAT thirty two, the most common version, famously
Speaker 2: had a four gigabyte limit for single files, which is
Speaker 2: tiny by today's standards. That's where x fat comes in.
Speaker 2: It's a newer file system, also for Microsoft, designed specifically
Speaker 2: for larger removable media. Like modern high capacity SD cards
Speaker 2: and USB drives.
Speaker 1: What's the key difference?
Speaker 2: A key improvement is its support for much larger files.
Speaker 2: XPECT can handle files up to theoretically one hundred and
Speaker 2: twenty eight petabytes that's pb, which is enormous. It achieves
Speaker 2: this partly by using eight byte values to store file
Speaker 2: sizes compared to FAT thirty two's four byte values, so
Speaker 2: it's much better suited for things like large video files
Speaker 2: on flash drives.
Speaker 1: Okay, then there's the standard for Windows for a long
Speaker 1: time now and TFS. What are it is? Defining features?
Speaker 1: What makes it such a robust system? And what kind
Speaker 1: of hidden details might it hold for investigation? Right?
Speaker 2: NTFS New Technology Filesystem has been the default for Windows
Speaker 2: for decades now, and it's a much more complex and
Speaker 2: robust filesystem than FAT. One key feature is journaling.
Speaker 1: What does that do?
Speaker 2: Journaling means the filesystem records pending changes to its metadata
Speaker 2: in a log or journal before actually committing those changes
Speaker 2: to the main filesystem structures. This makes NTFS much more
Speaker 2: fault tolerant. If the system crashes mid operation, it can
Speaker 2: use the journal to recover and ensure the filesystem structure
Speaker 2: remains consistent reducing the risk of data corruption.
Speaker 1: That sounds important very.
Speaker 2: NTFS also supports something called alternate data streams or ADS.
Speaker 2: This allows multiple separate streams of data to be associated
Speaker 2: with a single.
Speaker 1: File name like hidden attachments.
Speaker 2: Kind of Yeah, the main file data is in one stream,
Speaker 2: but you can attach other hidden streams. These aren't always
Speaker 2: visible through standard tools like Windows Explore, so they have
Speaker 2: sometimes been used to hide information maybe malware components or
Speaker 2: other data. Instigators definitely need to check for ADS.
Speaker 1: So it's like a hidden digital tag or a secret
Speaker 1: compartment within a file. Have investigators found surprising ways these
Speaker 1: ADS are used, maybe to trace a file's origin absolutely.
Speaker 2: For example, a common ADS you might encounter, maybe without
Speaker 2: realizing it, is the zone dot identifier. Windows often automatically
Speaker 2: attaches this stream to files downloaded from the Internet, and
Speaker 2: it records information like the original URL it came from.
Speaker 2: That can be crucial evidence for tracing malware or suspicious
Speaker 2: documents back to their source.
Speaker 1: Interesting. What else is key in NTFS?
Speaker 2: Well, the heart of NTFS is the Master Filetable or MFT.
Speaker 2: Think of it as a highly detailed database or library
Speaker 2: catalog for every single file and folder on the volume.
Speaker 2: Each file has an entry in the MFT.
Speaker 1: And what information is in that entry.
Speaker 2: Lots of metadata. It stores file attributes, including things like objectives.
Speaker 2: These are unique identifiers UUIDs that can act like digital fingerprints,
Speaker 2: potentially linking a file back to the specific computer it
Speaker 2: was a real created on, even if the file itself
Speaker 2: has been copied around. It includes creation time stamps and
Speaker 2: even the m MASS address of the network card of
Speaker 2: the creating machine sometimes WOW. And the MFT also holds
Speaker 2: security descriptor attributes. These contain information like the owner and
Speaker 2: group security identifiers sids and the access control lists acls,
Speaker 2: which define exactly who has permission to read, write, or
Speaker 2: execute the file, all crucial details for an investigation.
Speaker 1: Okay, moving across to the Linux world, now we have
Speaker 1: the EXT family of filesystems. How has that evolved over
Speaker 1: the years and what does the latest version XT four
Speaker 1: offer investigators?
Speaker 2: Right, the EXT family is native to Linux. It started
Speaker 2: with X two, which was simpler and stored file metadata
Speaker 2: in structures called inodes. Each file or directory has an
Speaker 2: inode containing information like permissions, time stamps, and pointers to
Speaker 2: the actual data blocks.
Speaker 1: But X two lacks something important, Right?
Speaker 2: Yes, X two lacked journaling, making it vulnerable to corruption
Speaker 2: if the system crashed during rites. So X three was
Speaker 2: developed and its main addition was journaling, providing that resilience
Speaker 2: similar to NTFS. X three also introduced h tree directory indexing,
Speaker 2: which was a significant performance improvement, allowing directories to efficiently
Speaker 2: handle millions of files, overcoming a major limitation of X
Speaker 2: two for large file systems.
Speaker 1: And X four is the modern standard now right, what
Speaker 1: really makes it stand out? Especially for forensics?
Speaker 2: Yes, xdoor is the default for many Linux distributions today
Speaker 2: and brought several important X to four innovations. One major
Speaker 2: change was the introduction of extents. Instead of using individual
Speaker 2: block pointers for large files, extends to find a starting
Speaker 2: block and a length, making storage much more efficient for
Speaker 2: large contiguous files and simplifying.
Speaker 1: Recovery any other key features Yeah.
Speaker 2: Another one is inline storage for very small files, X
Speaker 2: four can actually store the file's data directly within the
Speaker 2: inode structure itself, saving space and eliminating the need for
Speaker 2: separate data blocks entirely all interesting and crucially for investigators.
Speaker 2: XT four dramatically improved timestamp granularity down to nanosecond precision.
Speaker 2: It also officially added support for a file creation timestamp
Speaker 2: sometimes called cre time or b time, which was often
Speaker 2: missing or unreliable in older ext versions. This allows for
Speaker 2: incredibly detailed timelines of filesystem events down to billions of
Speaker 2: a second.
Speaker 1: Nine seconds again, okay, finally in our tour, Apple's next
Speaker 1: generation system, APFS. How does that compare? Especially given Apple's
Speaker 1: big focus on security and user privacy.
Speaker 2: APFS Apple filesystem was introduced relatively recently to replace their
Speaker 2: older HFS plus filesystem on macOS iOS and other Apple devices.
Speaker 2: A big architectural change was moving to sixty four bit enodes.
Speaker 2: This vastly increases the theoretical number of files possible on
Speaker 2: a volume compared to HFS plus tin essential for handling
Speaker 2: the massive amounts of data on modern devices.
Speaker 1: Makes sense. What about features?
Speaker 2: Well? APFS was designed with modern hardware like SSD's and mind.
Speaker 2: It features robust built in encryption, which can be applied
Speaker 2: at the whole disc level or even per file. This
Speaker 2: obviously makes forensic analysis much more challenging if you don't
Speaker 2: have the decryption keys, a.
Speaker 1: Big hurdle definitely.
Speaker 2: However, APFS also has really robust snapshot creation capabilities built in.
Speaker 2: These are used by time Machine for backups, but they
Speaker 2: also mean that older versions of the filesystem state might
Speaker 2: be easily accessible, which can be very useful for forensic analysis,
Speaker 2: allowing you to roll back and see previous file versions
Speaker 2: or system.
Speaker 1: States interesting, anything else unique.
Speaker 2: One other notable feature is space sharing. In APFS, multiple
Speaker 2: logical volumes can exist within a single physical container and
Speaker 2: share the underlying free space. This is flexible for users,
Speaker 2: but can make tracking exact data allocation and free space
Speaker 2: a bit more complex for forensic analysis compared to traditional
Speaker 2: fixed partitions.
Speaker 1: Wow, it's a lot of complex hidden infrastructure under the hood.
Speaker 1: So how do investigators actually get to all this data,
Speaker 1: these bits bytes in odes, MFT records without altering the
Speaker 1: original evidence or causing more problems like those SSD changes.
Speaker 1: What's in the investigator's toolkit acquiring and analyzing digital evidence right?
Speaker 2: The first and absolutely critical step is forensically sound acquisition.
Speaker 2: The goal here is to create a perfect copy of
Speaker 2: the original storage device without changing the original in any way.
Speaker 1: How do they guarantee that?
Speaker 2: Primarily through the use of right blockers. These can be
Speaker 2: specialized hardware devices that sit between the investigator's computer and
Speaker 2: the evidence drive, physically preventing any right commands from reaching
Speaker 2: the evidence, or they can be software based, like specific
Speaker 2: settings and Linux that mount a device and read only mode.
Speaker 2: At a very low level, the idea is to put
Speaker 2: that fragile artifact, the original drive, in a protective glass case,
Speaker 2: metaphorically speaking, before you even begin to study it.
Speaker 1: Okay. Essential step and a core Linux command for making
Speaker 1: that copy is DAD. I hear. That's incredibly powerful, but
Speaker 1: maybe a little dangerous if you're not careful.
Speaker 2: Yes. The AAD command is a classic, very powerful Linux
Speaker 2: tool for creating raw images, which are exact bit by
Speaker 2: dick copies of a device or partition. It's sometimes nicknamed
Speaker 2: data destroyer if you mix up the input and output.
Speaker 2: Uh hot, Yeah, you have to be careful, but used correctly,
Speaker 2: it copies everything every sector, including all the unallocated space
Speaker 2: and slack space we talked about earlier, which is vital.
Speaker 2: You can also use options like count and skip to
Speaker 2: copy only specific parts, allowing you to extract exact data
Speaker 2: that is desired. For example, you could use it to
Speaker 2: copy just the first five hundred and twelve bytes to
Speaker 2: get the master boot record, or just the blogs belonging
Speaker 2: to a specific partition table. Precise, very although for efficiency,
Speaker 2: error handling and adding metadata about the acquisition process, many
Speaker 2: forensic investigators now prefer specialized image formats like the Expert
Speaker 2: Witness Format EWF, often created by tools other than just DD.
Speaker 2: These formats can compress data, handle read errors better, and
Speaker 2: store case information alongside the image data.
Speaker 1: Okay, So once they have that pristine, forensically sound image,
Speaker 1: that bit for bit copy, how do they start actually
Speaker 1: picking it apart finding those hidden files, deleted remnants, or
Speaker 1: specific pieces of metadata.
Speaker 2: That's where analysis tools come in. A very widely used suite,
Speaker 2: especially in the open source world, is the sleuth kit,
Speaker 2: often abbreviated as TSK.
Speaker 1: Okay, what does that do?
Speaker 2: TSK is actually a collection of command line tools designed
Speaker 2: specifically for filesystem forensics. For example, a tool called fusstat
Speaker 2: can analyze the image and determine the filesystem type NTFS,
Speaker 2: XT four, FAT, et cetera, and provide overall information about
Speaker 2: the volume like block size and total blocks, so like
Speaker 2: an initial assessment exactly. Then there's FLS, which is used
Speaker 2: to list files and directories within the filesystem image. Crucially,
Speaker 2: FLS can often list deleted files that still have metadata entries,
Speaker 2: and it can even list the low level filesystem structures
Speaker 2: themselves like inodes and ext or cnids and hfs, plus
Speaker 2: essay showing you where things used to be or how they're.
Speaker 1: Organized, and getting the actual data for that.
Speaker 2: You'd use tools like astat to recover specific file metadata, timestams, permissions,
Speaker 2: size as block pointers by referencing its inode number or
Speaker 2: MFT entry id, and then iicat in use to recover
Speaker 2: the actual file content itself, essentially concatenating together the data
Speaker 2: blocks associated with that specific file or structure.
Speaker 1: So TSK can also help put together timelines and maybe
Speaker 1: even recover deleted files more automatically.
Speaker 2: Indeed, TSK includes tools like mac time, which can parse
Speaker 2: various timestamps collected from across the filesystem metadata like modified
Speaker 2: access change times from inodes or MFT entries, and generate
Speaker 2: incredibly detailed timelines of activity. There's also bly calls for
Speaker 2: extracting blocks from the unallocated space, making it easier to
Speaker 2: search that space for remnants of deleted data and scract
Speaker 2: cover attempts to automate the recovery of deleted files by
Speaker 2: finding their orphaned metadata and associated data blocks.
Speaker 1: What if the metadata is completely gone, though, the filesystem
Speaker 1: structures are corrupted, but maybe the raw data for say
Speaker 1: a picture, is still sitting out there in unallocated space. Ah.
Speaker 2: That's where a technique called data carving comes up.
Speaker 1: That sounds like digital arc cheology, like trying to reconstruct
Speaker 1: a shattered vase from its unique edge patterns.
Speaker 2: That's a great analogy. Data carving works by bypassing the
Speaker 2: file system entirely and instead searching for known file signatures
Speaker 2: directly within the raw data stream of the image. These
Speaker 2: signatures are unique sequences of bytes that typically mark the
Speaker 2: beginning header and sometimes the end footer of specific file types.
Speaker 2: For example, JPEG image files almost always start with the
Speaker 2: hex bytes zero ox f ft eight and end with
Speaker 2: zero ox f ft nine, so.
Speaker 1: You just scan the whole image for those patterns.
Speaker 2: Essentially, yes, carving tools scan the raw data looking for
Speaker 2: these known headers and footers, and then extract the data
Speaker 2: in between as a potential file. It's like looking for
Speaker 2: specific patterns of color and texture to identify pieces of
Speaker 2: that shattered vase. However, it's important to know that data
Speaker 2: carving is not fully reliable. Files can be fragmented, meaning
Speaker 2: the header and footer might be separated. By unrelated data,
Speaker 2: or the footer might be missing entirely. Also, those byte
Speaker 2: patterns might occasionally appear randomly within other unrelated day leading
Speaker 2: to false positives. So car files always need careful validation.
Speaker 1: Makes sense? Okay? Looking ahead now, with all this technology
Speaker 1: evolving so incredibly rapidly, SSD's new file systems, encryption, what
Speaker 1: are some of the biggest things on the horizon future
Speaker 1: challenges in digital forensics? What keeps investigators up at night?
Speaker 2: Well, probably the single biggest challenge is simply the data
Speaker 2: volume problem. We've seen this vast increase in the quantity
Speaker 2: of digital evidence phones, with terabies of storage, cloud accounts,
Speaker 2: IoT devices, it's everywhere, right, This creates a kind of
Speaker 2: vicious cycle because the resources available for analysis, skilled human analysts,
Speaker 2: processing power, storage for forensic images. They haven't kept pace
Speaker 2: more data, but limited resources to handle it efficiently means
Speaker 2: backlogs grow and investigations can slow down.
Speaker 1: And new file systems keep popping up too, right, Yeah,
Speaker 1: constantly changing the rules of the game.
Speaker 2: Absolutely. New file systems like APFS when it first appeared,
Speaker 2: and even Extra four. Historically, they often require significant reverse
Speaker 2: engineering by forensic researchers, especially if official documentation is scarce
Speaker 2: or non existent. This takes a huge amount of time
Speaker 2: and specialized skill, and there's always a risk of misinterpretation,
Speaker 2: which has obvious implications if the findings are presented in court.
Speaker 1: And you mentioned live data forensics earlier LDF, that comes
Speaker 1: with its own set of ongoing challenges too.
Speaker 2: Yes, definitely, Live data forensics revisited is a constant topic.
Speaker 2: We already talked about how it inherently breaks ACPO Principle
Speaker 2: one by altering data, making it impossible to realize that
Speaker 2: principle fully. But there are other.
Speaker 1: Risks too, sugg as like the system crashing maybe or
Speaker 1: that crucial audit trail.
Speaker 2: We talked about exactly. System crashes are a real possibility,
Speaker 2: especially when performing intrusive actions like acquiring the contents of
Speaker 2: RAM directly, which can sometimes destabilize a running system, and
Speaker 2: maybe more fundamentally, LDF is inherently non repeatable. Unlike deadbox forensics,
Speaker 2: where you can rerun analysis commands on a static image
Speaker 2: multiple times and get the same result, LDF changes the
Speaker 2: live system with every action. You can't perfectly recreate the
Speaker 2: state later, so.
Speaker 1: The documentation becomes even more critical.
Speaker 2: Absolutely paramount that documentation. The ACPO audit trail becomes the
Speaker 2: only way to verify the process, to show what was done,
Speaker 2: when and why, because you can't simply rerun the experiment.
Speaker 1: Okay, And then there's the elephant in the room for
Speaker 1: any digital investigation today. Encryption. It's fantastic for user privacy obviously,
Speaker 1: but it can be a massive hurdle, sometimes a complete
Speaker 1: dead end for an investigation.
Speaker 2: Encryption really is the classic double edged sword. It protects
Speaker 2: legitimate users privacy and security, which is essential, but it
Speaker 2: equally protects criminal communications and data from investigators if they
Speaker 2: can't get the keys.
Speaker 1: Are there any proposed solutions?
Speaker 2: Well, Ideas like key escro systems have been proposed, where
Speaker 2: decryption keys would perhaps be held by a trusted third
Speaker 2: party under specific legal conditions, but these face huge technical
Speaker 2: and ethical challenges. For one, criminals could simply choose to
Speaker 2: use other encryption software or methods that aren't part of
Speaker 2: the escrosystem. And second, there are massive privacy concerns about
Speaker 2: governments or other entities having potential access to everyone's encrypted data.
Speaker 2: It's a really difficult balance.
Speaker 1: So we're kind of back to square one on that.
Speaker 2: In many ways, and many ways yes, it remains a
Speaker 2: major challenge and finally sort of tying a lot of
Speaker 2: this together, there's a significant ongoing need for better standardization
Speaker 2: and tool testing in the field, meaning developing standardized TORBA
Speaker 2: basically large, well defined data sets of known digital evidence
Speaker 2: containing specific artifacts. These could then be used to rigorously
Speaker 2: test and validate the accuracy and reliability of different forensic
Speaker 2: tools and techniques. Having such standard test sets would greatly
Speaker 2: increase their acceptance in the courts and build more confidence
Speaker 2: in forensic findings overall because results could be consistently replicated
Speaker 2: and verified across different tools and laps.
Speaker 1: Wow, what a journey that was. We've really delved deep
Speaker 1: into the hit and structures of file systems, haven't we
Speaker 1: From the absolute basics of bits and bytes, through the
Speaker 1: intricate designs of different operating system formats like ntfs and
Speaker 1: XT four and apfs, and then explore the cutting edge
Speaker 1: techniques investigators use to try and uncover digital truths from
Speaker 1: all that complexity. It's a world that is just constantly,
Speaker 1: constantly changing.
Speaker 2: It really is. The evolution is relentless. Every new app,
Speaker 2: every new device, every new way we interact digitally, it
Speaker 2: creates new challenges, but also potentially new opportunities for digital forensics.
Speaker 2: And as that digital world keeps expanding, so does this
Speaker 2: invisible landscape of information hidden beneath our everyday interactions. It's
Speaker 2: honestly a constant race just to keep up to understand
Speaker 2: the new hidden languages that are always emerging.
Speaker 1: So here's something to think about as we wrap up.
Speaker 1: Given how deeply digital evidence now intertwines with almost every
Speaker 1: aspect of our lives, how might our growing understanding of
Speaker 1: these invisible file systems the stuff we talked about today,
Speaker 1: How might that reshape the very definition of truth in
Speaker 1: a modern investigation? And maybe more intriguingly, what new hidden languages,
Speaker 1: what new forms of digital evidence might emerge next that
Speaker 1: will challenge even our current forensic capabilities. Think about that
Speaker 1: for a moment. This knowledge isn't just for the tech
Speaker 1: experts or the investigators. It's really about understanding the very
Speaker 1: fabric of our digital existence and how those unseen layers
Speaker 1: can reveal or sometimes conceal, the most profound stories of
Speaker 1: our time.