In the official NTFS implementation, all metadata changes to a file system are logged to ensure the consistent recovery of critical file system structures after a system crash. This is called write-ahead logging.
The logged metadata is stored in a file called “$LogFile”, which is found in a root directory of an NTFS file system.
Currently, there is no much documentation for this file available. Most sources are either too high-level (describing the logging and recovery processes in general) or just contain the layout of key structures without further description.
Continue reading “How the $LogFile works?”
Things are changing and file systems are not an exception. Even when their version numbers are staying the same.
This post will outline some interesting things found in the current NTFS implementation which are either poorly documented or not documented elsewhere.
Continue reading “NTFS today”
One basic rule when dealing with “hibernated” volumes is to never write anything to them from another operating system. Otherwise, when a hibernated operating system is resumed, there will be a difference between what is on a drive and what the operating system considers to be on that drive.
In Linux, the NTFS-3G driver is issuing the following error message when trying to mount a “hibernated” volume in the read-write mode:
Windows is hibernated, refused to mount.
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
But this rule isn’t enforced in the Windows world. An NTFS volume is automatically mounted in the read-write mode even if it belongs to a hibernated operating system.
Since the fast startup mode, which uses the hibernation feature to restore the state of the kernel and the loaded drivers, is enabled by default in Windows 8.1 & 10 installations running on most modern computers, such behavior can lead to data corruption in a dual-boot configuration or when a system drive is attached to another computer.
From a forensics perspective, this means that hibernation files may contain some important data.
Continue reading “Hibernation and NTFS”
This is a reply to the Sunday Funday 12/30/18 challenge.
The following results represent an attempt to understand what Windows components write to the Syscache hive in a Windows Server 2008 R2 SP1 installation (64-bit; with updates installed as of January 3, 2019).
Continue reading “What writes to the Syscache hive?”
Since the “Last Access” updates are almost back, let’s revise the consistency of last access timestamps present in NTFS file systems.
There are some misconceptions about how and when these timestamps are updated.
Continue reading “The (in)consistency of last access timestamps”
The purpose of this post is to record the recent findings related to the NTFS “Last Access” updates in Windows 10.
According to ForensicsWiki:
In Windows Vista (presumably as of Windows XP SP3), NTFS no longer tracks the Last Access time of a file by default.
This is no longer the case in the recent versions of Windows 10.
Continue reading “The “Last Access” updates are almost back”
The purpose of this post is to record the recent findings related to artifacts of execution and artifacts of executables present in a system. No major details beyond what was posted on Twitter.
David Cowen began his public testing of Amcache artifacts found in Windows 10 operating systems in Forensic Lunch Test Kitchen 11/16/18 (be sure to watch newer videos on this topic).
During these tests, it was found that the Amcache hive may have artifacts for executables that weren’t executed at all. There were other interesting findings outlined in the videos, but I will not focus on them now.
Continue reading “The CIT database and the Syscache hive”