Develop Reference

What security measures should a application's 'Check for updates' process have?

I'm creating a firmware update application (in C#, WPF, MVVM, .Net version still up in the air, but I hope to run it on Windows and Mac) that will allow the user to check for updates to both the application itself and for the latest firmware. I plan to use the common method of putting a file on a server that contains the latest version number and a URL to the files. The application will download the file, compare the versions in the file with the local versions, and download the latest files and/or update the application. Universally lacking in the 'how to's' of this method is the topic of security.
My initial thought was to put the "current version file" in a password protected secret folder, but then that seems overkill for a simple XML file. And since the user will be able to download the app from the website anyway, hiding/password protecting the URL to the application seems pointless. Even the firmware, being a binary file running on custom hardware, at first thought seems rather benign from a security perspective. But then again, I don't spend my days thinking of how to hack into systems.
So, in regards to just the process described above, what kinds of security measures should be taken to protect the server, data and user from attacks? And potentially as a bonus question, what security measures can be taken to protect the application update itself? With this, I can at least see the potential to trick the updater into installing malicious code, so a checksum to verify the updated file's integrity would be a minimum there.

Store the state of a variable in C#

I am working on a c# application that is serially encrypted when user install the application and runs application first time I ask user for key and if he enters right key. I run the application. But my requirement that this process should be one time after installation only,
I think there are two possibilities.
Store software validation state in a variable and use it to allow the running of application (I do not want to use XML,Object serialize as I have to save the state of one variable also user can remove files created by serialize).
Ask user about key while he is installing application,If he enter wrong key then he should not be able to install the software.
Can some body answer
Is there a simple way to store the state of a single variable.
Or
2. How to trigger installer manually (after validation).

Software Protection is an old and expansive topic. The current state of the art, is that it's not really possible to protect you software 100% reliable. Sooner or later, someone will crack it anyway, given enough exposure and/or interest.
Nonetheless, a lot of people and companies protect their software products and there are a number of way to this (not 100% reliably however).
It is not clear what your requirements are, from your question. Given what you've described, the simplest option would be to zip up the installer with a password. If a user don't know the correct password they won't be able to unpack the zip file and install your program.
This is usually not very practical, as the same password is provided for everyone. You want to do your own serial key validation, and you considering doing this at installation time. If this is the route you want to go for you will need to provide some script that will do validation to your installation system. You indicated, that you are using windows installer. You can user Windows Installer XML (WiX) toolset to author an installation. Given enough patience, you can built the key validation into your windows installer package. Most practical way possible is to call your validation routine that you've writen in c# from the wix package. You can use Conditional Syntax to check conditions in your installation. This should cover your option 2.
As for option 1, then whenever in the system you store your piece of information, user always will be able to get there and change it (it's their computer after all). Some people store this in registry, some in key files. Deleting these files is usually not a problem, because if user deletes them, your program will know that it should not run. However a user would be able to copy them on other machine, etc.
Isolated Storage is yet another place to store you information with .NET. Ultimately it is some deeply buried files in the file system anyway.
Once again, Software Protection is a complex topic, it's up to you to decide, what you requirements are, what compromises you can afford and what you choose to implement.
Good luck!

for something like this, i would encrypt it and store it in the registry. this is not they type of thing that you want to store in a settings file. you can check out this codeproject article on how to access the registry using C#.

Any tools to monitor the changes made by an application?

I want to monitor the changes made by my installer, and I found the processmonitor is useful, But it just get too many information, and really hard to retrieve what I need. Is there any better solution on monitoring ? Like what folder, file, registry the application created ?
Thanks !

I often used InCtrl 5 (it's old but usefull).

did you try filtering un-necessary information?
Filters in processmon are very good and correctly prints only what you need.

If you are looking for professional application, there was one I used to use: Norton Cleansweep.
http://en.wikipedia.org/wiki/Norton_CleanSweep
Its no longer developed by Norton, but should not be hard to find if you want to grab one copy.

Patch an application

I need to create a patching routine for my application,
it's really small but I need to update it daily or weekly
how does the xdelta and the others work?
i've read around about those but I didn't understand much of it
the user shouldn't be prompted at all

Ok this post got flagged on meta for the answers given, so I'm going to weigh in on this.
xdelta is a binary difference program that, rather than providing you with a full image, only gives you what has changed and where. An example of a text diff will have + and - signs before lines of text showing you that these have been added or removed in the new version.
There are two ways to update a binary image: replace it using your own program or replace it using some form of package management. For example, Linux Systems use rpm etc to push out updates to packages. In a windows environment your options are limited by what is installed if you're not on a corporate network. If you are, try WSUS and MSI packaging. That'll give you an easier life, or ClickOnce as someone has mentioned.
If you're not however, you will need to bear in mind the following:
You need to be an administrator to update anything in certain folders as others have said. I would strongly encourage you to accept this behaviour.
If the user is an administrator, you can offer to check for updates. Then, you can do one of two things. You can download a whole new version of your application and write it over the image on the hard disk (i.e. the file - remember images are loaded into memory so you can re-write your own program file). You then need to tell the user the update has succeeded and reload the program as the new image will be different.
Or, you can apply a diff if bandwidth is a concern. Probably not in your case but you will need to know from the client program the two versions to diff between so that the update server gives you the correct patch. Otherwise, the diff might not succeed.
I don't think for your purposes xdelta is going to give you much gain anyway. Just replace the entire image.
Edit if the user must not be prompted at all, just reload the app. However, I would strongly encourage informing the user you are talking on their network and ask permission to do so / enable a manual update mode, otherwise people like me will block it.

What kind of application is this ? Perhaps you could use clickonce to deploy your application. Clickonce very easily allows you to push updates to your users.
The short story is, Clickonce creates an installation that allows your users to install the application from a web server or a file share, you enable automatic updates, and whenever you place a new version of the app on the server the app will automatically(or ask the user wether to) update the app. The clickonce framework takes care of the rest - fetching the update , figure out which files have changed and need to be downloaded again and performs the update. You can also check/perform the update programatically.
That said, clickonce leaves you with little control over the actual installation procedure, and you have nowhere close to the freedom of building your own .msi.

I wouldn't go with a patching solution, since it really complicates things when you have a lot of revisions. How will the patching solution handle different versions asking to be updated? What if user A is 10 revisions behind the current revision? Or 100 revisions, etc? It would probably be best to just download the latest exe(s) and dll(s) and replace them.
That said, I think this SO question on silent updates might help you.

There is a solution for efficient patching - it works on all platforms and can run in completely silent mode, without the user noticing anything. On .NET, it provides seamless integration of the update process using a custom UserControl declaratively bound to events from your own UI.
It's called wyUpdate.
While the updating client (wyUpdate) is open source, a paid for wybuild tool is used to build and publish the patches.

Depending on the size of your application, you'd probably have it split up into several dll's, an exe, and other files.
What you could do is have the main program check for updates. If updates are available, the main program would close and the update program would take over - updating old files, creating new ones, and deleting current files as specified by the instructions sent along with a patch file (probably a compressed format such as .zip) downloaded by the updater.
If your application is small (say, a single exe) it would suffice to simply have the updater replace that one exe.
Edit:
Another way to do this would be to (upon compilation of the new exe), compare the new one to the old one, and just send the differences over to the updater. It would then make the appropriate adjustments.

You can make your function reside in a separate DLL. So you can just replace the DLL instead of patching the whole program. (Assuming Windows as the target platform for a C# program.)

Safe and Secure way to Update over Internet in C#

What would be the Most secure and Safe way to allow software to auto-update without opening too many holes to enable a hacker easy access to a system?

Have you looked into ClickOnce Deployment?
http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx
The short overview is here:
http://msdn.microsoft.com/en-us/library/142dbbz4(VS.80).aspx

I recommend not building your own auto-update, use ClickOnce if it works for you or a commercial auto-update component if not.
If you want to see what is involved I wrote a series about writing an auto-update component on my blog some time ago, the last post with links to all the posts in the series is at: http://www.nbdtech.com/blog/archive/2007/08/07/How-To-Write-an-Automatic-Update-System-Part-8.aspx

If you are going to make your own system then you will probably want to have a public/private key pair.
So, you would zip up the update.
Then encrypt with the private key on the server.
The client can then decrypt and unzip it, and then install it.
That way, as long as your private key is secure then you can ensure that the update is legit.
The only weakness here is that if someone changed the public key to some other key, then they could fool that program into thinking that a trojan is a valid update.
There are various schemes you can use to get around this, but that would depend on how much work you want to put into this.

ClickOnce auto update is all fair and well but anyone can admit that it is not the most of fashionable solution. I've recently developed a solution that requires such an auto-update feature. Here is a list of brief steps I took to deploying my very own updating service that also allows for roll-backs with 'minimal' know-how.
Add a Setup project to the solution so that the project could be wrapped up neatly in a .exe or .msi installer package.
The following is to setup a FTP server with your desired user credential that only your application knows. On the ftp server, setup a default directory for where you will put any new updates.
Your application will check for internet connection on start-up, log into your remote FTP server and check for any new files to download.
Download new updates to your client application and put them in a date-time named folder for future reference. Some checks need to be in place to make sure that you don't download the same old files.
Close the application and run the new installation. Depending on how you setup your Setup project, the installation wizard may remove the previous version completely or just update partial (patches, etc.).
Your application may have a feature to roll-back to previous version by going into the local update directory and fish out the previously downloaded files. This is where the date-time stamped files come in handy for reference.
This solution offers a level of customization that I think most Enterprise solutions will need and I found that it works very effectively for me. FTP servers are secure and reliable as far as file downloads are involved. You can find a lot of FTP download helper library on the internet so its a matter of making work the way you want and not worry too much about how it works.