shareware/demoware

Kee Nethery kee at kagi.com
Thu Jun 13 18:50:01 CDT 2002


>I've been wondering how to password-protect my Rev project for 
>shareware distribution.  Maybe regcode-protect would be a better 
>term, since I'm not talking about only locking the scripts.  I've 
>posted questions several times on this topic and haven't seen any 
>good solutions that cover all platforms.
>
>As a fall-back position, I'd like to at least password-protect my 
>stacks that I compile for Windows (alas, that is the bulk of my 
>target audience).  I don't know anything about the Registry, but... 
>Can I write a username to the Registry and auto-generate a password 
>based on that?  If so, what are the pros and cons?  What are the 
>potential headaches with upgrades or users moving to a different 
>machine or hard drive?  Can someone give an example (something like 
>Ken Ray's tip win002)?
>
>
>-- D




I'd suggest that you use their email address as the seed for 
generating a reg code. I'd suggest you send the reg code to that 
email address. I suggest that they enter both their email and their 
reg code into the program to deactivate the protections.

I agree that you should add a sequence number into the data so that 
you can provide several unique keys to the same person and have the 
keys be unique.

Using the drive serial number is a possible solution but you have to 
keep in mind that people do upgrade their hard drives and you'll 
spend time administrating reg codes instead of focusing on building 
your business.

if the product lives on the internet, doing an internet password 
check is possible but you really want to make sure that people are 
aware that is what you are doing. People are very suspect of software 
that communicates out over the internet to be able to operate.

You are not going to prosecute people who give away serial numbers. 
Ain't going to happen. The FBI in the USA has a threshold of $40,000 
so unless your software is way too expensive for me, the most 
effective thing you will do to pirates is deactivate their reg number 
in future releases.

One cool trick I liked is for you to issue a crack for your software 
to crack boards before someone else is able to do so. Make sure the 
crack works, for a time. That removes the incentive for someone else 
to spend the time to crack your software. Why would someone want to 
be the second person to crack your software?

Ambrosia software embeds a date into their reg codes. You have to 
enter the reg code into the software before that date expires. After 
that date, even if they give out the reg code it cannot be used 
elsewhere.

"Registered to Jane Doe of Doe Corporation at (313) 555-1212 whose 
address we have on file" only works if you have a human looking at 
each order. If not, someone will buy it with a stolen credit card 
number and the text string will say "Registered to AAA BB of CCC 
Corporation at (222) 555-1212 whose address we have on file" which is 
not going to have the desired effect.

>My own pursuits along these lines stop at those sufficiently difficult
>to dissuade the casual thief.  Beyond that seems a case of diminishing
>returns, and I'd rather put my development time into bullet-point
>features.

>So my recomendation is unless your Adobe or Microsoft or something,
>don't spend too much time on it.

Both of these statements are EXTREMELY TRUE! Some of the most 
successful software we sell has some of the lamest reg code 
algorithms you could imagine. You can devote days trying to keep 
people who would never pay for your software from using it OR you can 
spend days trying to provide just enough incentive for potential 
paying customers to want to pay. I highly recommend you focus on 
getting people hooked on using your software and providing just 
enough protection to get them to pay (if they might ever be paying 
customers). The time you spend trying to defeat crackers is mostly 
(not always, but mostly) wasted time.

With Kagi you can run server side code to generate reg codes. 
<http://www.kagi.com/acg> has specs on our automatic code generation 
CGI framework. Essentially it is a CGI. There is a Perl example and 
if you ask we can provide you with the C example. A Java example is 
on the way. If you build a HyperTalk based algorithm, we can run that 
also. We run hundreds of algorithms for folks. They code it, we run 
it. We run algorithms on Mac MacOSX WinNT and Linux.

My recommendation, keep it simple and move back to productive work.

Here is a sample algorithm that I just now dreamed up. How about 
something like:

Data elements = user email, a sequence number, an expiry date, 
license type, misc data for future use.
User email = if the email provided doesn't contain "@" or a "." then 
don't calc a reg code. Repeat the user email until you have at least 
20 characters. Truncate the email element at 20 characters.
joe at acm.org = joe at acm.orgjoe@acm.o
sequence number = three digits for example: 001
Expiry date = YYYYMMDD for example 20020713 for july 13th 2002
license type = one character,for example: o = one machine, s = site 
wide license, e = evaluation and perhaps it expires 3 months after 
the expiry date, etc.
Misc would be some piece of data that you use for other stuff. Say 5 
digits. Perhaps for eval units you put the number of days after the 
expiry date that the product will function. For a site license 
perhaps you put a number and your software does a DNS lookup of 
<number>.lord.com which points to a server on their site behind their 
firewall and that does key management for that site. Whatever. For a 
single license perhaps this is just a random set of characters.
So your key string takes; joe at acm.orgjoe@acm.o,001,20020713,o,j38dh
or cat together to create
joe at acm.orgjoe@acm.o00120020713oj38dh
next convert this to a number, for example: take the decimal ascii 
values for these characters and always pad to 3 digits.
106 111 101 064 097 099 109 046 etc
Then maybe cat the digits and reverse the string (for example, using 
just the digits shown above)
106111101064097099109046
640901990790460101111601
Then convert this to something like base 34 (or something like that) 
where each digit in base 32 in ascending order is:
0123456789ABCDEFGHJKLMNPQRSTUVWXYZ
or perhaps you move the characters around in your base 34
ASDFGHJKLZXCVBNMQWERTYUP0987654321
If you use upper and lower characters you can use base 58
Anyway, converting the long number to base 58 will reduce the number 
of characters to something reasonable.
Then display the characters in groups of four or five, for example:
AGHYU - 6Y45G - JUY87 - 6T6TY
and you have a reg code.
Can someone decompile your algorithm, yes. Does it matter, not really.


Protecting against crackers is a fun engineering problem but it is 
not going to get you more sales. The more time you spend on marketing 
to your potential buyers, the more you will make.

Kee Nethery
Kagi



More information about the use-livecode mailing list