It's possible, but is it appropriate to use SHFileOperation within a Windows service? All those SHxxx API functions in shell32.dll seem to have been written with user level programs in mind. Can I be certain SHFileOperation won't display GUI ever?
According to the SHFILEOPTSTRUCT documentation, you can use the following flags to prevent any UI from appearing:
FOF_SILENT | FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_NOCONFIRMMKDIR
or (if you're targeting Windows Vista), FOF_NO_UI, which is the same as the above.
Looking in the ShellAPI.h header file in the Windows SDK, the comment against FOF_NO_UI says "don't display any UI at all", so from this I assume it's OK to use SHFileOperation.
I would say, not it's not appropriate or advisable. Most of the shell32 APIs were written with a basic understanding that they would be used in interactive processes. I don't think there is any way you can guarantee that SHFileOperation will never display a UI component. In fact, if you look at IFileOperation (which is the new Vista interface that replaces SHFileOperation), it clearly states:
Exposes methods to copy, move, rename, create, and delete Shell items as well as methods to provide progress and error dialogs. This interface replaces the SHFileOperation function.
I have to agree: not appropriate or advisable.
The prinicpal reason to use SHFileOperation is to perform operations with a UI, and/or which are reversable. I.e. using SHFileOperation to delete files is going to place the files in a recycle bin rather than deleting them allowing the current interactive user to undelete, or undo the operation performed.
As the services run on a non interactive desktop, no one will ever be able to clear that recycle bin out.
I had this issue as well and working at implementing a secure and reliable network file copy between servers and network shares ( most of these shares are CIFS / NetApp filer based ) and SHFileOperation fails from time to time.
now started using ROBOCOPY (available by default in all Microsoft OS from Vista/Server 2008 upwards) and really looks interesting and reliable.
this has opened my eyes: https://stackoverflow.com/a/1030752/559144
Related
I know that ntdll is always present in the running process but is there a way (not necessarily supported/stable/guaranteed to work) to create a file/key without ever invoking ntdll functions?
NTDLL is at the bottom of the user-mode hierarchy, some of its functions switch to kernel mode to perform their tasks. If you want to duplicate its code then I suppose there is nothing stopping you from decompiling NtCreateFile to figure out how it works. Keep in mind that on 32-bit Windows there are 3 different instructions used to enter kernel mode (depending on the CPU type), the exact way and where the transition code lives changes between versions and the system call ids change between versions (and even service packs). You can find a list of system call ids here.
I assume you are doing this to avoid people hooking your calls? Detecting your calls? Either way, I can't recommend that you try to do this. Having to test on a huge set of different Windows versions is unmanageable and your software might break on a simple Windows update at any point.
You could create a custom kernel driver that does the work for you but then you are on the hook for getting all the security correct. At least you would have documented functions to call in the kernel.
Technically, registry is stored in %WINDIR%\System32\config / %WINDIR%\SysWOW64\config, excepted your own user's registry which is stored in your own profile, in %USERPROFILE%\NTUSER.DAT.
And now, the problems...
You don't normally have even a read access to this folder, and this is true even from an elevated process. You'll need to change (and mess up a lot...) the permissions to simply read it.
Even for your own registry, you can't open the binary file - "Sharing violation"... So, for system/local machine registries... You can't in fact open ANY registry file for the current machine/session. You would need to shut down your Windows and mount its system drive in another machine/OS to be able to open - and maybe edit - registry files.
Real registry isn't a simple file like the .reg files. It's a database (you can look here for some elements on its structure). Even when having a full access to the binary files, it won't be fun to add something inside "from scratch", without any sotware support.
So, it's technically possible - after all, Windows does it, right? But I doubt that it can be done in a reasonable amount of time, and I simply can't see any benefit from doing that since, as you said, ntdll is ALWAYS present, loaded and available to be used.
If the purpose is to hack the current machine and/or bypass some lack of privileges, it's a hopeless approach, since you'll need even more privileges to do it - like being able to open your case and extract the system drive or being able to boot on another operating system on the same machine... If it's possible, then there is already tools to access the offline Windows, found on a well-known "Boot CD", so still no need to write in registry without any Windows support.
I want to set up path redirection in both files and registry keys in the same manner UAC virtualization works for another process at launch time (either programmatically or using some existing interface).
For example, I want to run C:\my_path\app.exe and when it opens any file on disk (C:\other_path\file.txt) for writing, the actual open file should be C:\temp_for_my_app\C\other_path\file.txt.
I've seen some programs are able to set up such redirection (i.e. Sandboxie), but I'm unsure which mechanism they are using (not even sure if it is the same UAC virtualization uses).
Any insight into the way UAC virtualization implements it might be useful (your comment on this will be appreciated)
Try cmregistercallback() or API HOOKING to hook zwopenkey() and zwcreatekey()
For testing and development purposes, it would be nice to somehow simulate (spurious) file access errors to local files. For example, even if an application has correctly opened a file with the appropriate restrictive sharing flags, it still can happen that an attempt to access the file (through any of the Win32 API functions or your favourite framework, which internally will just call any of the Win32 API functions) can fail.
The only example I ever was able to track down was the virus scanner on a machine, but I guess there could be other reasons. (In this question's comment, Luke mentions something about "File system filter drivers".)
FWIW, I know of a few possibilities to "simulate" file problems, that I do not consider good solutions, either because they require to much manual work or because they don't fit for every app/file:
Place a file on a network drive or removable storage device - that way you can just mess up the device (unplug, disk-full, ...).
Open the application process in Process Explorer and close the handle of the file you want to test.
So the question really is if there are any ((semi)automated) tools that can mess up file access (on an NTFS drive) even though an application has already opened a file with appropriate (for the app) sharing flags.
Holodeck purports to allow Win32 API hooking, which would enable you to manipulate return codes as needed for Fault Injection.
If your API set of interest is well-defined, you could probably do this yourself using the Import Address Table approach described here.
I want that an exe file can't be copied or cut from the Windows file system to paste somewhere.
The exe is made in C#. which must have to be in only one PC.
I have worked with FileSystemWatcher, NSIS, Clipboard. but for all I need to detect whether that file is being copied.
I also have seen 'Prevent'(http www free-download-blog.com disable-cut-paste-copy-delete-rename-functions-using-prevent ), but I need to prevent only that particular exe from being copied or cut.
Any pointer or idea will help.
As others have suggested you won't be able to disable the copy/cut behaviour so easily.
An alternative would be to disable the execution of the copied versions. In your executable you could check many things like :
The path of the present executable is explicitly your_path
The name of the machine and user is the one you authorise
You could even prevent the file of being executed more than once using Windows register entries (if already 1 don't launch). It won't be perfect since any experimented user could tweak that out, assuming they are seeking for that. But depending on your users profile it might be sufficient.
If you need the exe to be executable, you need to permit loading it into memory.
As soon as you do, anyone can read it to memory using ReadFile and then write to an arbitrary location using WriteFile. No shell-detectable copying involved.
A good reading: Raymond's post and its comments on preventing copying.
Well, this is a hard problem. Even if you get explorer.exe to disable cut&paste, what prevents a user from using the command window? Or writing their own exe to do it? Booting up in linux and reading it?
Still, you have a few options (there will be more, most likely) which you could try:
Use the right permissions: Set the
permissions such that the users who
you don't want to cut&paste cannot
read the file.
Write a device driver which can hook
onto the filesystem calls and do that
for you.
Encrypt the file.
And some hacky options like:
Use the APPINIT_DLLS regkey to put your own dll to be loaded into each process ( I am not sure if this will work with console process though). Then on your dll load, do IAT hooking to replace the kernel32.dll file calls.
Replace kernel32.dll with your own version. Might have to do some messing around with the PE format etc.
There are no guarantees though. If for instance, you expect them to be able to execute it, but not copy it, you are probably stuck.
Any local admin will be able to undo anything you do to prevent copying. I can pretty much guarantee the program on that page you mention relies on a service or background process to prevent copy-and-paste, and therefore is easily circumventable. If your users are in a closed environment where none of them are admins and they have very limited rights to their PCs, then you have a chance.
if you could completly block explorer from copying or moving files, then all u need is a 3rd party software for copying files (but make sure it can filter file extensions) for example Copy Handler
Set up an ENVIRONMENT variable in your machine
In your code add a check
if (ENVIRONMENT Variable=='Same as defined')
//Execute code
else
//Suspend execution
I am starting to design a DMO to run from inside a windows media player activeX control in Internet Explorer.
is there any reason why using windows named pipes from inside the DMO wouldn't work?
user permissions/privilages/ kernel mode stuff?
Thanks :)
Roey
I have not tried it but I can't think of any particular reason it could not work. However, keep in mind that starting with Vista Internet Explorer runs as a low integrity level processes so any pipe you connect to will need to have it's access control set accordingly.
I have done this from a FireBreath plugin (activex control on IE, npapi on others) and the only thing you need to keep in mind is that activex controls in IE are often running in low integrity mode, so you need to make sure you set the ACL mask on the pipe correctly. As long as you have it configured correctly, it works fine.