I wish to implement my software on a shareware basis, so that the user is
given a maximum trial period of (say) 30 days with which to try out the software. On purchase I intend the user to be given a randomly-generated key, which when entered
enables the software again.
I've never been down this route before, so any advice or feedback or pointers to 'standard' ways of how this is done would be much appreciated.
I do not anticipate users cheating by changing the system date or anything like that, though this is probably worth considering. Apologies if this topic has appeared before.
With regards to a random-generated key, how will you verify a key is legit or if a key is bogus if it is actually random? Have a look at the article "Implementing a Partial Serial Number Verification System" as it is quite good and is easy to implement in any language.
With regards to time trials, as basic solution would be to compare your main executable files creation time to the current system time and act on the difference. This assumes your installer sets the files creation time to the time of install as opposed to preserving the time you compiled it! :)
Also watch out for the time changing radically, if the current date is magically less than the install date and such.
One way to get around this type of datelock is to change your date before you install to be years in the future. So you should check that the date today is not less that the install date.
If your software is really useful, you'll certainly find cracked copies on P2P before you see your first order. This will happen no matter how sophisticated is the license enforcement code you are going to implement.
That said, just store first-run date somewhere (may be registry, if on Windows) and after 30 days refuse to start, or just open a reminder window.
Don't worry about cheaters, they'll find a way around your restrictions no matter what. Worry about your honest customers and try hard not to make their life harder.
Eric Sink has written more about this here (section 4).
On the first start, you can store the actual date somewhere.
Each following start, you look for the stored date, if it exist you read it an if it is more than 30 days after the first start, you stop the program.
Please see this library.
Description:
Convert any application into time-limited shareware. Generate serial numbers to register it. A function library offering a flexible locking system with solid encryption. Easy to implement. Support for VB, C++, Delphi, other languages.
Related
We have an application with 10 millions lines of code in 4GL(Progress) and a database also OpenEdge with 300 Tables. My Boss says we should migrate it to a new Programming language and a new Database Management system.
My questions are:
Do you think we should migrate it? Do you think Progress has a "future"?
If we should migrate it, how, are there any tools? Or should we begin with programming from scratch?
Thank you for the help.
Ablo
Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites.
http://www.joelonsoftware.com/articles/fog0000000069.html
Yes, Progress has a future. They probably will never be as sexy an option as Microsoft or Oracle or whatever the cool kids are using this week. But they have been around for 30 years and they will still be here when you and your boss retire.
There are those who will rain down scorn on Progress because it isn't X or it doesn't have Y. Maybe they can rewrite your 10 million lines of code next weekend and prove just how right they are. I would not, however, pay them for those efforts until after the user acceptance tests are passed and the implementation is completed.
A couple of years later (the original post being from 2014 and the answers being from 2014 to 2015) :
The post, which has gotten the most votes is argumenting basically two fold :
a. Progress (Openedge) has been around for a long time and is not going anywhere soon
b. Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites: http://www.joelonsoftware.com/articles/fog0000000069.html
With regard to a:
Yes, the Progress OpenEdge Stack is still around. But from my experience the difficulty to find experienced and skilled Openedge has gotten even more difficult.
But also an important factor here, which i think has evolved to much greater importance, since this discussion started:
The available Open Source Stacks for application development have gotten by factors better, both in terms of out-of-box functionality and quality and have decisively moved in direction of RAD.
I am thinking for instance of Spring Boot, but not only, see https://stackshare.io/spring-boot/alternatives. In the Java realm Spring Boot is certainly unique. Also for the development of rich Webui's many very valid options have emerged, which certainly are addressing RAD requirements, just some "arbitrary" examples https://vaadin.com for Java, but also https://www.polymer-project.org for Javascript, which are interestingly converging both with https://vaadin.com/flow.
Many of the available stacks are still evolving strongly, but all have making life easier for the developer as strong driver. Also in terms of architectures you will find a convergence of many of this stacks with regard basic building blocks and principles: Separation of Interfaces from Implementation, REST API's for remote communication, Object Relational Mapping Technologies, NoSql / Json approaches etc etc.
So yes the Open Source Stack are getting very efficient in terms of Development. And what must also be mentioned, that the scope of these stacks do not stop with development: Deployment, Operational Aspects and naturally also Testing are a strong ,which in the end also make the developers life easier.
Generally one can say the a well choosen Mix and Match of Open Source Stacks have a very strong value proposition, also on the background of RAD requirements, which a proprietary Stack, will have in the long run difficulty to match - at least from my point of view.
With regard to b:
Interestingly enough i was just recently with a customer, who is looking to do exactly this: rewrite their application. The irony: they are migrating from Progress to Progress OpenEdge, with several additional Open Edge compliant Tools. The reason two fold: Their code is getting very difficult to maintain and would refactoring in order to address requirements coming from Web Frontends. Also interesting, they are not finding enough qualified developers.
Basically: Code is sound and lives , when it can be refactored and when it can evolve with new requirements. Unfortunately there many examples - at least from my experience - to contrary.
Additionally End-of-Lifecyle of Software can force a company, to "rewrite" at least layers of their software. And this doesn't necessarily have to bad and impossible. I worked on a Project, which migrated over 300 Oracle Forms forms to a Java based UI within less then two years. This migration from a 2 tier to a 3 tier architecture actually positioned the company to evolve their architecture to address the needs of Web Ui's. So actually in the end this "rewrite" and a strong return of value also from the business perspective.
So to cut a (very;-)) long story short:
One way or another, it is easy to go wrong with generalizations.
You need not begin programming from scratch. There is help available online and yes, you can contact Progress Technical Support if you find difficulties. Generally, ABL code from previous version should work with only little changes. Here are few things that you need to do in order to migrate your application:
Backup databases
Backup source code and .r files
Truncate DB bi files
Convert your databases
Recompile ABL code and test
http://knowledgebase.progress.com articles will help you in this. If you are migrating from some older versions like 9, you can find a good set of new features. You can try them but only after you are done with your conversion.
If you are migrating from 32-bit to 64-bit and if you are using 32-bit libraries, you need to replace them with 64-bit
The first question I'd come back with is 'why'? If the application is not measuring up that's one thing, and the question needs to be looked at from that perspective.
If the perception is that Progress is somehow a "lesser" application development and operating environment, and the desire is only to move to a different development and operating environment - you'll end up with a lot of resources in time, effort, and money invested - not to mention the opportunity cost - and for what? To run on a different database platform? Will migrating result in a lower TCO? Faster development turn-around time? Quicker time to market? What's expected advantage in moving from Progress, and how long will it take to recover the migration cost - if ever?
Somewhere out there is a company who had similar thoughts and tried to move off of Progress and the ABL. The effort failed to meet their target performance and functionality metrics, so they eventually gave up on the migration, threw in the towel, and stayed with Progress - after spending $25M on the project.
Can your company afford that kind of risk / reward ratio?
Progress (Openedge) has been around for a long time and is not going anywhere soon. And rewriting 10 Million lines of code in any language just to use the current flavor of the month would never be worth it unless your current application is not doing what you need. Even then bringing it up to current needs would normally be a better solution.
If you need to migrate your current application to the latest version of Openedge (Progress) you would normally just make a copy of your database(s) and convert it/them to the new version of Openedge and compile your your code against the new databases and shake the bugs out. You may have some keyword issues, but this is usually pretty minor.
If you need help with programming I would suggest contacting Progress Software and attending the yearly trade show or going to https://community.progress.com/ and asking/looking for local user groups. The local user groups would be a stellar place to find local programming talent.
Hope this helps.....
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.
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
I'm developing a small windows app using c++ and i would like to get some kind of fingerprint of the software/hardware on a pc so that i can allow the app to be run only on certain pc's.
I am aware that the app can be cracked but i'm really interested in implementing something like this.
Any ideas how could i achieve this?
It basically depends on how tight you want to couple your software to the underlying hardware. For example you could get some hardware information from the registry, read out the MAC address from the LAN card, retrieve the gfx manufacturer, the CPU id, etc. and hash all these data.
You could then use this hash as a challenge code which is sent to your company. The customer then receives the signed (with your private key) version of this hash.
Upon start up your application is able to check if the signature of the hash is good or bad (i.e. has been signed by your company).
This not only binds your software to a certain hardware configuration, but also forces the crackers to patch your application (because they would need to patch the public key from your executable and replace it in order to write a keygen). Many people consider twice installing a crack obtained from various sources in contrast to just entering a valid serial copied from a keygen.
Edit:
In order to check the signature of the hash, anything from RSA over DSA to ECC can be used. I can recommend Crypto++ or libTomCrypt for that.
There's no reliable way known to do this in a vanilla PC; people have been trying for years. The problem is that you might change any component at any time, including the CPU and the BIOS ROMs. The closest people have come is using a cryptographically protected "dongle" but that has proven both to be unsatisfactory in operation, and not very secure.
If you come up with something, patent it; it would be very valuable.
As the others have said there is nothing perfect for what you want. I made a half-hearted attempt for a similar issue and ended up with a mix of drive volume ID (not good because it can be reformatted) and the OS key (from windows).
In the end I didn't spend much time on it as if people really want to crack your software they'll probably be able to do it. I left the dinky licensing "protection", but it is pretty poor.
Spend the time/effort on making them want to buy it by making it outstanding.