sleuthkit-developers

[sleuthkit-developers] unique identifier for TSK_FS_NAME

[Jon <jo...@li...>]

Would it be possible to add a field to TSK_FS_NAME for the byte offset
of the record, either from the start of the volume or from the start
of the disk (whichever is easier)?

"addr" works as a good unique identifier for TSK_FS_META structs, and
something similar for TSK_FS_NAME would be helpful. Paths aren't
necessarily unique, and a segmented scheme using the parent
directory's path/inum with the index number of the TSK_FS_NAME record
is not stable... a new version of TSK might figure out a way to
recover more files in a directory (hypothetically) and now the index
number may be shifted to a different record. Reporting the byte offset
of the record would be more stable and have the added benefit of
letting people quickly find the raw data in a hex editor, for
validation/inspection.

Thoughts?

Jon

Re: [sleuthkit-developers] unique identifier for TSK_FS_NAME

[Brian C. <ca...@sl...>]

Hi Jon,

What is the use case for this identifier?  Are you saying that a path is not unique because you could have the same path in different file systems in a disk image? You could use the file system offset as part of the path to make it unique?

That being said, sure we could make an identifier for each name.   What should it report for orphan files though (files that have a metadata structure, but no name)?

brian

On Jul 21, 2010, at 1:37 PM, Jon wrote:

> Would it be possible to add a field to TSK_FS_NAME for the byte offset
> of the record, either from the start of the volume or from the start
> of the disk (whichever is easier)?
> 
> "addr" works as a good unique identifier for TSK_FS_META structs, and
> something similar for TSK_FS_NAME would be helpful. Paths aren't
> necessarily unique, and a segmented scheme using the parent
> directory's path/inum with the index number of the TSK_FS_NAME record
> is not stable... a new version of TSK might figure out a way to
> recover more files in a directory (hypothetically) and now the index
> number may be shifted to a different record. Reporting the byte offset
> of the record would be more stable and have the added benefit of
> letting people quickly find the raw data in a hex editor, for
> validation/inspection.
> 
> Thoughts?
> 
> Jon
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] unique identifier for TSK_FS_NAME

[Jon S. <jo...@li...>]

The primary use case is to have an identifier that uniquely identifies  
a TSK_FS_NAME record, which ideally would be compact and stable-ish  
(if the fs interpretation changed slightly, most records would be  
unaffected). The secondary use case is to give folks a pointer to  
where the relevant record may be on disk (e.g., MFT record), while  
obviously making allowances for filesystem variations.

My understanding is that a path may not be unique as a  
deleted&recoverable file may have the same path as an allocated file.  
There would be separate TSK_FS_NAME records but they'd have the same  
paths. (Please correct me if I'm mistaken in how tsk handles this  
situation.)

What I'd propose is an unsigned int in the TSK_FS_NAME struct, which  
would hold the byte offset of the record on disk, thereby  
distinguishing it. Not sure what to put for orphan files, but those  
are easy enough to determine, and we know they can be identified  
uniquely via the metadata address (right?). When in doubt, MAX_INT.

I don't need a lookup function, so no new functions or state, just  
adding another field to the struct.

Cheers,

Jon


On Jul 21, 2010, at 8:35 PM, Brian Carrier <ca...@sl...>  
wrote:

> Hi Jon,
>
> What is the use case for this identifier?  Are you saying that a  
> path is not unique because you could have the same path in different  
> file systems in a disk image? You could use the file system offset  
> as part of the path to make it unique?
>
> That being said, sure we could make an identifier for each name.    
> What should it report for orphan files though (files that have a  
> metadata structure, but no name)?
>
> brian
>
> On Jul 21, 2010, at 1:37 PM, Jon wrote:
>
>> Would it be possible to add a field to TSK_FS_NAME for the byte  
>> offset
>> of the record, either from the start of the volume or from the start
>> of the disk (whichever is easier)?
>>
>> "addr" works as a good unique identifier for TSK_FS_META structs, and
>> something similar for TSK_FS_NAME would be helpful. Paths aren't
>> necessarily unique, and a segmented scheme using the parent
>> directory's path/inum with the index number of the TSK_FS_NAME record
>> is not stable... a new version of TSK might figure out a way to
>> recover more files in a directory (hypothetically) and now the index
>> number may be shifted to a different record. Reporting the byte  
>> offset
>> of the record would be more stable and have the added benefit of
>> letting people quickly find the raw data in a hex editor, for
>> validation/inspection.
>>
>> Thoughts?
>>
>> Jon
>>
>> --- 
>> --- 
>> --- 
>> ---------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> sleuthkit-developers mailing list
>> sle...@li...
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

Re: [sleuthkit-developers] unique identifier for TSK_FS_NAME

[Brian C. <ca...@sl...>]

On Jul 21, 2010, at 11:12 PM, Jon Stewart wrote:

> The primary use case is to have an identifier that uniquely identifies  
> a TSK_FS_NAME record, which ideally would be compact and stable-ish  
> (if the fs interpretation changed slightly, most records would be  
> unaffected). The secondary use case is to give folks a pointer to  
> where the relevant record may be on disk (e.g., MFT record), while  
> obviously making allowances for filesystem variations.
> 
> My understanding is that a path may not be unique as a  
> deleted&recoverable file may have the same path as an allocated file.  
> There would be separate TSK_FS_NAME records but they'd have the same  
> paths. (Please correct me if I'm mistaken in how tsk handles this  
> situation.)

TSK will de-duplicate files if they have the same name and metadata address.  So, yes an allocated file and a deleted file could have the same name if they refer to different metadata structures.

> What I'd propose is an unsigned int in the TSK_FS_NAME struct, which  
> would hold the byte offset of the record on disk, thereby  
> distinguishing it. Not sure what to put for orphan files, but those  
> are easy enough to determine, and we know they can be identified  
> uniquely via the metadata address (right?). When in doubt, MAX_INT.

I suppose we could also just use the address of the metadata structure as long as it is clear to the user that this is to be treated only as a unique identifier and not as the offset to the name.

Can you add this to the feature request tracker?

http://sourceforge.net/tracker/?atid=477892&group_id=55685

thanks,
brian