Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NTFS extra timestamps #16

Open
ajnelson opened this issue Mar 15, 2014 · 0 comments
Open

NTFS extra timestamps #16

ajnelson opened this issue Mar 15, 2014 · 0 comments

Comments

@ajnelson
Copy link
Member

There are several sets of timestamps available for files in NTFS:

  • A quartet of Modified, Access, Changed, Created (MACCr) times are available in $STANDARD_INFORMATION.
  • A quartet of MACCr times is available in a $FILE_NAME attribute.
  • Another quartet of MACCr times is available in each referencing directory entry (see: GrayScale Research's NTFS docs, page 24).

For example, this is the beginning of the istat output of C:\WINDOWS in the CFReDS "Hacking" image:

$ istat -o 63 cfreds-hacking.aff 458
MFT Entry Header Values:
Entry: 458        Sequence: 458
$LogFile Sequence Number: 37980014
Allocated Directory
Links: 1

$STANDARD_INFORMATION Attribute Values:
Flags: 
Owner ID: 0
Security ID: 0  ()
Version 6370040 of 468224
Created:    2004-08-19 12:50:37 (EDT)
File Modified:  2004-08-25 11:56:09 (EDT)
MFT Modified:   2004-08-25 11:56:09 (EDT)
Accessed:   2004-08-27 11:08:06 (EDT)

$FILE_NAME Attribute Values:
Flags: Directory
Name: WINDOWS
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:    2004-08-19 12:50:37 (EDT)
File Modified:  2004-08-19 12:50:38 (EDT)
MFT Modified:   2004-08-19 12:50:38 (EDT)
Accessed:   2004-08-18 20:00:00 (EDT)

Attributes: 
Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 48
Type: $FILE_NAME (48-1)   Name: N/A   Resident   size: 80
Type: $SECURITY_DESCRIPTOR (80-2)   Name: N/A   Resident   size: 288
Type: $INDEX_ROOT (144-6)   Name: $I30   Resident   size: 56
Type: $INDEX_ALLOCATION (160-5)   Name: $I30   Non-Resident   size: 28672  init_size: 28672
4883554 4883555 4883556 4883557 4883558 4883559 4883560 4883561 
4883562 4883563 4883564 4883565 4883566 4883567 4883568 4883569 
4883570 4883571 4883572 4883573 4883574 4883575 4883576 4883577 
4883578 4883579 4883580 4883581 4883582 4883583 4883584 4883585 
4883586 4883587 4883588 4883589 4883590 4883591 4883592 4883593 
4883594 4883595 4883596 4883597 4883598 4883599 4883600 4883601 
4883602 4883603 4883604 4883605 4883606 4883607 4883608 4883609 
Type: $BITMAP (176-4)   Name: $I30   Resident   size: 8

To represent all of these in a single <fileobject>, what would be the best way?

One option is to note the TSK-style MFT entry attribute that was the source of a timestamp. For instance:

<mtime ntfs:source="MFT/$STANDARD_INFORMATION" tsk:mft_source_attribute_id="9-16-0">2004-08-25T11:56:09EDT</mtime>
<mtime ntfs:source="MFT/$FILE_NAME" tsk:mft_source_attribute_id="9-48-7">2004-08-19T12:50:38EDT</mtime>
<mtime ntfs:source="dirent/5[n]">(Some other time)</mtime>

I forgot at the moment what the mechanism for getting directory entry times is using TSK tools, if there is one. Identifying the specific directory entry source may be easier with byte run extensions in place; that hackey-looking ntfs:source value is just supposed to mean "Directory entry, inode 5, entry $n$", but that may be an insufficiently precise way of identifying directory entries.

Those added attributes might be verbose. I welcome any leaner representations. However, this would enable far more complete timelines with DFXML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant