|
Using shame to stop copying
An old problem, you've got say a shareware app
You don't want people passing round Key codes rather than registering/paying.
Traditional Option 1: You use key codes tied to the machine. Stops the copying but potentially crackable, and a pain when people switch machine or whatever.
Traditional Option 2: You don't tie the key to the machine, even more crackable, plus you have the worry that your customer Joe Bloggs shares his key with 6 million of his closest friends.
Option Shame: Joe Bloggs' key code will cause the software to prominently say "This software licensed to Joe Bloggs and Joe Bloggs only". Will this stop Joe Bloggs sharing his key with his friends?
Additionally if you have millions of times more potentially valid keys than keys you actually issued, and make the software check against the keys-issued list on your site, this will mean any cracker will almost certainly come up with a key that has not been used on your site. So these can say prominently "You are using a pirate copy!"
S. Tanna
Monday, February 2, 2004
This issue has been hashed here over and over (no pun intended), and lots of great advice has been given on this topic.
www.MarkTAW.com
Monday, February 2, 2004
And also out of Joes 6,000,000 friends a fair proportion of them won't mind seeing Joes name on startup of the app.
The only time this theory is going to work is if your app is a business app and produces reports and you output "XYZ Corp." on all reports that is tied to the code. The when somebody at "ABC Corp." gets a copy from his mate at XYZ his boss will wonder why it says "XYZ Corp." on all the reports and might buy a copy of your app. - but most home users won't care.
Chris Ormerod
Monday, February 2, 2004
Option Shame is largely unworkable. Your application is likely to be cracked, rather than just have a key code passed around. If it's cracked, it can be registered to whatever name the person wants.
Additionally, the check server option fails if the app is cracked. What's even worse is it severely disadvantages legitimate users: They can no longer use your app unless they have an (unfirewalled) internet connection handy.
Sum Dum Gai
Monday, February 2, 2004
I've said it time and again, offer a free limited functinality version of your product.
I'm looking at calendar applications now and I came across TimeCalendar (http://www.timecalendar.com/). There is a free version you can use (TimeCalendarLE) which is limited in that you can only use 32 characters for event titles and can't add event descriptions and it can't do multiple calendars.
I think no event descriptions is pretty lame, especially since the box is there, but grayed out, but lets say you could add a description, just limited to 256 characters.
Then TimeCalendarLE would do 90% of what I need.
You can't download the full version of TimeCalendar from the website unless you pay for it, and if your LE version actually doesn't have the code in it to make it a full version, then you're asking the crackers to keep your software on their servers, or distribute it by p2p or whatever.
IMHO, this plus constantly adding features so you can release new versions which defeat existing known serials and cracks (so existing cracks fall out of date fast) is the best way to deal with this situation.
Treepad is another great example of an app that has a free version that is *completely* different from the full version - same concept, but obviously different code base and features. Lots of shared stuff of course, but the full version adds rich text editing, images, linking, encryption and more.
www.MarkTAW.com
Monday, February 2, 2004
The only real solution is product activation, expect to see a lot more of it in commerical software.
Tony Edgecombe
Monday, February 2, 2004
Product activation does not help against cracks. In fact, products with activation are the ones that get cracked first. The Adobe Photoshop CS crack was out before the official release.
What it does do is annoy a significant part of your legal customers. If I put down hundreds of dollars for software, I want to be sure I can still install it in 5 years. Even if the company went bust. Product activation adds a big minus in the product review chart. I only consider such products if there is no alternative. Which is why I bought Photoshop CS, despite of its activation feature.
Jan Derk
Monday, February 2, 2004
I can think of several products I didn't buy because the trial was limited functionality - the functionality that was limited was the part I really needed to see work to make sure it was worth the money (in the calendar app Mark mentions, no event descriptions may be a deal-killer)
This is based on a time when I *did* make the leap of faith, and got burned - the feature, when enabled, sucked.
I'd suggest instead a limited duration full-featured version, and after [x] days, some critical features stop working. (ThumbsPlus works this way).
One feature I'll agree you can generally disable in shareware, tho, is "Save" - do anything you want with your project, but you can't save it.
Philo
Philo
Monday, February 2, 2004
> Option Shame is largely unworkable. Your application is likely to be cracked, rather than just have a key code passed around. If it's cracked, it can be registered to whatever name the person wants.
I am thinking the key is stored on the user's PC. Which key corresponds to which person's name is stored on my server. To get the current person's name, you send a request with the key to my server, and it sends back the person's name. Unless they they change the binary to remove the code, or somehow get a list of which keys are actually in use (or at least one), they can't register it to any name they want.
> Additionally, the check server option fails if the app is cracked. What's even worse is it severely disadvantages legitimate users: They can no longer use your app unless they have an (unfirewalled) internet connection handy.
Internet connection yes, however as the particular app is Internet-based, I don't see this as a major limitation.
Unfirewalled probably no. I am thinking of using port 80.
S. Tanna
Monday, February 2, 2004
"I'd suggest instead a limited duration full-featured version, and after [x] days, some critical features stop working. (ThumbsPlus works this way). "
That's what we do. It works pretty well.
And, BTW, it's great when a teacher, for example, says "gee if you give me a free copy I can show it to my class".
I just say "well, the trial becomes a demo that you can use as long as you like. You can show them 2 excercises from each lesson (2% of the therapy content). That should be enough for an in class demo. If you want to use it in therapy (with patients) you can buy it.". Works great.
The real Entrepreneur
Monday, February 2, 2004
"you're asking the crackers to keep your software on their servers, or distribute it by p2p or whatever."
I think this is a flawed argument for the following reason: the crackers are going to crack ANY protection scheme. Something doing with limited functionality is of no special interest to them as you imply, they crack to crack, not because functionality is too limited. Such is the crack scene.
Shame? Yeah it's a good idea. Will it stop every body? No, it will not stop the shameless. But that's not everyone. Since it enforces ACCOUNTABILITY, a lot of people will be deterred.
Please note the following principle that so few people understand nowadays: Just because something is not 100% perfect does not mean that its better than nothing.
A good example is those steering wheel bars. People say "Well, a car thief could still steal it by cutting the steering wheel in half!" Er, yeah, that is TRUE, but you ever try to sell a stolen car with a steering wheel cut in half? Come on people, use some common sense here. Everything is not 100% black and white.
Dennis Atkins
Monday, February 2, 2004
'does not mean that its -not- better than nothing'
Dennis Atkins
Monday, February 2, 2004
Forget shame.
Use their credit card number as the registration key.
I've always wanted to do this...
AJS
Monday, February 2, 2004
If you really wanted to shame them, you could have the registration key say 'Jenny Smith is really 46, not 37' or 'Bob Jones has a small penis'.
How to collect this embarrassing information is left as an exercise for the reader.
AJS
Monday, February 2, 2004
<<Forget shame.
Use their credit card number as the registration key.
I've always wanted to do this... >>
PalmReader (Palm's ebook software) does it this way :)
Ron Porter
Monday, February 2, 2004
credit card .... PalmReader (Palm's ebook software) does it this way :)
Damn. I wonder if it's too late to lodge the patent!
AJS
Monday, February 2, 2004
> I am thinking the key is stored on the user's PC. Which key corresponds to which person's name is stored on my server. ... <
I think you could avoid the storing-name-on-the-server aspect by hashing the user's name and incorporating the hash value into the key code. For example, assume that the user's name is "Joe Smith," and that name hashes to a value of 3421. You could assign a registration code like 4321-3421-3490, and your activation code could then check whether "Joe Smith" is actually entered in the "registered to:" field by comparing the hash values.
The user would still need to contact you once to get an activation key, but wouldn't need to contact your server each time he did an install. Also, the user could get that code from you via email or telephone if he didn't have an active internet connection at the time of the install.
Robert Jacobson
Monday, February 2, 2004
>>Product activation does not help against cracks.
It might not stop the crack but it gives the developer an opportunity to stop stolen keys from working. Like it or not you are going to see a lot more of it.
Tony Edgecombe
Monday, February 2, 2004
Step 1: "Use their credit card number as the registration key"
Step 2: registration key stolen, or even given away by an idiot
Step 3: lawsuit
Step 4: profit for lawyers, not for you
I'm sure it's being done, but personally the idea of keeping that sort of information in a registration key seems a little risky to me even if it should discourage people from sharing those keys.
Monday, February 2, 2004
You're right, Philo, I didn't buy that app because it was simply unusable as a trial product. That and it stored it's calendar files in it's root folder and gave no option to backup/export everything to one file, which is what I really wanted.
I also agree that the full product's features (which you can't access) may suck, the same way you see all the best parts of some movies in the trailer.
This calender had "Layers" or multiple calenders you can turn on and off with a single mouse click. Different projects, different family members, etc. can all use the same program, you can share a layer so you can send the meeting schedule to your employees and so on. This is a feature I didn't really need, and this is the *only* one that should've been disabled in the limited functionality demo.
Instead they made it cripple-ware.
What I'm getting at is crackers can't crack a product that they can't get their hands on, and if they do, the end user can't apply the crack if they can't get the program. Everything else is easy to share.
www.MarkTAW.com
Monday, February 2, 2004
"I am thinking the key is stored on the user's PC. Which key corresponds to which person's name is stored on my server. To get the current person's name, you send a request with the key to my server, and it sends back the person's name. Unless they they change the binary to remove the code, or somehow get a list of which keys are actually in use (or at least one), they can't register it to any name they want."
That's exactly what a crack does though. Change the code to remove the registration checks.
The more complicated you make your check, the more time you'll waste on something that ultimately *will* be broken if your app is popular enough to gain the attention of crackers. I'd suggest not bothering to go overboard with protection for this reason. Put minimal protection in, and spend the rest of your time on making a product that people actually want to buy.
I doubt there's a single piece of popular shareware out there that a crack can't be found with 5 minutes of searching. It's a fact of life that you have to resign yourself to if you write shareware: no app is uncrackable, so it's not worth trying.
Sum Dum Gai
Monday, February 2, 2004
The key here is not to make a very complicated check, but to make LOTS of simple checks all over your code, and to use the results of those checks in your registered-only actions. I'm a particular fan of calculating message numbers from registration codes, because they're calculated in one place and verified in another. If they're right, the application behaves properly. If they're wrong, they either disappear into the ether and nothing happens, or the wrong thing happens.
That makes them a huge pain in the ass for a cracker to reverse-engineer, so he generally won't bother unless you're doing something really interesting. That's where most people fail. They try to do something elegant and clever. Crackers LOVE elegant and clever. What they *hate* is stuff that's boring and repetitive. So do something really boring and really repetitive.
Caliban Tiresias Darklock
Monday, February 2, 2004
I think I should clarify "message numbers": I'm talking about Windows messages, the kind you usually specify as WM_USER + some_constant. Instead of a constant, I use a calculation from some portion of the registration code hashed into another portion of the user's name. So when I PostMessage, the message gets picked up in my WndProc, but if it's not the right message -- who knows what will happen.
Caliban Tiresias Darklock
Monday, February 2, 2004
That "who knows what will happen" may well include crashing.
Now, you might say that you don't care, who cares if someone has cracked your software experiences crashes, right?
Wrong.
That person is going to tell all their friends that your application is a buggy piece of crap. Most certainly not the publicity you want.
On the internet, word of mouth can spread really fast, and it only takes a few annoyed people for lots of people to get the impression that a piece of software is poor quality. Then you'll be getting second and third hand accounts of how bad it is - and they wont know a crack was ever applied!
I don't know, maybe the increased sales are worth it. But personally, if it was me, I wouldn't want my software to crash if I could possibility avoid it. Not the kind of reputation I'd want to foster.
Sum Dum Gai
Monday, February 2, 2004
That's pretty silly since software cracks almost always introduce bugs. I guess this is part of that other thread "You shuld write defensizvely so crackers who don't have any coding ability won't accidentaly introduce errors into your code."
Its so funny how people complain about the viruses they get on their computer that is introduced by trojans riding on cracked software. Really, I don't care about the people who have cracks of software I've written. I don't care if their hard drives get accidentally erased or if their computers are commandeered by mafia spamming consortiums.
Who I care about is paying customers. No one listens to the imbeciles who post on crack bboards about how unhappy they are with all the bugs in their crack.
Dennis Atkins
Tuesday, February 3, 2004
Sum,
Your software? Obviously you don't write software. You just eat cracked software. Why don't you come out and admit it? And you're unhappy because of the low quality of the free crack you're addicted to.
Well that's your problem.
Dennis Atkins
Tuesday, February 3, 2004
Well, good on you. You've mastered the art of ad hom attacks. Congratulations.
Anyway, moving right along ...
How do you know people are only going to post on crack boards? In reality, people using cracks are mostly just normal people, only a really small minority of them are going to be l33t d00dz. These are people who have personal webpages, blogs, post on other forums, talk to co-workers and friends in real life, etc.
So if an app is buggy, word gets around. Even if it's not the apps fault. Surely anyone who's worked with software and hung around on the internet for some amount of time has heard of weird problems with software that was eventually tracked down to some user having applied a buggy crack.
The question is: How much damage has already been done to the program's reputation before it's discovered the crack is dodgy? And how many cases are there where it's never discovered that a crack was used at all?
I can't speak for anyone else, but if I hear a couple of bad things about a program, I'm probably not going to bother to try it out. There's usually dozens of similar shareware programs out there, so it's simply not worth my time to test them all.
So I think a bad crack floating around can potentially be very bad for a program, losing you customers before you even get a shot at them. Given that someone almost certainly will attempt a crack, making it so their crack will appear to work and then later crash the program is going to result on egg on the original program author's face.
As far as viruses go, I find it unlikely. A shareware author wouldn't knowingly release a program with a virus, would they? Of course not, their reputation would be shot. Likewise for crack authors. Everything I've read suggests they release cracks for the fame, so why on earth would they knowingly put a virus in their crack? Their reputation would be gone.
That's just my take on it though, I'm purely speculating, as I have no hard data on what a cracked program crashing ultimately does to a program's reputation. I also don't know any crackers personally, I'm only guessing based on what I've read as to what they do and how they do it.
Sum Dum Gai
Tuesday, February 3, 2004
Dude you are so right. I only grow the finest organic marijuana, strictly finest grade top shit. And the dealers keep lacing it with PCP. People freak out and they blame my weed! Can you believe this shit? After all the trouble I do to keep chemicals out of my grass, they go and do this to my good reputation.
Danny Chong
Tuesday, February 3, 2004
> That person is going to tell all their friends that your
> application is a buggy piece of crap.
I don't think that's likely, because chances are no crack will ever even *appear* to work. Here's the numeric breakdown.
Get the program to say you are registered: 14 CRCs.
Get the program to enable the "Save" menu item: 7 CRCs.
Get the "Save" menu to call the "Save" function: 7 CRCs.
Get the "Save" function to actually *work*: 217 CRCs.
That's 245 CRC calculations you would need to reverse-engineer just to make one of the half-dozen disabled features work. Even if you have a valid registration code to use for debugging purposes, that's going to take about 40 hours of work. And you'll need to do this at least six times. This is going to take MONTHS, and it is going to SUCK.
Nobody wants to do that. Nobody is *going* to do that. And even if someone did, we can change the whole scheme in about twenty seconds, and he'll just have to do it all over again.
An important factor in this system is that there are obvious cracking options that obviously don't work, so anyone capable of writing a crack will discern immediately that the solution is not trivial and eventually give up.
Caliban Tiresias Darklock
Tuesday, February 3, 2004
> making it so their crack will appear to work and then
> later crash the program is going to result on egg on
> the original program author's face.
It's important to note that when you start trying to make life difficult for crackers, many people fail to understand that you are NOT supposed to make life difficult for your legitimate users.
The case of an incorrect code is where many authors completely fail. When the code is incorrect, the most common reason is that the legitimate user has not typed it correctly. If you generate your code from the user's name and company, as most people do, there may be a difference in capitalisation or punctuation. Maybe there's an extra space in there somewhere.
What a lot of authors think is "oh, the registration code is entered but invalid; it must be a crack!" -- and they start doing nasty crap. Realistically, it is exponentially more likely that your user is just a bad typist. What more often identifies a crack is when the registration code *claims* to be correct, but isn't.
Credit cards have a check digit in them, so an incorrectly entered number raises a big red flag. Adding a few such things to your registration code can fix most problems; we use four separate verification fields -- one for the whole code, one for the name, one for the company, and one for the three other fields. If all four of these come out correct, then either the code is correct, or someone has calculated a correct series of verification fields for an incorrect code. Since we *never* do that, the latter case is almost certainly a crack attempt.
The proper response is NEVER EVER EVER to deliberately do anything nasty to the user! The *worst* thing you should deliberately do is report an error, and that's just what we do: we occasionally check some additional part of the code for validity (we literally have tens of thousands of ways to do this), and if it fails, we pop up a dialog that tells the user to contact tech support.
Registration schemes are complex. You have to balance the amount of work it takes against the amount of trouble it causes a cracker, and still never lose sight of the legitimate user -- who is a great deal more important than any cracker.
Caliban Tiresias Darklock
Tuesday, February 3, 2004
 Recent Topics
Fog Creek Home
|
