Good day, is there any option how to create a box, which cannot be seen from Windows? I would like to insert some files into this box. These files should be accessible only through my application, not from Windows. Thank you in advance.
How many files and how do you need to access them? If they are only for reading and you don't have too many, you always have the option to store them as a resource in your project. Have a look at this link on MSDN on how to store various file types directly inside your assembly.
NOTE: If you are planning on storing passwords or security-sensitive data, you shouldn't use this approach.
Another alternative would be to store you files inside a database. If you were to use something such as SQLite (here is the .Net data provider), Windows would have access to the database file, but not to the files contained within the database (which could be encrypted). Depending on your data, you'd have to store the file information as a binary large object (blob). See here for an example of how to do this.
It depends on the layer of abstraction you want. All files created by an application are at some level accessible by windows, however, you can mask the content of these files (i.e. encrypt them).
Generally speaking, you could still store the files in a folder, and apply encryption. Here's the msdn article on the point. The other issue is where do you store the key used for encryption.
A simple solution is to hard-code the key in some variable. However, if the assembly is decompiled, the key will become apparent. On the other hand, if you want the user that created the files to begin with, to be the only one to access the files, then you can use the Data Protection API.
If your question is how to the hide the box then you can set the "Visible" attribute to false no matter what control you are using for this "box".
if your box does not include a lot of files or not large file, you can try save it in a compress file like .zip and add a password for it. also add the hidden attribute on that box.
Related
I'm trying to create software that will add a computer to an Active Directory domain. One criteria I need to meet is the machine must be added to the proper OU. In order to do this I have a set list of site locations with addresses (this is how we determine OU). This list is currently in the form of an ACCDB file, and I want to include this within the application as the Access list will not be changed.
Everything I see wants the DB file to be connected to in a different location such as server or on the local machine. My preference is to use the DB file as a reference or something inside the program's .exe file itself. I may be missing something horribly obvious, but it's been messing with me for a couple days so I'm reaching out for help.
To clarify, this software MUST be self contained (no installer). It must also be able to determine the proper OU to join to the domain (no access to shares until the PC joins the domain). It must also be user-friendly enough to avoid mistakes, meaning I want to avoid copying distributing multiple files that must go to a correct location. This is why I want to embed the ACCDB file into the application for on the fly use.
Things get much easier because this is static data. You don't have to worry about persisting this data, reclaiming changes into your program, or users accidentally deleting something, etc. You will be able to just use an embedded resource in your application. In the link, follow the examples using the image file. Text file examples will corrupt your database.
However, there is still a trick to doing this. The problem is the Access engine included with Windows will not be able to open the database as a resource, and so you will need to save this file to the local hard drive. The good news is its not as bad as it seems, because your program can do this as needed, and make sure it's right, rather than asking the user to put a file in a specific place.
As for where to put the file when you extract it... the safest and best place is the Application Data folder. You can easily get the path for this folder by checking the results of this call:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
This will give you a path where standard privilege users do have write access, no matter which user.
In summary:
Embed the ACCDB as a resource.
When your program runs, get the Application Data path using the Environment object.
Open a FileStream for writing to a file based on the path from #2
Open the embedded resource as a Stream object in C#
Copy the stream from #4 to the stream from #3. Make sure to use a mechanism intended for binary data, rather than text.
Close/Dispose your streams, so no locks remain on the file. This is as simple as putting using blocks in the right places.
Open a normal Access connection to the file you just made, using any of the thousands of tutorials or examples available on the web as a guide.
In this way, you only need to distribute the final .exe file, and users won't need any special permissions to use the database. You don't have to worry if a user deletes your file; it's still embedded in the application, which will recreate it if needed every time it starts up.
The downside is a clever user may be able to manipulate the database to end up in an undesirable OU. If you need to worry about this, you should consider having the program check a web service, rather than using embedded data. Anything you embed can ultimately be altered by an end user. A web service is also nice because you can update your mapping data as your organization evolves, without needing to rebuild or redistribute the program.
I am looking for a few pointers to reaching am adequate solution to a problem/feature I need to implement/rectify in my asp.net mvc application.
My application is a LAN only interface that is run over a webserver. In this application there is a page that displays a bunch of files/folders.
I need to be able to store a set of attributes\properties about these files, and those props\attrs need to be independent of their location on the fileserver. This is my main issue, as I could easily link them to the db with the path as the primary key, but alas then as soon as the file moves their link to the db would be lost.
The types of files that need to be displayed unfortunately could be anything. .txt, .exe, media etc etc. So that provides a limiting option also from using something like the tagsharp lib.
One approach i was considering was simply storing a key somehow in the file itself, or with an ADS ( i have no experience in doing this, but am presently trying to research its potentiality).
Does anybody have any experience with this issue, and can recommend a simple approach. I am hoping i do not need to implement an ADS approach as what ive been reading so far is a little bit over my head and im not sure C# will handle the streams adequately for my needs.
Opinion based. Proposal anyway: what about an additional file which is found by a naming convention?
MyDocument.doxc
MyDomument.docx.properties
MyMovie.mp4
MyMovie.mp4.properties
When moving / renaming files, make sure you move / rename the properties file the same.
First of all thanks for taking a moment to reply.
I had considered the possibility of using a separate file. The problem is that the users of the filesystem ( which may or may not include users of the lan application ) need to be able to move/copy files independent of db application.
Therefore if a user moves a file in windows explorer, I need it to automatically move those additional properties with it. Unfortunately I cant rely on users to move those additional files on their own volition, and I cant ask users to only use the application to move files ( if i were to generate code for the program to do this ).
I'm writing an application using windows form and c# 3.0. I was wondering if there is a recommended way of persist data across time. However, i do not want to touch the machine it is running on, as a result, i would like to store the data in the binary executable (preferably, due to the need not clutter up the user's folder with random config files).
So if anyone have any ideas of how to do this, it would be much appreciated!
Jason
If you're looking to store configuration information - app.config or a settings file is probably the way to go.
If you are storing user data - you should really allow the user to control where it is saved - and prefer the \User\Username folder on the machine.
As for what format to store it in ... you can certainly use something like SQLLite - but there's nothing wrong with XML either, if you're not storing true binary data. .NET offers a number of APIs to transform object graphs into XML representations - which you may want to look into.
If you don't want to store anything on the local user's machine, you probably want a network database - or a webservice - to which you upload the users data. Just make sure your users understand this - many don't like their private data being sent somewhere on the web without their consent.
You really don't want to go about modifying the executable file. Many virus scanners quarantine executables that are constantly changing in content or size - as a way to proactively prevent viruses and malware from infecting the machine. You don't want to go there.
Do not modify the executable. Adding a single SQLite database is a much better solution.
Isolated storage is another alternative.
Doesn't clutter install directory
Doesn't cause issues with AnitVirus software
Part of the OS including .Net objects, don't need to install anything else
Already works with the Windows security model
Exists on a per user basis, so saved settings are separated for each user
Can serialize/deserialize obects directly into it
SQLite is what your looking for and is compatible with c#
If you dont want to store data in a SQLite db on the end users PC you could call out to a web service on another server which stores it's data in SQL Server or something else.
I don't believe a windows form project can modify itself like that (I've tried to find a way to do this myself some time ago). Some form of hosted application such as a silverlight application (where the application is essentially a zip file) may be the way to go. Silverlight applications would require the silverlight plugin though (and I'm still not sure if a silverlight application is allowed to modify itself).
I would think that one config file of some sort would be prefereable, and not leave much clutter.
One way to ensure that your applicaiton is entirely self contained would be to use a program like ThinStall after you have compiled the project. This virtualises the application and could give it it's own file system or registry internally to the .exe file.
One way for an executable to change itself would be to put another executable inside it, (embed as a resource then extract it to a file when needed). This executable could then modify the first, however I don't think ther'es any framework for it to do that, so it would require knowing excatly what to change and where.
I'm programming a fairly simple application which I want to cut to just one simple EXE file + some data storage (XML for example).
My question is regarding configuration files. Where to put those files? I saw a few applications that have just an EXE file (uTorrent, Media Player Classic - I can use them without any installation), but they store their config somewhere else. How to achieve this?
How would you approach such situation? Is it better to try to achieve the thing I described above, or simply use a configuration file and data storage in the same directory as the EXE file?
Creating or using a file in the same folder (or in the App_Data) is pretty standard practice.
You use an installer like Inno Setup (free) to create a single exe installer (http://www.jrsoftware.org/isinfo.php)
If you want a DB rather than XML, have a look at SQLite (http://www.sqlite.org/) a file based DB or use an MS Access DB.
I think you want to take a look at Application Settings. This is an API which allows you to save user or application settings using a strongly typed API. Under the hood the settings are stored via XML serialization.
This API works with virtually every type of .Net application including low permission Click Once versions. It does the work of finding the place on disk appropriate for storing the data and completely hides it from you. It also has a nice GUI integration into Visual Studio.
EXE-only programs store their data either in the Windows Registry or in the user's Application Data/AppData folder. Although this may appear cleaner at first, it just hides the ugliness of scattering all your data around. I would suggest just going with a simple XML/INI/text data file that is generated when needed and easy to migrate.
Please see: WPF/C#: Where should I be saving user preferences files?
You could use the app.config file for storing your configuration. For the data, I would sugest something like db4o or SQLite.
Edit
This tutorial can show you how simple is to use db40 to store and retrieve your data.
Do not forget Isolated Storage. It gives you a place to read and write files to without the need for you to specify a location. Sometimes it is the only way sandboxed applications (like Silverlight) can store user or machine specific data locally. See here for an example.
I would store them in the same directory. That just seems easier to me, at least that's the way I always do it.
What's the smartest way to prevent a textfile (e.g. xml) from being edited by a user?
I need to make sure that the file in which I store the usernames and there privileges for the desktop application can't be simply edited.
Maybe I can generate a certificate of the file and the desktop applications checks this?
I'm using C# in a WinForms app.
You could use File system permissions to prevent editing.
You could use encryption to make editing difficult
You could get a hash value for the file to detect editing.
I think encrypting the file, then decrypting it will be easiest. Though users might still be able to read the contents of the file if they're smart enough. e.g. reading the plain-text from memory
The simplest way is probably to use a database with username and password authentication.
The smartest is to encrypt it so that the data is not available to them.
However, if a user truly wants access to a file on their machine, they will get it. You can make it so that they cannot read anything useful or make useful edits, but if they want to, they will be able to edit the file.
Since your aim is to store users' privileges directly in an XML file, you need a level of security beyond just preventing users from editing the file. Even if you could (hypothetically) impose some restriction at the operating system level against editing the file, any administrative user could just edit the file on a different computer and then overwrite your protected version.
Thus, you have to assume that users can edit the file. The only recourse you have is to be able to identify when they have, and ignore their edits.
The approach you suggest of creating a certificate sounds exactly right. You could either compute a hash for the entire file, or could do so on a user-by-user basis (whichever makes most sense in your context), in either case using a private or secret key to ensure that someone editing the file cannot simply recompute the hash.
IMHO you can not guarantee no one can edit it, but you can encrypt the file to secure the information.
you can not guarantee as any one can boot the machine using disk start up for example and edit the text file simply.
Personally I don't think XML is the appropriate format for storing secure information in this case. The whole point of XML, compared to binary formats, is that it is human readable/editable. Use some kind of encrypted binary format with a known hash/crc that tells you if it's been interfered with if you want total security.
You can use cryptography, but use the DPAPI built into Windows as you will also have to store the encryption key safely, which again is another hassle.
The benefit of using DPAPI is that it uses a key unique to the user or computer, and is never disclosed, even to the programmer! But if you move the file onto another user's profile or computer, it will be unreadable.
If you MUST keep that data in a XML textfile you could consider digitally signing it by your application every time it is modified and checking the digital signature when you read the file.
More details on how to sign XML file and how to verify signature.
But I think it's better to just keep that kind of data in different formats - database, encrypted file, application properties...