Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site pyuxss.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxl!mhuxm!pyuxi!pyuxss!aaw
From: aaw@pyuxss.UUCP
Newsgroups: net.micro
Subject: Re: Software Piracy and Coupons
Message-ID: <207@pyuxss.UUCP>
Date: Fri, 11-Nov-83 12:53:44 EST
Article-I.D.: pyuxss.207
Posted: Fri Nov 11 12:53:44 1983
Date-Received: Sun, 13-Nov-83 05:33:14 EST
References: <3732@duke.UUCP>
Organization: Bell Labs, Piscataway
Lines: 21

The only reason it is possible to break software protection through
ZAPs is that traditionaly software producers have an aversion to
degrading their code with protection mechanisms. It is a SMOP to arm
high level language or assembler source that isn't baroque with a
collection of cross referential defense mechanisms (are you there?
good, I'm replacing you-go and fix the code in the routine that you
are responsable for); if the code is large enough, a hundred or so
sentinals of this sort and a few phony ones  could be determined to
take about the half life of the system to unravel; for references see
the available literature on bebugging theory (a slightly different
field but very related, also called 'intentional failure') this is
based on the attempts to determine the number of faults (=bugs) in a
system by inserting a number of known faults of specific type and
placement and determining the ratio of inserted faults detected/ total
inserted.
If anyone feels that this scheme of code mutation/guardhouses with
cross reference (put as many useful constants inside the guardhouses,
as part of the code... etc. etc.) I'd like to hear why. Any comments
about...well it would take to much time/space... please note details,
comparisons with schemes in practice or real evidence.
	Aaron Werman	pyuxi!pyuxss!aaw