Software working for limited time period
-
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
From what I have seen and heard, there is no good way to do trial software that can't be cracked by someone. The only viable solution I see is to store the user dates of expiration on a server, and force communication between the server and your app. If you don't have internet connectivity, then that option becomes a problem. Have you thought about doing a freeware version, with extremely limited functionality? You can have alot of advanced options disabled, and have a description for them. Then the user can see them, and a description of what they do.
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
-
This might not be particularly to the point, but I recall reading an article by somebody, the gist of which was that he started making more sales when he switched from time limited demos to limited functionality/unlimited time demos. Users seemed more likely to buy the product when they could see functionality there that would be useful but that they couldn't get to.
That's the conclusion we came to. When the users grasp the functionatlity and see what they will get purchasing it's much more effective. Plus, the more sophisticated the technique for limited "demo" time period the more time you spend maintaining the code/process. And someone will break it down eventually.
Thomas
-
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
Sell an atomic clock with the software.
Roger Irrelevant "he's completely hatstand"
-
Self-ediding exe is not so easy ... and does not help when user reinstalls the software
rrrado
rrrado wrote:
Self-ediding exe is not so easy
self-editing exe is a piece of cake, but you are correct, it doesn't stop reinstalls. I used it as a cross reference to the hidden sectored equivalent this way it had a doubled checked counterpart.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
On option is to have a critical dll for the application built dynamically with the restriction at delivery time, ie when they click download now. It doesn't work if the disk is burnt and mass produced however. One Key thing to keep in mind is that Adobe Photoshop is the definitive software graphics package and they have a 30 day trial and it is always cracked. I wouldn't much time keeping people honest. Software thieves are not likely to pay just because the trial is hard to crack.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
Try searching the Business of Software Forum[^]. That particular question has been answered there many, many times there before. From personal experience I can tell you that it's far easier and more secure to use a third party licencing component than to try to write your own.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Try searching the Business of Software Forum[^]. That particular question has been answered there many, many times there before. From personal experience I can tell you that it's far easier and more secure to use a third party licencing component than to try to write your own.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
From personal experience
and less headaches if your security algorithms get used for alternate and more troublesome uses by others.... :sigh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
-
what about hide installation date somewhere into registry? I know this won't stop any cracker but in fact there is nothing what would stop good cracker :)
rrrado
Actually there is. The iPhone will stop any hackers... er wait... nevermind.:-D
What I am up to: ReadyToGiveUp(Not!)[^] What friends are up to:SQLServerCentral[^]
-
This might not be particularly to the point, but I recall reading an article by somebody, the gist of which was that he started making more sales when he switched from time limited demos to limited functionality/unlimited time demos. Users seemed more likely to buy the product when they could see functionality there that would be useful but that they couldn't get to.
That's the best way I guess. Further than that, almost any lock will break, but if the demo has NOT some functions at all, then it's uncrackable and it is not likely that a hacker buys a software to hack it. p.s. Disabling functionality might break easily. It's better to remove codes from functions you don't want to be in demo version.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
This might not be particularly to the point, but I recall reading an article by somebody, the gist of which was that he started making more sales when he switched from time limited demos to limited functionality/unlimited time demos. Users seemed more likely to buy the product when they could see functionality there that would be useful but that they couldn't get to.
I think this depends on the user. I have not purchased any diskkeeper software in the past (although I have tried the product many times) primarily because the restricted functionality demo did not function well enough for me to want to buy the full version. Specifically running the demo will not defragment a hard drive by more than a few percent so after an initial run with a NTFS drive with 80% fragmentation (I do a lot of programming) after running it the fragmentation was reduced to 76% wow. On more than one occasion I actually took the time to email them that by not letting me try the software to see that it indeed does what it claims that they would not get any licences from my department... [EDIT]Well they now have a full functional version. If I get some free time I will give it a try.[/EDIT]
John
-
Try searching the Business of Software Forum[^]. That particular question has been answered there many, many times there before. From personal experience I can tell you that it's far easier and more secure to use a third party licencing component than to try to write your own.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
it's far easier and more secure to use a third party licencing component
Yes, but some times you want to change something that is not implemented yet. I had this trouble with one of them. I also should add that 'never use hardware locks'. Most of those usb, serial or parallel locks are a piece of sh*t. Just think about you want to update executable automatically, but you have to have the hardware to re enable security per user:wtf:. -- modified at 14:30 Thursday 30th August, 2007
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
what about hide installation date somewhere into registry? I know this won't stop any cracker but in fact there is nothing what would stop good cracker :)
rrrado
rrrado wrote:
hide installation date somewhere into registry?
Quiet weak. Hackers have tools to get an image of memory or registry and check changes after running the app. They quickly notice where you put that.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
Try searching the Business of Software Forum[^]. That particular question has been answered there many, many times there before. From personal experience I can tell you that it's far easier and more secure to use a third party licencing component than to try to write your own.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
t's far easier and more secure to use a third party licencing component
I would argue that it is more likely if you do so that your protection would be hacked because if it is a common protection scheme it will get more attention by hackers because it would be used in more applications. And in a lot of cases if they find a way to hack the protection scheme it opens the door to all the applications that use the scheme.
John
-
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
It depends on the purpose of the software. Personally, I would let users install the entire package, without any limited functionality. If a user has to guess at what the "other" functionality (non limited) is, then they may be setting themselves up for a let down which is bad from a marketing perspective. Users always expect the most so the expectation level is high. I would give them everything and let them decide if they want to purchase it. I'd take a different approach and control what's most important to the user, the data. Let them use the software all they want. Let them save their data. But after the trial period, don't allow access to the data. Granted, I'm talking about files not database. For example: Have a sign-up, registration on the install that creates a user account on your internet site. Store the data files in a secured zip format (ala Office 2007) with the entry password stored on the server. If they do purchase, then remove the password. Your application can check if the zip file has password protection. If it does, then it has to check the server after the trial period. If it doesn't have protection, then it's been purchased and no checks of the server are necessary in the future (and you don't need to be connected to the internet). Nothing is fool proof, though. Having control on the server gives you control so that even if they set the date back or re-install, you have the keys to their kingdom!
-
Johan Lombaard wrote:
...the user can still keep setting it back on day 29.
Does your application require Internet connectivity?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
thats exactly what i was going to say ... the only foolproof(ish) way really apart from being *really* draconian
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
I hope this is the correct forum. It's definitely not a coding question, since I'm looking for ideas on the WHAT, not the HOW ... I need to give users a 30 day trial period on a product, but I want to prevent them from changing back the clock to get the software to work again. Just storing a flag when it has expired will not solve it, since the user can still keep setting it back on day 29. Does anyone have ideas on how to best do this ?
Johan Lombaard Only two things are infinite, the universe and human stupidity, and I'm not sure about the former - Albert Einstein
Simple solution: don't limit total time, but execution time, and monitor time while your program executes. You still have to solve some problems (persisting some information, multiple instances), but you take the whole "where to get a valid date from" question out of the equation. (Actually, if you insist on a total time limit, there's the right question for you already: where do you get a valid time from?) [edit] Moreover, there are important points to consider: Computers regulary change the time themselves, when adjusting for DST. People change their computers times when they travel to different time zones. It may be up to 24hours when they cross the date line (even more if these two regions have different DST settings). Well meaning users with an accidentally wrong system time are at least as common as people trying to trick you. So you need to have safety ropes to not alienate well meaning customers over a simple change of system time. There actually are hardware dongles that include a real time clock. -- modified at 15:43 Thursday 30th August, 2007
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
rrrado wrote:
Self-ediding exe is not so easy
self-editing exe is a piece of cake, but you are correct, it doesn't stop reinstalls. I used it as a cross reference to the hidden sectored equivalent this way it had a doubled checked counterpart.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
self-editing exe is a piece of cake
Esp. when you have no write access to the exe ... ;P
-
Try searching the Business of Software Forum[^]. That particular question has been answered there many, many times there before. From personal experience I can tell you that it's far easier and more secure to use a third party licencing component than to try to write your own.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
it's far easier and more secure to use a third party licencing component
Recommendation?
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]