Volume slack vs file system slack; confusing definition

Not exactly sure about the reformat/reuse of $MFT and possible presence of old records (need to test this). But given the fact that records are not wiped (the index numbers are reused), there may be traces of previous records inside newer records. Regardless of the reuse of records, during the lifetime of a given record, it's attributes may change, like for instance with resident $DATA like smaller files that fit within the record. Therefore $MFT record slack may contain different sort of stuff like deleted ADS's etc. Steganographic use of this slack is also possible, as long as you have the ability to write to these sectors. I have thought of a PoC for this.

Edit This is of course a very NTFS specific slack issue, which is not relevant on other filesystems.

I would try to find something other than "indexed" and "unindexed". I understand what you are writing, but there file systems that do not use "indexing" per se, that is a separate set of references to the files in the storage media. Usually these are systems that write-once or primarily for sequential access, but are not exclusively.

I would try to find something other than "indexed" and "unindexed". I understand what you are writing, but there file systems that do not use "indexing" per se, that is a separate set of references to the files in the storage media. Usually these are systems that write-once or primarily for sequential access, but are not exclusively.

Well, I would gladly accept a replacement/better synonym for "unindexed" ) , and I would also appreciate a few practical examples of filesystems that behave like you describe.

I mean it is very possible that some filesystems exist that also do not consider the sector or the cluster a "boundary" or "minimal unit" of some kind besides not using some form or the other of an "index", and in case, just to prove a point, you may well write one, but I thought the this list as a possiibly easily understandable mnemonic or digest for practical uses on "common" filesystems that the forensic investigators actually happen to find "usually" on a disk drive, not the "ultimate answer to all questions filesystem related", nor as a replacement for a "generic" Wikipedia article, like
http//en.wikipedia.org/wiki/File_system
or for any of the specific "in deep" articles that the forensic community produces, let0s call it a "quick check list".

But nothing prevents from adding to each entry in definition list a [1], [2], [3], etc. set of footnotes, Wikipedia style, like (example)

1. "file slack" <-
   unindexed

   <put a better word here> space between file size and allocated space, three types

1. "sector file slack" <-
   unindexed

   <put a better word here> 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

   <put a better word here> space between file size and next cluster border

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

3. "valid data file slack" <-
   unindexed

   <put a better word here> space between actual file size and declared file size [1]

[/listo]

4. "filesystem slack"<-
   unindexed

   <put a better word here> space within the filesystem

5. "volume or partition slack" <-
   unindexed

   <put a better word here> space outside the filesystem but inside the partition/volume

6. "disk slack" <-
   unindexed

   <put a better word here> space outside the partition volume but (obviously) inside the disk

[/listo]
[1]- only on NTFS filesystems where the SetFileValidData() function or "fsutil file setvaliddata" has been used to allocate to the file a size exceeding the size of it's contents

Or we could make several of such lists, one for each specific "common" filesystem, integrating it with new findings and with new lists when new filesystems will be "out in the wild" (I am thinking of the new ReFS or "protogon")
http//blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx
http//reboot.pro/15466/

jaclaz

Sorry to chip in, but how about these

1. "file slack" additional bytes between allocated sectors and actual file size , three types
1. "sector file slack" <- additional bytes 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" <- additional sectors between file size and next cluster border

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

3. "valid data file slack" <- additonal clusters between actual file size and declared file size [1]

[/listo]

4. "filesystem slack"<- unallocated sectors within the filesystem
5. "volume or partition slack" <- additional sectors outside the filesystem but inside the partition/volume
6. "disk slack" <- sectors outside the partition volume but inside the addressable sectors on the disk

[/listo]
[1]- only on NTFS filesystems where the SetFileValidData() function or "fsutil file setvaliddata" has been used to allocate to the file a size exceeding the size of it's contents

This gets rid of the generic term "space" - and by using "sectors" you also make it more filesystem-independent.

Sorry to chip in, but how about these

This gets rid of the generic term "space" - and by using "sectors" you also make it more filesystem-independent.

Good, but actually (though I concur that "space" is a bit too "generic", but IMHO we need a more "generic" term than bytes/sectors/clusters.
I mean an "area" or "space" can be measured in different "units", but that won't change the actual "area" or "space" essence, you cannot define something by enumerating the units in which it is measured.

All types of slack are made of "bytes" (and by nibbles and by bits), on a "common" disk, NTFS, you "group" bytes by 512 and call them "sectors" and "group" them by 4096 and call them "clusters".

Additional could be a replacement for Unindexed, though I still understand better "unindexed", maybe "external"? ? - but the same problem arises "additional" or "external" to WHAT? (BTW you cheated and used Unallocated or "Nothing" in some of the other definitions), IMHO we must find something that explains "slack" using the same adjective in all items of the list.

"file slack" 1.1 is made of bytes (as it's value is between 0 and 511 or "sector size")-
"file slack" 1.2 is made of bytes (as it's typical value is between 0 and 4095 or "cluster size"), unless you use "fractional sector units" calling this "additional sectors" is wrong, BUT you have a point, in my view, anything after file end and next sector is "file slack" 1.1, and anything after file end and next cluster is "file slack" 1.2, i.e. this latter is comprehensive of the former.
In your view (that will need a change of the note, the former is from file end up to next sector, and the second is from the beginning of the unused sector till the next cluster.
I.e., current definition (example)
File End|<-file slack 1.1->|Next Sector0|Next Sector1|Next cluster|
File End|<--------------file slack 1.2-------------->|Next cluster|Your new approach
File End|<-file slack 1.1->|Next Sector0|Next Sector1|Next cluster|
File End|<-file slack 1.1->|<-----file slack 1.2---->||Next cluster|I like it. D
"file slack" 1.1 ("sector file slack") is an "area" or "space" (or let's find a better word for it) now expressed in bytes.
"file slack" 1.2 ("cluster file slack") is is an "area" or "space" (or let's find a better word for it) now expressed in sectors and does not "overlap" on the previous.

About file slack 1.3, what you wrote, at least according to the mentioned
http//blog.cmdlabs.com/tag/ntfs/
is plainly "wrong" 😯 , you can set "valid data" to a byte value, independently form sectors or clusters, the example sets the valid data to 1000 bytes.

jaclaz