If you've taken a look through Explorer++ recently, you might have noticed an option to 'Save file slack...'. What exactly is file slack though?

To understand file slack, one first needs to understand how disks are organized at the lowest level. As can be seen in the diagram below, disks are subdivided into a set of tracks. These tracks are further subdivided into a set of sectors. A collection of sectors form together to make a cluster.

Figure 1. Generic disk structure. A - Track, C - Sector, D - Cluster.

What's important here is to realize that a sector is the smallest accessible unit available on a disk for reading and writing. This means that at the lowest level, data can only be read/written in terms of sectors, not in terms of bytes. For example, reading one byte from a disk can only be achieved by reading in the entire sector that that byte resides within.

Unfortunately, the relatively small sector size in comparison to the total disk size means that reading/writing directly to sectors would incur a significant management overhead. To help alleviate this problem, the notion of a cluster was introduced. A cluster is simply a collection of consecutive sectors on the disk. By increasing the cluster size, the cost of disk management can be reduced.

Now, whereas the sector is the smallest accessible unit on the disk, the cluster is the smallest unit under which files are stored. So, clusters can be thought of as containers that are able to hold some portion of a file (or perhaps the whole file, if it small enough).  Files are always allocated a whole number of clusters , so if a file is bigger than one cluster, it will be allocated two, and so on.

To see an example of this, create a file that has a size of one byte. When you view the files properties in windows, you will notice that the size is given as 1 byte (this is the logical file size), however the size on disk is given as something like 4096 bytes (this is the physical file size, and will vary based on the cluster size of your file system). Even though the file is only 1 byte in size, it has been allocated an entire cluster. In this example, the remaining 4095 bytes allocated to the file are wasted.

If you then increase the file size to 4097 bytes (or one byte more than whatever your cluster size your file system has), you'll notice that the size on disk is twice what is was before (8192 bytes in this case). This is because the file overflowed one cluster, and was allocated another by the operating system.

It should be clear at this point that a problem will arise concerning internal fragmentation (i.e. wasted space within individual clusters). Since clusters by their nature are constructed to house data from a single file, any unused space within a cluster will be unused and wasted.

Figure 2. File slack

For example, say that you want to write a 1KB file to a disk that has a cluster size of 4KB. As the cluster can only have one file allocated to it, the last 3KB of the cluster will be wasted. This unused space between the logical end-of-file and physical end-of-file is known as the file slack.

The perhaps somewhat unexpected consequence from this is that the file slack contains whatever data was on the disk before the cluster was allocated, such as data from previously deleted files. Using file slack, it would be possible not only to recover previously discarded (and potentially sensitive information) information, but also to effectively hide data. The ability to hide data arises because the operating system does not modify data within a cluster once it has been allocated. This means that any data that is stored in the slack is safe (provided the files size does not change).

So how do you go about accessing a files slack space? Put simply, you just need to extend the file (i.e. increase its size) to the physical end-of-file. The problem that arises is that most ordinary programs can only do this destructively. Writing to a file with notepad, for example, may extend that file, but any data in the files slack is overwritten with the data that you entered into notepad.

The solution is simply to extend the file without writing any data to it. This can be done easily in a language such as C. 

The procedure to read data out of a files slack space would be something along the lines of:

1.       Extend the file out to the physical end-of-file.

2.       Read data between the original end-of-file and the physical end-of-file (remember this is the files slack).

3.       Shrink the file back down to initial file size.

Likewise, to store data in the file slack, the procedure would be something like:

1.       Write data to be stored to the end of the file (this will automatically increase the files size).

2.       Non-destructively shrink the file such that any stored slack data is beyond the logical end-of-file but before the physical end-of-file.

One important point to note is that data within the last valid sector of the file (i.e. the sector that contains the logical end-of-file) is zeroed when a file is written. This constrains the slack space that can be used to hold data, since only sectors past the last valid one can be used to store any data.

I hope this helps to explain what is happening when you ask Explorer++ to read and save a files slack. Note that I didn't get into a lot of detail about issues such as why management overhead decreases with increasing cluster size or how cluster size affects internal fragmentation. If you are interested, the references below contain more information, and Google is a great resource if you're looking to find out more about how files are stored on disk.

References: 

File Slack Defined - http://www.forensics-intl.com/def6.html

Hard Disk Drive Basics - http://www.ntfs.com/hard-disk-basics.htm

Slacker is a tool from metasploit that allows you to hide files within the slack space of the NTFS file system. You can download it from: http://www.metasploit.com/research/projects/antiforensics/