From kernel mode in Windows I'm able to intercept and monitor virtually all actions performed on a particular disk. When a file is opened for any purpose I get an event.
Now I want to trace which application that opened it. I think this should be possible but don't know how.
I'm using the standard file management functions in Windows Win32 API.
Thanks in advance.
/Robert
Sysinternals Filemon (free) does this, and better yet they describe how they did it:
For the Windows 9x driver, the heart
of FileMon is in the virtual device
driver, Filevxd.vxd. It is dynamically
loaded, and in its initialization it
installs a file system filter via the
VxD service,
IFSMGR_InstallFileSystemApiHook, to
insert itself onto the call chain of
all file system requests. On Windows
NT the heart of FileMon is a file
system driver that creates and
attaches filter device objects to
target file system device objects so
that FileMon will see all IRPs and
FastIO requests directed at drives.
When FileMon sees an open, create or
close call, it updates an internal
hash table that serves as the mapping
between internal file handles and file
path names. Whenever it sees calls
that are handle based, it looks up the
handle in the hash table to obtain the
full name for display. If a
handle-based access references a file
opened before FileMon started, FileMon
will fail to find the mapping in its
hash table and will simply present the
handle's value instead.
-Adam
Sysinternals did a so good job at doing it and explaining it, that some source code of old version are still available here for instance, and the code is well documented (imho). It could be a good start as well.
I would use the "handle.exe" app from Sysinternals.
Or, are you actually trying to do this programmactically?
Just use Win32 N.API to get the pid from the File handle.
It's a FAQ for 15 years...
Related
I'm trying to use QSharedMemory and QClipboard to share data between a SYSTEM process (running on the WinSta0\\Winlogon desktop) and a normal user process, but both fail to share data with others non-SYSTEM processes running on the normal desktop. I belive this is because the WinSta0\\Winlogon desktop is a isolated desktop.
My app is a program that takes shots of the Windows Secure Desktop and send it to clipboard.
The question is: Is there any way to share memory data between that process and non-SYSTEM processes? (Actually I'm using a file to do the job).
On Windows Vista and later, system services run in an isolated session ("session 0"). This is the most likely cause of your problem. (Note that all system services run in session 0, regardless of whether they are running in the SYSTEM security context or not. Similarly, it is possible to launch processes as SYSTEM in an arbitrary session.)
Each session has a separate WinSta0 workstation, and hence a separate clipboard. So clipboard functionality is not going to work here.
It is possible for file mapping objects (shared memory) to work across session boundaries. However, I don't know whether it is possible to do this with Qt. The best bet would appear to be to use setNativeKey which presumably determines the name of the file mapping; to make a file mapping cross session boundaries, use a name that begins with Global\ as described in the MSDN article on CreateFileMapping. If possible, consider using the Win32 API directly rather than Qt.
In Linux to read File System Events, most of us use Inotify which is really a Good One. But it has it's limitations.
I have to keep track of all the directories i have to watch and get a inotify descriptor for each and every directory. Let's say i want to monitor my Whole System and it has about 10 million directories. Listing and queuing them for inotify API itself would take hours. It would eat a lot of memory also.
And i certainly can't watch directories more than that specified in max_user_watches in /etc/syscntl.conf or /proc/sys/fs/inotify/max_user_watches .
But we know that each and every file system event is monitored by Kernel and we use inotify API to register for a certain directory modifications. But how do i read fs events directly from kernel without API ..? [ In Mac OS X, i can read from /dev/fsevents , likewise if i can read from /proc or something like that, it would be great]. I'm ready to write a Kernel Module too, but please share some light on this.
Did you look at the virus scanner stuff? Ie, Fanotify, also fsnotify and hooked to dnotify and inotify. This depends on kernel version; present in some form since approximately 2.6.36 (early 2011).
Some kernel files,
proc documentation
fsnotify.h
fsnotify_backend.h
fanotify.h
Lwn.net links,
API overview
Main Commit notice
Various commits
i need to add some files to results returned by FindFirstFile and FindNextFile under windows. Is this possible by file system filter driver or what type of drivers?
Thank you
You can do this by File System Filter Driver. But you can do this by implementing a system wide API hook. I have not tried it before but you really don't need to take the pains of writing the drivers and making the system unstable in case of spoiling the driver stack.
System Wide API Hooking
API Hooking Revealed
As pointed out you can use a file system filter driver (legacy or mini-filter, based on fltmgr). However, I would strongly recommend against the system-wide API hooking. Simple reason: if you do it in usermode it's not really going to be system-wide and if you use an SSDT-hook or some hotpatching method you risk the system's stability. An alternative, albeit equally shady as system-wide hooking, would be entry-point stealing. In this case you use the device object of the volume (in which you're interested, just listen for the attach notifications or enumerate them at startup) to find the driver responsible for it and modify the major function entry points in the driver object (Ilho pointed you into the right direction already).
A file system filter driver is the supported method to do just that.
In the latest Windows 7 WDK the sample under 7600.16385.1\src\filesys\miniFilter\minispy provides a good starting point. Biggest problem with mini filters for a private person is to get assigned an altitude for the driver to load at. Because using just any altitude can well lead to BSODs - and in case of FSFDs you might even risk your data integrity (although the kernel steps in with the BSOD to prevent that). You only need to fake IRP_MN_QUERY_DIRECTORY - this is the minor control code you're looking for when you are handling the IRP_MJ_DIRECTORY_CONTROL major control code. All others you can pass through as long as you don't need to allow the file to be opened, read or written and such. How to do that can be seen in the 7600.16385.1\src\filesys\miniFilter\passThrough sample source.
Is there a way to access file system info via some type of Windows API? If not what other methods are available to a user mode developer?
Not very clean, but you can use DeviceIoControl()
Open volume as a file, pass resulting handle to DeviceIoControl() together with control code. Check MSDN for control codes, there is something like "read journal record".
In another post, someone recommended this : Keeping an Eye on Your NTFS Drives: the Windows 2000 Change Journal Explained.
It explains how to use the NTFS Filesystem with C++ through Windows 2000.
The implementation might have changed.
I am trying to snoop on a log file that an application is writing to.
I have successfully hooked createfile with the detours library from MSR, but createfile never seems to be called with file I am interested in snooping on. I have also tried hooking openfile with the same results.
I am not an experienced Windows/C++ programmer, so my initial two thoughts were either that the application calls createfile before I hook the apis, or that there is some other API for creating files/obtaining handles for them.
You can use Sysinternal's FileMon.
It is an excellent monitor that can tell you exactly which file-related system calls are being
made and what are the parameters.
I think that this approach is much easier than hooking API calls and much less intrusive.
Here's a link which might be of use:
Guerilla-Style File Monitoring with C# and C++
It is possible to create a file without touching CreateFile API but can I ask what DLL injection method you're using? If you're using something like Windows Hooks your DLL won't be installed until sometime after the target application initializes and you'll miss early calls to CreateFile. Whereas if you're using something like DetourCreateProcessWithDll your CreateFile hook can be installed prior to any of the application startup code running.
In my experience 99.9% of created/opened files result in a call to CreateFile, including files opened through C and C++ libs, third-party libs, etc. Maybe there are some undocumented DDK functions which don't route through CreateFile, but for a typical log file, I doubt it.
Process Monitor from sysinternals could help too.