File slack / RAM slack: why does Windows write arbitrary RAM bytes to disk? Does Linux too?

Question

I just read about file slack in a book about Windows 7. What I already (think to) know:

• Windows stores data on the disk in clusters. A cluster usually contains 8 sectors of 512 bytes each, so 4096 bytes or 4kiB.
• Large files get split over multiple clusters, when the remainder of a file does not fill an entire cluster, this remaining unused space at the end of the cluster is called "file slack".
• Windows always writes 512 byte blocks at once, so the first only partially used sector must get filled up before being written to disk.
• For whatever reason, Windows decides to pick a random sequence from RAM to fill this sector.
• The remaining unused sectors in the partially used cluster remain unchanged and keep the bytes they had before, which can be parts of a previously deleted file in this location. It's called drive slack.

Are those assumptions correct?

And why does Windows write random pieces of memory (which could contain passwords etc) to my disk simply to fill up space - and not just zero these bytes out?

And is this behaviour specific to Windows (which versions?) or is it specific to the NTFS file system? Would Linux or ext4 file systems do the same?

Answer 1

"File Slack" refers to the data between the last byte of the file and the end of the cluster. It usually contains whatever bit pattern the OS uses to represent unallocated memory.

"Drive Slack" refers to clusters that have been deallocated but not overwritten. It can also refer to unallocated space that no longer falls within a partition boundary.

"RAM Slack" -- I have never heard this term before. Googling this, all the resources I find seem to be quoting or deriving from a book titled "Cyber Forensics: A Field Manual For Collecting, Examining, and Preserving Evidence of Computer Crimes" by Albert J. Marcella, Jr. and Doug Menendez.

I read the chapter where the term is used. Even though it was copyrighted in 2010, it makes reference to the way DOS and Windows 95/98 did things. That hasn't been relevant for over a decade. I could be reading it out of context though. Either way, this book appears to be the source of the term.

---

Windows stores data on the disk in clusters. A cluster usually contains 8 sectors of 512 bytes each, so 4096 bytes or 4kiB.

This is correct in the case of legacy drives and 4K "advanced format" drives. The sector size is truly 4KB on 4K "native" drives, so there is a 1:1 correlation between sectors and clusters for those drives.

Large files get split over multiple clusters, when the remainder of a file does not fill an entire cluster, this remaining unused space at the end of the cluster is called "file slack".

Also correct.

Windows always writes 512 byte blocks at once, so the first only partially used sector must get filled up before being written to disk.

This is incorrect. Windows does not write in blocks; only clusters. It will write data at any arbitrary size, but they will be in multiples of the cluster size (usually 4KB). The only time Windows cares about sectors/blocks is when an LBA address must be calculated. The low-level disk driver does this, not the filesystem driver. It's actually very inefficient to do reads/writes in 512-byte chunks. It works against the drive's internal hardware caches. Doing a dd in Linux with a 512-byte blocksize will confirm this. It's an order of magnitude slower on both reads and writes.

For whatever reason, Windows decides to pick a random sequence from RAM to fill this sector.

Also incorrect. Windows will write whatever is in the buffer. Almost every application (including the filesystem driver) allocates fresh memory from the heap when writing to the output buffer. When an application allocates memory, it does so in pages, which are (guess what!) 4KB in size. Unallocated memory is usually represented by a repeating bit pattern (not 00 or FF), so that is what will be written to the end of the cluster if it's not full. In cases where the application's output buffer is a modified copy of its input buffer, the slack will contain whatever data the input buffer had in it.

The remaining unused sectors in the partially used cluster remain unchanged and keep the bytes they had before, which can be parts of a previously deleted file in this location. It's called drive slack.

Also incorrect. Windows will always do a full-cluster commit even if there's only 1 byte of changed data. It is true that deallocated clusters have whatever data was in them before. Windows does not bother with zeroing out deallocated clusters. But none of this takes place at the sector level.

4KB is a magic number. Memory pages are 4KB. I/O buffers are 4KB. Sectors are 4KB now. Even the drive's hardware is optimized for I/O requests that are 4KB (or some multiple thereof).

---

All modern operating systems work this way (Windows, Linux, and OS X). The only exceptions to the rules above are applications that have the disk open for raw access. They completely bypass the operating system's API calls for doing writes. You only see this with low-level recovery and forensic tools because such applications do not benefit from all of the optimizations you get with buffered I/O.

Answer 2

RAM slack is actually a well known digital forensics artifact.

Indeed older (i.e. Win 95/98) versions of Windows did write 512 byte memory blocks. Please do not confuse cluster writing to the media. When I write 512 byte memory, I mean Windows allocated/grabbed memory for writing out in 512-byte chunks, totaling the storage media cluster.

So example - 4096-byte clusters on storage media, and a file 2049-bytes long. Older Windows allocated and grabbed buffer/cache/memory storage in chunks of 512 bytes in memory for that 2049-byte file.

That requires 5 x 512-byte memory chunks. That leaves 511-bytes grabbed that was not part of the 2049-byte file. (5 x 512 = 2560, but 2049 / 512 = 4.002).

So what is in the 511-byte memory ( 2560 - 2049 = 511) ? In older versions, Windows did not clear the 511-byte portion, and wrote it out with the entire 4KB. That is what is referred to as RAM slack in digital forensics circles.