NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/programm/12854

Internet Message Format | 1992-07-22 | 3.2 KB

Path: sparky!uunet!stanford.edu!rutgers!dziuxsolim.rutgers.edu!gandalf.rutgers.edu!rgonzal
From: [e-mail] (Ralph Gonzalez)
Newsgroups: comp.sys.mac.programmer
Subject: Re: how to put indelible serial# in resource fork of app?
Keywords: serial#
Message-ID: <[e-mail]>
Date: 22 Jul 92 18:59:09 GMT
References: <[e-mail]> <[e-mail]>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 52

[e-mail] (Jamie R. McCarthy) writes:

>Write a quickie program that lets you select an application with the
>standard file box, then have it make n copies, adding a serial number to
>each one.  Since it's a quickie, you can hard-code both n and the serial
>number to start at, and no one will know the difference but you.  :-)

>It's pretty easy to make it "unchangeable."  Make a routine that converts
>a 32-bit number into a moderately long (say, a 32-byte) code.  Make it
>so ridiculously weird and complicated that no one will ever be able to
>figure out what in the heck you're doing.  Then have the app check to be
>sure its code can be derived from a real 32-bit number;  if so, that's
>the serial number;  if not, put up a nasty message and exit.

Thanks, and thanks to the others who responded via email.  The consensus
was that I should write a program which sticks serial#'s into the
resource fork (or the data fork!) of the applications.  The serial#'s
should be encrypted and a checksum should be embedded in the resource
as well.  Preferably this info should be in a non-obvious place,
such as a CODE resource.  Several interesting alternative schemes
were suggested as well.

Also, it appears to be a good idea to have the user enter their name
the first time they run the program, and display it in the startup
screen after that.  This helps "shame" non-registered users.

QUESTION 1:  Is it ok to store this name in the application's own
resource fork?  I know this is normally discouraged since the app
may be on a read-only fileserver, but for product registration you
don't want to just store it in the Preferences file where everyone
accessing the fileserver gets to register their own name...

QUESTION 2:  It occurs to me that if someone is going to get hold of
someone else's serial#, then they will probably steal this person's
copy of the software as well.  Therefore it doesn't help that each
copy of the software has its own serial# encoded into it.  Rather, it
should be sufficient to have the application request a serial #, and
run it through a scheme (such as that suggested by Jamie McCarthy,
above) which checks if it is a valid serial# -- RATHER THAN CHECKING
IF IT IS THE "CORRECT" ONE.  For example, ask for a 10-digit number
of which only 1000 combinations are valid (assuming you won't sell
more than 1000 copies!).  This saves you from having to attach a
unique serial # to each copy, and bundle it with a manual containing
the correct serial # -- a hassle if someone else is doing the
duplication for you.  Is this a common approach?

-Ralph

--
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: [phone]; Internet: [e-mail]
--