Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
Brought to you by:
carrier
Menu
▾
▴
Re: [sleuthkit-users] TSK_FS_ATTR.id uniqueness bug with ext2
|
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
|
