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)?
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
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
"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
>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
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 email@example.com
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 firstname.lastname@example.org,001,20020713,o,j38dh
or cat together to create
joe at email@example.com
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)
Then convert this to something like base 34 (or something like that)
where each digit in base 32 in ascending order is:
or perhaps you move the characters around in your base 34
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.
More information about the use-livecode