My app creates a directory(file folder) on C:/ drive, since I don't want to expose all the data in it, and I don't want to encrypt all files in it, I wonder if there is a way to lock the folder up, so only my app can access it, no other person through windows explorer or another program can open the folder, doesn't matter if my app is running or not, is it doable ?
This is inherently impossible.
There is nothing that your program can do on the user's machine that he cannot do himself. (possibly aided by a decompiler and a debugger)
Nope, operating systems just don't provide this type of facility. You can look at file locks (http://en.wikipedia.org/wiki/File_locking) but those are intended to prevent "concurrent access" not this sort of "lock". With that said, you should ask yourself what are you trying to do here, is it securing information (encrypted file) or preventing accidental configuration changes (hiding the directory)?
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 am working on a Windows application written in Java that writes its project specific information and settings in specific project files. I wish that only this application can read and modify the project files and settings and these files can not be read or edited via some text editor by the user or written to by some other application. I was thinking of adding obfuscation to prevent information access but how can i prevent any other user process from writing to the files.
As long as your application is running, you can just keep the file open in your application. You can specify how other processes can access the file while you have open when opening the file (the default usually is that no one else can write it, though)¹.
However, if your application isn't running all the time that won't work, obviously. The usual way to solve this is to run the application under a separate user account and only give that account permission to modify the files. That sort of thing works for servers and services, of course, but is rather rare for a normal user-facing application, though.
You can employ obfuscation, or store the contents elsewhere as well (e.g. another file in another place, registry, ADS, ...) and try recovering from a mismatch. But fundamentally, barring separate user accounts, you have no way of actually forbidding access to a file. Such things cannot be done with process-level granularity on Windows.
¹ I'm not sure how much control Java gives you over this, though. A quick look at FileInputStream seems to give you absolutely no control over the handle's sharing policy. You can use native code to open the file, though, though I'm not sure right now how to pass that to the usual Java I/O classes. It could be difficult.
I want to put some sort of "hook" into windows (only has to work on Windows Server 2008 R2 and above) which when I ask for a file on disk and it's not there it then requests it from a web server and caches it locally.
The files are immutable and have unique file names.
The application which is trying to open these files is written in C and just opens a file using the operating system in the normal way. Say it calls OpenFile asking for c:\scripts\1234.12.script, and that is there then it will just open it normally. If then it asks for c:\scripts\1234.13.script and it isn't then my hook in the operating system will then go and ask my web service for the file, download it and then return that file as it it were there all the time.
I'd prefer to write this as a usermode process (I've never written a windows driver), it should only fire when files are not found in a specific folder, and I'd prefer if possible to write it in a managed language (C# would be perfect). The files are small (< 50kB) and the web service is fast and the internet connection blinding so I'm not expecting it to take more than a second to download the file.
My question is - where do I start looking for information about this kind of thing? And if anyone has done anything similar - do you know what options I have (eg can it be done in C#?)?
You would need to create a kernel-mode filesystem filter driver which would intercept requests for opening such files and would "fake" those files. I should say that this is a very complicated task even for driver development. Our CallbackFilter product would be able to solve your problem however mechanism for "faking" files is not yet ready (we plan this feature for CallbackFilter 3). Until then I don't know any user-mode solutions (frankly speaking, no kernel-mode solutions as well) that would solve your problem.
If you can change the folder the application is accessing, then you can create a virtual file system and map it to the drive letter or a folder on NTFS drive. From the virtual file system you can direct most requests to/from real disk and if the file doesn't exist, you can download the file and cache it. Our other product, Callback File System, lets you do what I described in user-mode. If you have a one-time task you need to accomplish, and don't have a budget for it, please contact us anyway and maybe we can find some solution. There also exists an open-source solution with similar (but not so comprehensive) functionality named Dokan, yet I will refrain from commenting on its quality.
You can also try Dokan , it open source and you can check its discussion group for question and guides.
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
To me its a no-brainer. The settings for my program go into the Windows Registry. After all, that's what it's for, isn't it?
But some programmers are still hesitant in using the Registry. They state that as it grows it slows down your computer. Or they state that it gets corrupted and causes your computer to malfunction.
So they write their own configuration files, or may use the INI files that Microsoft has depreciated since a few OS's ago.
From what I hear, the problems with the registry that occurred in early Windows OS's were mostly fixed as of Windows XP. It may be the plethora of companies that make Registry Cleaners that are keeping up the rumors that "registry bloat" and "orphaned entries" are still bad.
So I ask, is there any reason today not to use the Windows Registry to store my program configuration settings?
If the user does not allow registry access, you're screwed.
If the user reinstalls Windows and he wants to migrate his settings, it's much more complicated than with a simple file
Working with a config file means your app is portable
Much simpler for the user to change a setting manually
When you'll want to port your app to other OS, what are you gonna do with your registry settings ?
Windows Registry is bloated. Do you really want to contribute to this chaos?
For me, quickly installing, migrating and moving applications is a key point to productivity. I can't if I need to care of hundreds of possible registry keys. If there's a simple .ini or .cfg or .xml file somewhere in my user folder (or even the application directory if it is a portable app), migration is easy.
Often-heard argument pro registry: easy to write and read (assuming you're using plain WinAPI). Really? I consider the RegXXXfamily of functions pretty verbose ... too many function calls and typing work for storing just a few bits of information. So you always end up wrapping the registry away .. and now compare this effort with a simple text configuration file, maybe just key=value-like.
It depends, when you have small entries that need to read by multiple programs registry is ok, as database have locking issues, and config files are application based.
The problem happens when the user does not allow registry access, that are lots of software in the market that will show a pop up when anyone tries to modify registry and the user can cancel or allow the users. These programs are too common with the anti virus programs.
Putting your settings into the Registry means that if your user wants to move your program and its settings to another computer, he can't. Backup, ditto. Those settings are in a mysterious invisible place. I find this to be a hostile approach to one's users.
I've written numerous small-to-medium programs, and always used a .ini file. A tech-savy user can edit this file using an editor, he can check the settings in it, he can email it to a tech supporter, he can do a large variety of things that are significantly harder to do with registry entries.
And my programs don't contribute to slowing the computer down.
Personally speaking, I just don't like binary configuration of any type. I much prefer text file format which can be easily copied, edited, diffed & merged, and put under change control complete with history.
The last of these is the biggest reason not to use the registry - I can stick configuration files into SVN (or similar) with the full support given to text files, instead of having to treat it as a blob.
I don't really have much of an opinion for or against using the registry, but I'd like to note something... Many answers here indicate that registry access may be restricted for a certain user. I'd say the exact same thing goes for config files.
With registry you need to write to the "current user" to be fairly certain about having access (and should do so anyway, in many cases). Config files should be put in a user based area as well (e.g. AppData/Local) if you want "guaranteed" access without questions asked. As far as I know putting config files in "global" areas are as likely to yield access problems as the registry is.