From: medici@dorm.rutgers.edu (Mark Medici)
Newsgroups: bit.listserv.novell
Subject: Re: execute only flag
Date: 5 Jan 93 05:39:47 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I  agree  with the sentiment  that  there  needs to  be better ways to
protect copyrighted  software  from illicit duplication.   However, as
much as  I would like to  see Novell  make  some improvements  in this
area, I don't think it's fair to admonish them for the shortcomings of
MS-DOS.  Further,  having  survived (just barely)  the  era of  ultra-
facist copy protection methods, I certainly don't want to see a return
to popularity of the unwieldly mechanisms of the past.

It  is  true that MS-DOS and standard MS-DOS programming practices  do
not facilitate user-supplied copy protection.  Novell's "Execute Only"
attribute is a worthwhile  and useful tool for protecting software  in
certain circumstances.   I find that I  am able to protect the primary
executable file using  "Execute  Only" for about 70% of my non-Windows
software (Borland's stuff is a notable exception).  It  is conceivable
that Novell  could improve this feature, and such an improvement would
be of great  advantage to  Novell, but it seems they  have their hands
full on other, more profitable matters.

There are three ways I can think of to protect network software:

  1. Load TSRs  that  intercept all file/disk I/O and  check that  the
     operation  is permitted.   Determining when  a program is  legit-
     amately  reading large chunks of a  file versus  when  someone is
     trying  to  pirate the  files is  difficult,  but not impossible.
     I know  of  two commercial products that do exactly this and  are
     available now:

	Fischer Scientific's "WatchDog/PC" (also a Mac version);
	Silver Oak System's "IronClad"

     Of course, if these capabilities could  be built-into the NetWare
     redirector, which is already intercepting all file and  disk I/O,
     I  would  imagine  better  performance,  reliability  and  memory
     utilization  would  be  gained.   Perhaps  Novell  will  consider
     licensing this technology  (or just buying the whole  company) to
     add value to NetWare.

  2. User modification of each  executable in  the  same manner that a
     virus might do, so that special copy-protection (and, at the same
     time, usage metering) code is executed each time  the  program is
     run.   This additional code  might check  for  the  existance  of
     certain files that only occur on that one server, might perform a
     network API call to check the  server OS serial number, or  might
     make a  call to an NLM/VAP on the server  (or  a central "license
     server") for authorization to run.

  3. Developer  modification  of  software during development  so each
     main executable would make a network API  call for  an  available
     license each time  the program was run.  This was proposed a year
     or so ago  separately by the  Microcomputer  Managers Association
     and the NetWare Masters Group  (the latter of which seems to have
     faded  from  existence shortly  thereafter).   The  APIs  on  the
     application end would work similarly on any major network system,
     with an NLM/VAP or equivalent handling the  authorizations.

  4. Normally disallow read privs to all software, but have  an NLM on
     the server  and  a corresponding utility program to call the NLM.
     Theutility would be run from a batch file  or set-up as a Windows
     icon  (wearing the name and icon from the target program)  before
     the targetprogram is run.  This utility would  send a call to the
     NLM, which  in turn would check that a license was available  and
     then grant  additional rights  to that  user to run the software.
     When done,  the utility would  be run  again  to  remove  rights.
     Thus, the  userwould only have rights  to read the file when  the
     program was being run.   I  believe there  is already  a software
     metering  program  available  that  does  this  (Funk  Software's
     AppMeter?).

Case 1  would prevent the software from being  copied.   Case  2 would
allow the  software to be copied, but would prevent it from being used
unless the workstation running the software could communicate with the
server the software was originally installed  on.   Case 3 would func-
tion as #2, but with the additional security and reliability from  the
necesasary modifications being implemented and supported by  the soft-
ware  developer.  Case  4 would probably the easiest to implement, but
also the least secure  as users might  be able to "shell out" of prog-
rams then copy them (and I don't like the idea of a client workstation
being able to request and get security changes on the server).

Anyway,  it's clear there are shortcomings to the present copy protec-
tion capabilities of  MS-DOS and networks that operate with it.  There
are also some  solutions available now to help  improve the situation,
though  at a considerable  cost in dollars  and memory (and, possibly,
compatibility).  Perhaps Novell or some third party  will get the idea
and come up with  a solution that is more acceptable,  though the lack
of  movement  on  the  MMA/NMG's network licensing API  recommendation
leads me to believe this won't happen soon.
-- 
_________________________________________________________________________
RUCS     | Mark A. Medici * Telecommunications Analyst II * User Services
User     | Rutgers University Computing Services, New Brunswick, NJ 08903
Services | [medici@gandalf.rutgers.edu]                    [908-932-2412]
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU