We would like to be able to create intermediate releases of our software that would time-bomb or expire after a certain fixed time or number of uses that would not easily be manipulated. We are using Visual C++ with mixed native and managed assemblies.
I imagine we may need to rely on a registry tag but this seems to be insecure.
Can anyone offer some advice on how to do this?
I was working on a "trial-ware" solution a while back and it used a combination of registry keys, information stored in a flat-file at a certain position surrounded with junk data, and then also had an option to reach out to a webservice that would verify it back with the software creators.
However, as FrustratedWithFormsDesigner stated, there is no 100% fool-proof way to do this. There is always a way that a hacker can get around whatever precautions you put in place.
If you are using a database for the application, then it might be better to store a install (datetime) and a numberofusers (int) and then make code that checks those fields when the program is starting / loading / initing. If they are past a certain number or time (this could also be in the db) then exit the program.
This is very hard if not impossible to do in a foolproof way. In any event, there's nothing to stop somebody removing and reinstalling the software (you do support that, right?).
If you cannot limit the function of these intermediate releases (a much better incentive for people to move to official bits), it might be more trouble than it's worth to implement such a scheme.
Set a variable to a specific date in the program then every time the program is run access the system date and check if that date is equal to or greater than the specified date. If true then start the expiry process and display a message or alert panel to the user.
Have the binary download a tiny bit of code on startup from one of your servers.
Keep track of the activation counter on the server, when the counter reaches the limit, return a piece of code that displays the 'sorry!' message.
You could deploy it as a ClickOnce application with a certificate that expires at a certain date. If I recall correctly, the app will err on startup after that date.
A couple caveats:
The only option for the user may be to uninstall the app, which is a jerk move.
You will end up maintaining a ton of different deployments.
It will be a shock to the user as it will just happen without warning.
Related
Suppose for an application which will never receive internet connection during its lifetime, how can you prevent the piracy of the software?
There cannot be a single product key requirement during installation because, once installed legitimately anybody can copy the installation and re-distribute it.
So every time the application runs it should check for something and crash if the check fails.
Now what could it possibly check?
Initially I thought keeping an encrypted binary file will do the job, but as answered here, that seems a negligible prevention.
Any hacker can modify the executable so that instead of crashing when the check fails it should continue running.
So no matter how difficult the check is, the cracked application will always run.
Now I cannot see any possible solution to this problem.
PS: I am a single independent developer who is developing productivity software with very low charge. Seeing this question I believe I just have to let it go. Sigh....
EDIT: I would like to thank all the contributors in this discussion in letting me know the grim reality...
What I understand now is that you are indirectly submitting the source code of your application in the form of the target executable. Its source code can be modified by anybody using a debugger, thus ANY method of preventing piracy through source code of your application is useless. The only possible solution to this problem is to keep your legitimate customers happy by providing them services (apart from the software) and keep your price below their expectations.
I was think of solving this problem for past 3 days and now all seems worthwhile but still learnt a lot in this process, which I wouldn't have otherwise...
I ha
The only standalone thing I've seen that is semi-effective is hardware keys that come with the boxed software. They used to attach to a parallel port or a serial port and get checked when you started the program.
AutoCad and similar programs used to do this, but it is a BIG PAIN for your customers. Any time it doesn't read it, or a key goes bad, customer productivity suffers. It hurts your legitimate customers far more than those who end up pirating it anyway, and a sufficiently motivated pirate can make a VM that will overcome this. Modern versions of this use USB.
My recommendation is to trust people. Upon install, make them click a "I promise I paid for this" button and be done with it. If they click "I didn't pay for this" show them a small paragraph about how to help keep good software coming and prevent customer-harming DRM schemes by simply contributing to the success of good software authors.
You could generate a unique copy for each user, create a database, and check it agents copies you find online if you like playing the biggest game of wack-a-mole ever.
I'm creating a django website with Apache2 as the server. I need a way to determine the number of unique visitors to my website (specifically to every page in particular) in a full proof way. Unfortunately users will have high incentives to try to "game" the tracking systems so I'm trying to make it full proof.
Is there any way of doing this?
Currently I'm trying to use IP & Cookies to determine unique visitors, but this system can be easily fooled with a headless browser.
Unless it's necessary that the data be integrated into your Django database, I'd strongly recommend "outsourcing" your traffic to another provider. I'm very happy with Google Analytics.
Failing that, there's really little you can do to keep someone from gaming the system. You could limit based on IP address but then of course you run into the problem that often many unique visitors share IPs (say, via a university, organization, or work site). Cookies are very easy to clear out, so if you go that route then it's very easy to game.
One thing that's harder to get rid of is files stored in the appcache, so one possible solution that would work on modern browsers is to store a file in the appcache. You'd count the first time it was loaded in as the unique visit, and after that since it's cached they don't get counted again.
Of course, since you presumably need this to be backwards compatible then of course it leaves it open to exactly the sorts of tools which are most likely to be used for gaming the system, such as curl.
You can certainly block non-browserlike user agents, which makes it slightly more difficult if some gamers don't know about spoofing browser agent strings (which most will quickly learn).
Really, the best solution might be -- what is the outcome from a visit to a page? If it is, for example, selling a product, then don't award people who have the most page views; award the people whose hits generate the most sales. Or whatever time-consuming action someone might take at the page.
Possible solution:
If you're willing to ignore people with JavaScript disabled, you could choose to count only people who access the page and then stay on that page for a given window of time (say, 1 minute). After a given period of time, do an Ajax request back to the server. So if they tried to game by changing their cookie and loading multiple tabs at once, it wouldn't work because they'd need to have the same cookie in order to register that they'd been on that page long enough. I actually think this might work; I can't honestly see a way to game that. Basically on the server side you store a dictionary called stay_until in request.session with keys for each unique page and after 1 minute or so you run an Ajax call back to the server. If the value for stay_until[page_id] is less than or equal to the current time, then they're an active user, otherwise they're not. This means that it will take someone at least 20 minutes to generate 20 unique visitors, and so long as you make the payoff worth less than the time consumed that will be a strong disincentive.
I'd even make it more explicit: on the bottom of the page in a noscript tag, put "Your access was not counted. Turn on JavaScript to be counted" with a page that lays out the tracking process.
As HTML Requests are stateless and you have no control over the users behavior on his clientside, there is no bulletproof way.
The only way you're going to be able to track "unique" visitors in a fool-proof way is to make it contingent on some controlled factor such as a login. Anything else can and will fail to be completely accurate.
I hope the title is chosen well enough to ask this question.
Feel free to edit if not and please accept my apologies.
I am currently laying out an application that is interacting with the web.
Explanation of the basic flow of the program:
The user is entering a UserID into my program, which is then used to access multiple xml-files over the web:
http://example.org/user/userid/?xml=1
This file contains several ID's of products the user owns in a DRM-System. This list is then used to access stats and informations about the users interaction with the product:
http://example.org/user/appid/stats/?xml=1
This also contains links to various images which are specific to that application. And those may change at any time and need to be downloaded for display in the app.
This is where the horror starts, at least for me :D.
1.) How do I store that information on the PC of the user?
I thought about using a directory for the userid, then subfolders with the appid to cache images and the xml-files to load them on demand. I also thought about using a zipfile while using the same structure.
Or would one rather use a local db like sqlite for that?
Average Number of Applications might be around ~100-300 and stats and images per app from basically 5-700.
2.) When should I refresh the content?
The bad thing is, the website from where this data is downloaded, or rather the xmls, do not contain any timestamps when it was refreshed/changed the last time. So I would need to hash all the files and compare them in the moment the user is accessing that data, which can take an inifite amount of time, because it is webbased. Okay, there are timeouts, but I would need to block the access to the content until the data is either downloaded and processed or the timeout occurs. In both cases, the application would not be accessible for a short or maybe even long time and I want to avoid that. I could let the user do the refresh manually when he needs it, but then I hoped there are some better methods for that.
Especially with the above mentioned numbers of apps and stuff.
Thanks for reading and all of that and please feel free to ask if I forgot to explain something.
It's probably worth using a DB since it saves you messing around with file formats for structured data. Remember to delete and rebuild it from time to time (or make sure old stuff is thoroughly removed and compact it from time to time, but it's probably easier to start again, since it's just a cache).
If the web service gives you no clues when to reload, then you'll just have to decide for yourself, but do be sure to check the HTTP headers for any caching instructions as well as the XML data[*]. Decide a reasonable staleness for data (the amount of time a user spends staring at the results is a absolute minimum, since they'll see results that stale no matter what you do). Whenever you download anything, record what date/time you downloaded it. Flush old data from the cache.
To prevent long delays refreshing data, you could:
visually indicate that the data is stale, but display it anyway and replace it once you've refreshed.
allow staler data when the user has a lot of stuff visible, than you do when they're just looking at a small amount of stuff. So, you'll "do nothing" while waiting for a small amount of stuff, but not while waiting for a large amount of stuff.
run a background task that does nothing other than expiring old stuff out of the cache and reloading it. The main app always displays the best available, however old that is.
Or some combination of tactics.
[*] Come to think of it, if the web server is providing reasonable caching instructions, then it might be simplest to forget about any sort of storage or caching in your app. Just grab the XML files and display them, but grab them via a caching web proxy that you've integrated into your app. I don't know what proxies make this easy - you can compile Squid yourself (of course), but I don't know whether you can link it into another app without modifying it yourself.
I need to create a simple application that doesn't work after 30 days.
How can I do that ?
Is there a way to use Trial program after 30 days ?
There is always a way to use a trial program after 30 days.
If by "best" you mean least breakable, then there is really only one way: make it an Internet-based "software as a service" application. If you don't provide access, they're not using the software. If it is a desktop-based application, then some key piece of functionality would still have to be on an online server somewhere.
If the hacker has the entire application on their local machine, it can be reverse engineered and "cracked" in some fashion. The only way to overcome this is to assure that some part of the functionality is never on their machine.
I think a better solution is a feature-limited application -- say you can do basic operations but to take advantage of the best features you have to get a paid license. This does two things -- assuming your app is well-done and interesting to a variety of users. First, you can get a larger number of people to try your app. Second you can get some good will by releasing your "lite" version free.
If you really need to do a time-limited trial, then I would consider having it write an encrypted key to the registry (windows) or a dot-file (linux). This key could encode the expiration date. Using reversible encryption allows you to get this value back out. Using a secret key helps protect against someone generating their own (valid) key. The fully licensed app could use the same key mechanism but encrypting a key value that allows permanent usage.
From my answer to implementing-expiration-dates-in-an-application/1871218#1871218:
Probably the most user friendly to do this is to keep track of the number of days a user has used your software. For example, each time your program starts up you could write a date to an encrypted file (unless the date already exists in the file). Then once there are more than, say, 30 dates in the file, let the user know it is time to buy the full version.
Real products such as Beyond Compare use this scheme - great for potential customers that install your product and don't use it for 30 days only to find that the trial has expired.
Also keep in mind that your scheme does not have to be perfect, just make it strong enough that it will not be convenient for users to break it.
Have the program request a key from your server on first run and check its validity every time the program starts and every 24 hours.
Another option is to have a server-side compiler when you download the application. This can "inject" a license key into the binary. You can do this using a constant in a seperate file. This can then be linked with the other pre-comiled files. This method is slower but harder to crack as the hacker would need to decompile the program.
I'd like to put an expiration date in some software I made. Obviously
psuedocode:
if time() > xxx: exit()
All someone has to do here is set their system clock back. Anything better to do?
What would be more user friendly is to keep track of the number of days a user has used your software. For example, each time your program starts up you could write a date to an encrypted file (unless the date already exists in the file). Then once there are more than, say, 30 dates in the file, let the user know it is time to buy the full version.
Someone will always be able to defeat your system if they put enough effort into it. Joel Spolsky said something to this effect that is very accurate (words are mine):
Your software protection scheme does not have to be bullet-proof (nor can it be), it just needs to be good enough to keep the honest people honest
So, with that in mind we can think up something clever enough to keep the honest people honest as the filthy cheaters are not going to pay for your app anyway. I have never needed to do this, nor have I looked into any known methods, but I can think of a few ideas:
Use a two-way hash to store the initial date and compare that to the present date. You can save the has to disk.
On Windows, use the registry. Yes, this is no where near bullet-proof, but most people will not go digging through the registry to find your key (and most will not know how to anyway).
Use the created date of your installation files as a reference.
Work off of the create date of one of the files you install.
this gives you a non-changing date to subtract from now to get the time the program has been installed. The only problem with this is when they re-install it. The easiest way to combat this is with a registry setting.
There's no real solution here - anything can be cracked. You could consider:
checking the time with an online
service
storing the last run date and
checking to make sure that it isn't
after the current date
checking the
"last modified" date on some system
files.
What is your goal here? If it's to stop all theft, good luck with that; all protection schemes will be broken eventually. If it's to keep the honest people honest, don't worry about them setting the clock back - it's enough of a hassle that nobody will do it, and those honest folk will pay up immediately.
The solution doesn't need to be perfect, it just has to be annoying enough to the user so he won't try to game the system.
You could calculate the aboslute value's difference and make sure that it is smaller than X days. In that way, they would need to always keep their clock within X days. Which no one would ever do forever.
You can try to record the timestamps in the registry. You can encrypt the timestamps when you put them there. The question is is it worth it?
Messing with your computer clock, especially rolling it back creates all sorts of headaches. People usually do not do it, At least all the time - limited trial versions of software from Microsoft, Adobe, etc, do not try to build protection against rolling back the clock