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).
Related
I want to prevent executable being copied to another PC and thus i need to somehow save information inside my EXE file about that it was already used somewhere else on another PC.
Can i embed small piece of information like user's hard drive number into my EXE file so this information would be available when this EXE is copied to another PC?
I thought maybe there is a way to read and write to some resource file embedded in an EXE file but i presume that resource file is read only and if so is there is a place inside EXE file where i could keep information which i need?
You're fighting an uphill battle this way. It's possible to create a home-grown licensing scheme but be prepared to do a lot of work (I did it, so I speak from first-hand experience). Just some problems to solve:
If the hard drive fails and needs to be replaced, your user won't be able to use the program. Every time this happens, you'll get a support call with an angry user.
If the user runs your program inside a virtual machine, the hard drive serial number won't be unique - anyone can clone the virtual machine and now your program can be run on another machine.
Hard drive serial numbers can be changed - they don't come directly from the hardware.
What if the hard drive is a removable drive? Your user can run your program from a removable drive and then keep moving it to different machines.
Even if you get it done, how do you protect the license information from being modified?
If you really want to license your product, look at existing licensing products - they're not cheap but they already did the (considerable amount of) work that's necessary to have any kind of reliability.
Even if you only want to have minimal protection, consider this: you'll have to do a lot of work to get even minimal security of your secret token (whatever that is). If its security is minimal, then what's the point of you even doing all that work? If all you do is force people to put in a meaningless serial number, you'll just annoy your honest customers. If anyone wants to steal something that's not well protected, they will steal it. All a 'simple' protection scheme does is annoys your users and gives you a false sense of protection.
I ended up using Reprise RLM - I'm not associated with this company but I had a good experience with their sales and support people and their product worked well in the testing scenarios.
Ok, I analyzed all the variants that were proposed and decided that in my case it will be better to develop my own copy-protection system, due to the reason that I am an indie developer and not going to work with extra large applications.
Just in case, somebody faces to the same issue - here is the algorithm (well, one of them):
User starts APP1.EXE
APP1.EXE reads itself to some variable and adds HDD serial number to the end of it, e.g. HDD serial number - when you add something to the end it does not break EXE file and you do not have to worry about PE headers
Unfortunately, EXE cannot save itself in runtime so it saves its copy called APP2.EXE with the information about HDD
When APP2.EXE is saved APP1.EXE starts it as a separate process via Process.Start() and terminates itself
Now APP2.EXE is running and has the same content as APP1.EXE + HDD serial number so we simply write all bytes from APP2.EXE back to APP1.EXE, close current process and start APP1.EXE again
From now on APP1.EXE is running and have all needed information about current HDD so each time user starts APP1.EXE it compares HDD number at the end of its content with the actual one on user's PC, if they differ - terminate the process
Delete APP2.EXE so that user would not realize how these files exchange information about his HDD.
Useful info about self-deleting EXE can be found here :
http://www.catch22.net/tuts/self-deleting-executables
http://buffernow.com/selfdelete-executable-in-c/
P. S. I know that it is like a huge hole of security (I will not mention all of them) but implementation of this algorithm took just 20 lines of code in C# and was moved to a separate DLL which I can use everywhere and it works. There is NO any registration in the algorithm above and user can simply take this app and use it and I am sure that ~ 80% of them will not realize how this app is protected from copying.
Link to implementation : https://bitbucket.org/artemiusgreat/examples/src/ef7b60142277?at=master
I'm trying to make a system that basically allows me to shove a DLL in an installation and some code in an exe that allows me to release all of my future programs as beta releases for a while.
Now the problem is of course if I'd want to do that, i'd need to choose until when the program is valid. Which is fine, except that by changing your system clock, you can easily bypass the system.
Now, I'd like to hear what people generally do for something like this.
I've been trying a few approaches such as contacting a site to give the timestamp and compare that, which would be fine if it didn't always increase the program start time by over 9000
and and the fact that people would then not be able to use it if they're not connected to the internet.
Any suggestions are much appreciated.
This is not 100% guaranteed solution but it will take you there
You will need to implement these things in the config file (Why Config file, because if user deletes it your app won't run). Also encrypt all the following data.
Store the Date and Time on which application ran.
Store the exact amount of time for which application ran.
By doing so you can avoid:
If user change the computer time, you will come to know that, as your app is logging Date and Time, it might overlap the earlier time, say user ran app on 6th and 10th of month, and then he reverts date to 7th, you will come to know about it.
Secondly user can change the date on every run to single date, in that case the total duration used will help you. Say user set date to 1st of month every time he runs it, in that case, he can use app for 24 Hrs only not more than that.
Other options like
Checking time from External Server (Flaw: Requires internet access)
Storing Time in Registry (Flaw: User can easily manipulate registry)
Hope this helps you.
If your software can access some network share on some local server/nas, you can create a new file on this network share, and this file will have a creation time set using the clock of the server/nas, so you can compare the time set on the server/nas to the time of the local computer.
Or you can also save somewhere (a file, in the registry, in a DB) the last time of the last execution, and if the clock go back in time, then you can lock the application and require further assistance :-)
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#.
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 have written a program for one customer. I implemented a licensing method for him (signed XML files). This customer wants the application to be installed only once on his customer's PC, and wants me to "secure" this ... especially because his licenses are time-limited. Those PCs do not have internet access.
I told him this is absolutely stupid and it's not able to secure this kind of thing (VM eg.), but he wants at least a little "security".
Now I am looking for a good place on a Windows machine that is writable by every user (no UAC), where I can store some "secret" data (e.g. last time used) so the user can't just turn back time on the PC.
He should also not be able to just delete the application folder, set back the time, reinstall and use the program, nor should he be able to do this by deleting the actual user and using the software from a new created one.
I know this is something really really stupid, but my customer insists so...
I tried finding some places but with no luck so far.
Do any one you know of some directory that meets these requirements?
Maybe the registry would be better? Ya, it's a terrible requirement really. Maybe you could encode the installation date into the XML file as part of the installation process, obfuscate it some way perhaps.
I pretty sure process monitor would destroy this no matter what directory you pick, so just use a normal application data directory. There isn't a magic directory that will somehow help you hide the fact that you're reading/writing from it during the license check, and as long as you've told the customer how not-secure this is I wouldn't spend much time on it
In the past when I've had similar inane requirements I've used the registry. Here's what I do:
In an embedded resource, give the program the public part of an asymmetric key
When running, check for a few registry entries (detailed later). This is the first run, so they'll be absent
Send to a central licensing server the CPU serial numbers (and
possibly product serial number)
Server verifies that the CPU/serial has not been seen before,
generates an expiry date/time. If
they have, pulls up the old expiry
date/time. If expiry date/time is
passed, returns nothing, otherwise
returns old date/time
Server sends the client the expiry date time and all of the
information (expiry, CPU, serial)
signed with the private key
Client stores the expiry date/time and the signed data in the
registry
On subsequent runs, the client takes all of the information and
compares it to the signature. If
the signature is invalid, registry
information is deleted
So now, if the user runs the program after the window, the information is deleted, server will refuse to re-auth. If they try to copy to a new machine with registry info, signature check fails. If they install on a new machine, re-auth fails (due to different CPU serials). The only thing you can't really cover is if they always adjust the time, though you could find the time easily with a NIST check.
Downside is it depends on the internet and you need a licensing server.
Ok. I took a little of everyones suggestions :)
I am putting the file unter {sys}{My-GUID}\
and granting this directory full-permissions for everyone in my setup (innosetup)
Think this should be ... ok ... somehow :)
And # NullUserException : He is paying my car ... i can't fire him :)
Thanks for your answers