Page 1 of 2 12 LastLast
Results 1 to 15 of 20

Thread: File time

  1. #1

    File time

    Hmm... this is really weird...

    Can someone explain this? I look at properties of a file and get
    Created : 12 May 2004, 13:17:22
    Modified : 27 April 2004, 13:11:22
    Accessed: 19 May 2004 20:08:23

    How is this possible that a file is modified before it is created? Which date should i trust for last modified date?

    Thanks,
    crUs

  2. #2
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,516
    Blog Entries
    1
    this happens mostly when file extracted (from archive or installer)
    (time from archive seems copied to "modified" attr)

  3. #3
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    if it really bothers you, you can use a tool like this to change the days/times: http://www.eluent.com/eltouch.htm

  4. #4
    hi disavowed... it doesnt really bother me... i just need to find out the exact time that a file was last modified...

  5. #5
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    The modified date is gospel, it usually is the actual correct date of when the file was "created", unless the installer was told to set the date to the date of install, in which case, you lose all date info.

    -nt20

  6. #6
    Is there a difference between file security on Nt/Xp/2k and 9x/me? Or can you still just set the file-times as you wish? Wouldn't be surprised, anyway.

    Fake

  7. #7
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    NTFS has more date info for files than FAT(32), yes, and you can set this data as long as you have the correct permission for the files. This may be necessary for smooth operation of e.g. archiver tools and similar (as mentioned above), and since there is a separate permission system I don't see it as a flaw, but rather as a useful feature.

  8. #8
    Quote Originally Posted by dELTA
    NTFS has more date info for files than FAT(32), yes, and you can set this data as long as you have the correct permission for the files. This may be necessary for smooth operation of e.g. archiver tools and similar (as mentioned above), and since there is a separate permission system I don't see it as a flaw, but rather as a useful feature.
    The question isn't really whether it's a flaw or design feature - it's whether it can be exploited. Thought NTFS had more security, though.

    Fake

  9. #9
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    I meant "security flaw" as in "bad security design", which is quite inherent in your statement "Thought NTFS had more security". But again, you need to have write access to the file (which can be nicely controlled in NTFS, because it has just that, "more security") to be able to change its date, so I really don't see the security problem. If you have access to change the contents of the file, why shouldn't you be able to change the date of it? Not to mention that even if there weren't any direct APIs to do it, you could just change the system time and recreate/touch/read the file to set any date information you wanted anyway.

  10. #10
    Quote Originally Posted by dELTA
    I meant "security flaw" as in "bad security design", which is quite inherent in your statement "Thought NTFS had more security". But again, you need to have write access to the file (which can be nicely controlled in NTFS, because it has just that, "more security") to be able to change its date, so I really don't see the security problem. If you have access to change the contents of the file, why shouldn't you be able to change the date of it? Not to mention that even if there weren't any direct APIs to do it, you could just change the system time and recreate/touch/read the file to set any date information you wanted anyway.
    Actually, I meant: "thought NTFS had more security than 9x/me". In a, "thought so"-kinda way.

    Generally, I just don't see much use for setting file date/time.

    Fake

  11. #11
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    One primary use of making it possible to set the filedates manually is when you want to preserve the timestamps on files through some operations, e.g. the earlier mentioned compress/extract scenario, but also other scenarios like e.g. editing or writing metadata to media files (e.g. pictures taken with a digital camera). There are lots and lots of scenarios like this.

  12. #12
    Quote Originally Posted by dELTA
    One primary use of making it possible to set the filedates manually is when you want to preserve the timestamps on files through some operations, e.g. the earlier mentioned compress/extract scenario, but also other scenarios like e.g. editing or writing metadata to media files (e.g. pictures taken with a digital camera). There are lots and lots of scenarios like this.
    Unfortunately, it's also quite easy to hide changes to files that way.
    I see pro's and con's to the stuff - don't really care much bout it though. If people want to wreak havoc or abuse the OS, there are worse things they can do.

    Fake

  13. #13
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    [Rant]
    Yes, many things can be used in one way or another to aid bad deeds, but it is practically never a good solution to remove these things for this sake though (bye bye internet?). Instead, it is often best to provide a security base that can be utilized to secure these items anyway. In this case this security base is the NTFS permission system. If we are talking about a user without admin permissions, the admin can set the permissions so that the user cannot modify the files (and thus not their dates either), and if we are talking about an admin level user, any malicious program he runs could bypass the file system layer and manipulate the file data directly on the disk anyway, even if there were no APIs to write to files without changing the dates, and no APIs to directly manipulate the dates either. So, then we would have removed this feature and all its "good" uses for nothing, making life more inconvenient for normal users, but still having just the same vulnerability as before. Finally, to cover any possible counter-example situation, if a non-admin user wants to be able to modify the contents of the files, but still wants to be able to see if the files have been modified by someone else, he should consider to accomplish this cryptographically (which will result in the bad guys not being able to edit the files undetected by any method, not even with admin rights and direct access), instead of trusting the security-by-obscurity-based method of not directly exposing certain functionality to normal users.

    And yeah, sure, this example with filedates might be less significant than others, but it's this general philosophy and approach to security that I'm objecting against. It's quite a widespread and normal reaction though, but it practically never holds up in reality if you just think some more about it.
    [/Rant]


  14. #14
    Quote Originally Posted by dELTA
    [Rant]
    Yes, many things can be used in one way or another to aid bad deeds, but it is practically never a good solution to remove these things for this sake though (bye bye internet?).
    One doesn't need to remove it - just make it harder to abuse or screw up, by default.

    Instead, it is often best to provide a security base that can be utilized to secure these items anyway. In this case this security base is the NTFS permission system. If we are talking about a user without admin permissions, the admin can set the permissions so that the user cannot modify the files (and thus not their dates either)
    And what about the files that the user needs to be able to modify? Perhaps if there were settings, so that only the system sets the time, but not allowing user time/date changes.

    Ofcourse things can be circumvented, but rather that it be hard than easy.

    ... and if we are talking about an admin level user, any malicious program he runs could bypass the file system layer and manipulate the file data directly on the disk anyway, even if there were no APIs to write to files without changing the dates, and no APIs to directly manipulate the dates either.
    Running admin priviledges is also a risk - it's the normal user that's the main concern to me.

    So, then we would have removed this feature and all its "good" uses for nothing, making life more inconvenient for normal users, but still having just the same vulnerability as before.
    Strange that you arrive at this conclusion.

    Finally, to cover any possible counter-example situation, if a non-admin user wants to be able to modify the contents of the files, but still wants to be able to see if the files have been modified by someone else, he should consider to accomplish this cryptographically (which will result in the bad guys not being able to edit the files undetected by any method, not even with admin rights and direct access), instead of trusting the security-by-obscurity-based method of not directly exposing certain functionality to normal users.
    "He should consider" ... which is of course true. The main problem arises when the normal user trusts the system that is not secure. The whole point of talking about the normal user is exactly that the normal user isn't always in a position to have the necessary level of information - how is the normal user to know how the date/time can be changed? Far as I remember, that's what started this whole thread.
    I agree that there are good uses for functions like these. There are also very good uses for Outlook Express, however the program should be deleted at first sight - most of the problems with it, is that normal users don't have the information level necessary to determine what is a risk and what is not. And even though this may be a fault on the part of the normal user, the risk and damage is too high to disregard. There will always be stupid users, and blaming them won't help - making software secure will. This doesn't mean removing all functions, it just means making it as secure as possible.

    And yeah, sure, this example with filedates might be less significant than others, but it's this general philosophy and approach to security that I'm objecting against. It's quite a widespread and normal reaction though, but it practically never holds up in reality if you just think some more about it.
    [/Rant]

    Well, in general I agree with your attitude towards security - better to advance the level of knowledge than to try and remove the threat (since, by hypothesis, new threats will always arrive). However, there's two sides to the coin: the other hypothesis is that new fools are born every minute. As such, the only rational thing to do seems to me to be to raise the general level af computer-literacy, while striving to make software as secure as possible. In no way does this entail removing functions from software.

    And, as I have stated already in this thread, I do believe that the security of file time/date is an improvement over 9x/me - security is in pretty much every way improved from 9x/me, which is very nice. This just doesn't mean that it can't get better - as long as normal users continue to get fooled (in one way or another, in regard to security in general) there is obviously room for improvement. Be it in the area of knowledge or software-security.

    Scuze the ramble, btw.

    Fake

  15. #15
    care to what kind of exploits you could make out of changing File date/time?

    You can only do it on files for which you have write access. Is there anything that relies on file date/time that would break if you changed them?

Similar Threads

  1. Hi all, it's time for a new interesting tutorial, this time SSlEvIN took time for a j
    By Shub-nigurrath in forum Advanced Reversing and Programming
    Replies: 1
    Last Post: March 5th, 2010, 15:58
  2. File hiding
    By ReVeR in forum The Newbie Forum
    Replies: 7
    Last Post: October 6th, 2004, 09:42
  3. File Handle
    By ReVeR in forum The Newbie Forum
    Replies: 10
    Last Post: September 21st, 2004, 07:45
  4. UDD File Format
    By asdf in forum Plugins (General)
    Replies: 1
    Last Post: February 23rd, 2004, 06:23
  5. Win32 PE File - GUI
    By whoda in forum The Newbie Forum
    Replies: 5
    Last Post: May 25th, 2003, 16:57

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •