fls and mactime: missing file activities and misleading output

[joachimmetz]

Per: http://www.sleuthkit.org/sleuthkit/man/mactime.html

mactime - Create an ASCII time line of file activity

nit: ASCII might no longer be accurate seeing UTF-8 encoding of file names

the following scenario on an NTFS file system:

• A file “testfile1” is created
• 100 milliseconds later the file is accessed and its access time is updated
• 100 milliseconds later the content of the file is modified its modification time is updated

To reproduce the test data https://github.com/dfirlabs/ntfs-specimens/blob/master/generate-specimens-behavior.sh#L257

Issue 1 - Creating a bodyfile with fls removes timestamp accuracy which is also mentioned in #1810:

0|/testfile1 ($FILE_NAME)|64-48-3|r/rrwxrwxrwx|48|0|84|1598723379|1598723379|1598723379|1598723379
0|/testfile1|64-128-2|r/rrwxrwxrwx|48|0|10|1598723379|1598723379|1598723379|1598723379

Working around that limitation with another tool:

0|\\testfile1|64|r/rrwxrwxrwx|0|0|10|1598723379.643009424|1598723379.746297598|1598723379.746297598|1598723379.539569855
0|\\testfile1 ($FILE_NAME)|64|r/rrwxrwxrwx|0|0|84|1598723379.539569855|1598723379.539569855|1598723379.539569855|1598723379.539569855

Ran: mactime -d -y -z UTC -b bodyfile

Date,Size,Type,Mode,UID,GID,Meta,File Name
2020-08-29T17:49:39Z,10,macb,r/rrwxrwxrwx,0,0,64,"\\testfile1"
2020-08-29T17:49:39Z,84,macb,r/rrwxrwxrwx,0,0,64,"\\testfile1 ($FILE_NAME)"

Again accuracy is removed and what are 3 different file activities are now (mis)represented as 1.
The date and time values in the $FILE_NAME attribute could misleadingly strengthen the hypothesis there is only 1 file activity.

[bcarrier]

Hi @joachimmetz:

Is the summary of this report that:

• Resolution is at the seconds level instead of milliseconds
• The existence of 'm', 'a', 'c', and 'b' to denote which event occurred at that time is more confusing than having four lines?

[joachimmetz]

Resolution is at the seconds level instead of milliseconds

NTFS date and time values have a "datetime storage granularity" of 100ns. See: https://dfdatetime.readthedocs.io/en/latest/sources/Date-and-time-values.html#accuracy-and-precision for an explanation of terminology.

The existence of 'm', 'a', 'c', and 'b' to denote which event occurred at that time is more confusing than having four lines?

These are not the same file activity, the current output is grouping this as one. This is misleading and can lead to interpretation errors.

There are 3 distinct file activities in the test data, a way to represent this with MACB-grouping and proper granularity could be:

2020-08-29T17:49:39.539569855Z,10,...b,r/rrwxrwxrwx,0,0,64,"\\testfile1"
2020-08-29T17:49:39.539569855Z,84,macb,r/rrwxrwxrwx,0,0,64,"\\testfile1 ($FILE_NAME)"
2020-08-29T17:49:39.643009424Z,10,.a..,r/rrwxrwxrwx,0,0,64,"\\testfile1"
2020-08-29T17:49:39.746297598Z,10,m.c.,r/rrwxrwxrwx,0,0,64,"\\testfile1"

Note that one could argue that:

2020-08-29T17:49:39.539569855Z,10,...b,r/rrwxrwxrwx,0,0,64,"\\testfile1"
2020-08-29T17:49:39.539569855Z,84,macb,r/rrwxrwxrwx,0,0,64,"\\testfile1 ($FILE_NAME)"

is actually 1 file activity, but there is less room for interpretation errors here IMHO.