Thread: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: Jon S. <JSt...@St...> - 2016-03-28 20:18:17
|
The docs say:
"Each attribute has a type and an ID. The types are defined in the TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique to the file. A file can have multiple attributes with the same type, but it can have only one attribute with a given id."
But I have an ext2 filesystem, some simple test evidence, where many files have two different attributes with id == 0. The docs also say that "TSK stores UFS and ExtX indirect blocks in separate attribute. [sic]" With these files there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so presumably such attributes contain the pointers for indirect blocks. It looks like these types of attributes also do not respect the uniqueness of attribute IDs.
My guess is that the docs should be updated to reflect that attribute ID is unique only for given types, although it sure would be convenient to have a unique attribute ID regardless of type.
Example:
"attrs":[
{
"flags":"In Use, Non resident",
"id":0,
"name":"",
"size":348576,
"type":1,
"rd_buf_size":0,
"nrd_allocsize":352256,
"nrd_compsize":0,
"nrd_initsize":348576,
"nrd_skiplen":0,
"nrd_runs":[
{"addr":34009,"flags":"","len":12,"offset":0},
{"addr":34022,"flags":"","len":74,"offset":12},
{"addr":0,"flags":"Sparse","len":950,"offset":86}
]
},
{
"flags":"In Use, Non-resident",
"id":0,
"name":"",
"size":4096,
"type":4097,
"rd_buf_size":0,
"nrd_allocsize":4096,
"nrd_compsize":0,
"nrd_initsize":4096,
"nrd_skiplen":0,
"nrd_runs":[
{"addr":34021,"flags":"","len":1,"offset":0}
]
}]
Jon Stewart
Development Manager
STROZ FRIEDBERG
1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
T: +1 202.534.3290
M: +1 202.492.4412
F: +1 202.534.5700
JSt...@St... www.strozfriedberg.com
This message and/or its attachments may contain information that is confidential and/or protected by privilege from disclosure. If you have reason to believe you are not the intended recipient, please immediately notify the sender by reply e-mail or by telephone, then delete this message (and any attachments), as well as all copies, including any printed copies. Thank you.
|
|
From: Brian C. <ca...@sl...> - 2016-03-29 01:58:01
|
Hey Jon,
Those docs should certainly be updated. There is another comment about:
#define TSK_FS_ATTR_ID_DEFAULT 0 ///< Default Data ID used if file system does not assign one.
And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the easiest thing is to update the docs as you suggested. Do you have a use case where having an ID would be useful? It would probably not be much work to make that happen if it is important.
thanks,
brian
> On Mar 28, 2016, at 3:57 PM, Jon Stewart <JSt...@St...> wrote:
>
> The docs say:
>
> "Each attribute has a type and an ID. The types are defined in the TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique to the file. A file can have multiple attributes with the same type, but it can have only one attribute with a given id."
>
> But I have an ext2 filesystem, some simple test evidence, where many files have two different attributes with id == 0. The docs also say that "TSK stores UFS and ExtX indirect blocks in separate attribute. [sic]" With these files there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so presumably such attributes contain the pointers for indirect blocks. It looks like these types of attributes also do not respect the uniqueness of attribute IDs.
>
> My guess is that the docs should be updated to reflect that attribute ID is unique only for given types, although it sure would be convenient to have a unique attribute ID regardless of type.
>
> Example:
>
> "attrs":[
> {
> "flags":"In Use, Non resident",
> "id":0,
> "name":"",
> "size":348576,
> "type":1,
> "rd_buf_size":0,
> "nrd_allocsize":352256,
> "nrd_compsize":0,
> "nrd_initsize":348576,
> "nrd_skiplen":0,
> "nrd_runs":[
> {"addr":34009,"flags":"","len":12,"offset":0},
> {"addr":34022,"flags":"","len":74,"offset":12},
> {"addr":0,"flags":"Sparse","len":950,"offset":86}
> ]
> },
> {
> "flags":"In Use, Non-resident",
> "id":0,
> "name":"",
> "size":4096,
> "type":4097,
> "rd_buf_size":0,
> "nrd_allocsize":4096,
> "nrd_compsize":0,
> "nrd_initsize":4096,
> "nrd_skiplen":0,
> "nrd_runs":[
> {"addr":34021,"flags":"","len":1,"offset":0}
> ]
> }]
>
>
> Jon Stewart
> Development Manager
>
> STROZ FRIEDBERG
> 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
>
> T: +1 202.534.3290
> M: +1 202.492.4412
> F: +1 202.534.5700
> JSt...@St... www.strozfriedberg.com
>
> This message and/or its attachments may contain information that is confidential and/or protected by privilege from disclosure. If you have reason to believe you are not the intended recipient, please immediately notify the sender by reply e-mail or by telephone, then delete this message (and any attachments), as well as all copies, including any printed copies. Thank you.
>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
|
|
From: Jon S. <JSt...@St...> - 2016-03-29 21:03:50
|
A unique ID would be very helpful. My use case is that I'm trying to map out which ranges of the disk are associated with given (inode, attribute) pairs. Without a unique attribute ID, I can't trust that process.
When there isn't a nice organic attribute ID from the filesystem itself (as with NTFS), I'd be happy with a simple per-inode counter serving as the ID.
Jon
> -----Original Message-----
> From: Brian Carrier [mailto:ca...@sl...]
> Sent: Monday, March 28, 2016 9:58 PM
> To: Jon Stewart
> Cc: sleuthkit-users
> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
>
> Hey Jon,
>
> Those docs should certainly be updated. There is another comment about:
>
> #define TSK_FS_ATTR_ID_DEFAULT 0 ///< Default Data ID used if file
> system does not assign one.
>
> And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the easiest
> thing is to update the docs as you suggested. Do you have a use case where
> having an ID would be useful? It would probably not be much work to make
> that happen if it is important.
>
> thanks,
> brian
>
>
> > On Mar 28, 2016, at 3:57 PM, Jon Stewart <JSt...@St...>
> wrote:
> >
> > The docs say:
> >
> > "Each attribute has a type and an ID. The types are defined in the
> TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique
> to the file. A file can have multiple attributes with the same type, but it can
> have only one attribute with a given id."
> >
> > But I have an ext2 filesystem, some simple test evidence, where many files
> have two different attributes with id == 0. The docs also say that "TSK stores
> UFS and ExtX indirect blocks in separate attribute. [sic]" With these files
> there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so
> presumably such attributes contain the pointers for indirect blocks. It looks
> like these types of attributes also do not respect the uniqueness of attribute
> IDs.
> >
> > My guess is that the docs should be updated to reflect that attribute ID is
> unique only for given types, although it sure would be convenient to have a
> unique attribute ID regardless of type.
> >
> > Example:
> >
> > "attrs":[
> > {
> > "flags":"In Use, Non resident",
> > "id":0,
> > "name":"",
> > "size":348576,
> > "type":1,
> > "rd_buf_size":0,
> > "nrd_allocsize":352256,
> > "nrd_compsize":0,
> > "nrd_initsize":348576,
> > "nrd_skiplen":0,
> > "nrd_runs":[
> > {"addr":34009,"flags":"","len":12,"offset":0},
> > {"addr":34022,"flags":"","len":74,"offset":12},
> > {"addr":0,"flags":"Sparse","len":950,"offset":86}
> > ]
> > },
> > {
> > "flags":"In Use, Non-resident",
> > "id":0,
> > "name":"",
> > "size":4096,
> > "type":4097,
> > "rd_buf_size":0,
> > "nrd_allocsize":4096,
> > "nrd_compsize":0,
> > "nrd_initsize":4096,
> > "nrd_skiplen":0,
> > "nrd_runs":[
> > {"addr":34021,"flags":"","len":1,"offset":0}
> > ]
> > }]
> >
> >
> > Jon Stewart
> > Development Manager
> >
> > STROZ FRIEDBERG
> > 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
> >
> > T: +1 202.534.3290
> > M: +1 202.492.4412
> > F: +1 202.534.5700
> > JSt...@St... www.strozfriedberg.com
> >
> > This message and/or its attachments may contain information that is
> confidential and/or protected by privilege from disclosure. If you have
> reason to believe you are not the intended recipient, please immediately
> notify the sender by reply e-mail or by telephone, then delete this message
> (and any attachments), as well as all copies, including any printed copies.
> Thank you.
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
|
|
From: Simson G. <si...@ac...> - 2016-03-29 21:08:17
|
I like byte offset from the beginning of the drive as a nice organic unique ID. It can be the byte offset of the metadata....
> On Mar 29, 2016, at 5:03 PM, Jon Stewart <JSt...@St...> wrote:
>
> A unique ID would be very helpful. My use case is that I'm trying to map out which ranges of the disk are associated with given (inode, attribute) pairs. Without a unique attribute ID, I can't trust that process.
>
> When there isn't a nice organic attribute ID from the filesystem itself (as with NTFS), I'd be happy with a simple per-inode counter serving as the ID.
>
>
> Jon
>
>> -----Original Message-----
>> From: Brian Carrier [mailto:ca...@sl...]
>> Sent: Monday, March 28, 2016 9:58 PM
>> To: Jon Stewart
>> Cc: sleuthkit-users
>> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
>>
>> Hey Jon,
>>
>> Those docs should certainly be updated. There is another comment about:
>>
>> #define TSK_FS_ATTR_ID_DEFAULT 0 ///< Default Data ID used if file
>> system does not assign one.
>>
>> And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the easiest
>> thing is to update the docs as you suggested. Do you have a use case where
>> having an ID would be useful? It would probably not be much work to make
>> that happen if it is important.
>>
>> thanks,
>> brian
>>
>>
>>> On Mar 28, 2016, at 3:57 PM, Jon Stewart <JSt...@St...>
>> wrote:
>>>
>>> The docs say:
>>>
>>> "Each attribute has a type and an ID. The types are defined in the
>> TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is unique
>> to the file. A file can have multiple attributes with the same type, but it can
>> have only one attribute with a given id."
>>>
>>> But I have an ext2 filesystem, some simple test evidence, where many files
>> have two different attributes with id == 0. The docs also say that "TSK stores
>> UFS and ExtX indirect blocks in separate attribute. [sic]" With these files
>> there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so
>> presumably such attributes contain the pointers for indirect blocks. It looks
>> like these types of attributes also do not respect the uniqueness of attribute
>> IDs.
>>>
>>> My guess is that the docs should be updated to reflect that attribute ID is
>> unique only for given types, although it sure would be convenient to have a
>> unique attribute ID regardless of type.
>>>
>>> Example:
>>>
>>> "attrs":[
>>> {
>>> "flags":"In Use, Non resident",
>>> "id":0,
>>> "name":"",
>>> "size":348576,
>>> "type":1,
>>> "rd_buf_size":0,
>>> "nrd_allocsize":352256,
>>> "nrd_compsize":0,
>>> "nrd_initsize":348576,
>>> "nrd_skiplen":0,
>>> "nrd_runs":[
>>> {"addr":34009,"flags":"","len":12,"offset":0},
>>> {"addr":34022,"flags":"","len":74,"offset":12},
>>> {"addr":0,"flags":"Sparse","len":950,"offset":86}
>>> ]
>>> },
>>> {
>>> "flags":"In Use, Non-resident",
>>> "id":0,
>>> "name":"",
>>> "size":4096,
>>> "type":4097,
>>> "rd_buf_size":0,
>>> "nrd_allocsize":4096,
>>> "nrd_compsize":0,
>>> "nrd_initsize":4096,
>>> "nrd_skiplen":0,
>>> "nrd_runs":[
>>> {"addr":34021,"flags":"","len":1,"offset":0}
>>> ]
>>> }]
>>>
>>>
>>> Jon Stewart
>>> Development Manager
>>>
>>> STROZ FRIEDBERG
>>> 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
>>>
>>> T: +1 202.534.3290
>>> M: +1 202.492.4412
>>> F: +1 202.534.5700
>>> JSt...@St... www.strozfriedberg.com
>>>
>>> This message and/or its attachments may contain information that is
>> confidential and/or protected by privilege from disclosure. If you have
>> reason to believe you are not the intended recipient, please immediately
>> notify the sender by reply e-mail or by telephone, then delete this message
>> (and any attachments), as well as all copies, including any printed copies.
>> Thank you.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
|
|
From: Jon S. <JSt...@St...> - 2016-03-29 21:12:46
|
That would be nice, but TSK_FS_ATTR.id is a uint16_t. I'm fine with recompiling, but that might break things for others.
Jon
> -----Original Message-----
> From: Simson Garfinkel [mailto:si...@gm...] On Behalf Of Simson
> Garfinkel
> Sent: Tuesday, March 29, 2016 5:08 PM
> To: Jon Stewart
> Cc: Brian Carrier; sleuthkit-users
> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
>
> I like byte offset from the beginning of the drive as a nice organic unique ID.
> It can be the byte offset of the metadata....
>
> > On Mar 29, 2016, at 5:03 PM, Jon Stewart <JSt...@St...>
> wrote:
> >
> > A unique ID would be very helpful. My use case is that I'm trying to map out
> which ranges of the disk are associated with given (inode, attribute) pairs.
> Without a unique attribute ID, I can't trust that process.
> >
> > When there isn't a nice organic attribute ID from the filesystem itself (as
> with NTFS), I'd be happy with a simple per-inode counter serving as the ID.
> >
> >
> > Jon
> >
> >> -----Original Message-----
> >> From: Brian Carrier [mailto:ca...@sl...]
> >> Sent: Monday, March 28, 2016 9:58 PM
> >> To: Jon Stewart
> >> Cc: sleuthkit-users
> >> Subject: Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
> >>
> >> Hey Jon,
> >>
> >> Those docs should certainly be updated. There is another comment
> about:
> >>
> >> #define TSK_FS_ATTR_ID_DEFAULT 0 ///< Default Data ID used if file
> >> system does not assign one.
> >>
> >> And TSK_FS_ATTR_ID_DEFAULT is what Ext2 is using for its ID. So, the
> easiest
> >> thing is to update the docs as you suggested. Do you have a use case
> where
> >> having an ID would be useful? It would probably not be much work to
> make
> >> that happen if it is important.
> >>
> >> thanks,
> >> brian
> >>
> >>
> >>> On Mar 28, 2016, at 3:57 PM, Jon Stewart
> <JSt...@St...>
> >> wrote:
> >>>
> >>> The docs say:
> >>>
> >>> "Each attribute has a type and an ID. The types are defined in the
> >> TSK_FS_ATTR_TYPE_ENUM structure and the ID is an integer that is
> unique
> >> to the file. A file can have multiple attributes with the same type, but it
> can
> >> have only one attribute with a given id."
> >>>
> >>> But I have an ext2 filesystem, some simple test evidence, where many
> files
> >> have two different attributes with id == 0. The docs also say that "TSK
> stores
> >> UFS and ExtX indirect blocks in separate attribute. [sic]" With these files
> >> there are type 4097 attributes, TSK_FS_ATTR_TYPE_UNIX_INDIR, so
> >> presumably such attributes contain the pointers for indirect blocks. It
> looks
> >> like these types of attributes also do not respect the uniqueness of
> attribute
> >> IDs.
> >>>
> >>> My guess is that the docs should be updated to reflect that attribute ID is
> >> unique only for given types, although it sure would be convenient to have
> a
> >> unique attribute ID regardless of type.
> >>>
> >>> Example:
> >>>
> >>> "attrs":[
> >>> {
> >>> "flags":"In Use, Non resident",
> >>> "id":0,
> >>> "name":"",
> >>> "size":348576,
> >>> "type":1,
> >>> "rd_buf_size":0,
> >>> "nrd_allocsize":352256,
> >>> "nrd_compsize":0,
> >>> "nrd_initsize":348576,
> >>> "nrd_skiplen":0,
> >>> "nrd_runs":[
> >>> {"addr":34009,"flags":"","len":12,"offset":0},
> >>> {"addr":34022,"flags":"","len":74,"offset":12},
> >>> {"addr":0,"flags":"Sparse","len":950,"offset":86}
> >>> ]
> >>> },
> >>> {
> >>> "flags":"In Use, Non-resident",
> >>> "id":0,
> >>> "name":"",
> >>> "size":4096,
> >>> "type":4097,
> >>> "rd_buf_size":0,
> >>> "nrd_allocsize":4096,
> >>> "nrd_compsize":0,
> >>> "nrd_initsize":4096,
> >>> "nrd_skiplen":0,
> >>> "nrd_runs":[
> >>> {"addr":34021,"flags":"","len":1,"offset":0}
> >>> ]
> >>> }]
> >>>
> >>>
> >>> Jon Stewart
> >>> Development Manager
> >>>
> >>> STROZ FRIEDBERG
> >>> 1150 Connecticut Avenue, NW, Suite 700, Washington, DC 20036
> >>>
> >>> T: +1 202.534.3290
> >>> M: +1 202.492.4412
> >>> F: +1 202.534.5700
> >>> JSt...@St... www.strozfriedberg.com
> >>>
> >>> This message and/or its attachments may contain information that is
> >> confidential and/or protected by privilege from disclosure. If you have
> >> reason to believe you are not the intended recipient, please immediately
> >> notify the sender by reply e-mail or by telephone, then delete this
> message
> >> (and any attachments), as well as all copies, including any printed copies.
> >> Thank you.
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Transform Data into Opportunity.
> >>> Accelerate data analysis in your applications with
> >>> Intel Data Analytics Acceleration Library.
> >>> Click to learn more.
> >>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> >>> _______________________________________________
> >>> sleuthkit-users mailing list
> >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> >>> http://www.sleuthkit.org
> >
> > ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X