2

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?

  • I highly doubt that your last assumption is correct. Referring to the one you didn't ask about – "Windows [does] write random pieces of memory to my disk" sounds like it'd have violated quite a few security testing requirements that Windows claims to have passed. – grawity Mar 29 '16 at 13:01
2

"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.

  • 1
    Okay, thanks for your detailed answer. Would you mind citing some official sources? I'd love to research more on that topic and learn what you found out. However, if your statements are correct, why do so many sources claim the described RAM slack phenomenon and why are there forensic tools to read and analyze this part of the file slack and scan it for possibly sensitive data like passwords? – Byte Commander Mar 30 '16 at 6:50
  • I showed up here myself because my college textbook is covering RAM slack (although not in depth). The book was published in 2014. – Seth Nov 28 '16 at 2:42
  • @Seth; I would be very interested in hearing what this book has to say about the subject. It's quite possible that "RAM slack" refers to some other thing that I've been calling a different name. – Wes Sayeed Nov 28 '16 at 3:32
  • @WesSayeed i.stack.imgur.com/9hUUF.jpg. Pretty much just that paragraph. – Seth Nov 28 '16 at 3:52
  • @Seth; What's the title of this book? The wording and contextual usage sounds almost exactly like the source I found. – Wes Sayeed Nov 28 '16 at 5:09
0

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.

  • 1
    As there seems to be quite some confusion about this topic (e.g. the other answer disagrees with what you wrote), do you have any sources you can cite? – Byte Commander May 5 '17 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.