Jump to content











Photo
- - - - -

SetMACE

timestamp; ntfs; anti-forensics

  • Please log in to reply
18 replies to this topic

#1 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 05 December 2011 - 12:06 PM

Posted Image

File Name: SetMACE
File Submitter: joakim
File Submitted: 04 Dec 2011
File Updated: 06 Sep 2014
File Category: Security

This is an advanced filesystem timestamp manipulating tool. Some interesting features;

- Support for files and directories.
- Complete 64-bit timestamp (including the nanoseconds).
- Native 64-bit OS support (as well as 32-bit).
- Complete direct support for $FILE_NAME, $STANDARD_INFORMATION, $INDEX_ROOT and $INDEX_ALLOCATION timestamps, without workarounds.
- Modify timestamps within shadow copies.

- Makes Cache Manager reload the file system cache stored in memory, after modification.
- Dump all filesystem timestamps (4 x $STANDARD_INFORMATION and 4 x unlimited $FILE_NAME)...

- Dump timestamp information from within shadow copies.
- Dump timestamps from the INDX of the parent.
- Damn hard to detect a manipulated timestamp..


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.

Parameter explanation;
- Parameter 1
is input/target file. Must be full path like C:\folder\file.ext

- Parameter 2 is 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.

- Parameter 3 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.

- Parameter 4 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).

-Parameter 5 is optional.
"-shadow" willactivate shadow copy mode. Relevant for both read and write. See examples.

Note:
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):
  • 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).
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).

The synchronization of timestamps from $STANDARD_INFORMATION and those found in the INDX entries of parent.
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.

Dumping information with the -d switch
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.

Shadow Copies
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.

Tip:
Get MFTRCRD from http://reboot.pro/fi...ols-collection/ and quickly dump a substantial amount of information about the file (all timestamps ++++).

Warning:
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!

Examples;
Setting the CreationTime in the $STANDARD_INFORMATION attribute:
setmace.exe C:\file.txt -c "2000:01:01:00:00:00:789:1234" -si

Setting the LastAccessTime in the $STANDARD_INFORMATION attribute:
setmace.exe C:\file.txt -a "2000:01:01:00:00:00:789:1234" -si

Setting the LastWriteTime in the $FILE_NAME attribute:
setmace.exe C:\file.txt -m "2000:01:01:00:00:00:789:1234" -fn

Setting the ChangeTime(MFT) in the $FILE_NAME attribute:
setmace.exe C:\file.txt -e "2000:01:01:00:00:00:789:1234" -fn

setting 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" -fn

setting 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" -fn

Setting 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" -x

Setting 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" -x

Setting 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 -shadow

Dumping all timestamps for the metafile $Boot (including all shadow copies):
setmace.exe C:\$Boot -d -shadow

2 methods of dumping all timestamps for $MFT itself (no shadow copy timestamps displayed):
setmace.exe C:\$MFT -d
or
setmace.exe C:0 -d



Thanks:
Click here to download this file
  • Nuno Brito likes this

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13574 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 December 2011 - 12:17 PM

NOT tested :w00t:, BUT question :ph34r::
  • Can it deal with Directory timestamps?

:cheers:
Wonko

#3 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 05 December 2011 - 12:30 PM

NOT tested :w00t:, BUT question :ph34r::

  • Can it deal with Directory timestamps?


No, currently everything is assumed to be a file. If NtSetInformationFile can handle directories, then yes it can be added. Need to look into it.

#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13574 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 December 2011 - 12:35 PM

If NtSetInformationFile can handle directories, then yes it can be added. Need to look into it.

It would be nice. :)

As a "side note" OT :ph34r: but not much ;), a couple of handy tools:
http://code.kliu.org/misc/timeclone/
http://code.kliu.org/misc/vcopy/

:cheers:
Wonko

#5 AceInfinity

AceInfinity

    Frequent Member

  • Team Reboot
  • 228 posts
  • Location:Canada
  • Interests:Windows Security, Programming, Customizing & Crash Dump Analysis.
  •  
    Canada

Posted 05 December 2011 - 12:59 PM

I actually created an application similar to this to edit NTFS last accessed, modified, and created timestamps, nice work :)
  • Ariom likes this

#6 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 05 December 2011 - 01:07 PM

I just tested and directories will also be supported with minor modifications to code.

Also had a quick look at the source for the timeclone app. It only supports 3 (MAC) timestamps, with the E (MFT entry creation) missing. :( That's the reason for using NtQueryInformationFile and NtSetInformationFile functions. ;)

#7 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 05 December 2011 - 07:48 PM

New version is up, and now with support for directories. On NTFS you can modify all 4 (MACE) timestamps (3 for FAT*). The trick with the 4 extra timestamps inside the $FILE_NAME attribute is currently deactivated for directories as it may cause issues if run uncleverly. The file/directory is auto-detected. Source is now included.

#8 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 24 January 2012 - 12:16 AM

Here is a major update to my setMACE. I have now implemented complete support for the manipulation of $FILE_NAME timestamps for both files and directories. Just want to say that this is not at all a trivial task, and involves some complicated stuff. First and foremost, I will like to say that (despite successfull testing on XP x86 and Windows 7 x64) it should be considered as risky and experimental. In particular, it involves writing directly to physical disk, and bypassing any filesystem driver. For this reason I would be happy if someone would test this on an NTFS volume (on usb storage or inside a VM), and report results back. I have, like just mentioned, tested it myself though (of course). And lots of error and sanity checking have been implemented. But there might still be things that I've missed. Anyways, read the included readme for more information.

Note that if testing on a large volume, it may take some time for the program to finish because it must resolve and search through the $MFT for the target file.

Most interesting features are now:
- Support for both files and directories.
- Complete 64-bit timestamp accessible (including the nanoseconds).
- Native 64-bit OS support (as well as 32-bit).
- Complete support for both $FILE_NAME and $STANDARD_INFORMATION timestamps, without workarounds.
- Clone timestamps from a second file ($STANDARD_INFORMATION )
- Dump all filesystem timestamps (up to 4+4+4) for a file/directory
- Damn hard to detect a manipulated timestamp.


Enjoy testing and source inspection. But regarding the source, you may end up even more confused than before (you are warned). And all suggestions are welcome..

#9 AceInfinity

AceInfinity

    Frequent Member

  • Team Reboot
  • 228 posts
  • Location:Canada
  • Interests:Windows Security, Programming, Customizing & Crash Dump Analysis.
  •  
    Canada

Posted 24 January 2012 - 12:38 AM

Sounds like a good update joakim :)

I can do some testing on a USB key, but I also run Windows 7 x64 as mentioned in your testing.

#10 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 24 January 2012 - 10:47 AM

That would be nice if you could run a few tests. Wanted testing scenarios;

- files/folders on volumes with lots of stuff on.
- "stupid" user actions (not sure exactly what). Maybe files on systemdrive on nt6.x, or files on the same volume as setmace on nt6.x (for physical disk writing with $FILE_NAME tweaking)..
- notice potential errors by comparing with chkdsk run prior and after timestamp modifications.

But I believe I have implemented blocks for most stupid user actions. The biggest risk though is that the data written to physical disk is in fact written to the correct location. Meaning that runs are correctly solved ($MFT fragmentation). However it seems working perfectly..

#11 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 24 January 2012 - 10:19 PM

I've done more testing and it seems stable and good. New version has some minor fixes and a lot more meaningfull feedback written to the console. Would still like to know about testresults from others though, due to the somewhat risky nature of the app.

Now with this in place, it might not be too hard too extend it into a more comprehensive $MFT modifier..

#12 AceInfinity

AceInfinity

    Frequent Member

  • Team Reboot
  • 228 posts
  • Location:Canada
  • Interests:Windows Security, Programming, Customizing & Crash Dump Analysis.
  •  
    Canada

Posted 24 January 2012 - 11:29 PM

I'll do some testing tonight for you Joakim, and report back with all the tests i've done. I'll set up a specific environment to do so, and i'll do tests with various filetypes, filesizes, folders with different sub items (contributing to the overall foder content filesize), etc...

I'm experienced with debugging, I spend hours debugging and testing my own applications, and sometimes it helps me come out with new knowledge and new inventions :)

#13 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 26 November 2013 - 09:05 PM

SetMace is updated. This version is even more powerful. All timestamp handling is done by direct physical disk writing now, which means everything on the volume (NTFS) is resolved internally. Detection of manipulation by this version may be impossible. At best you may be able to say it looks strange, if a reference timestamp was found somewhere else like $LogFile, $UsnJrnl, shadow copy (but it is not given that anything is to be found in these).. Or traces of the program itself on the system, could indicate that something may have been done, without knowing what..

 

Physical disk writing still with the same limitations as mentioned several times earlier, with regards to nt6.x.

 

Long story short, and kind of old news, nt5.x is screewed, at least when it comes to this topic.



#14 bilou_gateux

bilou_gateux

    Frequent Member

  • Expert
  • 230 posts
  •  
    France

Posted 01 December 2013 - 05:14 PM


Long story short, and kind of old news, nt5.x is screewed, at least when it comes to this topic.

 

I never tried previous versions.

 

Not sure i understand the quoted part.

 

Still using rock-solid Windows NT 5.1 core OS, Embedded flavor.

 

Does latest setmace release still support nt5.x



#15 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 01 December 2013 - 10:00 PM

By "this topic" I mean the things that SetMace is doing (but also whatever else tool uses similar techinique to achive what it wants). Rock-solid and nt5.x may go into the same sentence, if security is totally excluded.. Don't you think write access to anywhere on the volume is worrying (or at least enough to downgrade "rock-solid"), considering there is no real system check of its internal components like signature checking of core executables including drivers? What doess the kernel actually do to prevent malware-like drivers to get loaded, or even sanity-check itself for such? Who knows what direct write access anywhere potentially could lead to.... In this case, only a manipulated timestamp :)

 

SetMace does support nt5.x.

 

Uploaded a new version with fixes for new bugs I introduced after the rewrite. Now, you can also modify timestamps on nearly unlimited $FILE_NAME attributes, when dealing with hardlinks (for instance). The rest is in changelog.



#16 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 04 August 2014 - 10:18 PM

Another new version made. This one implements a kernel mode driver, and consequently removes most of the restrictions imposed on earlier versions. Be sure to have read the updated readme before using it.



#17 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 06 August 2014 - 06:01 AM

New version with signed and embedded drivers. Without signed drivers on x64, it would produce an ntstatus code 0xC0000428 if just TESTSIGNING was configured. For full PatchGuard fix it was ok though. Non-relevant on x86.



#18 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 16 August 2014 - 03:40 PM

New version supporting MFT record size of 4096 bytes (Windows 8/2012). Fixed synchronization ($STANDARD_INFORMATION and timestamps in INDX of parent) issue in certain scenarios.



#19 joakim

joakim

    Silver Member

  • Team Reboot
  • 909 posts
  • Location:Bergen
  •  
    Norway

Posted 06 September 2014 - 08:58 PM

SetMace has been almost completely rewritten, and definetely entered a new advanced level. Of the most significant changes are:

  • Support for changing timestamps within Shadow Copies.
  • Modifcation of timestamps within $INDEX_ROOT and/or $INDEX_ALLOCATION of the parent.
  • Makes Cache Manager reload the file system cache stored in memory, after modification.
  • Various minor bug fixes.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users