[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-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