2 Votes

Parameter explanation;

Note

Boot with TESTSIGNING configured and use a test signed driver.

Crack patchguard (and then no need for TESTSIGNING configuration) and use an unsigned or test signed driver.

Find a way to use a properly signed driver (maybe next version).

Dumping information with the -d switch

Tip

Warning

Examples

Ascend4nt for theWinTimeFunctions

DDan at forensicfocus for valuable help

Driver code; http://www.codeproje...aw-Disk-Sectors

This is an advanced filesystem timestamp manipulating tool. Some interesting features;From the readme.txt:This is an advanced filesystem timestamp manipulation tool, originally inspired by good old timestomp. This version is NTFS only, and attributes supported for timestamp manipulation are $STANDARD_INFORMATION, $FILE_NAME, $INDEX_ROOT and $INDEX_ALLOCATION. In later versions there is no longer any dependency on NtSetInformationFile. That means it is completely based on resolving the filesystem structures inetrnally and writing a modified MFT record back directly to physical disk. There is also support for unlimited $FILE_NAME attributes, but is restricted to what fits inside an MFT record (not spread across $ATTRIBUTE_LISTS). In earlier versions, only the $FILE_NAME attribute was modified by physical disk writing, but now also $STANDARD_INFORMATION. However, be sure to have read the warning below!The $FILE_NAME attribute can be present twice, giving it 8 possible timestamps. Short filenames have only 1 $FILE_NAME attribute (4 timestamps) whereas files with long filenames have 2 $FILE_NAME attributes (4+4 timestamps). If links (for instance hardlinks) are present, even more $FILE_NAME It's all supported.is input/target file. Must be full path like C:\folder\file.extis determining which timestamp to update."-m" = LastWriteTime"-a" = LastAccessTime"-c" = CreationTime"-e" = ChangeTime (in $MFT)"-z" = all 4"-d" = Dump existing timestamps (in UTC and adjusted for timezone configuration), including those in the INDX of the parent.is the wanted new timestamp. Format must be strictly followed like; "1954:04:01:22:39:44:666:1234". That is YYYY:MM:DD:HH:MM:SS:MSMSMS:NSNSNSNS. The smallest possible value to set is; "1601:01:01:00:00:00:000:0001". Timestamps are written as UTC 0.00 and thus will show up in explorer as interpreted by your timezone location. Note that nanoseconds are supported.determines if $STANDARD_INFORMATION or $FILE_NAME attribute or both should be modified."-si" will only update timestamps in $STANDARD_INFORMATION (4 timestamps), or just LastWriteTime, LastAccessTime and CreationTime (3 timestamps) for non-NTFS."-fn" will only update timestamps in $FILE_NAME (4 timestamps for short names and 8 timestamps for long names)."-x" will update timestamps in both $FILE_NAME and $STANDARD_INFORMATION (8 or 12 timestamps depending on filename length).is optional."-shadow" willactivate shadow copy mode. Relevant for both read and write. See examples.Directories are also supported just like regular files. Since version 1.0.0.10, where a kernel mode driver has been implemented, most of the restrictions put on earlier version are now removed.The restrictions that was limiting SetMace in previous versions:Since nt6.x Microsoft blocked direct write access to within volume space (like \\.\PhysicalDrive0 or \\.\E:): http://msdn.microsof...3(v=vs.85).aspx In order to do so it was necessary to dismount the volume first, effectively releasing all open handles to the volume. However, this was of course not possible to do on certain volumes (for instance on the systemdrive or a volume where a pagefile existed). Theefore SetMace could not be located on the volume to be modified. The solution to make all this work the proper way is to implement a driver that can set the SL_FORCE_DIRECT_WRITE flag on the Irp before sending it further: http://msdn.microsof...7(v=vs.85).aspx That way, there is no need to dismount the volume, and thus even the systemdrive can be modified. All this, did not apply nt5.x (XP and Server 2003) and earlier. With 64-bit Windows, Microsoft implemented another security measure, "PatchGuard", to protect the kernel in memory as well as preventing the loading of unsigned or test signed drivers. Of course Windows does not natively ship with a driver allowing to circumvent the security features just mentioned. That leaves 3 possible options for using SetMace on a live 64-bit nt6.x OS (all other Windows OS's are fine):Since the driver in this version is test signed, we need to choose either 1 or 2. Both work equally well, and in fact as of today4. August 2014, "PatchGuard" is still officially cracked and unpatched (google KPP Destroyer).Directories keep attributes of type $INDEX_ROOT and/or $NDEX_ALLOCATION which conatins various information about the objects (files/directories) within that directory. The content within these attributes are indexed information taken from both the $STANDARD_INFORMATION and $FILE_NAME attributes of the object. The timestamps are taken from $STANDARD_INFORMATION. It seems the indexed information is updated whenever the target object is queried in some way. A full investigation of this behaviour has not been performed, but I found that a simple call to NtQueryINformationFile would force it to be updated. This fix was implemeneted in 1.0.0.13. Earlier versions would in some cases leave inconsistencies between $STANDARD_INFORMATION and the indexed $STANDARD_INFORMATION as found in $NDEX_ROOT/$INDEX_ALLOCATION of the parent. The limitation to the fix for this is that target file/folder for modification must be specified by name and not INdexNumber, and NtQueryINformationFile will fail for any of the filesystem metafiles. That means timestamps for emtafiles like $MFT and $LogFile can still be changed, but if $STANDARD_INFORMATION is modified, these will be inconsistent with the ones found in the INDX of the root directory. Modified timestamps in $FILE_NAME attribute will not face this inconsistency issue. This holds true for any file on the filesystem.From version 1.0.0.9 the -d switch will also dump timestamp information from the target volume, as well as from present any shadow copies of that volume. So if the volume that the target file resides on, also have shadow copies, the -d switch will also dump information for the same MFT reference for every relevant shadow copy. Matching shadow copies are identified by the volume name and serial number. The dumped information includes filename, parent ref, sequence number and hardlink number to help identify if the same file actually holds a particular MFT ref across shadow copies. From version 1.0.0.13. also the timestamps in the INDX of the parent are retrieved.With version 1.0.0.14 ssupport has been added to also modify timestamps within shadow copies. It is either all shadow copies or none. Use the -shadow switch. The switch matters for both read and write mode. In order to add the write mode support, quite comprehensive shadow copy parser code had to be added to SetMace. So how could write mode work shadow copies are read-only?. The reason is it is only the symbolic link to it, like for instance \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopyX, that is read-only. In the end, on the filesystem, it is just a file within the "System Volume Information" folder. However, this file has a complicated structure that must be parsed correctly. And the actual data within it are the modified clusters of the original volume (may appear as a bunch of bits and pieces). The name of the shadow copies are constructed like {GUID}{GUID} , whereas the information about these files are found within a shadow copy master file named {3808876b-c176-4e48-b7ae-04046e6cc752}. The method by which it writes to the shadow copy files, are by direct writing to sectors just like it modifes $MFT.Get MFTRCRD from http://reboot.pro/fi...ols-collection/ and quickly dump a substantial amount of information about the file (all timestamps ++++).Bypassing the filesystem and writing to physical disk is by nature a risky operation. And it's success is totally dependent on me gotten SetMace resolving NTFS correctly. Having said that, I have tested it on both XP sp3 x86, Windows 7 x86/x64 and Windows 8.1 x64, on which it works fine. This new method of timestamp manipulation is a whole lot harder to detect. In fact, I can't think of any method, except the presence of this tool, and by comparison of some other artifact (like a shadow copy, and maybe $LogFile on not so heavily used volumes). The earlier versions that used the "moce-trick" and/or NtSetInformationFile would leave traces in the $ogFile. I wil still call this version experimental. I take no responsibility for any loss of data by the usage of this tool! Use only for educational purposes in non-productional environments!Setting the CreationTime in the $STANDARD_INFORMATION attribute:setmace.exe C:\file.txt -c "2000:01:01:00:00:00:789:1234" -siSetting the LastAccessTime in the $STANDARD_INFORMATION attribute:setmace.exe C:\file.txt -a "2000:01:01:00:00:00:789:1234" -siSetting the LastWriteTime in the $FILE_NAME attribute:setmace.exe C:\file.txt -m "2000:01:01:00:00:00:789:1234" -fnSetting the ChangeTime(MFT) in the $FILE_NAME attribute:setmace.exe C:\file.txt -e "2000:01:01:00:00:00:789:1234" -fnsetting all 4+4 timestamps in the $FILE_NAME attribute for a file with long filename:setmace.exe "C:\a long filename.txt" -z "2000:01:01:00:00:00:789:1234" -fnsetting 1+1 timestamps ($MFT creation time * 2) in the $FILE_NAME attribute for a file with long filename:setmace.exe "C:\a long filename.txt" -e "2000:01:01:00:00:00:789:1234" -fnSetting all 4+4 (or 4+8) timestamps in both $STANDARD_INFORMATION and $FILE_NAME attributes:setmace.exe C:\file.txt -z "2000:01:01:00:00:00:789:1234" -xSetting the LastWriteTime in both $STANDARD_INFORMATION and $FILE_NAME attribute of root directory (defined by its index number):setmace.exe C:5 -m "2000:01:01:00:00:00:789:1234" -xSetting the LastWriteTime in the $STANDARD_INFORMATION attribute, for current timestamps and in all shadow copies:setmace.exe C:\file.txt -m "2000:01:01:00:00:00:789:1234" -si -shadowDumping all timestamps for the metafile $Boot (including all shadow copies):setmace.exe C:\$Boot -d -shadow2 methods of dumping all timestamps for $MFT itself (no shadow copy timestamps displayed):setmace.exe C:\$MFT -dorsetmace.exe C:0 -d