Slashdot Mirror
More On Policing Shareware
RHW22 writes "Washington Post's Rob Pegoraro looks at shareware, focusing on the question of whether or not this industry can survive if people never actually cough up $$ for the product. He mentions Ambrosia Software, 'a developer of Macintosh games and utilities in Rochester, N.Y., could stop guessing after it revised its payment system last year. The new system aims to stop people from using pirated registration codes in two ways.' Read his column here." We mentioned this several weeks ago, with a link to Ambrosia's description of their system and what led to its adoption.
I think you have misunderstood. Once you have given a legitimate, non-expired key the software will work forever. The only time you need to go back to Ambrosia is if you bought the key and didn't get around to applying it before it expired, or (I expect) if you reinstall. The reinstall is a problem, but not as bad as your scenario. (More like spare parts becoming unavailable when GM goes out of business.)
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
Okay, you want to write your own key generator.
My advice:
1) Use RECOGNIZED encryption & hashing algorithms. Do NOT invent your own!
2) Don't shorten the result from a hash. I recommend at least 128 bits of entropy in the key (if you use Base64 to represent your key, you need 22 characters)
3) Use public key encryption to prevent giving away your secrets.
An example protocol:
User sends his name (case sensitive) and the current timestamp (both of which the client stores to use in future validation) to the "authentication server" which also takes his credit card number. After receiving payment and validating the timestamp, it generates the registration code as follows:
1) Take the username, timestamp, and a secret symetric string (which will be embedded into the client, but, thus, vulnerable to attack). Concatenate them together with some sort of seperator (like a NUL character).
2) Take this new concatenated string and do some bit scrambling if needed. Take the MD5 hash of this new string and use for the next step.
3) Using RSA and a PRIVATE KEY (*NOT* embedded in your application!), encrypt this hash. Send the encrypted hash value in Base64 to the user. Remember he may need the timestamp as well to re-enter this value. The timestamp can be simply a day/month/year string.
To VALIDATE a registration string,
1) Decrypt the encrypted hash string using the PUBLIC KEY (embedded in your application). Because it is a public key, it doesn't matter if anyone knows it.
2) Verify that that hash equals the value of a hash constructed on a client using the user's name, his registration timestamp, and the shared secret embedded in the application.
Really, this isn't a secret science. But every game designer seems to think he is more creative then hundreds of experts on encryption. This is basically no different then a FFI (Friend or Foe Identification) system used on a military aircraft.
If done right, this isn't strictly true. A registration system only needs to rely on central servers if data used for the authentication process changes, such as a System ID or a timestamp, the latter being used in Ambrosia's system.
A simple authentication system would take the registree's name, address, and perhaps a keycode given at regtime to create a hash for the authentication server. If that hash is valid (meaning the registration actually happened), the authentication server will respond with a countercode that the program uses to unlock itself. If this countercode is not time-limited in any way, there's nothing logisticially preventing it from beging shown to the user, and thus permanently recorded; it will still be valid so long as the user remembers his name/address/etc.
If changing data is used for the hash, however, then there's a trickier situation if the authentication servers go permanently down. Most schemes would have the server respond with a sepereate countercode, and thus an old one would not work to unlock the program.
One solution to this problem is a master-key; a nonchanging constant that could be released if the company goes out of buisness. This creates security flaws, however, if the key is found out before the company goes out of buisness. Also, having a master key for the product out there would significantly reduce the possible value of the software "asset" in bankruptcy proceedings, so the courts might not allow the key to be made public.
A possibly better alternative would be to have the company release a patch that turned off the date-checking code in the program. Although this doesn't create any security holes in the product while the company's still alive, it does require that the company know it's irrevocably going bankrupt, and the programmers must have enough knowledge about the banakrputcy and power to release the patch -- neither of which are particularly likely in large corporations... after all, management can spin off the now-crippled masses as a "customer base" for future revisions to be sold at auction.
What's really needed is some sort of "dead-man's switch" so that if the company suddenly drops off of the face of the earth, the software will still work. To do this, the software should become non-functional if it receives a negative response from the auth server, instead of becoming non-functional if it fails to receive a positive response. The reg-server hostname should be hardcoded into the software somewhere (binary data file or program executable -- NOT a plaintext file), and the software (given use of an expired regcode) will try authenticating with the server on run and every hour or so until it receives a positive or negative response, in which case it will update its datafile and not try again (with that regcode).
"But Wait!" you say, "Isn't that system inherently insecure, as malpeople can crack the software or selectively block access to the auth servers?"
This is true, but, as the Ambrosia article says, the vast majority of people will do very little beyond trying a cracked regcode -- even installing a crack is beyond the vast majority of people who would typicially use the software; configuring special firewall rules is probably out of the question. (This is also why I said "put the server info in a binary file", as instructions to remove the data from a textfile is easy enough for most users.) Software registration is a game of 90%'s, so eliminating 90% of potential copyright infringers is about as good as you can get for reasonable effort. For people who _do_ tell Zonealarm to not allow the program to connect, a nag screen on startup to the effect of "This software has not verified its registration, click OK to continue" will get another fraction or two to register -- admittedly, it would be a pain if the company went out of buisness, but it doesn't have any bearing on the functionality of the software, especially for something noncritical like a game.
Running the software on a computer without internet access at all is another possibility of getting aroud the auth scheme, but that's becoming increasingly less likely as time goes on -- more and more computers are getting connected in some way, shape, or form, and shareware is largely distributed over the Internet now anyway.
Admittedly, this isn't a 100% perfect solution to the tradeoff between infringement-possibilities and functionality in the face of bankruptcy, but I'd guess that it's 80% of the way there, and it would require no changes to the keygen routines themselves.
--
The ideas expressed in this writeup are expressly placed into the public domain.
"Evil company X is threatening to restrict our rights! Let's all get together to stop--OOOH! SHINEY!!!" -- AC
True shareware has absolutely no limitations whatsoever. I would still consider software with nag screens shareware, but I suppose that might be something of a grey area.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Of course if you find where in the code this all happens, you just patch the binary to jump right around it and that's the end of that story.
A quick run on Dict.org to check shareware.. well, according to this, I was somewhat right. Again, there is not a definition that will be accepted by everyone.
/sheir'weir/ {Freeware} for which the author
From The Free On-line Dictionary of Computing (13 Mar 01):
shareware
requests some payment, usually in the accompanying
documentation files or in an announcement made by the software
itself. Such payment may buy additional support,
documentation or functionality.
See also {careware}, {charityware}, {crippleware},
{guiltware}, {nagware}, {postcardware}, and {-ware}; compare
{payware}.
{The Conception of Shareware
(http://www.halcyon.com/knopf/history.htm)}.
[{Jargon File}]
(1997-10-11)
geek page at KY speaks
Pricing lower only works if pricing is an issue. For some users, any price is too much. For other users, you can charge quite a bit. From what I've seen, piracy is mainly an issue for popular software, where people who fall into the first camp publish kracks/keys, which are then used by the second group...
That's where the real revenue hits come in - when downloading the key/krack is easier than registering, and users who would have paid, if they had been forced to, take the easy way out.
BTW, there was a brief experiment done by a shareware author (Colin Messitt), who inserted code that would cripple his app for half the users, and have full functionality for the other half. Who would get which version activated was totally at random. One of the observations from this experiment was that the crippled version had a MUCH higher rate of registration/payment than the non-crippled version. The price for the utility was $25. A copy of the article is here (google version).
Mind you, if you release "true" shareware (no restrictions), you essentially provide the "krack", and can fall victim to users just being too lazy to register (or falling victim to the perception that since they can use the software for free, that's all its worth.)
This isn't true of all users, of course. But the grim truth is that there aren't enough scrupulously honest users out there that value your software enough for you to build a thriving business without some protections in place (at the very least, some sort of nag.) Most of the shareware authors I know would agree with me on this point.
I can crack this protection (and have done so many times) in my sleep. How? Just NOP the comparison function and ret 1 (or whatever).
Support T(H)GSB Apr 21-27, 2002
Shareware is perhaps the largest abuse of the legal system. Not only does the software developer retain most rights to the software, they forbid their customer the right to use the software for any purpose. Whether by locking out certain functionality ("crippleware") or by having a legal clause saying that the user must delete the software after a certain amount of time.
Shareware authors must have a distorted belief that software users deserve no rights at all without direct compensation. Then they might allow their customers the right to use the software and thats all. They still forbid rights to modify and distribute the software. This seems to me to be rather a large breach of ethics.
Good thing we have free software and can avoid all this crap.
If these people want money, they should just sell their software like all the rest of the shrink-wrapped crap out there.
I mean, I donno their system seems well designed, but the whole point of 'shareware' is to share it... It's extremely disingenuous to bitch about piracy.
autopr0n is like, down and stuff.