sleuthkit-developers

[sleuthkit-developers] output of ntfs file names.

[Lee A. <ay...@in...>]

In the current version of ntfs.c multiple names are concatenated
together and separated by white space.   This makes multiple names
difficult to distinguish from file names with white space in them.  I
propose that a change be made to the formatting of names for output.

My understanding is that ntfs allows for any character but null and
'/'.  Separating the values with '/' characters would seem to me to be
a compliant choice, however it might confuse users.

In practice the names could be surrounded with quote characters since
Windows doesn't allow them and in my experience they are very uncommon
even in environments and filesystems where they are allowed. If you
are willing to put just a small bit of cognitive burden on the human
viewer the name string could be escaped with \" replacing literal
double quotes and \\ replacing literal backslashes.

Alternately, the output can have multiple "Name" lines.

I'm happy to submit a patch that implements any one of the
alternatives if needs be.

P.S.  If one wants to get terrifically pedantic, I see nothing to
indicate that new-lines are disallowed in ntfs file names. Am I wrong
about that, and if not what effect might that have on the choice of an
output strategy?

-- 
Lee T. Ayres, Senior Analyst
Interhack Corporation
http://web.interhack.com/ +1 614 545 4225

Re: [sleuthkit-developers] output of ntfs file names.

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

Hi Lee,

Can you point to an example in the code where this happens?  Line number is fine if you have one.  I'm not sure that I am following the problem.

thanks,
brian


On Jan 19, 2011, at 1:46 PM, Lee Ayres wrote:

> In the current version of ntfs.c multiple names are concatenated
> together and separated by white space.   This makes multiple names
> difficult to distinguish from file names with white space in them.  I
> propose that a change be made to the formatting of names for output.
> 
> My understanding is that ntfs allows for any character but null and
> '/'.  Separating the values with '/' characters would seem to me to be
> a compliant choice, however it might confuse users.
> 
> In practice the names could be surrounded with quote characters since
> Windows doesn't allow them and in my experience they are very uncommon
> even in environments and filesystems where they are allowed. If you
> are willing to put just a small bit of cognitive burden on the human
> viewer the name string could be escaped with \" replacing literal
> double quotes and \\ replacing literal backslashes.
> 
> Alternately, the output can have multiple "Name" lines.
> 
> I'm happy to submit a patch that implements any one of the
> alternatives if needs be.
> 
> P.S.  If one wants to get terrifically pedantic, I see nothing to
> indicate that new-lines are disallowed in ntfs file names. Am I wrong
> about that, and if not what effect might that have on the choice of an
> output strategy?
> 
> -- 
> Lee T. Ayres, Senior Analyst
> Interhack Corporation
> http://web.interhack.com/ +1 614 545 4225
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] output of ntfs file names.

[Lee A. <ay...@in...>]

Oh my, upon further review I kinda screwed up my problem.  It happened
quite a while back and I hacked a fix into 3.1.3 that I had to revisit
as I was working on confirming that 3.2.0 will integrate into our
process. Working from memory is a bad policy, however I was on the
right track.  Ill show the code and give an illustrative example.

Beginning with line 4187 in ntfs.c

if (fs_file->meta->name2) {
  TSK_FS_META_NAME_LIST *fs_name = fs_file->meta->name2;
  tsk_fprintf(hFile, "Name: ");
  while (fs_name) {
    tsk_fprintf(hFile, "%s", fs_name->name);
    fs_name = fs_name->next;
    if (fs_name)
      tsk_fprintf(hFile, ", ");
    else
      tsk_fprintf(hFile, "\n");
   }
 }

I have come across instances in the wild of files with the same name
attribute twice. I dont know enough about the way Windows manages
files to be able to assert why that was. Such a file with a duplicated
name attribute, for example, with the name "Larry, Curly, and Moe"
would have the following line in istat output:

"Name: Larry, Curly, and Moe, Larry, Curly, and Moe"

A human reader may be able to tease that apart, but a script is likely
to freak out.

On Wed, Jan 19, 2011 at 2:52 PM, Brian Carrier <ca...@sl...> wrote:
> Hi Lee,
>
> Can you point to an example in the code where this happens?  Line number is fine if you have one.  I'm not sure that I am following the problem.
>
> thanks,
> brian
>
>
> On Jan 19, 2011, at 1:46 PM, Lee Ayres wrote:
>
>> In the current version of ntfs.c multiple names are concatenated
>> together and separated by white space.   This makes multiple names
>> difficult to distinguish from file names with white space in them.  I
>> propose that a change be made to the formatting of names for output.

-- 
Lee T. Ayres, Senior Analyst
Interhack Corporation
http://web.interhack.com/ +1 614 545 4225

Re: [sleuthkit-developers] output of ntfs file names.

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

So the issue is when trying to parse 'istat'?  Can you use the library to do this?  The istat output is intended for human consumption. Would you prefer different names instead?


On Jan 19, 2011, at 4:19 PM, Lee Ayres wrote:

> Oh my, upon further review I kinda screwed up my problem.  It happened
> quite a while back and I hacked a fix into 3.1.3 that I had to revisit
> as I was working on confirming that 3.2.0 will integrate into our
> process. Working from memory is a bad policy, however I was on the
> right track.  Ill show the code and give an illustrative example.
> 
> Beginning with line 4187 in ntfs.c
> 
> if (fs_file->meta->name2) {
>  TSK_FS_META_NAME_LIST *fs_name = fs_file->meta->name2;
>  tsk_fprintf(hFile, "Name: ");
>  while (fs_name) {
>    tsk_fprintf(hFile, "%s", fs_name->name);
>    fs_name = fs_name->next;
>    if (fs_name)
>      tsk_fprintf(hFile, ", ");
>    else
>      tsk_fprintf(hFile, "\n");
>   }
> }
> 
> I have come across instances in the wild of files with the same name
> attribute twice. I dont know enough about the way Windows manages
> files to be able to assert why that was. Such a file with a duplicated
> name attribute, for example, with the name "Larry, Curly, and Moe"
> would have the following line in istat output:
> 
> "Name: Larry, Curly, and Moe, Larry, Curly, and Moe"
> 
> A human reader may be able to tease that apart, but a script is likely
> to freak out.
> 
> On Wed, Jan 19, 2011 at 2:52 PM, Brian Carrier <ca...@sl...> wrote:
>> Hi Lee,
>> 
>> Can you point to an example in the code where this happens?  Line number is fine if you have one.  I'm not sure that I am following the problem.
>> 
>> thanks,
>> brian
>> 
>> 
>> On Jan 19, 2011, at 1:46 PM, Lee Ayres wrote:
>> 
>>> In the current version of ntfs.c multiple names are concatenated
>>> together and separated by white space.   This makes multiple names
>>> difficult to distinguish from file names with white space in them.  I
>>> propose that a change be made to the formatting of names for output.
> 
> -- 
> Lee T. Ayres, Senior Analyst
> Interhack Corporation
> http://web.interhack.com/ +1 614 545 4225