I have a problem, i have a file who opened other process and this process defined in CreateFile non file sharing, then i have other application and i want read data from this
file in same time, but how to do.
I can't change file sharing in first application.
I can reach computer administrator right's, i can do changes in system, but probably "code" solution will be better for this problem if this can be done by code.
Can anyone help me?
How about using EasyHook and hook in the API to the CreateFile routine, in effect, your code will intercept the API and possibly change the dwShareMode parameter to make it FILE_SHARE_READ bitwise or FILE_SHARE_WRITE i.e. (FILE_SHARE_READ|FILE_SHARE_WRITE) and call the original hook to allow the CreateFile to work normally...
Use the backup API if you have sufficient privilege. Otherwise, note that these flags exist for a reason. If someone disabled sharing, it's disabled.
You want to call BackupRead, and MSDN notes the following:
a backup
application must have access to the
system-level access control settings,
the ACCESS_SYSTEM_SECURITY flag must
be specified in the dwDesiredAccess
parameter value passed to CreateFile.value passed to CreateFile.
parameter value passed to CreateFile.
One of the options is to use our RawDisk product, which lets you bypass system security restrictions and open files, which have been opened exclusively or the ones for which you don't have access rights. Note, that installing RawDisk itself requires admin rights, so RawDisk can't be used for intrusion to other's computer.
Another option is to use backup API, i.e. above mentioned BackupRead() Windows API function. Doing google search for BackupAPI will give you not just description of this function, but also several comments from users about what's involved in using this backup API
Related
I've created a communication between two applications using named pipes.
The first application creates a named pipe with CreateNamedPipe and reads the received messages with ReadFile sent by the second application. Both applications are able to communicate that way as intended.
Is it somehow possible to identify the sender of a received message?
Without some sort of identification (like getting the sender exe path) or authorization every other application could use that pipe to send messages to my application.
(Edit) Further details, because it seems it's important in this case:
The application that creates the pipe is running as a Windows service.
Both applications run locally on the same system.
The GetNamedPipeClientProcessId() will give you the process ID of the client process. You can then open a handle to the process with OpenProcess() and call GetModuleFileNameEx() to determine what application is running in that process. You can then vet the application in whatever way you think best, e.g., you might want to check the identity of the digital certificate or you might prefer to just check that the pathname is as you expect it to be.
Note that attempting to restrict access to a particular application rather than a particular user is never going to be robust; an attacker could always take control of the approved application and replace its code with their own. Basically it isn't going to be more than a speed bump, but if you feel it is worth doing, it can be done.
If what you really want to know is what user has connected, you should instead be using ImpersonateNamedPipeClient() as already suggested in the comments, followed by OpenThreadToken() and so on. Or better still, set the permissions when creating the named pipe so that only the authorized users are able to connect in the first place.
Now that you've clarified that the client runs with elevated privileges, I can make a more concrete recommendation: do both of the above. Configure the permissions on the named pipe so that only members of the Administrators group can access it; that will ensure that only applications running with elevated privilege can access it. Checking the executable as well won't hurt, but it isn't sufficient by itself, because an attacker could launch a copy of your application, suppress the requested elevatation, and inject their own code into the process. (Or, as conio points out, modify their own process to make it look as if they are running your executable; GetModuleFileNameEx() is not intended to be used as a security measure, so it makes no effort to avoid spoofing.)
In other words, is it possible to access a file without a handle being utilized?
You could use the CreateFile()-API to create a handle to the raw file-system and then parse the file structure by yourself (this is more work as it sounds!)
Though this would require admin-rights. This wouldn't trigger any hooks you have on CreateFile() or other file-related API-functions.
This wouldn't create a handle to the file but you still need a handle to the device.
For code running in user mode, any operation on a file will involve a handle of some kind, though not necessarily to the file in question. There are APIs that don't expose the handle to the programmer, but there is always one there.
In kernel mode, although it is usual to use handles for file operations, it is not necessary. For example, the file server component doesn't appear to open file handles when it is accessing a file on behalf of a remote user.
In Windows, I have an application that needs to set the access control to the user/group 'Everybody' only. And sets permissions to Read-Only. Under Linux a Simple open() call with octal 004 permissions is sufficient. On Windows, how do I accomplish the same thing? Preferably in the call to CreateFile().
Create a SECURITY_DESCRIPTOR with the proper attributes. The functions linked to from there are a good starting point for creating the proper security descriptor (it's far from trivial). This page shows a good example of creating one, including how to get the SID for the "Everybody" group (pEveryoneSID in the code).
Then, just pass in that security descriptor to CreateFile as the lpSecurityAttributes parameter.
The FileShare enumeration offers various flags such as Read, Write, Delete, ... . Normally I'd think that sharing a file for deletion only allows deletion but nothing else (like reading).
However, I remotely recall that Windows only differentiates between read-only and full access to files, so actually sharing for deletion allows writing to the file as well. Sadly this is from many years back and I neither found the original source nor any related info. Is there a reliable spec on the actual behavior? Is it dependent on the OS or the FS?
Take a look at the documentation for the CreateFile Function.
FILE_SHARE_DELETE:
Enables subsequent open operations on a file or
device to request delete access. Otherwise, other processes cannot
open the file or device if they request delete access. If this flag is
not specified, but the file or device has been opened for delete
access, the function fails. Note Delete access allows both delete and
rename operations.
The documentation doesn't mention that read access is allowed, too.
I want to be able to lock a file in Win32 so that it can only be used by my current process. The most obvious way to accomplish that seemed to be via CreateFile:
HANDLE file = ::CreateFile("c:\\foo.txt",
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
However once that call has succeeded, the file is also apparently locked by my own process, ie. I get a "sharing violation" once the MFC framework stuff tries to open it.
Is there a convenient way to prevent access to the file by other processes but still allow it by mine? I'd rather not have to replace all the loading/saving framework code... Am I doing something wrong in the parameters I'm passing in to CreateFile?
From Creating and Opening Files:
An application also uses CreateFile to
specify whether it wants to share the
file for reading, writing, both, or
neither. This is known as the sharing
mode. An open file that is not shared
(dwShareMode set to zero) cannot be
opened again, either by the
application that opened it or by
another application, until its handle
has been closed. This is also referred
to as exclusive access.
See also How do the FILE_SHARE_* bits interact with the desired access bits?
I'm not aware of any simple way to do this. As far as more complex methods go, you could:
set up a special user name for accessing the file.
Open the file non-shared.
Edit the ACL to allow use only from the special user name
Close the file.
Impersonate that user
Open the file, allowing sharing
Close the file
Set the ACL back to allow other users access
Note that I'm not saying I'd recommend that at all -- it's ugly and more or less an abuse of the system -- but if you're sure you need to do this, it's one way that probably would work.