Using Hooks
-
Hi, can anybody give me some idea that how to use hooks to find that whether a file is in use or not. Thanks
I do not think that a hook will provide you with anything useful as the opening of a file is not message-based. Why not just try and open the file? If the open fails, and not because the file didn't exist, you know the file is in use.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
-
I do not think that a hook will provide you with anything useful as the opening of a file is not message-based. Why not just try and open the file? If the open fails, and not because the file didn't exist, you know the file is in use.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
Maybe he meant to use some API Hooking on the CreateFileXXX family of functions in order to monitor what files are open. But i guess this method isn't so good. Writing a driver may offer a better solution, with a file system filter IFSMGR_InstallFileSystemApiHook in order to be in the chain of all file system requests. (Windows 9x) or a file system driver that attach a filter device objects to target file system device objects so that it see all IRPs and FastIO requested from drives. A hash is necessary to keep track of the correspondance of HANDLE <-> Pathname Papa while (TRUE) Papa.WillLove ( Bebe ) ;
-
Maybe he meant to use some API Hooking on the CreateFileXXX family of functions in order to monitor what files are open. But i guess this method isn't so good. Writing a driver may offer a better solution, with a file system filter IFSMGR_InstallFileSystemApiHook in order to be in the chain of all file system requests. (Windows 9x) or a file system driver that attach a filter device objects to target file system device objects so that it see all IRPs and FastIO requested from drives. A hash is necessary to keep track of the correspondance of HANDLE <-> Pathname Papa while (TRUE) Papa.WillLove ( Bebe ) ;
Papa wrote: Writing a driver may offer a better solution, with a file system filter IFSMGR_InstallFileSystemApiHook in order to be in the chain of all file system requests. (Windows 9x) or a file system driver that attach a filter device objects to target file system device objects so that it see all IRPs and FastIO requested from drives. A hash is necessary to keep track of the correspondance of HANDLE <-> Pathname Which is how SysInternals' FileMon utility works: "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."
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
-
Papa wrote: Writing a driver may offer a better solution, with a file system filter IFSMGR_InstallFileSystemApiHook in order to be in the chain of all file system requests. (Windows 9x) or a file system driver that attach a filter device objects to target file system device objects so that it see all IRPs and FastIO requested from drives. A hash is necessary to keep track of the correspondance of HANDLE <-> Pathname Which is how SysInternals' FileMon utility works: "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."
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
Exactly. But the same hash is also needed in the first case when using API hooking. Should be noted that both techniques lacks info on the files that where opened before the startup of our code, so basically its better to start before any user process. So its add some tiny complication to our friends request. Good luck anyway! Papa while (TRUE) Papa.WillLove ( Bebe ) ;
-
I do not think that a hook will provide you with anything useful as the opening of a file is not message-based. Why not just try and open the file? If the open fails, and not because the file didn't exist, you know the file is in use.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
DavidCrow wrote: Why not just try and open the file? If the open fails, and not because the file didn't exist, you know the file is in use. That will not work in some cases. The reason for this is that you can open files that share all access. So if you try to open a file, which is opened by an application that shares all access, this method will fail. I also got the blogging virus..[^]
-
DavidCrow wrote: Why not just try and open the file? If the open fails, and not because the file didn't exist, you know the file is in use. That will not work in some cases. The reason for this is that you can open files that share all access. So if you try to open a file, which is opened by an application that shares all access, this method will fail. I also got the blogging virus..[^]
Right. I was answering on the assumption that if the file was opened for exclusive access then it could be considered in use. Otherwise, I'd simply consider it open but not in use.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown