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#.
Related
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.
I want to restrict the use of any exe file to specific number of iteration, lets say 10. After that limit is reached user shall not be able to run the exe file, or on running the exe file for the 11th time, he / she shall be greeted with a message "Exceeeded Trial Run" .
This is very much possible in C, like this - http://www.gidforums.com/t-22362.html
An example to accessing the PE header is here - http://code.cheesydesign.com/?p=572 , but it checks the timeststamp, whereas I want the number of occurrences the application has been launched .
I dont want to change the registry.
All suggestions are welcome.
Barring the existing comment about whether you should do this or not, the only other option besides not modifying the registry is to save something to a file in an encrypted fashion. Installing the app or exe would create the file and each launch of the application would decrypt, update, encrypt the file. But even then, that is subject o a user changing things without you wanting it. Security through obscurity is always a pain.
The surest way to prevent a user from exceeding some number of trial runs is to issue them a registration code (a GUID would work well) and then keep track of the remaining trial runs on your own database server. It would be exceedinly difficult to guess another user's GUID and impossible for them to hack the trials remaining (short of hacking into your server).
When the application runs, it could simply hit a small web service that would return the status of the software. If the web service cannot be reached, then the application would ask the user to connect to the internet and try again.
Short of that, there are not many options that could not be easily, easily hacked. Even if you encrypted the number of trials left, all the user would need to do is copy the file to somewhere else, then when they've reached their limit delete the original file and replace it with the copy... repeat ad infinitum.
The nice thing about this model is that, when the user purchases the full version, all you need to do is update your database and grant them full access.
If you wanted to let fully-paid users continue using the software without needing to connect to the internet, then on the first connection to the web server after paying the software could store a key file somewhere confirming the user's paid subscription. You could even create a hash based on the user's registration number to ensure that one user cannot use another user's key file.
If the subscription is annual, then a paid user's application could requery the server whenever an internet connection is available and recheck to make sure their registration is still valid. Or your key file could contain some encrypted date at which it would no longer be valid.
EDIT: A trial run based on a date would be much easier to implement. You could provide a key file with an encrypted date. Since the date would not change, the user would have a much hard time hacking the key file. Even if they borrowed or stole someone else's, they'd only get an extra week or two (depending on your trial period) before that, too, would become invalid. The difference is that a date based key file is static, making it much hard to spoof.
Now, another alternative is to combine the two approaches. You could have a countdown with an encrypted date in the same key file. That would ensure that, even if the user attempts to copy/replace the key file, the trial would still eventually end (maybe 10 uses/1 month, whichever is reached first).
I'm writing my own serial number verification/protection for a software I wrote.
Assuming the serial number verifier is using pattern matching...once the serial number is verified, how can I change the program itself so that it doesn't ask the user for a serial number any longer?
I really don't want to have to create a separate license file. Is there a way to embed this within the program itself? Or is the registry the only other option (besides online verification, etc.)
You shouldn't really attempt to edit the program itself - it'll break signatures/strong-naming, the exe/dll file will almost certainly be locked, and even if you shadow-copy: many users won't have permission to edit it in program-files (or as click-once).
Something external such as a license file or registry setting seems appropriate (unless you want to build the app at your server per-client).
Is there a way to embed this within the program itself?
If you're hinting at modifying the assembly, then it's possible*, You'd need to have two assemblies - one that's currently executing and one that you're modifying - because the executing assembly will be locked by the file system. And you'd need to reserve enough space to store whatever new value you intend to inject.
*To prove this to myself, I created a small executable with that simply writes the value of a string, and used a hex editor to alter the value of the string.
You'd need to be quite smart about what change you made, though, otherwise registering the software and then simply copying the modified binary to other machines would circumvent your registration process.
Storing registration details in the registry is probably a far easier solution.
Personally I always generate a unique key from the machines hardware and store this in the registry.
Here is a simple example of a unique key but you may need to expand it if you want separate keys for different versions of the software.
http://www.vcskicks.com/hardware_id.php
You could save the serial key that was entered to a file or registry, and just authenticate it whenever the user starts your 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.)
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.