fileopendialog question

[majlumbo]

I am writing a small app that reports the MD5 and SHA1 hashes of a file, and the specific dates of a file.. date created, date last accessed, date of last modification..

What I'm finding is that the file open dialog itself affects the last accessed date, which is something I cannot have happen in a piece of production software.

I attempted to read the last accessed date and put it in a hold variable of type tfiletime, and reupdate it back to its original date. This does not work, because by the time the fileopendialog identifies the file I need to hash and report the dates on, the date is already changed for me to read and hold it.

What I need is a way to identify a file using the fileopendialog or some alternative, but to not change the last accessed date.

 

[Glenn9999]

More or less, anytime you open a file the last access date of the file is changed to when you open the file. This means your TOpenDialog is changing the date when it checks for file existance, and your code is changing this date as well upon processing. So you really can't trust the number to remain the same, unless you disable recording all disk access dates in the file system.

Not the answer you wanted to hear, but the answer nonetheless.



It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[Glenn9999]

And even checking the properties of the file itself in Explorer will change the last access date.

Here's the tweak if you're interested in globally disabling this record keeping in the file system. There are three or four settings like this you can disable to gain some performance increase in disk access.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[majlumbo]

I know there's got to be some programmatic way to do this. I work in a forensics shop and they already have tools to be able to access all of this information without affecting the last access date. The problem is that they have one tool to get the MD5 hash, another for the SHA1 hash. Another to get the file dates. Some are command line tools, others have GUI interfaces. I wanted to provide one app to do it all.

The issue is that the original media may be considered evidence, so I cannot tamper with it in any way. It MUST remain the same from the beginning to the end of the process, and that must be provable.

The last access date of a file has obvious evidentiary value to it, so if the code affects it, it becomes useless, and puts in question the other items it reports back.

 

[Glenn9999]

I know there's got to be some programmatic way to do this.

Actually there's not. Anytime a file is accessed or touched by anything or anyone, this date is changed. This can be a person at the computer or a scheduled task such as a virus scanner. And if you think there is, then there's a way for attackers (people or programs) to do the same thing, and any perceived evidentary value of it goes out the window. If your program can forge this value, that means anyone else can too.

This will be good reading to see where the issue lies:

http://www.symantec.com/connect/forums/last-access-dates

I work in a forensics shop and they already have tools to be able to access all of this information without affecting the last access date.

If they do anything, they likely just set the date back close enough to what the original is. Besides, from what I read, there's a granularity of about an hour, and that can be changed since the OS updates this time when the OS is idle.

The issue is that the original media may be considered evidence, so I cannot tamper with it in any way. It MUST remain the same from the beginning to the end of the process, and that must be provable.

The problem is the moment you read or touch any file on that drive, it will be modified in the last access date. There is nothing to prove that it was modified in a manner consistent with what you are seeking. And furthermore, if the tweak I posted is applied on XP (Vista and Seven have the tweak by default), your last access date won't have any value anyway.

To wit, if you're following basic forensic protocol you need to be working off of a mirror of the drive instead of the original anyway, so anything you do shouldn't matter.

The last access date of a file has obvious evidentiary value to it, so if the code affects it, it becomes useless, and puts in question the other items it reports back.

You'd better re-evaluate any value that this has. Any one of these arguments can be developed further by a truly tech-savvy lawyer to tear apart any perceived value of "last access date".

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[Glenn9999]

For those that might be interested, how you change "last accessed date".

procedure TForm1.Button2Click(Sender: TObject);
var
  Access_Time: TSystemTime;
  faccess_time, laccess_time: TFileTime;
  afile: File;
begin
  if OpenDialog1.Execute then
    begin
      Access_Time.wYear := 1999;
      Access_Time.wMonth := 12;
      Access_Time.wDay := 21;
      Access_time.wHour := 23;
      access_time.wMinute := 59;
      access_time.wSecond := 59;
      SystemTimeToFileTime(access_time, laccess_time);
      LocalFileTimeToFileTime(laccess_time, faccess_time);
      AssignFile(afile, OpenDialog1.FileName);
      Reset(afile, 1);
      SetFileTime(TFileRec(afile).handle, nil, @faccess_time, nil);
      CloseFile(afile);
    end;
end;

The only other thought I can offer the OP is maybe to try turning off all file existence validation in the options of the OpenDialog.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[majlumbo]

Our shop does work off of mirrors, not the original media, but that does not change the requirements that no changes are to be made to the media being examined.

My problem is not that I cannot read it, it's that the opendialog is changing the date before I can read it. When I hardwire scanning for an individual file in code (not using the opendialog), I can access the last accessed date and NOT affect it.

This is the code that can read the last accessed date and not affect it:

procedure TForm1.Report_File_Data(path, filenm:  string);
var
   SRData:  TWin32FileAttributeDate;
   The_File:  PANSIChar;
   SysTime:  TSystemTime;
begin
   The_File := PANSIChar(Path+FileNm);
   if GetFileAttributesEX(The_File, GetFileExInfoStandard, @SRData) then
      filetimetoSystemtime(SRData.ftLastAccessTime, SysTime);

...

Then the time is now available in SysTime.WYear, WMonth, WDay etc...

The change the last access date, this is another approach:

Declare in the private section of TForm1

Hold_Last_Access_Date:  TFileTime;

Procedure TForm1.Reset_Last_Access_Date(FileNm:  String);
var
  Handle:  Integer;
begin
   Handle:=FileOpen(FileNm, fmopenwrite or fmsharedenynone or fmopenread);
   if Handle >= 0 then
      try
         if setfiletime(handle, nil, @hold_last_access_date,nil) then
            fileClose(Handle);
      except
         showmessage('Error');
      end;
end;

I think the only way around this issue is to write my own opendialog.

 

[majlumbo]

One more item on reset_last_access_date..

Ensure Hold_Last_Access_Date has valid information in it before calling the procedure.

 

[Glenn9999]

Did you try turning off all the file validation options in the TOpenDialog you are using? If you did that and it didn't work, the only way you will be able to forge the original date is to write your own (or study source and extend the part that's reading the file).

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[majlumbo]

Well, it's embarrassing, but using the Win 31 controls DriveComboBox, DirectoryListBox and FileListbox worked. I can select a file, and not affect the last access date of the file.