Thoughts on registration and software protection for PalmOS apps
by Ron Nicholson, HotPaw, <http://www.hotpaw.com/rhn/palm/ >
First note that the customer base for PalmOS applications is constituted by
all different kinds of people. Different ethics. Different nationalities.
Different personalities.
Some people actually send in voluntary payments for freeware
applications (I've gotten a few). Some will read the documentation that
comes with non-nagging donationware, and send in their payment. Others
are basically honest, but will (sometimes or often) forget to pay for
software when they can install a copy "temporarily" for free and
there is no reminder. Some are less honest, can't afford a particular
software application, or are just cheap. Others will actually seek out
"cracked" copies of registered and commercial software, whether or not
they actually use the software; they just collect the stuff.
And there are a few who take it upon themselves to crack any
protected/disabled product. And I do mean any; it's a challenge. It's
likely that no protection scheme is truly secure, given that students
have broken into commercially hardened cryptographic smart-cards having
built-in self-distruct circuitry by reading plaintext bits directly off
cryogenically cooled transistors using the scanning atomic microscopes
found in the universities labs. Using POSE to dump a 68K instruction
trace is child's play by comparison.
So what's the value in somehow protecting software from being freely
usable? The answer is in the fact that there *are* a range of types of
potential customers. There are some who are honest, some who aren't,
some who are lazy, some who would never participate in a war3z chat
rooms, and some who do.
Basically, there is a yield curve, where the more encouragement there
is, caused by making the application less easy to use freely, the
greater the percentage there are of people who will pay. Where there is
disagreement is on the shape of this yield curve. My guess is that there
are a large number of software users who will "forget" to pay without
some simple encouragement, but that the number of additional paying
customers one might get from a really hard to break cryptographic
protection scheme is much smaller. e.g. the curve is probably reverse
"hockey stick" shaped, where any simple user-friendly registration
scheme will get a lot more paying customers, but that the returns
diminish quite rapidly past some point in protection effort. But there
are many who disagree with this analysis.
One important point is that there is also a cost of protecting
applications. There is the time-to-market cost. There are competitive
costs. You can spend time adding protection schemes, while your
competitor uses the same time to fix more bugs and add more features and
thus takes away your market share. There can also be a quality or
user-friendliness cost (protection code can causes crashes, can
sometimes have hard to follow registration procedures, requires more
time to reinstall applications after crashes or upgrading to a
new/replacement model, etc.) Some don't use protected software on
principle. Some run only open source software. And some even think
that software theft can actually add value to a business (Bill Gates got
his first taste of owning the defacto standard software product because
Altair 8080 Basic was widely "stolen").
So what are some registration options? There are many:
One can:
just write freeware (and maybe sell support or documentation),
just ask for payment in the documentation or about box,
have a nag screen occasionally, or at startup,
disable features, amount of data, or play levels, etc.,
disable features after a certain amount of time,
disable the entire application after a certain period of time,
only distribute the full executable after receiving payment.
One can fully enable a distributed application:
always,
with a simple checkbox ("I payed"),
with a hidden checkbox ("secret" sent after registration),
with a magic word,
with a registration key database (prc/pdb),
with a shared library containing part of the apps actual code,
(all of the above will appear on a chat board before
an application is broken.)
with a code keyed to the UserName (just checksums or fancy crypto),
with a code keyed to the hardware ID,
with a hardware dongle,
with a custom OEM ROM if you are a Very Big Company.
Internally, one can just set a bit saying "I'm registered", store a key
plaintext, or store an encrypted copy of the registration key. One can
check for the reg bit or the key in one place in the Startup code (easy
to patch), in several places, or even encrypt portions of the data or
the applications actual machine code.
There was one Apple II game that had 7 levels of encryption of the
applications executable code, all different (the scheme was broken).
You can store registration information and expiration dates:
in the Saved Preferences DB,
in a saved pref belonging to some other application or creator ID,
is a Feature Manager feature,
in one of your applications databases,
hidden in some other applications database,
in the standard DateBook, AddressBook, MemoPad or ToDo databases,
even in some undocumented (and unsupported!) OS data structure.
Note that some people will complain about any or all of the above. The
question isn't about whether they complain, but what percentage of your
customers they might constitute and whether you consider this technique
ethical. There are some people who noisily complain (mailing lists,
usenet, palmdev, etc) about leaving preferences behind, but they
probably constitute a tiny percentage of users. ( Note that I am the
author of a freeware Preference utility.)
My personal preference is for registration schemes which are not
convenient for typical non-techie office workers to share over the water
cooler, but that waste no development time in making it a more fun game
for kids who frequent the warez sites and chat rooms. Take that
development time and instead make your application more marketable and
higher in quality.
I suppose the reason that there isn't a standard reg code library is that
any well documented scheme (XOR UserName with bytes XYZ from the Saved
Pref, etc.) would be too easy to mechanically break.
The above is purely IMHO, and
Copyright 2000 Ronald H. Nicholson, Jr.
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
