Hi is it possible to prevent my .exe application on being renamed..?
here is the senario(my problem)
After i Run my program, (lets say i run MyApp.exe)
a unfriendly user suddenly for fun, renamed my MyApp.exe to ... lets say Goodtime.exe
after that. he log-off windows(xp) and then when my program is attempting to run on startup
MyApp.exe , i wont because it got renamed
is it possible to prevent this through codes?
thanks to anyone who would help =)
You can't really attempt to stop this. It's the user's computer and if they want to rename files on their computer they can do.
That is not possible.
However there is an alternative to do that.
You can set the user to have limited rights on his user account to the computer. In that case he cannot rename files in such a way he wanted. This is a restriction provided by the operating system in which only the administrators of the computer can set these restrictions to user accounts.
EDIT
What I mean here is if you are the administrator of the computer, as an alternative you can manually limit the privileges of the users who logs-in to the computer. For a better understanding on what I mean, please read the replies on my post. :)
You can place your application somewhere the user is less likely to go and rename it, like in the program files folder. But you can't stop them actually renaming the application.
If the user isn't an administrator on that machine they won't have permissions to rename files in the Program Files directory by default. One would hope that unfriendly users aren't administrators on the target machine (If they are, they can do a lot worse than renaming one application file).
You can check what name the executable has when it's being run.
But you cannot prevent a user from renaming it.
You might consider using clickonce publishing. For the life of me I can never guarantee I can find the ruddy application after installing it with clickonce so that might stop your friendly user messing with the app? ;-)
Here is some info on ClickOnce Publishing.
In essence, write an application, right click the project/solution, choose "Publish", then follow the wizard.
It won't guarantee the user won't be able to rename and mess with the files, but it'll make it harder.
By permissions way as most folks here explained.
Stupid and waste method is to have a daemon (Service) running accessing this file all time since system boot. That way system wont allow this executable to be renamed unless this daemon is stopped.
you can prevent renaming or moving your exe file while it is running.
Open the exe file within your exe file for reading and deny writing.
Keep this file open as long as it runs.
Related
I want to give my application data folder kaspersky antivirus like security. Where I can add a folder but cant change any content or create any file. I even gave the current user full control security privilege but it just does not working only for this kaspersky data folder. I can only modify data when I turning off "Self protection option". I just want to give same type of security into my application data folder. I know how to give security to my folder or file but dont know the option by which option kaspersky doing it. If any one have any idea please share with me. Thanks.
Much of what you're looking for can be accomplished with NTFS directory permissions. Just deny Everyone (and SYSTEM, if you're feeling lucky) the permission to create files in the folder or write/append files in the folder. Make sure the permissions apply to "This folder only" and "Files only" respectively, though, or your folder will probably become rather useless til you remove said restriction.
The permissions you need probably won't be obvious. You'll need to be in the advanced permissions dialog in order to set them.
Anyway, you don't really need C# to do it. You could use code if you really wanted to, but you'd do it the same way you'd set any other permissions on files and folders.
Finaly I got it ... kaspersky protecting its folder by starting a Service. For that reason the Unlock software unable to track the process handle.
So I have been writing to
Environment.SpecialFolder.ApplicationData
this data file, that upon uninstall needs to be deleted. I am using Innos Setup to build my installer. It works great for me. So my data file hangs out in the above path and I do that cause when I used to try to write it to
Application.ExecutablePath
certain boxes I tested it on would throw a nasty error at me trying to write data there. I do research and somehow its not always writable and its how i came up with the Environment.SpecialFolder.ApplicationData
That is why my data file now resides in the SpecialFolder.ApplicationData. Trouble is if the user uninstalls and reinstalls I need that file gone. It might be a short coming of my knowledge of Innos but I cannot figure out how to know where that file will be to tell innos that.
So then I thought I had a clever solution: Innos can run a file when its done uninstalling, so I had my program create this file "uninstallData.bat" that says:
del "the file in my special folder application data path"
and I wrote it out to drumroll
Application.ExecutablePath
(yes it was a while in development and I had forgot it was't doable.)
So of course I am back to square one, I need to write a file to a path Innos knows about {app} and I need it to be able to delete my data file in the SpecialFolder... i don't care how I do it i just need that file gone.
Are there other Environment. or Application. approches I have missed? Maybe somewhere that is viewable by an uninstaller AND can be written to?
As an aside, I am not sure why my box I develop on can write to the application folder no issue, but it cannot on other boxes... weird.
Any input would be great sorta lost as to how to crack this nut.
The environment location is in the user profile. If there are multiple users on the machine, and they all run the application then a copy of the file will be in each profile.
The path also depends on the OS.
Regardless, the current user's app data location is pointed to by %APPDATA% and %LOCALAPPDATA%. These Windows environment variables should be available within Innos.
Appliccation.ExecutablePath is not writable per standard defintions - the program files folder should never be manipulated by running applications. Ther area number of special folders for that. Nice that you finally found.... what is properly documented by Microsoft for a LONG time now (minimum 10 years).
I suggest you get a proper installer - WIX comes to my mind. Your problem is totally unrelated to C# - it seems to be totally a "crappy installer" issue. Or provide a PROGRAM (not bat file) to run at uninstall. What exatly is your problem there?
I currently store a serialized XML file in the application directory that contains all changes specific to the program operation (not typical system or user configuration). Weeks ago, we started running into problems where it would not save correctly (read my previous question about this).
Long story short, we finally discovered that Windows 7 (and sometimes Vista) has an issue with writing into the application directory (specifically anything under Program Files). Now, if this were a normal configuration file I would simply store it under the user's APPDATA folder, but it is not normal. We run this on our own instrumentation, and misconfigurations are 99% of the reason customers have issues running our software. So we need this file to be accessible such that they can easily find it and email it to us. Appdata is hard enough for experienced users to find, much less very non-technological people.
We've also tried running it as Administrator, and making folder permissions wide open (we have control over every computer it runs on; it will never run on some random person's machine). But, these sometimes work, and sometimes do not.
The worst part is that when I write the file back out, it doesn't even throw an error; it simply writes it to some temporary directory that expires at some unknown point in time. Weeks later, our user will have an issue, and the configuration file is all messed up.
So, my question is where should I be storing this file, if not in Program Files? Should I just put it in APPDATA anyway, and make a small utility that emails it to us automatically in case of a problem? Or can I leave it in Program Files, but change some specific permission or registry key to allow it to operate normally?
It depends on whether or not the user needs to edit the file directly. If not, you should put them in %APPDATA%, which you can access via:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Otherwise, you might put it in My Documents:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
Either way, putting it in Program Files is not a good idea. As you discovered, there are permission issues, even if running as Administrator.
For those users, you could build a button in that would open this directory. You could put it in an inconspicuous place that you could later direct them to.
For users that have an email client on their box, you could have a button that would create a new email with subject and automatically attach the file to the email.
Is it possible to delete-protect a file/folder using Registry or using a custom written Windows Service in C#? Using Folder Permissions it is possible, but I am looking for a solution that even restricts the admin from deleting specific folders.
The requirement is that the administrator must not be easily track the nature of protection and/or may not be able to avert it easily. Obviously all administrators will be able to revert the procedure if the technique is clearly understood.
Like folder Permissions/OwnerShip Settings can easily be reset by an administrator. SO that is not an option.
Folder protection software can easily be uninstalled and show clear indication that a particular folder is protected by some special kind of software. So that too is not an option.
Most antivirus programs protect folders and files in Program Dir. Windows itself doesnt allow certain files such as registry files in c:\windows\system32\config to not even copied. Such a protection is desired for folders which allowse to read and write to files but not allow deletion. Similar functionality is desired. The protection has to seemless and invisible.
I do not want to use any protection features like FolderLock and Invisible secrets/PC Security and Desktop password etc. Moreover, the solution has to be something other than folder encryption.
The solution has to be OS-native so
** that it may implemented **
pro grammatically using C#/VB.Net.
Please help.
Obviously all administrators will be
able to revert the procedure if the
technique is clearly understood.
Please don't tell me your solution is going to rely on security by obscurity...
Anyway, if you don't trust people with administrative rights on the server not to do the right thing, then I suspect you are trying to solve the wrong problem. The problem you should be trying to solve is restricting access rights, and training those who have elevated privileges.
Well, i don't know what you are actually trying to achieve, one option to prevent the deletion is to keep the file open in write mode from your program. nobody will be able to delete it as long as it is open. This is why you are not able to delete windows registry files.
But this does mean that nobody else will be able to write to the file.
I am trying to write a test which, in it's fixtures Setup, it backs up a file and deletes the original, runs the test without the original present, then in the teardown, restores the original from the backup. The file is located in my %ProgramFiles% folder. I get an UnauthorizedAccessException on the fileInfo.Delete() statement. I have no problem deleting this file from another test project on the same machine that is not running from the Resharper Test Runner.
I can't move the file to somewhere else - it's ssapi.dll, an installed dll for Visual SourceSafe. (Yes, I'm doing something invasive in a Unit Test.)
It's the same user (me) for both ways -- I checked it via Task Manager. My user account is a member of the local Administrators group. What other factors are there which determine my "Authorization" to do something with a file?
RESOLVED: Though it doesn't answer my original question (which I'd still like to know the answer to), I have found a workaround for my testing purposes, using the System.Security.Permissions framewok, doing a Demand for FileIOPermissionAccess.Read in the app (non-test) code which requires the file (for an Interop call), and a Deny for the same in the test of that code which requires a scenario that that file is not there. This should work for now (and I love having learned a bit about the System.Security.Permissions namespace)!
Not really a solution, but I'd consider fixing this problem from a different angle.
You could perhaps consider changing the directory to %AppData% (you might need to make this change for you main application also).
It might solve your problem and also will see you well when you move to Vista, since UAC could stop you (or the application user) from using the %ProgramFiles% directory.
It is possible that ReSharper is running its Test Runner as a separate process, and that separate process is not using your Windows identity but, instead, another one with lower privileges.
You might be able to verify this opening Task Manager and checking Show processes from all users.
You can probably fix this by giving your user account full access to that folder.
Navigate to the folder in windows explorer. Right click on the folder and select properties. Select the security tab, then the Edit button, and add full control for yourself. Yes - I suppose it's a potential security issue, but you have to change the files in that directory, and you seem to know what you're doing, so it should work.
You could activate auditing for the file, and check the error message in the event log. Note that you have to turn on auditing in two places, once under Local Security Policy/Local Policies/Audit Policy and once on the file itself.
This would not solve the problem, but would at least help diagnose the problem.
Are you running Vista or Server 2008 with UAC turned on? If yes, this might be the cause - the test runner process might not be in "elevated" mode.