±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 33982
New Yesterday: 0 Visitors: 168

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

RSS Feed Widget

±Latest Webinars

Volume slack vs file system slack; confusing definition

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Wed Jul 18, 2012 6:48 pm

- jhup
Maybe that is why I think sparse files muddle the definition.

Could you be so kind as to explain to me WHERE inside a sparse file there is "slack"?
Or how a sparse file can "produce" slack?

As I see it, and as said, creating a sparse file or writing data to it does not create any kind of "peculiar" file slack (though it may create, just like any file "sector file slack" or "cluster file slack").

Am I missing something?
Can you fill the gaps?
Can you post an example of "file slack" that is "typical" of sparse files ( and of sparse files only)?

Possibly the difference is that you consider TWO types of "sparse files":
I have seen two types of sparse files. One, where the OS/application interprets a "empty" section of a large data set and compressed it on the disk. Second, where a an application reserves a large amount of disk space by creating a large file with empty content, to be used in future.

In either case, from the drive perspective, file slack may exist. In the first scenario there is no virtual "slack", as the empty space only exists as it is referenced from the OS/application. In the second scenario, there is "internal slack space" that may or may not have been used, but currently not in use.

whilst I consider only the first as being actually "sparse", the second being a form of the "setvaliddata" type.
Can you give some examples of some apps that actually "reserve a large amount of disk space by creating a large file with empty content" BUT that does not use the "setvaliddata" approach AND tyhat does not actually writes 00's to it?


jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Thu Jul 19, 2012 2:56 am

I cannot because I do not disagree with you.

I referred to "slack" in sparse files, but I do not consider it real slack space as we define it.  

jhup
Senior Member
 
 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Thu Jul 19, 2012 7:02 am

- jhup
I cannot because I do not disagree with you.

I referred to "slack" in sparse files, but I do not consider it real slack space as we define it.


Good, then "sparse files" do not belong (in the sense that they don't "deserve a special mention") to the list.

Right now we are still at:
  1. "file slack" <- unindexed space between file size and allocated space, three 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
      (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 space between actual file size and declared file size (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)
  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 (obviously) inside the disk

Ideas, corrections, corollaries?

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Thu Jul 19, 2012 11:24 am

Maybe slack space found within $MFT (kind of like file slack, but for the records) is worth a note. Don't forget that roughly 40-50% of the $MFT is slack space, so if your Master File Table is 400 MB you will have around 200 MB of slack space within in.
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Thu Jul 19, 2012 12:21 pm

- joakims
Maybe slack space found within $MFT (kind of like file slack, but for the records) is worth a note. Don't forget that roughly 40-50% of the $MFT is slack space, so if your Master File Table is 400 MB you will have around 200 MB of slack space within in.

Yes Smile , this may be an addition.

But what contents may it contain? Question
I mean, let's start from the beginning.
You get a brand new disk drive.
From factory it is - unless I am mistaken "fully wiped" or all 00's.
Then *somehow* *someone* partitions it.
Then *somehow* *someone* formats the partition/volume as NTFS and creates the original $MFT.
All the "slack" space of the $MFT is 00's.
During the life of the disk (nowadays seemingly a shorter one than what we were used to) the disk may be re-paritioned/re-formatted several times, possibly without wiping the disk (though with the newer FORMAT behaviour of Vista and later this might happen increasingly more seldom).
I have seen that the location of $MFT is *somehow* (possibly there is a resource that explains the algorithm, but right now I don't recall a source for it) "hardcoded" in the sense that a "normal", "same" OS will place it on the "same" place on a "same" size volume. (on XP it is "usually" 786,432 or 0x000C0000)
So, unless the partition size is not changed "greatly", when a re-format is done, the $MFT will "fall" exactly in the same space.

I have not tested if the previous data "survive" the re-format. Shocked

If it does, and the previous data were all 00's, we have nothing to find in it.
If it does not, and the new, even "quick" format re-writes to it 00's, we have again nothing to find in it.

So, provided that it is possible to write data to this "slack" without affecting the normal NTFS operations Confused , we are not actually inside the "slack", but rather in what I consider a form of "steganography" i.e. there is no actual "unindexed" space, the areas are indexed as $MFT BUT they contain different data "hidden" there, and there is no possibility that "by chance" some non 00's data that was previously written "normally" to those sectors remains untouched and can be recovered/analyzed.
The exception being maybe IF the partition/volume size was greatly changed and/or another OS (I seem to recall that 2K used a different address for the $MFT) or a non-standard tool was used to do the formatting.
At first sight it seems to me like these conditions may be met rarely.

So IMHO the $MFT can be (I take your word for it, given you are an expert on the specific matter) a very good "hiding place" for data, but not really "slack" in the sense we have been using till now.

OT, but not much, what about "very small" files (the ones that are directly written to $MFT being less than 512 bytes):
www.ntfs.com/ntfs-mft.htm
what happens to them when the file is deleted/the volume is re-formatted (quick) or simply when they "grow in size" beyond the limit that makes them "fit" into the $MFT? Question


jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

jaclaz
Senior Member
 
 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Thu Jul 19, 2012 1:12 pm

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.
_________________
Joakim Schicht

github.com/jschicht 

joakims
Senior Member
 
 
  

Re: Volume slack vs file system slack; confusing definition

Post Posted: Thu Jul 19, 2012 3:24 pm

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.  

jhup
Senior Member
 
 

Page 6 of 7
Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next