Passkeys and registrations

Shari gypsyware at earthlink.net
Wed Sep 25 18:26:01 EDT 2002


>Hey, Shari... if it's not too proprietary, could you tell us what you ended
>up doing? Some of us might be interested in protecting our stacks in the
>same way...
>
>Thanks,

The registration code is stored in a embedded stack, which is 
password encrypted.  This prevents people from reading the code with 
a text editor.

The hack test was a very simple one.  I opened the standalone with a 
text editor and attempted to change the code.  By either adding an 
"answer" handler, or changing an "answer" handler to say something 
else.  I even tried changing only one word, to a word of the same 
length, in case it was looking for a length match.

When I tried to launch the program, it would not launch.  This is 
something within Metacard's code, not mine, that performs the 
checksum that fails when you try to change the code.  This was good 
news, as I'd heard you could hack a program this way, but had never 
tried it.  Opening a standard program presumably written in C, no 
code was visible at all.

It is quite unnerving to see your program's code all laid out nice 
and pretty in a text editor, for anyone to read.

Any piece of code that relates to registration, or checking 
registration, is stored in a password encrypted stack.  This hides 
the code from text editors.  Actually it encrypts the code, turns it 
into gibberish.

Password protection is easy.

In the stack's object window, there is a PASSWORD button.  You then 
set the password.  Whenever you open that stack, you must click the 
PASSKEY button (the Password button becomes a Passkey button) and 
enter the password.  This temporarily allows you to edit the stack. 
Once you save and close the stack, the password automatically goes 
back into effect.  And the stack cannot be edited, nor the scripts 
read, until the password is supplied.

Note that if the stack needs to store data, you will have to store 
the data somewhere outside the stack.  I was not able to enter data 
into a field, or make any modification to, a password protected 
stack, without first supplying the password, which I assume can't be 
done from within a script.  My attempts to store data in the stack 
failed.

Obviously you can store big chunks of your code this way, as long as 
the stacks that contain the code don't need data changed or stored in 
them.

Password protecting the main stack, encrypts all of the stacks 
within.  Which broke my program.  So I moved any critical code from 
the main stack, to an embedded stack, and encrypted it.

As for my actual registration system, that part is proprietary :-) 
I've read many shareware authors newsgroups, articles on protection, 
articles by well known shareware authors, and whatever else I could 
get my hands on, and created a very detailed registration system made 
up of bits and pieces of all I read.

Nothing is hack proof.  Just as no house is burglar proof.  But you 
can make it a lot harder, so that only a very anal hacker with a lot 
of time can break in.

One thing many authors do, which is a very big no-no... is to create 
a code based on the user's name.

John Doe = registration code 12345

Anybody can post that info on the net, download your program, type in 
John Doe for the name and code 12345, and instant registration.

Find another way!  Find a way to prevent people from giving out their 
user name and password.

Recommended newsgroups:

alt.comp.shareware.authors
alt.comp.shareware.programmer
comp.software.shareware.authors

You will wade through a lot of philosophy and a few wars, but many 
jewels make their way into the posts, and often links to articles and 
detailed info will be posted as well.

Read everything you can, and ask yourself if the advice makes sense. 
Try to think of ways someone could "workaround" your system, and do 
whatever you can to prevent that.

I also read the Kagi mailing list, as I'm a Kagi author.  (Kagi is my 
payment processor.)

Shari C
-- 
--Shareware Games for the Mac--
http://www.gypsyware.com



More information about the metacard mailing list