> Where you are: Part I, Chapter 2 of 40. Chapter 1 drew both the line and the bridge between data recovery and digital forensics and argued that they rest on a single technical foundation. This chapter lays the first stone of that foundation: what...
In This Chapter
- A photo that was never really gone
- Binary: the only thing a computer actually stores
- Hexadecimal: how humans read binary
- ASCII, text, and character encoding
- From bits to magnetic domains: how a hard drive stores a byte
- From bits to trapped charge: how an SSD stores a byte
- The logical/physical divide: sectors, clusters, and the file system's view
- The central idea: deletion removes the pointer, not the data
- Reading raw bytes: the tools
- Worked example: finding the wedding photos by hand
- Common mistakes
- Limitations: knowing when to stop
- Progressive project: establish your byte-level baseline
- Summary
Chapter 2: How Data Is Stored — Bits, Bytes, Sectors, Clusters, and the Physical Reality of Digital Information
Where you are: Part I, Chapter 2 of 40. Chapter 1 drew both the line and the bridge between data recovery and digital forensics and argued that they rest on a single technical foundation. This chapter lays the first stone of that foundation: what "data" physically is, from a magnetized grain or a single trapped electron all the way up to the photo you double-click. Everything later in this book — file carving, timeline analysis, memory forensics, courtroom testimony — stands on the one idea introduced here and owned by this chapter: deleting a file removes the pointer, not the data. The bits persist until something overwrites them.
Learning paths: Everyone reads this chapter; there is no path around it. 💾 Data Recovery and 🔍 Forensic Examiner tracks — this is bedrock. Hex literacy and the logical-to-physical map are not optional; you will use them in every chapter that follows. 🛡️ Incident Response — you will lean on slack space and data persistence when you reconstruct what an attacker tried to wipe. 📜 Legal/eDiscovery — you do not need to decode a hex dump byte by byte, but you must understand why "deleted" files are routinely producible in litigation, because opposing counsel will, and a judge will expect you to know the difference between deleted and destroyed.
A photo that was never really gone
A client drops a laptop hard drive on your bench inside a sandwich bag. She is shaking. Two nights ago she meant to reformat an old external drive to give to her nephew; instead, half-asleep, she reformatted the wrong volume — the one holding ten years of family photographs. Wedding photos. Her late mother. Her children as infants. She has already tried the obvious: the Recycle Bin is empty, the files do not appear, the folders are gone. The operating system tells her, with total confidence, that the data does not exist.
The operating system is wrong. Or rather, the operating system is telling the truth about its own bookkeeping while being completely silent about the physical reality of the platter. The photos are, in all probability, still there — every byte of them — sitting in the same physical locations they occupied a week ago. What the format destroyed was not the photographs. It was the index that told the computer where the photographs lived. The map burned; the territory remains.
This is the wedding-photos case, the first of four anchor cases that recur throughout this book (you met it briefly in Chapter 1; you will recover from it in Chapter 6 — Logical Recovery and Chapter 7 — File Carving). We open with it here because it is the cleanest possible demonstration of the single most important and most counterintuitive fact in both data recovery and digital forensics. To a non-specialist, "I deleted it" and "it is gone" are the same sentence. To you, by the end of this chapter, they will be two entirely different claims, and you will know exactly why the gap between them exists, how wide it is, and — crucially — when it closes for good.
To understand why the photos survived a "format," you have to descend, layer by layer, from the comfortable world of files and folders down to the physical substrate where information actually lives: a magnetized grain on spinning glass, or an electron trapped behind an insulator in a flash cell. Then you have to climb back up through the abstractions — sectors, clusters, file systems — and see exactly where, on that climb, the word "delete" intervenes and what it actually touches. That round trip is this chapter.
Why This Matters. Almost every recovery you will ever perform and almost every piece of evidence you will ever produce exploits the gap between the file is gone from the index and the data is gone from the medium. If you internalize one idea from Part I, make it this one. It is the reason your profession exists.
Binary: the only thing a computer actually stores
Begin at the bottom. A digital storage device — any of them, of any era — stores exactly one kind of thing: a long sequence of two-state values. We write those two states as 0 and 1 and call each one a bit (a contraction of binary digit). That is the whole alphabet. Every photograph, spreadsheet, encryption key, malware sample, and incriminating email on Earth is, at the physical level, nothing but an enormous string of zeros and ones.
The choice of two states is not arbitrary or aesthetic; it is physical engineering pragmatism. A storage cell that must reliably distinguish only two conditions is dramatically easier to build, read, and keep error-free than one that must distinguish ten. "Is this region of the platter magnetized north-up or south-up?" is a far more robust question than "exactly how strongly is it magnetized, on a scale of zero to nine?" The same logic governs flash: "is there charge trapped in this cell, yes or no?" is easier than measuring a precise voltage — which, as you will see, is exactly why packing more bits into each flash cell makes drives cheaper but slower and less durable. Two states give you noise immunity. Noise immunity gives you reliability. Reliability is why your bank balance is stored in binary and not in some denser, more fragile scheme.
A single bit, on its own, carries almost no information — one yes-or-no answer. So bits are grouped. The groupings have names, and you must know them cold because the entire profession speaks in them.
Bit 1 binary digit 0 or 1
Nibble 4 bits 0000 .. 1111 16 possible values (one hex digit)
Byte 8 bits = 2 nibbles 00000000 .. 11111111 256 values (two hex digits)
Word CPU-dependent natural unit (Intel/x86 legacy: 16 bits;
DWORD = 32 bits, QWORD = 64 bits;
"word size" of a modern PC = 64 bits)
The byte is the unit that matters most for storage. It is eight bits, and eight bits can represent exactly 2⁸ = 256 distinct values, conventionally the integers 0 through 255. The byte is the fundamental quantum of digital storage: file sizes are measured in bytes, memory addresses point at bytes, sectors are measured in bytes, and a hex dump — the tool you will live inside — shows you bytes. When someone says a file is "4,096 bytes," they mean it is a sequence of 4,096 of these eight-bit values, one after another.
A word of caution about the word "word" itself. Unlike bit and byte, which are fixed, "word" depends on the processor architecture and the context. In the Intel/x86 world you will encounter constantly in Windows forensics, "WORD" conventionally means 16 bits, "DWORD" (double word) means 32 bits, and "QWORD" (quad word) means 64 bits — and you will see exactly those terms in the Windows registry, where a value type is literally called REG_DWORD. Meanwhile, when a hardware person says a CPU is "64-bit," they mean its natural word size — the width of its registers — is 64 bits. Hold both meanings loosely and let context disambiguate. (The DataField Assembly volume in this series takes word size apart in detail; for forensics, "byte" carries almost all the weight.)
Counting in binary, briefly
You do not need to do binary arithmetic by hand to be a competent examiner, but you do need to read it, because file-system flags, permission bits, and partition attributes are frequently single bits inside a byte. Counting in base 2 works exactly like counting in base 10, except each position is worth twice the one to its right instead of ten times:
Decimal: 0 1 2 3 4 5 6 7 8
Binary: 0 1 10 11 100 101 110 111 1000
Place values in one byte (8 bits):
128 64 32 16 8 4 2 1
| | | | | | | |
0 1 0 0 1 1 0 1 = 64 + 8 + 4 + 1 = 77
That last byte, 0100 1101, equals 77 in decimal. Hold onto the number 77; we are about to meet it again wearing two different costumes.
Try This. Convert the byte
1111 1111to decimal in your head: it is every place value added together, 128+64+32+16+8+4+2+1 = 255 — the largest value a single byte can hold. Now0000 0000= 0, the smallest. Every byte you will ever examine lives somewhere in that closed interval, 0 to 255. There are no exceptions and there is no byte number 256.
Hexadecimal: how humans read binary
Binary is how the machine stores data, but it is miserable for humans. The byte 0100 1101 is hard to read, hard to write without errors, and hard to talk about over the phone with a colleague at 2 a.m. during an incident. We need a denser notation that still maps cleanly onto bits. That notation is hexadecimal — base 16 — and it is the working language of this entire field. When you open a "hex editor" or run xxd, hex is what you are reading.
Hexadecimal uses sixteen digits. The first ten are the familiar 0–9; the next six borrow letters: A=10, B=11, C=12, D=13, E=14, F=15. The magic — the entire reason hex won over decimal for this purpose — is that one hex digit represents exactly one nibble (4 bits), and therefore two hex digits represent exactly one byte. Four bits have 2⁴ = 16 combinations; one hex digit has 16 values; the correspondence is perfect and lossless. Decimal has no such clean alignment with binary, which is why no one dumps storage in decimal.
Bits Hex Bits Hex Bits Hex Bits Hex
0000 = 0 0100 = 4 1000 = 8 1100 = C
0001 = 1 0101 = 5 1001 = 9 1101 = D
0010 = 2 0110 = 6 1010 = A 1110 = E
0011 = 3 0111 = 7 1011 = B 1111 = F
Now take our byte 0100 1101. Split it into two nibbles: 0100 and 1101. From the table, 0100 = 4 and 1101 = D. So the byte is 4D in hex — written 0x4D when we want to make the base explicit (the 0x prefix is a near-universal convention meaning "what follows is hexadecimal"). And 0x4D is, as we computed, 77 in decimal. One byte, three costumes: 0100 1101 (binary), 0x4D (hex), 77 (decimal). They are the same value. Fluency means seeing all three at once.
Converting hex to decimal uses place values of 16 instead of 2:
Hex place values: 16^3 16^2 16^1 16^0
=4096 =256 =16 =1
0x1F4 = 1×256 + 15×16 + 4×1 = 256 + 240 + 4 = 500
0x4D = 0×256 + 4×16 + 13×1 = 0 + 64 + 13 = 77
0xFF = 15×16 + 15 = 240 + 15 = 255
You will not often need to do these conversions on paper — tools do them — but you must be comfortable enough that 0xFF reads instantly as "all-ones byte, 255, the maximum," and 0x00 reads as "null byte, zero." Those two values, 00 and FF, are the most common bytes you will ever see in a dump, because empty space tends to be filled with one or the other.
Reading a hex dump
Here is where it all becomes concrete. A hex dump (or hex view) is the standard way to look at raw bytes. The canonical layout — produced by xxd, by hexdump -C, by PowerShell's Format-Hex, and by every graphical hex editor — has three columns:
OFFSET HEX BYTES (16 per line, grouped in two 8-byte halves) ASCII
-------- ------------------------------------------------------- ----------------
00000000 48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21 Hello, World!
^ ^ ^
| | |
| the 16 (or fewer) bytes on this line, in hex those same bytes,
| shown as text where
byte offset of the first byte on this line, in hex printable, "." if not
Read it left to right. The offset column on the left is the position of the first byte of that line, counted from the start of the file or device, expressed in hex. The first line always starts at offset 00000000 — position zero, because computers count from zero, a fact you must burn in now to avoid a lifetime of off-by-one errors. The hex column in the middle shows up to sixteen bytes, usually split into two groups of eight for readability. The ASCII column on the right shows each of those same bytes interpreted as a text character if it happens to be a printable one, and a . placeholder if it is not.
In the line above, the bytes 48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21 spell out, in the ASCII column, Hello, World!. Let us verify just the first byte by hand: 0x48 = 4×16 + 8 = 72, and ASCII character number 72 is capital H. The dump is not magic; it is this exact translation, performed for every byte, by a tool, instantly. Learning to read — to glance at FF D8 FF E0 and think "JPEG," to glance at 50 4B 03 04 and think "ZIP or a Microsoft Office file" — is one of the core literacies of this profession, and it is the entire subject of Chapter 7 — File Carving and Appendix A — File Signatures Reference.
Tool Tip. The offsets in most hex tools are in hex by default, but the file sizes your operating system reports are in decimal, and your own notes might be in either. Mixing bases is a classic, embarrassing mistake. Get in the habit of always labeling a number with its base —
offset 0xC0000000oroffset 3,221,225,472 (decimal)— so that nobody, including future-you reading the report, has to guess.
ASCII, text, and character encoding
The ASCII column only makes sense because of an agreement, decades old, about which number means which character. That agreement is ASCII (American Standard Code for Information Interchange). ASCII is a mapping from the numbers 0–127 to characters. It is a 7-bit code (2⁷ = 128 values), which is why it fits comfortably inside a byte with a bit to spare. You will memorize a handful of landmark values without trying, simply by working:
Char Dec Hex Char Dec Hex Char Dec Hex
---- --- --- ---- --- --- ---- --- ---
(NUL) 0 0x00 'A' 65 0x41 'a' 97 0x61
(TAB) 9 0x09 'B' 66 0x42 'z' 122 0x7A
(LF) 10 0x0A 'Z' 90 0x5A '0' 48 0x30
(CR) 13 0x0D '[' 91 0x5B '9' 57 0x39
(space) 32 0x20 'M' 77 0x4D '!' 33 0x21
Three patterns in that table pay rent forever. First, the printable characters occupy the contiguous range 0x20 (space) through 0x7E (~); anything below 0x20 is a non-printing control code (tab, newline, the null byte). That is precisely why a hex dump shows a . for bytes outside 0x20–0x7E: they have no sensible character to display. Second, the digits '0'–'9' are 0x30–0x39, so the character '7' is the byte 0x37, not the number seven — a distinction that has confused beginners and crashed parsers since the 1960s. Third, lowercase letters sit exactly 0x20 (32) above their uppercase twins: 'A' is 0x41, 'a' is 0x61. That constant offset is occasionally a useful trick when you are eyeballing a dump.
And there is our friend 77 again. 0x4D is capital M. So the single byte 0100 1101 is, depending entirely on how some program decides to interpret it, the number 77, or the letter M, or part of a JPEG, or a flag field, or a fragment of an encryption key. A byte has no intrinsic meaning. Meaning is imposed by interpretation. This is one of the deepest ideas in the whole field, and it cuts both ways: it is why the same raw bytes can be read as text or as a file structure, and it is why you must always know — and document — which interpretation you are applying when you make a claim about evidence.
War Story. Two capital letters illustrate the point. Open almost any Windows
.exeor.dllin a hex editor and the first two bytes are4D 5A—MZin the ASCII column. Those are the initials of Mark Zbikowski, a Microsoft architect who designed the DOS executable format in the early 1980s. Forty years later, his initials still sit at offset 0 of every PE executable on the planet, a tiny fossil signature. When you learn to recognize4D 5Aon sight, you can spot an executable masquerading as a.jpgby its extension — a trick malware uses and a trick Chapter 7 and Chapter 32 — Malware Forensics teach you to see through.
Beyond ASCII: Unicode and UTF
ASCII covers English and not much else — 128 characters cannot represent the world's writing systems. Modern text uses Unicode, a vastly larger character set, encoded most commonly as UTF-8 or UTF-16. You need three practical facts about this for now. (1) UTF-8 is backward-compatible with ASCII: any plain-ASCII byte (0x00–0x7F) is identical in UTF-8, so English text looks the same in a dump either way; non-ASCII characters expand to two, three, or four bytes. (2) UTF-16, used heavily inside Windows internals (including parts of the NTFS file system and the registry), stores each basic character as two bytes, which is why Windows filenames in a raw dump often appear as letters interleaved with 00 bytes — S.M.I.T.H reads as 53 00 4D 00 49 00 54 00 48 00. (3) When you see that interleaved-with-nulls pattern, think "UTF-16 / Windows string," not "corruption." Recognizing encodings on sight saves hours; Chapter 16 — Windows Forensics and Appendix H — Command-Line Reference (the strings tool, with its -e encoding flag) return to this.
Endianness: byte order matters
One more wrinkle, and it is one that trips up even experienced people. A single byte is unambiguous. But the moment you store a value larger than 255 — anything needing two or more bytes — you face a choice: which byte goes first? Consider the number 1000. In hex that is 0x03E8, which needs two bytes: 0x03 and 0xE8. There are two ways to lay them down in memory or on disk:
Value: 1000 = 0x03E8
Big-endian (most significant byte first): 03 E8
Little-endian (least significant byte first): E8 03
As a 32-bit (4-byte) field:
Big-endian: 00 00 03 E8
Little-endian: E8 03 00 00
Big-endian stores the "big end" — the most significant byte — first, the way we write numbers in English ("one thousand" = 1, then 0, 0, 0). Little-endian stores the least significant byte first, which feels backward but is what virtually all the hardware you will examine actually does: x86, x86-64, and ARM in its common configurations are little-endian. This matters enormously when you parse a structure by hand. If an NTFS MFT record or an ext4 inode stores a file's size as a 32-bit little-endian integer and you read those four bytes left to right as if they were big-endian, you will compute a wildly wrong size — E8 03 00 00 read backward looks like 0xE8030000 = 3,892,510,720 instead of 1,000.
The subtle trap: endianness is a property of the format, not just the machine. On-disk file-system structures (NTFS, ext4, FAT) store their multi-byte fields little-endian because they grew up on little-endian PCs. But many file formats are big-endian by specification regardless of the machine. JPEG is the classic example: the segment-length fields inside a JPEG are big-endian, so a length stored as 00 10 means 16, not 4,096. Network protocols are big-endian too (it is even called "network byte order"). So within a single forensic image you will flip between conventions: the NTFS metadata describing a JPEG is little-endian, while the JPEG's own internal markers are big-endian. There is no shortcut here except knowing the spec for whatever you are parsing — which is exactly why Appendix G — File System Reference exists.
Why This Matters. Theme four of this book — technology changes, principles don't — shows up already. The media will change from platters to flash to whatever comes next, and file systems will come and go, but a multi-byte value will always have a byte order, and getting it wrong will always produce nonsense. Master the principle once and it transfers to every format you will ever meet.
From bits to magnetic domains: how a hard drive stores a byte
We have established what data is logically — sequences of bits, grouped into bytes, written in hex, sometimes meaning text. Now descend to the physical layer and ask the literal question: when a byte is "on the drive," what physical thing is holding it? The answer differs sharply between the two dominant technologies, and that difference is not academic — it is the single biggest factor in whether deleted data is recoverable, which is the whole point of the chapter and the recurring tension of the book. Here we cover hard disk drives; the deep mechanical anatomy (heads, actuators, the PCB, clean-room work) belongs to Chapter 3 — Storage Technology and Chapter 8 — Hard Drive Recovery. What you need here is how a bit becomes physical.
A hard disk drive (HDD) stores bits as patterns of magnetization on rigidly spinning disks called platters. A platter is a smooth disk — historically aluminum, increasingly glass — coated with an extremely thin film of a magnetic alloy. The surface is divided, by the drive's own firmware and a magnetic head, into billions of microscopic regions. Each region can be magnetized in one of two opposing orientations, and that orientation is how a bit's value is physically encoded. In modern drives the magnetization points vertically into the platter surface — a scheme called perpendicular magnetic recording (PMR) that replaced the older horizontal "longitudinal" approach around 2005 and allowed densities to climb enormously. The precise translation from logical bits to physical magnetic transitions runs through layers of channel coding and error correction that are well beyond our scope, but the headline is simple and durable: on an HDD, a bit is the magnetic orientation of a tiny region of the platter, and that orientation does not change unless a write head deliberately changes it.
That last clause is the entire foundation of HDD recovery and forensics. Magnetism is stable and persistent. A magnetized grain stays magnetized — for years, powered or not — until a write head flies over it and flips it. Reading the platter does not disturb it. There is no natural decay on human timescales, no "use it or lose it." So when you delete a file and the operating system simply stops referencing those regions, the regions keep their magnetization exactly as it was. The data is physically, stubbornly still there. This is why a "formatted" drive full of wedding photos is, in the overwhelming majority of cases, a fully recoverable drive — and why a careless investigator can also leave a damning trail that survives every casual attempt to erase it.
The platter's surface is organized geometrically so that the drive can find any given region on demand:
A single platter surface (top-down view, simplified)
___________________
.-' tracks '-. * TRACK: one concentric ring.
.' .-----------------. '. A platter has hundreds of
/ .' .-----------. '. \ thousands of them.
| / / .-----. \ \ |
| | | | . | | | | * SECTOR: a wedge-shaped arc
| | | | (o) | | | | of a track -- the smallest
| | | | ' | | | | physically addressable unit.
| \ \ '-----' / / | Traditionally holds 512 bytes
\ '. '-----------' .' / of user data (modern: 4096).
'. '-----------------' .'
'-.___________________.-' * CYLINDER: the same track on
every platter, stacked.
(A drive stacks several platters; a head
flies nanometers above each surface.)
The key term to carry forward from this picture is sector. A sector is the smallest chunk of the platter that the drive will read or write as a unit. You cannot ask an HDD for "byte number 5"; you ask it for "sector number N," and it hands you the whole sector. For decades that sector was 512 bytes. We will return to the sector — it is the hinge between the physical world and the logical world — after we look at how the other half of the industry stores a bit.
Limitation (preview). Magnetic persistence is so reliable that a single overwrite pass is sufficient to render data unrecoverable on modern HDDs — the old folklore about needing dozens of passes and electron microscopes does not apply to current drive densities. Persistence is a gift for recovery and a liability for anyone trying to truly erase. We will treat secure deletion honestly in the Limitations section below and in Chapter 30 — Anti-Forensics.
From bits to trapped charge: how an SSD stores a byte
A solid-state drive (SSD) has no platters, no heads, no moving parts at all. It stores bits as electrical charge trapped inside microscopic transistors in NAND flash memory. The deep anatomy — the controller, the DRAM cache, the Flash Translation Layer — is Chapter 3 and Chapter 9 — SSD and Flash Recovery material. What you need here is, again, how a bit becomes physical — and why that physics quietly rewrites the rules of recovery.
The storage element is a special transistor with an electrically isolated region — a floating gate (or, in newer designs, a charge-trapping layer) — sandwiched in insulator. By forcing electrons onto that isolated region and trapping them there, the cell's electrical behavior (its threshold voltage) shifts measurably. To read the cell, the controller checks whether charge is present. Charge present versus absent encodes a bit. Because the gate is insulated, the charge stays put with the power off — that is why an SSD, like an HDD, retains data without power. (Over very long unpowered periods — years — the trapped charge can slowly leak, a real archival concern, but irrelevant to a drive in active use.)
NAND flash organization (logical, simplified)
CELL -> stores 1 bit (SLC), 2 bits (MLC), 3 bits (TLC), or 4 bits (QLC)
depending on how many distinct charge levels it must distinguish.
many cells
|
v
PAGE -> smallest unit that can be READ or WRITTEN (programmed).
Typically 4 KB, 8 KB, or 16 KB.
|
v
BLOCK -> smallest unit that can be ERASED.
Typically 128-256 pages (~256 KB to several MB).
THE CRITICAL ASYMMETRY:
* You can write to a page that is empty (erased).
* You CANNOT overwrite a page in place. To rewrite it, the
controller must erase the ENTIRE BLOCK first -- which means
relocating every other still-valid page in that block.
Two facts from that diagram reshape everything. First, how many bits per cell is an engineering knob. SLC (single-level cell) stores one bit and is fast and durable; QLC (quad-level cell) crams four bits into one cell by distinguishing sixteen charge levels, making drives cheap and dense but slower and far less durable. This is the noise-immunity tradeoff from the top of the chapter, made concrete: more states per cell means each state is harder to tell apart and the cell wears out faster.
Second — and this is the fact that will haunt SSD recovery for the rest of the book — flash cannot be overwritten in place. On an HDD, writing new data to a location simply re-magnetizes it; the old bits are flipped and gone, and any not rewritten persist indefinitely. On an SSD, a page that holds data cannot simply be rewritten; the entire surrounding block must be erased first. To make this bearable, the SSD's controller never erases on demand during normal writes. Instead it writes new data to already-empty pages elsewhere, marks the old pages as stale, and quietly reclaims stale pages later in the background through a process called garbage collection. A layer of firmware called the Flash Translation Layer (FTL) maintains the secret mapping between the logical block the operating system thinks it wrote and the physical page where the data actually landed, and it shuffles data around constantly to spread wear evenly (wear leveling) because each cell tolerates only a limited number of erase cycles.
The forensic consequence is profound and we flag it now even though Chapter 9 owns it: on an SSD, the operating system can tell the drive — via a command called TRIM — "the user deleted these logical blocks; I no longer need them." The controller is then free to garbage-collect and physically erase those pages on its own schedule, often within seconds or minutes, with no further instruction. The same delete that leaves wedding photos sitting safely on an HDD platter for years can, on a TRIM-enabled SSD, trigger the genuine, permanent, physical destruction of the data before you ever get the drive on your bench. "Deleted ≠ destroyed" is the default truth of magnetic storage; on flash, it comes with an asterisk the size of a building.
War Story. A client deleted a folder of files from an SSD on a Tuesday and called us Wednesday afternoon. The files were unrecoverable — not damaged, not partially overwritten, but gone, returning all zeros at the logical level. Had those exact files been deleted from a spinning disk, the recovery would have been a routine afternoon. The only thing that changed between "trivially recoverable" and "permanently destroyed" was the storage technology under the same operating system performing the same delete. We will examine why, and the narrow exceptions, in Chapter 9. The lesson lands here: the medium decides what is possible. Know your medium before you promise a client anything.
Recovery vs. Forensics. This single difference splits both disciplines along the SSD/HDD line. For 💾 recovery, TRIM is the enemy — it shrinks your window from "years" to "minutes," so the very first question on an SSD job is "was TRIM active, and how long ago was the deletion?" For 🔍 forensics, TRIM is a double-edged artifact: it can destroy exculpatory or inculpatory data beyond reach, and the absence of expected data on a TRIM-enabled SSD must not be misread as deliberate wiping by a suspect. The medium's normal behavior can mimic anti-forensics. Confusing the two is how examiners get embarrassed on cross-examination (Chapter 27 — Expert Testimony).
The logical/physical divide: sectors, clusters, and the file system's view
We now have both physical pictures: magnetized regions on a platter, trapped charge in flash cells. But you almost never work at that raw physical layer. Between you and the platter sit layers of abstraction, each one translating "where is this data?" into terms the next layer down understands. Understanding exactly where these layers sit — and which one the word "delete" touches — is the heart of this chapter. This is the climb back up.
Sectors: the bottom rung, and 512 vs. 4Kn
The lowest unit you can normally address is the sector. Even though a platter physically stores bits and an SSD physically stores charge in pages, both present themselves to the rest of the computer as a simple, numbered array of fixed-size sectors. The traditional sector size is 512 bytes, a number you will see everywhere and should treat as the historical default. But as drives grew past a few terabytes, 512-byte sectors became inefficient — each sector carries fixed overhead (synchronization marks, address marks, error-correction codes, inter-sector gaps), and with billions of tiny sectors that overhead added up, while the error correction could not keep pace with rising densities. The industry's answer was Advanced Format: a physical sector of 4,096 bytes (4 KB). There are two flavors you must distinguish:
512n ("512 native")
Physical sector = 512 bytes. Logical sector = 512 bytes.
The classic. Legacy drives and many older SSDs.
4Kn ("4K native")
Physical sector = 4096 bytes. Logical sector = 4096 bytes.
The drive truly speaks in 4 KB units.
512e ("512 emulation") <-- the sneaky middle ground
Physical sector = 4096 bytes. Logical sector = 512 bytes.
The drive PRETENDS to offer 512-byte sectors for backward
compatibility but internally works in 4 KB. Writing a single
"512-byte sector" forces a slow internal read-modify-write
of the whole 4 KB physical sector.
Why does this matter to you? Because almost every offset calculation you will ever do — "the partition starts at sector 2048, so it starts at byte..." — depends on knowing the sector size. Get it wrong by a factor of eight and every offset in your analysis is wrong. When you image a drive (Chapter 5 — The Forensic Process, Chapter 14 — Forensic Acquisition), the tool records the logical sector size; check it and write it in your notes. Misaligned partitions (where a file system's clusters do not line up with the drive's 4 KB physical sectors) also cause real performance problems and occasionally complicate recovery, which is why partition alignment is a thing professionals care about.
LBA addressing and the one piece of arithmetic you must own
Modern drives are addressed with Logical Block Addressing (LBA): the sectors are simply numbered 0, 1, 2, 3, … up to the last one, and you ask for them by number. (The ancient Cylinder-Head-Sector, or CHS, scheme that named a physical location directly is long obsolete; the drive's firmware hides its real geometry and presents a flat list of LBAs.) This gives us the single most important calculation in the entire field — the bridge between the logical sector world and the byte-addressed world of a hex dump:
byte offset = LBA (sector number) × sector size
Example, 512-byte sectors:
Partition begins at LBA 2048.
2048 × 512 = 1,048,576 = exactly 1 MiB.
(This is why modern partitions start at the 1 MiB mark --
it aligns cleanly to both 512-byte and 4 KB boundaries.)
Example, finding a carved file:
A JPEG header is found at byte offset 3,221,225,472 (= 0xC0000000 = 3 GiB).
3,221,225,472 ÷ 512 = sector 6,291,456.
3,221,225,472 ÷ 4096 = cluster 786,432 (at a 4 KB cluster size).
Commit byte offset = sector × sector size to memory. Its inverse, sector = byte offset ÷ sector size, is just as important. You will use both constantly: a carving tool reports a hit at a byte offset and you need the sector for your notes; a partition table lists a starting sector and you need the byte offset to seek there in a hex editor. This arithmetic is so central that Appendix H opens with it.
Clusters: the file system's allocation unit
Sectors are the drive's unit. But file systems — NTFS, ext4, FAT, exFAT, APFS, the subject of Chapter 4 — File Systems — find it inefficient to track space one little sector at a time across a multi-terabyte volume. So they group sectors into larger chunks called clusters (the NTFS/FAT term) or blocks (the ext4/Unix term) or allocation units (the generic term). A cluster is the smallest amount of space the file system will hand to a file. The default NTFS cluster size on most volumes is 4,096 bytes — that is eight 512-byte sectors, or one 4 KB sector, bundled together and treated as one indivisible allocation unit.
The nesting of units, smallest to largest:
BIT -> BYTE -> SECTOR -> CLUSTER -> FILE
1 -> 8 bits -> 512 or 4096 -> e.g. 8 sectors -> one or more
=1 byte bytes = 4096 bytes clusters
The file system thinks in CLUSTERS.
The drive thinks in SECTORS.
The hardware thinks in magnetic domains / flash pages.
YOU must translate fluently between all of them.
The consequence of allocating in whole clusters is immediate and forensically rich: a file always occupies a whole number of clusters, even if it does not need all that space. A 1-byte text file on a 4,096-byte-cluster NTFS volume still consumes an entire 4,096-byte cluster. It uses one byte and wastes 4,095. Multiply that waste across millions of small files and you understand why cluster size is a real tradeoff — bigger clusters mean less bookkeeping overhead and less fragmentation but more wasted space; smaller clusters waste less but cost more overhead. That wasted space is not merely an efficiency footnote. It has a name, and it is one of the most productive hunting grounds in forensics.
Slack space: the data hiding in the gaps
Slack space is the leftover room between the end of a file's actual data and the end of the last cluster allocated to it. Because the file system gives out whole clusters but files rarely end exactly on a cluster boundary, there is almost always a gap at the tail — and crucially, the operating system does not clear that gap. Whatever bytes were physically sitting there before — fragments of a previously deleted file, in many cases — remain. Consider a 1,500-byte file on a volume with 4,096-byte clusters (eight 512-byte sectors per cluster):
A 1,500-byte file in one 4,096-byte cluster (eight 512-byte sectors)
sector: 0 1 2 3 4 5 6 7
+--------+--------+----------+------+------+------+------+------+
bytes: | file | file | file|RAM | drive slack (5 full sectors) |
| data | data | 476 | 36 | leftover from whatever was here |
| 512 | 512 | +pad| pad| before -- often an older, |
| | | | | deleted file's contents |
+--------+--------+----------+------+------+------+------+------+
|<--- 1,500 bytes of real file --->|<--- 2,596 bytes of slack -->|
File data: 1,500 bytes (fills sectors 0,1 and 476 bytes of sector 2)
RAM slack: 36 bytes (rest of sector 2; padded to the sector end)
Drive (file) slack: 2,560 bytes (sectors 3-7, untouched leftover data)
Total allocated: 4,096 bytes -> 4,096 - 1,500 = 2,596 bytes of slack
There are two species of slack in that picture, and the distinction matters. RAM slack is the space from the end of the file's data to the end of the sector it ends in — here, the 36 bytes after the file's 476th byte in sector 2. Modern Windows fills RAM slack with zeros (the name is a fossil from old systems that padded it with whatever happened to be in RAM at the moment, sometimes leaking memory contents onto the disk — a genuine information-disclosure bug in its day). Drive slack (also called file slack) is the rest of the allocated cluster beyond that final sector — here, the five full sectors 3–7, 2,560 bytes. The operating system does not touch drive slack. Whatever was there before the current file was written is still there, sitting quietly inside a cluster that the file system considers "in use" by the current file.
That is why slack space is forensic treasure. A small file written into a cluster that previously held a large deleted file leaves most of the old file intact in the new file's slack. Searches for keywords, signatures, and fragments routinely turn up evidence in slack that the suspect believed was long gone. Chapter 6 — Logical Recovery and Chapter 21 — Timeline Analysis both mine it.
Ethics Note. Slack space, by definition, contains data that has nothing to do with the file you are nominally examining — it is residue from unrelated prior files. You will encounter material outside the scope of your authorization there: personal information, communications, sometimes evidence of entirely different matters. Theme six of this book — the human cost is real — and the discipline of scope (covered fully in Chapter 25 — The Legal Framework and Chapter 28 — Ethics) demand that you handle incidental finds lawfully and humanely. Finding something does not automatically mean you are authorized to act on it. Know, before you start, what your warrant or engagement actually covers.
The central idea: deletion removes the pointer, not the data
Everything above converges here, on the concept this chapter owns for the entire book. We can now answer the wedding-photos question precisely and physically.
When you "delete" a file — drag it to the Recycle Bin and empty it, run rm, or even reformat the whole volume — the operating system, in the overwhelming majority of cases, does not touch the file's data clusters at all. Writing new data over hundreds of megabytes would be slow and pointless; the system has no reason to do it. Instead, deletion is a fast bookkeeping operation that changes two small things: it marks the file's directory/metadata entry as no longer valid, and it marks the file's clusters as available for reuse in the file system's free-space map. The data itself — the actual magnetized regions or charged cells holding the photograph — is left exactly as it was. The file is not erased. It is orphaned: still physically present, but no longer pointed to.
BEFORE deletion AFTER deletion (logical view)
Directory / MFT entry Directory / MFT entry
+-------------------------+ +-------------------------+
| name: wedding.jpg | | name: (marked unused / |
| size: 3,400,000 bytes | | first char 0xE5 |
| starts at cluster 786432|---+ | on FAT; in-use |
+-------------------------+ | | flag CLEARED on |
| | NTFS) |
| | -> pointer GONE |
v +-------------------------+
Data clusters on the medium: (no arrow)
[##### the actual JPEG bytes #####] Data clusters on the medium:
FF D8 FF E0 ... (still there) [##### the actual JPEG bytes #####]
FF D8 FF E0 ... STILL THERE,
Free-space map: cluster 786432 = USED just marked "free" and reusable.
Free-space map: 786432 = FREE
The mechanism differs by file system — and Chapter 4 is where you learn each one in detail — but the principle is universal. Two concrete examples make it tangible at the byte level:
- FAT/exFAT: Deleting a file replaces the first character of its directory-entry filename with the byte
0xE5(a specific marker meaning "this slot is free") and zeroes the cluster-chain entries in the File Allocation Table that linked the file's clusters together. The directory entry — minus that first character — and the data clusters are otherwise untouched. Recovery often means guessing the missing first character and following the (now-broken) chain or carving the data directly. You can literally watch this happen in a hex editor: the entry that readwedding.jpgnow reads?edding.jpgwith a0xE5where thewwas. - NTFS: Every file has a record in the Master File Table (MFT). Deletion clears a single bit — the "in use" flag (bit 0 of the flags field at offset 0x16 in the MFT record header) — and marks the file's clusters as free in the
$Bitmapmetafile. The MFT record itself, with all its metadata and often the pointers to the data, survives until that MFT slot is reused. This is why NTFS deleted-file recovery via residual MFT records (Chapter 6) is so frequently successful: the map is not burned, merely marked "ignore me."
So what does destroy data? Overwriting. The data is genuinely gone only when something new is physically written on top of it — when the operating system reuses those "free" clusters for a different file, when a secure-wipe utility deliberately writes zeros or random bytes across them, or, on an SSD, when TRIM and garbage collection physically erase the underlying flash pages. Until one of those things happens, the data persists. That gap — between marked free and actually overwritten — is the window every recovery and many investigations live inside. Sometimes the window is months; sometimes, on a busy SSD with TRIM, it is seconds. Sizing that window for a given case is one of the first judgments you will make as a professional.
Why This Matters. This is theme one — deleted ≠ destroyed — stated in full, and it is the reason the rest of this book has content. It is also a sober warning, the flip side of the same coin: if you, your client, or a suspect believe that "delete" means "gone," you are all mistaken. Sensitive files survive deletion. Donated and resold computers spill their previous owners' lives. And — theme three — every action leaves a trace: the very act of trying to erase often leaves its own evidence, a topic Chapter 30 — Anti-Forensics is built around.
Legal Note. Because deleted files routinely persist and are recoverable, they are also routinely discoverable in litigation. Under the U.S. Federal Rules of Civil Procedure, electronically stored information includes data that a party deleted but that remains recoverable, and a party with a duty to preserve evidence who allows it to be overwritten can face spoliation sanctions. "We deleted it" is not a defense; in many situations it is an admission. The legal weight of data persistence is developed in Chapter 25 — The Legal Framework and Appendix E.
Reading raw bytes: the tools
You will spend real time staring at hex dumps. Here are the standard tools, each shown doing the same elementary thing — revealing the true first bytes of a file regardless of what its extension claims. (As always in this book, command output is illustrative and was authored for correctness; the point is the technique, not the literal run.)
On Linux/macOS, xxd is the workhorse:
# Dump the first 64 bytes of a file in canonical hex+ASCII form
xxd -l 64 wedding.jpg
# Seek to a specific byte offset (hex ok) and read a length -- e.g. inside an image file
xxd -s 0xC0000000 -l 64 evidence.dd
# Read one 512-byte sector (LBA 2048) directly from a device, piped into xxd.
# In real casework you read from a WRITE-BLOCKED source or, better, from an image,
# never casually from a live evidence device.
dd if=/dev/sdb bs=512 skip=2048 count=1 status=none | xxd
A typical xxd -l 64 wedding.jpg produces exactly the three-column layout we have been reading:
00000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001 ......JFIF......
00000010: 0001 0000 ffdb 0043 0008 0606 0707 0607 .......C........
00000020: 0809 0809 0a0c 140d 0c0b 0b0c 1912 130f ................
00000030: 141d 1a1f 1e1d 1a1c 1c20 242e 2720 222c ......... $.' ",
On Windows, PowerShell has Format-Hex built in (no extra install), and dd-style and hex-editor tools (HxD is the popular GUI) cover the rest:
# First lines (each line = 16 bytes) of a file's raw bytes
Format-Hex -Path .\wedding.jpg | Select-Object -First 4
# Pull the signature of every .jpg in a folder and show the first 8 bytes,
# a quick way to spot a file whose extension lies about its real type
Get-ChildItem *.jpg | ForEach-Object {
$bytes = [System.IO.File]::ReadAllBytes($_.FullName)[0..7]
"{0}: {1}" -f $_.Name, (($bytes | ForEach-Object { '{0:X2}' -f $_ }) -join ' ')
}
And because forensic work means automating these reads at scale, Python is the book's primary scripting language. The following two helpers — a from-scratch hex dumper and a sector reader — are the kind of thing you will reach for constantly; expanded, reusable versions live in Appendix B — Python Forensics Toolkit and in the book's code/ directory:
def hexdump(data: bytes, base: int = 0, width: int = 16) -> None:
"""Render bytes as an xxd-style dump: offset | hex | printable ASCII."""
for off in range(0, len(data), width):
chunk = data[off:off + width]
hex_part = " ".join(f"{b:02x}" for b in chunk)
hex_part = f"{hex_part:<{width * 3 - 1}}" # pad final short line
text = "".join(chr(b) if 32 <= b <= 126 else "." for b in chunk)
print(f"{base + off:08x} {hex_part} {text}")
SECTOR = 512 # bytes; confirm against the actual media (512n / 512e / 4Kn)!
def read_sector(path: str, lba: int, sector_size: int = SECTOR) -> bytes:
"""Read one sector by LBA. byte offset = lba * sector_size -- the core arithmetic."""
with open(path, "rb") as f: # "rb" = read BINARY; never open evidence as text
f.seek(lba * sector_size)
return f.read(sector_size)
# Example: dump the boot sector (LBA 0) of an image file
hexdump(read_sector("evidence.dd", 0), base=0)
Note two professional habits baked into that code, both expressions of theme two — the original is sacred. The files are opened read-only ("rb", never a writable mode), and the comments insist on confirming sector size rather than assuming 512. In real casework you go further: you work from a verified image, never the original device, and the device itself sits behind a hardware write blocker. Those practices are the entire subject of Chapter 5 — The Forensic Process and Chapter 14 — Forensic Acquisition; we flag them here so that even your earliest hex-poking builds the right reflexes.
Worked example: finding the wedding photos by hand
Let us return to the client's reformatted drive and make the abstract concrete. After taking the drive in, you do the non-negotiable first thing: you do not boot it, browse it, or attempt recovery on it. You attach it through a write blocker and create a forensic image — a bit-for-bit copy — and you compute a cryptographic hash of that image so you can later prove it never changed (hashing is introduced properly in Chapter 5; for now, treat the hash as a tamper-evident seal). All subsequent work happens on a copy of the image, never on the drive itself. The original goes back in its bag and into evidence storage.
Now you open the image in a hex editor and go looking. The "quick format" the client performed wrote a fresh, nearly empty file system at the front of the volume — a new boot sector, a new, almost-empty MFT — but it did not walk the entire platter overwriting old data clusters. (A full format with a surface scan is a different and slower beast; quick format, the default, is essentially "lay down a new index and call the rest free.") So the old photographs' data is still sitting out in what the new file system now regards as free space. You navigate to a region well past the new file-system metadata — say, byte offset 0xC0000000, which your arithmetic tells you is 3,221,225,472 bytes in, sector 6,291,456 — and you see this:
xxd -s 0xC0000000 -l 64 wedding_drive.dd
c0000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001 ......JFIF......
^^^^ ^^^^ ^^^^^^^^^^
| | "JFIF" identifier at offset +6
| APP0 marker (FF E0); next 2 bytes 00 10 = length 16 (BIG-endian!)
SOI: Start Of Image. FF D8 FF is the universal JPEG signature.
c0000010: 0001 0000 ffdb 0043 0008 0606 0707 0607 .......C........
^^^^ ^^^^
DQT marker (FF DB), length 00 43 = 67 -- quantization table
c0000020: 0809 0809 0a0c 140d 0c0b 0b0c 1912 130f ................
c0000030: 141d 1a1f 1e1d 1a1c 1c20 242e 2720 222c ......... $.' ",
There it is. The bytes FF D8 FF E0, immediately followed at offset +6 by 4A 46 49 46 — JFIF in the ASCII column — are the unmistakable opening of a JPEG image. This is not metadata about a photo; this is the photo itself, its first bytes, physically present on the platter exactly where they were written years ago, untouched by the reformat. The pointer that used to say "wedding.jpg starts here" is gone, burned with the old MFT. But the territory — the data — remains. Notice, too, the endianness lesson made real: the JPEG's own internal length field 00 10 is big-endian (=16), even though the NTFS structures that used to describe this file were little-endian. Same image, two byte orders, exactly as warned.
From this header you can recover the file two complementary ways, the subjects of the next two chapters. If a residual MFT record for the file still exists, you can read its metadata and follow its (possibly still-intact) cluster pointers to reassemble the file precisely — logical recovery, Chapter 6. If the MFT record is gone — as it largely is after a format — you fall back to file carving (Chapter 7): scan the raw image for the FF D8 FF header, read forward to the JPEG end-of-image footer FF D9, and write everything in between out as a .jpg. Carving ignores the file system entirely and trusts only the file's own internal structure — which is exactly why it works when the file system has been destroyed. Either way, the recovery is possible only because of the principle this chapter exists to teach: the data outlived the deletion of its pointer.
Recovery vs. Forensics. Those same bytes at offset
0xC0000000mean two different things depending on your mission, and this is the book's signature lens. For the 💾 recovery client, the goal is the photograph back in her hands, intact and complete; you optimize for speed and for getting all of it, and a slightly imperfect recovery is still a gift. For the 🔍 forensic examiner, that same JPEG might be evidence, and the bytes are only half the job: you must record the exact byte offset and sector where it was found, note that it resided in unallocated (deleted) space rather than an active file, preserve the chain of custody, hash your work, and write your findings so that a second examiner working independently from your documentation reaches the identical result. Recovery asks "can I get it back?" Forensics asks "can I prove where it came from and that I did not alter it?" The bytes are identical; the rigor is not.Chain of Custody. The moment those bytes might matter in a proceeding, your notebook matters as much as your hex editor. Record: the source media's make/model/serial, the imaging tool and its version, the image's hash, the exact offset and sector of the find, who handled the evidence and when, and where it was stored between handoffs. "I found a JPEG" is worthless in court. "I recovered a JPEG whose
FF D8 FF E0header began at byte offset 3,221,225,472 (sector 6,291,456) of the unallocated space on the imaged drive, image SHA-256…, examined on a verified working copy" is testimony. The forms that capture this are in Appendix F.
Common mistakes
- Confusing bits and bytes. Eight bits make one byte, and the difference shows up constantly: network and drive speeds are usually quoted in bits per second (megabits,
Mbps, lowercaseb), while sizes are in bytes (megabytes,MB, uppercaseB). A "100 Mbps" link moves about 12.5 MB per second, not 100. Mixing them produces estimates off by 8×, which is how imaging-time predictions go embarrassingly wrong. - Forgetting endianness. Reading a little-endian multi-byte field left to right as if it were big-endian (or vice versa) yields garbage. When a parsed value looks absurdly large or small, byte order is the first thing to check.
- Believing "format" or "delete" destroys data. It almost never does on a magnetic drive. A quick format lays down a new index and leaves the old data clusters intact; a delete clears a pointer. Treating either as secure erasure is a mistake clients make and that you must not — both for setting recovery expectations and for advising on secure disposal.
- Treating an SSD like an HDD. The instinct "deleted data persists, so we have time" is true for spinning disks and dangerously false for TRIM-enabled SSDs, where the window can close in seconds. Always identify the medium first; the medium decides what is possible.
- Using the wrong sector size in offset math. A drive may be 512n, 512e, or 4Kn. Assuming 512 on a 4Kn drive throws every byte-offset calculation off by a factor of eight. Confirm the logical sector size from your imaging tool and write it down.
- Off-by-one and base-confusion in offsets. Hex dumps count from offset zero, and offsets are usually shown in hex while file sizes are reported in decimal. The first byte is at offset 0, not 1;
offset 10in a dump means decimal 16. Label every number with its base. - Working on the original. Browsing, mounting read-write, "just taking a quick look," or running recovery tools against the source device can overwrite the very free space you need — and, in a forensic matter, destroys admissibility. Image first, verify the hash, work on the copy. The original is sacred.
- Confusing logical (file) size with physical (allocated) size, and ignoring slack. A file's content size and the space it occupies on disk differ because of cluster rounding, and the gap — slack space — can hold evidence from earlier, deleted files. Reporting only logical content while ignoring slack misses real data.
Limitations: knowing when to stop
This chapter's central promise — deleted ≠ destroyed — is the default truth of digital storage, but it is a default with genuine exceptions, and a mature professional sizes those exceptions before making any promise to a client, a manager, or a court. Theme five — know your limitations — starts here, where the optimism of "the data is probably still there" must be tempered with the honest cases where it is not.
The data is genuinely gone, or genuinely unreadable, when:
- It has been overwritten. Once new data is physically written over the old clusters — by ordinary reuse on a busy volume, or deliberately by a secure-wipe tool that passes zeros or random bytes over the space — the original is gone. On modern HDD densities a single overwrite pass is sufficient; the old multi-pass folklore and "magnetic-force microscopy can read under an overwrite" claims do not hold against current drives. There is no software, and in practice no laboratory, that recovers truly overwritten data on a modern drive.
- TRIM and garbage collection have run on an SSD. As covered above, a deletion on a TRIM-enabled SSD invites the controller to physically erase the underlying flash pages on its own schedule, often within minutes. After that, the logical blocks return zeros and the data is unrecoverable through any normal means. Chapter 9 covers the narrow exceptions (TRIM disabled, certain RAID and USB-bridge configurations, chip-off attempts) and why none of them should be assumed.
- It is encrypted and you lack the key. Full-disk encryption (BitLocker, FileVault, LUKS, VeraCrypt) is the great asterisk on this whole chapter. The encrypted bits persist on the medium just as faithfully as any others — but without the key they are computationally indistinguishable from random noise. The pointer-not-data principle still holds at the physical layer; it simply does not help you, because reading the bits gains you nothing. Strong, correctly implemented modern encryption with a good passphrase is, for practical purposes, unbreakable by brute force. Chapter 29 — Encrypted Device Forensics is honest about what you can and cannot do.
- The medium is physically destroyed or degraded. Degaussing scrambles a platter's magnetization beyond reading; physical shredding, incineration, or drilling ends the conversation; and ordinary failure — a head crash that scores the platter, NAND that has worn past its erase-cycle limit — can put data out of reach without a clean room or chip-level work, the province of Chapter 8 and Chapter 9.
- The physical layout is hidden by the FTL. On flash, the Flash Translation Layer constantly remaps and relocates data, so the tidy "sector × size = offset" model that works beautifully on an HDD does not directly expose the physical truth of an SSD. You read what the controller chooses to present. This is not a failure of the principle but a limit on your direct access to the physical layer.
Recognizing these limits is not pessimism; it is professionalism. Promising a client their photos are "definitely recoverable" before you know whether the drive is a TRIM-enabled SSD, before you know whether the space was reused, before you know whether the volume is encrypted, is how reputations are lost. "I need to examine the medium before I can tell you what is recoverable" is the honest and correct first answer — and in forensics, "the evidence is insufficient to reach a conclusion" is itself a valid, defensible professional finding.
Progressive project: establish your byte-level baseline
This book's spine is the Forensic Case File — a complete, court-style investigation you build one skill at a time, beginning in earnest with the assignment and acquisition in Chapter 5. Chapter 2's contribution is the literacy everything else assumes. Before the next chapter, do three concrete things and keep the results — they become the opening pages of your case file's technical notes.
- Get a hex tool working and prove you can read bytes. Install or locate
xxd(Linux/macOS/WSL), HxD (Windows GUI), or simply use PowerShell'sFormat-Hex. Dump the first 16 bytes of three files of different types — a.jpg, a.pdf, and a.zipor.docx— and write down each signature you see. Confirm them against Appendix A — File Signatures Reference: you should findFF D8 FFfor the JPEG,25 50 44 46(%PDF) for the PDF, and50 4B 03 04(PK..) for the ZIP/Office file. - Prove that an extension can lie. Copy your
.jpgto a new name ending in.txt, then dump its first bytes again. The signature is unchanged —FF D8 FF— even though the name now claims it is text. Note in your case file why this matters: forensic identification trusts the bytes, not the name, and Chapter 7 builds an entire technique on that fact. - Record the media geometry and run the arithmetic. For whatever practice drive or image you will use, record its logical sector size and total sector count (your operating system or imaging tool reports both), and compute its capacity with
total sectors × sector size. Then, as a drill, compute the byte offset of sector 2048 and the sector number containing byte offset 1,073,741,824 (1 GiB). Gettingbyte offset = sector × sector sizeinto muscle memory now pays off in every later chapter. (Sources for practice images and a full lab build are in Appendix J — Practice Images and Lab Setup.)
When you can read a signature on sight, explain why a renamed file still gives itself away, and convert fluidly between sectors and byte offsets, you have the baseline. Everything from acquisition to testimony builds on it.
Summary
This chapter descended from the file you double-click all the way down to the magnetized grain and the trapped electron, and then climbed back up — and on that round trip you met every layer of abstraction that stands between a human's idea of a "file" and the physical reality on the medium. Data is, at bottom, nothing but bits: two-state values chosen because two states are easy to keep reliable. Bits group into bytes, the fundamental unit of storage, which we read in hexadecimal because one hex digit maps cleanly onto one nibble and two onto a byte. A byte has no inherent meaning — the same 0x4D is 77, or M, or a flag, depending entirely on interpretation — and multi-byte values carry the further subtlety of endianness, which is a property of the format, not only the machine.
Physically, a hard drive stores each bit as the magnetic orientation of a tiny region on a spinning platter, and that orientation persists, stable and undisturbed by reading, until a write head deliberately changes it. A solid-state drive stores each bit as charge trapped in a flash cell, organized into pages that can be written and blocks that must be erased as a unit — an asymmetry that forces the controller to relocate data constantly through the Flash Translation Layer and, via TRIM and garbage collection, to physically erase deleted data on its own schedule. Above the hardware sit sectors (the drive's addressable unit, 512 bytes traditionally, 4,096 in Advanced Format), then clusters (the file system's allocation unit), and the gaps left by cluster rounding — slack space — quietly preserve fragments of older, deleted files.
And atop all of it sits the idea that justifies both disciplines: deleting a file removes the pointer — the directory entry or MFT record, plus a "this space is free" mark — but leaves the data physically in place until something overwrites it. That gap between marked free and actually overwritten is the window recovery and forensics work inside. The window is wide on magnetic media and can be vanishingly narrow on a TRIM-enabled SSD; it closes for good upon overwriting, strong encryption, or physical destruction. The wedding-photos drive survived its reformat because a quick format burns the map, not the territory — and you can now read the territory directly, one byte at a time.
You can now: - Read a hex dump fluently — offset, hex, and ASCII columns — and translate confidently among binary, hexadecimal, decimal, and ASCII for any byte. - Recognize a file by its signature (e.g.,
FF D8 FF= JPEG,50 4B 03 04= ZIP/Office,4D 5A= Windows executable) regardless of its extension, and account for endianness when reading multi-byte fields. - Explain physically how an HDD stores a bit as magnetic orientation and an SSD stores a bit as trapped charge, and why that difference governs recoverability. - Navigate the logical/physical stack — bit → byte → sector → cluster → file — and compute byte offsets from sectors (and back) usingbyte offset = sector × sector size, accounting for 512 vs. 4Kn sizing. - Identify slack space and explain why it harbors recoverable fragments of deleted files. - State, defend, and bound the book's foundational principle — deletion removes the pointer, not the data — including the real cases (overwriting, TRIM, encryption, physical destruction) where the data truly is gone.
What's next. Chapter 3 — Storage Technology — takes the bit-level physics you just learned and builds out the full machines: the mechanical anatomy of hard drives (platters, heads, actuators, the PCB) and their failure modes, the internal architecture of SSDs (controller, NAND, DRAM, the FTL) and how flash wears out, and the multi-disk worlds of RAID, NAS, and SAN. Where this chapter asked how is a single bit stored?, the next asks how are real devices built, how do they fail, and what does each failure mean for getting the data back?
Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.