I'm trying to make a small program that could intercept the open process of a file.
The purpose is when an user double-click on a file in a given folder, windows would inform to the software, then it process that petition and return windows the data of the file.
Maybe there would be another solution like monitoring Open messages and force Windows to wait while the program prepare the contents of the file.
One application of this concept, could be to manage desencryption of a file in a transparent way to the user.
In this context, the encrypted file would be on the disk and when the user open it ( with double-click on it or with some application such as notepad ), the background process would intercept that open event, desencrypt the file and give the contents of that file to the asking application.
It's a little bit strange concept, it could be like "Man In The Middle" network concept, but with files instead of network packets.
Thanks for reading.
The best way to do it to cover all cases of opening from any program would be via a file system filter driver. This may be too complex for your needs though.
You can use the trick that Process Explorer uses to replace itself with task manager. Basically create a key like this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe
Where you replace 'taskmgr.exe' with the name of the process to intercept. Then add a string value called 'Debugger' that has the path to your executable. E.g:
Debugger -> "C:\windows\system32\notepad.exe"
Every a process is run that matches the image name your process will actually be called as a debugger for that process with the path to the actual process as an argument.
You could use code injection and API redirection. You'd start your target process and then inject a DLL which hooks the windows API functions that you want to intercept. You then get called when the target process thinks it's calling OpenFile() or whatever and you can do what you like before passing the call on to the real API.
Google for "IAT hooking".
Windows has an option to encrypt files on the disk (file->properties->advanced->encrypt) and this option is completely transparent to the applications.
Maybe to encrypt decrypt file portions of a disk you should consider softwares like criptainer?
There is this software as well http://www.truecrypt.org/downloads (free and open source) but I haven't tried it.
Developing a custom solution sounds very difficult.
Related
I want create a kernel driver program to monitor certain kernel events such as creating files, so that I receive a notification whenever a file is created, including the process ID of the process that created the file. I already created a program where I can see the files which are opened in the system, by creating an handler for IRP_MJ_CREATE.
I used this project as a reference.
There are several ways to do it, with the file system filter being the most complete. However for simple notifications, the easiest way to do it is through a minifilter.
You have several examples by microsoft:
https://github.com/microsoft/Windows-driver-samples/tree/master/filesys/miniFilter
Here is the reference: https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/ifs-reference
Do note however that you can do this without a driver, so unless you have a very good reason to do it in kernel space, you can do it from userspace. See FindFirstChangeNotification:
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstchangenotificationa
I have a file name and I want to check whether it can be executed or not on windows through c++. I found _access and _access_s, but they only check for read/write.
My problem is that when I download a bat file for example, the windows blocks it as a security measure. When I run my program and try to execute it, windows blocks my program and asks user if he wants to continue anyway, because the file is risky. I want to avoid that by checking the file rights before executing it.
The windows filesystem, NTFS, does not support an executable attribute in the way you might expect if you have used a Unix based OS.
What you are seeing here is the shell reacting to an extra stream that was added to the file. And streams are a feature of NTFS.
Microsoft has some sample code showing how to access streams in a file:
How to use NTFS Alternate Data Streams
In the case of files downloaded from the internet, Microsofts browsers (IE and Edge) add a stream called "Zone.Identifier", which ShellExecute and related APIs check for when asked to execute a file to present the user with a security prompt.
To cleanse the file so that the security prompt does not appear it is necessary to erase the stream.
BOOL didDeleteZoneIdentifier = DeleteFile(TEXT("Path To Batch File.bat:Zone.Idenfier"));
if(!didDeleteZoneIdentifier){
int errorCode = GetLastError();
....
It is easier to explain with example.
When 2 text editors edit the same text file in the same time, when one editor saves the file, the other one understands that it was modified and asks to do smth.
How is it possible to get a signal that a file was modified outside the program?
I am working with c++ (though I think it isn't important) and on linux. (solution for windows would be good too)
ISO-C++ does not offer this functionality, so you have to stick with what the operating system provides.
On Linux that would be inotify, on Windows you would use directory change notifications.
① Check the timestamp of the file as close as possible before writing. If it is not what it was when you last opened this file for reading, then beware!
② You can build a checksum of the file and compare this to one you built earlier.
③ Register to a system service which informs you about file activities. This depends on the goodwill of the OS you are using; if this notification service isn't working properly, your stuff will fail. On Linux have a look at Inotify.
I'm trying to fulfill a client request here, and I'm not entirely sure I can actually do it. I have an MFC application that relies upon ShellExecute to open files in their appropriate viewer, which spawns multiple viewers if you try to open multiple files one after the other. If you open one .txt document, and then open another, two copies of notepad appear as expected.
The client wants us to change this functionality - Windows' functionality - to just pass file locations to any viewers that might already be opening. The first image clicked should open Image Viewer, but any other should just be opened in that existing process.
Is that kind of inter-application control/communication possible? Can I generically "pass" files to existing processes? I don't think I can. Executing a program with a file as a parameter is one thing, but passing a file to a running process is something else altogether. I'm not sure you can do that generically, I don't think that kind of functionality is anywhere in the Windows APIs.
I could be wrong, though.
This isn't possible if the viewer don't support multiple open files in same instance.
in your example: notepad will launch a new version with each file, while Notepad++ (a free editor) will open in same instance in a new tab.
The first thing you should try is calling the program again with the new parameters. If the program is written in such a way it will delegate the new parameter to the existing instance. Notepad doesn't do this, image viewer may though.
The next thing you can try is managing the life of the application by keeping track of the handle yourself. You call CreateProcess, so you create and own the handle to this process. On the next call to CreateProcess, enumerate the open windows and try to find your last handle. If the handle is found, close it and continue with your open process. You should only get one open application. For the most reliable solution, put this in a separate thread and wait for the handle (as well as a new request event) to avoid any race conditions.
Use case: 3rd party application wants to programatically monitor a text file being generated by another program. Text file contains data you want to analyze as it's being updated.
I'm finding a lot of answers to this question wrapped around FileSystemWatcher but let's say you are writing an application for a Windows machine and can't guarantee .NET is installed.
Are there any libraries out there available for this, or am I just going to have to roll my own solution then?
Thanks.
You can monitor a directory with FindFirstChangeNotification works on any windows.
It's efficent if you know where the file is - otherwise you can use the virtual driver/Filemon described below to check for changes anywhere on the system.
Example code here
A simpler solution could be to check the last modified time stamp of the file.
If you use the _stat64() function to do this, it becomes a cross-platform solution.
Example code:
struct __stat64 fileinfo;
if(-1 != _stat64(filename, &fileinfo)
return fileinfo.st_mtime;
looks like this : Tracing which process that has opened a particular file
again sysinternal gave some tips and tools
This sounds a lot like what FileMon, from sysinternals (now MS) does. They do this by creating a virtual device driver that is dynamically loaded. they have a good description of how it works here:
How FileMon 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.