Recently, Microsoft warned users about compatibility issues with applications using some non-ASCII characters in names of their registry keys. According to Microsoft:
Compatibility issues have been found between apps using some non-ASCII characters in their registry keys or subkeys and Windows 11. Affected apps might be unable to open and might cause other issues or errors in Windows, including the possibility of receiving an error with a blue screen. ImportantAffected registry keys with non-ASCII characters might not be able to be repaired.
Although NTFS has been designed with case-sensitivity in mind, it’s used mostly in the case-insensitive environment. One can natively store, within the same directory, two or more files with their names differing only in case, but Windows-based tools won’t deal with them correctly. To provide true case-sensitivity, Microsoft implemented an additional layer, per-directory case-sensitivity, as described here, here, and here.
But there are several issues with usual, case-insensitive, operations…
Windows Explorer displays $STANDARD_INFORMATION timestamps.
A file with a single name has 12 timestamps: 4 timestamps come from the $STANDARD_INFORMATION attribute in a file record, 4 timestamps come from the $FILE_NAME attribute in the same file record, and 4 timestamps come from the $FILE_NAME attribute in an index record ($I30) of a parent directory.
If there is a short file name together with a long one, the number of timestamps is 20 (8 more timestamps come from two additional $FILE_NAME attributes in a file record and in an index record of a parent directory respectively).
You can also add an UUIDv1 timestamp from the $OBJECT_ID attribute, timestamps recorded in the USN journal and in the $LogFile journal. But these aren’t always present.
Things are more complicated with timestamps displayed by Windows Explorer.
Some virtualization software allows a user to launch a virtual machine with its real-time clock starting ticking from custom base time. For example, a user can launch a virtual machine with base time set to 2020-12-31 23:59:59 UTC, the real-time clock inside this virtual machine will start ticking from that value, regardless of the current date and time set on a host. I use this feature to test artifacts without telling Windows to move the clock.
However, if you decide to go back and restart the same virtual machine without defining custom base time (also without Internet access and without changing the date and time settings in the running operating system), the guest operating system won’t necessary use the current date and time (as set on a host). In some cases, it will continue to run using the previously defined (future) date.
Some editions of Windows 10 are capable of running Windows containers using Docker. Each Docker container is based on an immutable image with all modified data stored in an overlay. When a Windows container is used, the system has to record modifications affecting both the file system and the registry.
In 2016, Microsoft implemented new functionality called layered keys to allow programs access a merged view of keys and values from two or more registry hives! Now, this functionality is utilized by Docker…
Have you ever heard that solid-state drives destroy evidence? Let’s revisit the facts before going further.
When first solid-state drives appeared, there was no Trim command. There was no easy way for a drive to reclaim unused blocks of user data (i.e., data exposed to a host as drive contents) for the wear-leveling process.
To mitigate this problem, manufacturers did a clever trick: they began producing file-system-aware solid state drives!
Some articles deny the existence of such a trick, but the truth is that some ancient solid-state drives were capable of parsing a partition table and an NTFS file system to locate unallocated (free) clusters and reclaim their blocks for the wear-leveling process (thus, wiping remnant data in these clusters).
If you visit the “Configure Storage Sense or run it now” page in the “Settings” window of Windows 10 “19H2”, you may notice the “Delete files in my Downloads folder if they have been there for over” option. The same option in “20H1” reads: “Delete files in my Downloads folder if they haven’t been opened for more than“.
So, this old new NTFS feature has something to do with Storage Sense. It’s a component used to delete unneeded files “to keep your storage optimized”. And the “Last Access” updates are a good way to detect such unneeded files (and the “StorageUsage.dll” library actually uses last access timestamps to find “cold” files).
But there is something you might not notice. Look at the same settings page in Windows 10 “19H2” and read:
Content will become online-only if not opened for more than"
Wait a minute! The “Last Access” updates are on for a relatively small subset of Windows 10 “19H2” installations only… Does this option really work for systems with large system volumes?
Are you aware of DLL hijacking? If yes, let’s suppose there is a program that executes the following line of code:
Its executable has the following name: “i_use_riched32.exe” (just as an example).
Now, take a look at the following contents of a directory containing this executable, the screenshots were taken of three tools: Explorer, FTK Imager Lite, The Sleuth Kit (each one points to the same directory).
Is the “riched32.dll” library hijacked for the “i_use_riched32.exe” executable? Let’s assume that no attempts to hijack the library have been made outside of the directory shown above.
Have you ever encountered on-disk artifacts originating from another system?
Typically, this is something you see when a custom operating system image had been deployed to multiple computers by IT staff (on-disk artifacts appeared before the image is captured become a part of that image).
But there are some minor artifacts existing in installation images coming from Microsoft!