Can I trace who wrote a file?

  • Thread starter Thread starter Todd
  • Start date Start date
Is there a way to find which program wrote a file to disk?
Click to expand...

Short answer, no. There might be clues contained in the filename, it's
contents, its location within the directory structure, even the
specific time that it was written might be a clue. You might look at
everything that you have available and still not be able to arrive at
a definitive answer, though.
 
Todd said:
Hi All,

Is there a way to find which program wrote a file to disk?

Many thanks,
-T
Click to expand...

Only if you prepared in advance.

Maybe Sysinternals Procmon, could record certain file system calls ?
Then, you'd have to go back through the log, after the fact, for
evidence.

This would be an example of a filter in Procmon.

"Operation" "Is" "CreateFile" "Include"

I think ProcMon by default, stores things in system RAM. But, there's
a preference, where you can store results in a file. Perhaps you'd need
that option, if you're going to leave it running all the time.

http://technet.microsoft.com/en-us/sysinternals/bb896645 (Process Monitor)

If you wanted something lower level or more inclusive than that,
you'd likely need to run a "real debugger".

And, as you'd expect, you can't catch everything that way.
A rootkit, for example, could hide from such an effort.
A rootkit hooks some of the same things that ProcMon might
be using.

HTH,
Paul
 
Only if you prepared in advance.

Maybe Sysinternals Procmon, could record certain file system calls ?
Then, you'd have to go back through the log, after the fact, for
evidence.

This would be an example of a filter in Procmon.

"Operation" "Is" "CreateFile" "Include"

I think ProcMon by default, stores things in system RAM. But, there's
a preference, where you can store results in a file. Perhaps you'd need
that option, if you're going to leave it running all the time.

http://technet.microsoft.com/en-us/sysinternals/bb896645 (Process
Monitor)

If you wanted something lower level or more inclusive than that,
you'd likely need to run a "real debugger".

And, as you'd expect, you can't catch everything that way.
A rootkit, for example, could hide from such an effort.
A rootkit hooks some of the same things that ProcMon might
be using.

HTH,
Paul
Click to expand...

Hi Paul,

I have ProcMon. But, I have never done this before. Can
you point me to some instructions?

Many thanks,
-T
 
Todd said:
C:\windows\system32\grpconv.exe

I can't get rid of it. Virus Total says it is clean
Click to expand...

Why would you be trying to get rid of it? It is a Windows file... it's
the Windows Program Group Converter, and has been a part of Windows
operating systems since Windows 95. If a file with that name is in a
different location, then it may be a trojan, but the legit file is
stored in system32.
 
Why would you be trying to get rid of it? It is a Windows file... it's
the Windows Program Group Converter, and has been a part of Windows
operating systems since Windows 95. If a file with that name is in a
different location, then it may be a trojan, but the legit file is
stored in system32.
Click to expand...

Delete it and it comes right back. Overwrite it with something
else and it comes right back. Virus Total says it is legit.

And it harasses Kaspersky's installer. Says it does not have permission
to delete it.

I want to find who is writing it back after I delete it.

-T
 
Why would you be trying to get rid of it? It is a Windows file... it's
the Windows Program Group Converter, and has been a part of Windows
operating systems since Windows 95. If a file with that name is in a
different location, then it may be a trojan, but the legit file is
stored in system32.
Click to expand...

Can you do an MD5SUM on yours?
 
Todd said:
Can you do an MD5SUM on yours?
Click to expand...


6dd28a6d99cf7b14b2d1786d143624e0

Version 5.1.2600.5512 (xpsp.080413-2105)

If you don't have SP3 installed, you will have a different version and
MD5SUM.
 
Todd said:
Hi Paul,

I have ProcMon. But, I have never done this before. Can
you point me to some instructions?

Many thanks,
-T
Click to expand...

Maybe you don't need to in this case, if Windows File Protection
is putting it back :-)

WinXP Pro SP3 x32

C:\WINDOWS\system32\
C:\WINDOWS\system32\dllcache

grpconv.exe

5.1.2600.5512 (xpsp.080413-2105)
39,424 bytes
Monday, April 14, 2008, 12:00:00 PM

MD5SUM

6dd28a6d99cf7b14b2d1786d143624e0 *grpconv.exe

https://www.virustotal.com/file/ec4...4efde46b362e2427004bc99477683beefac/analysis/

Paul
 
Can you do an MD5SUM on yours?
Click to expand...

Never mind. I found a good one on one of my virtual macines:

$ md5sum grpconv.exe.customer grpconv.exe.vm
6dd28a6d99cf7b14b2d1786d143624e0 grpconv.exe.customer
6dd28a6d99cf7b14b2d1786d143624e0 grpconv.exe.vm
 
Maybe you don't need to in this case, if Windows File Protection
is putting it back :-)
Click to expand...

I am thinking that this was never a problem. (You learn
something new every day!)

Thank you for the help.
-T
 
Todd said:
Hi Glen,

I think it is going to turn out to be Kaspersky's installer that
is the problem. My reappearing program is probably caused by
Windows File Protection.
Click to expand...

Yes.... IF you have a copy of grpconv.exe in dllcache, then it is due to
SFP. I'm saying, if the MD5SUM didn't match, then use MBAM. Heck, I'd
do an MBAM scan regardless. Good luck.
 
Todd said:
"grpconv.exe is a Windows Operating System tool. It is used to convert
Windows 3.1 groups to folders when upgrading to Windows 95 or later."
Click to expand...

"grpconv.exe is a Windows Operating System tool.
It is used to convert groups to folders when upgrading to Windows New OS."

like SP1 to SP2 to SP3 and will be needed
for upgrading SP4 if there is one.....
Why would I care?
Click to expand...

Updates changed folders to a new SP.
 
Back
Top