Volume slack vs fil...
 
Notifications
Clear all

Volume slack vs file system slack; confusing definition

45 Posts
8 Users
0 Likes
5,995 Views
yunus
(@yunus)
Posts: 178
Estimable Member
Topic starter
 

Hi all,

Can you clearly understand the difference between "volume slack" and "file system slack"?

I have come accross the following definitions on the internet, which says;
"…Volume slack is the unused space between the end of file system and end of the partition where the file
system resides. File system slack, is the unused space in the end of a file system that is not allocated to any cluster…"

I understand file system slack clearly. It makes sense easily as it is mathematical, however, volume slack's definition is not clear. The definition says "unused space between the end of file system and end of the partition where the file system resides. That does not tell about why it exists. Where does it come from? What is it that cause volume slack to emerge?

Can you make a clearer differentiation?

Regards,

 
Posted : 12/07/2012 1:09 pm
athulin
(@athulin)
Posts: 1141
Noble Member
 

"…Volume slack is the unused space between the end of file system and end of the partition where the file system resides.

That seems clear enough. If the granularity of the partition and the file system are different, there will be space in the partition that the file system cannot utilize. That's what I personally would call 'partition slack' – – space in a partition that isn't used by whatever structure the partition contains.

The term 'volume slack' hints at Carrier being the possible source of this definition – and indeed, on p. 178 in 'File System Forensic Analysis', I find a definition that covers it.

However, I also find (in Vacca System Forensics, Investigation and Response, p. 86), a different definition, in which 'volume slack is the space that remains on a hard drive if the partitions do not use all the available space'. (But perhaps Vacca defines 'volume' in some new way?)

File system slack, is the unused space in the end of a file system that is not allocated to any cluster…"

That seems to presuppose a file system that has a explicit or implicit specification of extent that has a granularity larger than a single sector. (It also seems to make an assumption about where filesystems may place clusters, which doesn't seem to have anything to recommend it.)

The source I think you are referring to also says "… This happens due to the partition size may not be the multiple of the cluster size (Carrier, 2005). For example, there is 10001 sectors in the partition, there first 10000 sectors are allocated to 2500 clusters with the cluster size of 4 sectors and the last sector left becomes file system slack. '

I suspect a general attack of confusion, possibly brought on by the differences in terminology – note that this writer does not use 'volume', but 'partition', and also seems to think that clusters are related to partitions instead of file systems, i.e. he appears to have mislaid an entire level in the hierarchy of on-disk structures.

As for the meaning, I suggest you ask the author himself he might simply have expressed himself unfortunately. Ask him to give an example of a file system / partition conbination which may exhibit this particular form of slack, for example.

(Added More likley, the definition was not intended to be a general definition, but refer only to NTFS.)

 
Posted : 12/07/2012 3:46 pm
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

yunus, the definition you found, I presume here
http//www.forensicfocus.com/Content/pid=66/page=2/
is IMHO somewhat misleading lexically, (personally I would call the "Volume slack" "partition slack").

To me Volume and filesystem are the SAME thing (with the exception for "recent" NTFS of the excess copy of the bootsector on last sector).

This latter however helps to clear the idea.

On a normal disk, with only one partition, NTFS formatted, geometry 255/63, you will have this situation

  • MBR+hidden sectors (let us assume a 2K/XP, these will be 63 sectors)
  • Partition, extending from (say) sector 63 to sector 625121280
  • The partition extends for 625121280-63=625121217 sectors.

But if you look in BPB of the bootsector, you will see how the NTFS volume is 625121216 in size.
This is because there is a (by design) "partition slack" of exactly one sector between the end of the Volume (or filesystem) and this "unindexed anywhere" sector is filled with a backup copy of the first sector of the Volume (or filesystem).

Those that are used to MS tools are somewhat "deceived" by the fact that on disks the FORMAT command is NOT "independent" from the "disk management".
The procedure is

  1. use FDISK or Disk Management or diskpart to create the partition
  2. a drive letter is assigned to the partition thus created (actually to the unformatted Volume that the partition represents)
  3. the Format command is then run on the drive letter and it "fills" the whole space of the partition (actually unformatted volume) with a filesystem (in the case of NTFS the filesystem is one sector smaller than the space available)
  4. [/listo]
    The various "advanced" partition tools that are able to resize partitions also keep the partition size linked to the Volume and to the filesystem, resizing these latter ones accordingly.

    But actually nothing prevents you to create a smaller filesystem (or a bigger partition), as an example by creating a partition and volume filesystem "normally" and then manually change the data in the partition table in the MBR to add some sectors to the partition size (i.e. shifting a few sectors it's end).

    In this operation the Volume and filesystem data is not touched in the least and you have a number of "slack" sectors after the end of the Volume/filesystem and before the start of the following partition (or the end of the disk).

    If you prefer, the entry in the MBR partition table is only saying that from address X to address Y there is "something" (i.e. that that space is "reserved" to "something" and that to know what is the something you should read the data in the first sector of the addressed space).
    Once you read that data (filesystem size) you use these latter data only, and you are not going to check if it is exactly the same as the "reserved space" you read before in the MBR.

    Think of it as a building 😯 , let's say a six storeys one with 2 flats at each level.
    When you build it you buy a nice brass plate for the doorbell pushbuttons nicely aligned in 6 rows by 2 columns.
    Then a rich man buys the two top flats and makes a single apartment/penthouse out of them.
    You have three possibilities

    1. you leave everything "as is" and have the two top buttons with two tags to the same name (and connect them to the same single doorbell)
    2. you leave everything "as is" and have the two top buttons one with a name tag connected to the single doorbell and one with a blank tag and the button not connected
    3. you buy a new brass plate with 5 rows with two buttons and the top row with a single button
    4. [/listo]
      If you choose #3 you have effectively created an "apartment slack" (or a "flat slack") wink , or, if you prefer, you have "unindexed" an area of the building.

      HTH

      jaclaz

 
Posted : 12/07/2012 4:31 pm
C.R.S.
(@c-r-s)
Posts: 169
Estimable Member
 

@jaclaz
You are right, I think, regarding the cited definitions. But it generally is an unwanted situation and except of those who are faced with the particular problem there should not be many undersized file systems. Someone should rather have an eye on the space between partitions, which is commonly used by advanced malware for own (encrypted) file systems.

 
Posted : 13/07/2012 8:33 am
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

Someone should rather have an eye on the space between partitions, which is commonly used by advanced malware for own (encrypted) file systems.

Yep ) , that is a "third type" of slack, gaps between a partition or volume and the one following it.
I would call it "disk slack".
A particular case of it is (was) typical on devices partitioned with the "old" standard of "aligned cylinder", you always had some space, smaller that 1x255x63x512=8,225,280 bytes (on a 255/63 geometry device) at the END of the disk, i.e the disk space is not fully indexed in the partition tables of the MBR and of the various EPBR's.

Also very easy to reproduce experimentally.
Create one partition (or volume inside Extended).
Create a (very small) second partition (or volume inside Extended).
Create a third partition (or volume inside Extended).
Delete the second partition.
You have effectively created a little "no man's land" on the disk that you can read/write allright with direct access disk tools, such as a disk editor, dd and similar, etc.

In the previous building example that would correspond to a "hidden level" that the builder has made (of course with no windows on the outside) between (say) 3rd and 4th floor, that you can access through an undocumented stop of the elevator wink .

To sum up

  1. "filesystem slack"<- unindexed space within the filesystem
  2. "volume or partition slack" <- unindexed space outside the filesystem but inside the partition/volume
  3. "disk slack" <- unindexed space outside the partition volume but (obvioulsy) inside the disk
  4. [/listo]

    jaclaz

 
Posted : 13/07/2012 2:47 pm
C.R.S.
(@c-r-s)
Posts: 169
Estimable Member
 

And

0. file slack between file size and allocated cluster size.

  1. "filesystem slack"<- unindexed space within the filesystem
  2. "volume or partition slack" <- unindexed space outside the filesystem but inside the partition/volume
  3. "disk slack" <- unindexed space outside the partition volume but (obvioulsy) inside the disk
  4. [/listo]

 
Posted : 13/07/2012 9:38 pm
Patrick4n6
(@patrick4n6)
Posts: 650
Honorable Member
 

And

0. file slack between file size and allocated cluster size.

  1. "filesystem slack"<- unindexed space within the filesystem
  2. "volume or partition slack" <- unindexed space outside the filesystem but inside the partition/volume
  3. "disk slack" <- unindexed space outside the partition volume but (obvioulsy) inside the disk
  4. [/listo]

If we're increasing the number of slack definitions, you need to add RAM slack, which is the space between the end of file and the end of the sector. Some lazy systems write RAM content in there, hence RAM slack.

 
Posted : 13/07/2012 10:30 pm
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

And

0. file slack between file size and allocated cluster size.

Good ) , but since the list tag starts with 1, let's renumber the whole lot

  1. "file slack" <- unindexed space between file size and allocated cluster size (very limited, on smallish cluster size filesystems like NTFS with a cluster size of 4 Kb)
  2. "filesystem slack"<- unindexed space within the filesystem
  3. "volume or partition slack" <- unindexed space outside the filesystem but inside the partition/volume
  4. "disk slack" <- unindexed space outside the partition volume but (obvioulsy) inside the disk
  5. [/listo]

    If we're increasing the number of slack definitions, you need to add RAM slack, which is the space between the end of file and the end of the sector. Some lazy systems write RAM content in there, hence RAM slack.

    I don't know. ?

    That should be partially the same area of the "file slack".

    Let's say that you have a file 12,720 bytes in size on a 512 byte/sector device, with a filesystem 4 Kb (8 sectors) and that the filesystem is "cluster aligned".
    File will occupy 24 "whole" sectors + 432 bytes of the 25th sector, and your "RAM slack" would be 80 bytes in size.
    File will occupy 3 "whole" clusters + 432 bytes of the 4th cluster and C.R.S.'s "file slack" would be 80+7*512=3,664 bytes.

    jaclaz

 
Posted : 13/07/2012 11:25 pm
C.R.S.
(@c-r-s)
Posts: 169
Estimable Member
 

Good ) , but since the list tag starts with 1, let's renumber the whole lot

Nobody expects the Spanish inquisition!

I don't know. ?

That should be partially the same area of the "file slack".

Yes, I think. There is confusion about sector and cluster slack. Even X-Ways writes on its German product pages regarding the "trusted download" feature, that it avoids "cluster overhang" to be written to the destination media. In my opinion, clusters are the logically allocated/addressed unit, but only sectors are actually written by the file system.

 
Posted : 14/07/2012 12:08 am
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

Nobody expects the Spanish inquisition!

Sure, that's by design ) , WHEN it will come, the Spanish inquisition will be UNEXPECTED (but we will be ready for it NONETHELESS wink )

  1. "file slack" <- unindexed space between file size and allocated space, two types
    1. "sector file slack" <- unindexed space between file size and next sector border (Maxsize=SectorSize-1, i.e. on a 512 byte/sector device at the most 511 bytes)
    2. "cluster file slack" <- unindexed space between file size and next cluster border
    3. (Maxsize=ClusterSize-1, i.e. on a typical 4096 byte/cluster filesystem at the most 4095 bytes)
      "cluster file slack" is comprehensive of "sector file slack" .
      [/listo]

    4. "filesystem slack"<- unindexed space within the filesystem
    5. "volume or partition slack" <- unindexed space outside the filesystem but inside the partition/volume
    6. "disk slack" <- unindexed space outside the partition volume but (obviously) inside the disk
    7. [/listo]

      jaclaz

 
Posted : 14/07/2012 1:16 am
Patrick4n6
(@patrick4n6)
Posts: 650
Honorable Member
 

If you want to be technical, the formula for calculating RAM slack is
FileSize MOD 512

File slack is
FileSize MOD ClusterSize

For those who didn't study computer science, MOD is http//en.wikipedia.org/wiki/Modulo_operation

 
Posted : 14/07/2012 10:30 am
athulin
(@athulin)
Posts: 1141
Noble Member
 

[*]"file slack" <- unindexed space between file size and allocated space, two types

  1. "sector file slack" <- unindexed space between file size and next sector border (Maxsize=SectorSize-1, i.e. on a 512 byte/sector device at the most 511 bytes)
  2. "cluster file slack" <- unindexed space between file size and next cluster border
  3. (Maxsize=ClusterSize-1, i.e. on a typical 4096 byte/cluster filesystem at the most 4095 bytes)
    "cluster file slack" is comprehensive of "sector file slack" .[/listo]

It's not at clear what purpose the definition of 'sector file slack' serves – unused space is unused space, no matter where it appears. And 'sector file slack' is an 'interesting' definition only for file system implementations where that particular space may contain interesting data.

Some versions of NTFS (XP and up) has a special type of file slack inside files, always at the end, where file contents is specified to be zero, yet there are allocated clusters (which will not be read for data). The system call SetValidData() describes this particular functionality. It's a kind of strange 'sparse file'. It doesn't fit the usual definition of 'slack' (as data in 'gaps'), but as the effect of it is much the same as that of ordinary slack, it may deserve a nod of recognition.

 
Posted : 14/07/2012 11:25 am
jaclaz
(@jaclaz)
Posts: 5135
Illustrious Member
 

If you want to be technical, the formula for calculating RAM slack is
FileSize MOD 512

NO.
It is

FileSize MOD SectorSize

We do have most devices having 512 bytes/sector, but this is not *always* the case and it will be increasingly less so in the future.

It's not at clear what purpose the definition of 'sector file slack' serves – unused space is unused space, no matter where it appears. And 'sector file slack' is an 'interesting' definition only for file system implementations where that particular space may contain interesting data.

The idea (at least mine) was to use the question by yunus as a start point to "consolidate" all types of "unindexed" areas (and possibly the reason why this happens), putting together all the experiences/suggestions as to provide a "common definition".

Some versions of NTFS (XP and up) has a special type of file slack inside files, always at the end, where file contents is specified to be zero, yet there are allocated clusters (which will not be read for data). The system call SetValidData() describes this particular functionality. It's a kind of strange 'sparse file'. It doesn't fit the usual definition of 'slack' (as data in 'gaps'), but as the effect of it is much the same as that of ordinary slack, it may deserve a nod of recognition.

Can you expand on this?
Is it not a "plain" sparse file?
From what you write it sounds more like some areas "inside" the files, if you prefer a "very soft" form of steganography…. ?

jaclaz

 
Posted : 14/07/2012 3:41 pm
athulin
(@athulin)
Posts: 1141
Noble Member
 

Can you expand on this? Is it not a "plain" sparse file?

I'm sure you know it already – it made a bit of a stir when it was introduced in XP.

Sparse files in Windows are created only by DeviceIoControl() calls. But this thing is done by SetValidData(), which would be called (roughly) as

SetValidData( ..., GetFileSize() + 65536 or whatever);
which adds 65536 (or whatever) bytes at the end of the file.

This allocates enough clusters to hold the extra space at the end of the file. To make this fast, NTFS never initializes those clusters, but remembers the previous file size (sometimes called 'logical file size', but that's a very misleading term). Anyway, any read from the area between that byte offset and the new end of file will always return zeroed bytes, regardless of what the allocated clusters actually contain. They don't get new data until something is actually written to this area.

It's a kind of special file slack, in that there are clusters at the end of the file, the actual contents has not been overwritten, but which cannot be read by the user process. And it's kind of like sparse files in that if the user process tries to read these clusters, it only gets zeroed bytes back.

 
Posted : 15/07/2012 1:08 am
Patrick4n6
(@patrick4n6)
Posts: 650
Honorable Member
 

It's not at clear what purpose the definition of 'sector file slack' serves – unused space is unused space, no matter where it appears. And 'sector file slack' is an 'interesting' definition only for file system implementations where that particular space may contain interesting data.

It's not "sector file slack", it's RAM slack, and the importance is knowing how the data past EOF got there. For most file slack, it's remnants from the last file in that cluster. For RAM slack, it's potentially data from RAM and has no relevance to the last file that resided on the disk. We are not just in the business of WHAT, but also of WHY and HOW (plus WHERE, WHEN and WHO). A large part of this industry is also about knowing the exceptions to the rules as they sometimes make or break.

 
Posted : 15/07/2012 5:33 am
Page 1 / 3
Share:
Share to...