[sleuthkit-developers] [ sleuthkit-Bugs-3220237 ] NULL attribute 'name' in 3.2.0 and 3.2.1

[SourceForge.net <no...@so...>]

Bugs item #3220237, was opened at 2011-03-17 16:51
Message generated for change (Comment added) made by robklpd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rob@klpd (robklpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: NULL attribute 'name' in 3.2.0 and 3.2.1

Initial Comment:
In the 2.3 release of OCFA libtsk is used by the tsklf module. This module was working OK in the 3.1 version of libtsk. Now with the 3.2 releases tskfs seems to have broken as a result of the fact that the attribute name now has become a NULL character pointer instead of a pointer to a real name.

Currently tskfs uses the name info to determine if it is handling the main content of the file, or some other attribute. The following is code from tskfs that has broken as a result of this problem:

//Helper function for constructor for processing data attribute.
          attributetype TskFsInode::processAttribute(const TSK_FS_ATTR *attribute,std::string name) {
              if (attribute->size == 0) {
                 return ATTR_NODATA;
              }
              if (((attribute->name) && ( (std::string(attribute->name) == "$Data")))||(attribute->type == TSK_FS_ATTR_TYPE_DEFAULT)) { //Process normal data attribute.
                   if (name =="EFS0.TMP") { //Special marker for EFS0.TMP file.
                      ocfa::misc::metautil::addMetaToMap(mMeta,"specialmarker", new ocfa::misc::ScalarMetaValue(ocfa::misc::Scalar("efs-crypto-temp")));
                   }
                   return ATTR_PRIMARY;
              }
              if  ((attribute->name) && (std::string(attribute->name)) == "$I30") {
                  return ATTR_NODATA;
              }
              if (attribute->type == TSK_FS_ATTR_TYPE_NTFS_BITMAP) {
                 return ATTR_NODATA;
              }
              if (attribute->flags & TSK_FS_ATTR_NONRES) { //All non resident attributes are processed as data attributes.
                 return ATTR_DATA;
              } else {
                 switch (attribute->type) {
                      case TSK_FS_ATTR_TYPE_NTFS_SI:
                if (mVerboseMeta) { //Only process SI information in verbose meta mode. 
                               processNtfsStandardInfo(attribute);
                            }
                            //fall trough OK.
                      case TSK_FS_ATTR_TYPE_NTFS_FNAME:
                           //fall trough OK.
                      case TSK_FS_ATTR_TYPE_NTFS_VVER:
                            return ATTR_NODATA;
                      default:
                            return ATTR_DATA;
                 }
              }
          }

Currently this means that ATTR_PRIMARY is no longer recognized correctly by the code above, and tskfs processes NTFS images severely wrong.

----------------------------------------------------------------------

>Comment By: rob@klpd (robklpd)
Date: 2011-03-21 13:30

Message:
I've added a small piece of code that demonstrates the difference between
the two versions of libtsk. This code has an hardcoded image name for an
ntfs partition image and a hardcoded inumber for a file with an alternate
stream.

Also added two output files for this code, one generated with the 3.1 and
one with the 3.2 version of libtsk. These files show that the old libtsk
named its steam '$Data' and its altstreams something user defined. The new
libtsk returns NULL for the name of the primary stream.

Currently the OCFA tskfs module uses the magic '$Data' name to distinguish
between the primary stream and any alternative stream, and for this reason
the tskfs module breaks completely by this bug/feature, mis-qualifying all
normal files as empty files with an alternative stream. 

So possibly this might actualy be a bug in tskfs, but with no reliable
cross-versionalternative  way to distinguish between the primary and
alternate streams, it appears on first sight to be a libtsk bug. 

----------------------------------------------------------------------

Comment By: rob@klpd (robklpd)
Date: 2011-03-18 12:33

Message:
Added the 3 possibly relevant OCFA tskfs module files so the libtsk calls
can easily be seen in the sequence that led to the given symptoms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&group_id=55685