in my minifilter, until i get everything done i want to monitor just a specific process’s file operations (ex. filetest.exe or other tools)
since i would like to avoid to lose time when testing, i would like to send the image path of the application that i want to monitor from a user-mode application to the driver
i have a process notify routine, in which i use PsLookupProcessByProcessId->ObOpenObjectByPointer->ZwQueryInformationProcess method to get the image path for a pid, which is returned in a \Device\HarddiskVolume*.… format
since my user mode application uses the [driveletter]:\path format i have two options:
-i can construct the normalized path in user mode and send it to the kernel
-or i can normalize it in kernel mode
i thought i could use NtQueryInformationFile (in the user mode app) with FileNameInformation class, but that function requires NtOpenFile, which in turn requires normalized paths
If this is only for testing purposes then don’t worry about the drive
name. I would just use a wild card match such as *FILETEST.EXE. Unless
the application is running from more than one drive on the system and
you care which one you are monitoring then just punt on the drive name.
Again, if this is for testing purposes only …
Pete
On 5/6/2013 9:37 AM, xxxxx@gmail.com wrote:
in my minifilter, until i get everything done i want to monitor just a specific process’s file operations (ex. filetest.exe or other tools)
since i would like to avoid to lose time when testing, i would like to send the image path of the application that i want to monitor from a user-mode application to the driver
i have a process notify routine, in which i use PsLookupProcessByProcessId->ObOpenObjectByPointer->ZwQueryInformationProcess method to get the image path for a pid, which is returned in a \Device\HarddiskVolume*.… format
since my user mode application uses the [driveletter]:\path format i have two options:
-i can construct the normalized path in user mode and send it to the kernel
-or i can normalize it in kernel mode
i thought i could use NtQueryInformationFile (in the user mode app) with FileNameInformation class, but that function requires NtOpenFile, which in turn requires normalized paths
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
i would like to use this feature later, not just for testing purposes, so i thought i could lay the foundation here.
but i can fake the verification to test only the actual exe name anyway
I usually use GetFinalPathNameByHandle, as it gives you the option of getting the name back with a drive letter, a GUID, or the native NT name.
Is there a reason this standard Win32 function (Vista and beyond) doesn’t work for you?
Tony
OSR
i`m using windows xp for testing
but i went with only comparing the end of the strings (the filename part) for now
you can use something like this to get full name in nt format in user mode
struct name_information
{
OBJECT_NAME_INFORMATION name;
wchar_t buffer[260];
};
void get_full_name(HANDLE file)
{
name_information ni;
ULONG size = sizeof(ni);
NTSTATUS stat = NtQueryObject(file, (OBJECT_INFORMATION_CLASS)1, &ni,
size, &size);
}
On Mon, May 6, 2013 at 11:06 PM, wrote:
> i`m using windows xp for testing
>
> but i went with only comparing the end of the strings (the filename part)
> for now
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>