🚀 go-pugleaf

   >The point of entry I'm using is the fact that software is interactive.
   >A single use of a piece of software doesn't reveal all of its intricacies 
   >(unlike a musical number or a novel).  We can therefore hope to force
   >a contact with a host machine H during each unique run of the program,
   >enabling us to insist upon payment.
	[....]
   >The key to success is "cryptographically strong code shuffling" which
   >gives a cryptographic guarantee against disassembly, or more precisely,

In article <Byz911.2Lo@sneaky.lonestar.org> gordon@sneaky.lonestar.org (Gordon Burditt) writes:

	[ much discussion on whether anyone would *want* pay-per-view
	software, ways to break implementations, ways that protection
	makes use of the software annoying at best, etc.]
   This description sounds suspiciously like many MS-DOS viruses.  I suspect
   that it will be equally popular.
   If the CPU can execute it, it can be disassembled.

   ....
   So who says the OS lets the application do self-modifying code?  Or
   read its own code?  And the debug monitor can disable the checking code 
   when the program enters the "contact host & verify" routine, and put it 

You can *always* build self-modifying code -- use an interpreter,
and include the real program as data -- as long as performance
isn't too critical.  If you only need a couple of MIPS of CPU,
and you've got a RISC or 486/50 or DSP processor, you can write
the program as p-code or LISP or (shudder) BASIC or Forth,
or roll your own interpretive system which is more amenable to
running scrambled.  Still don't know if you can solve the problem,
but at least you've got another tool.
--
#				Pray for peace;      Bill
# Bill Stewart 908-949-0705 wcs@anchor.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Nov 12 - Anniversary of Indonesian massacre in East Timor, 1991
# Indonesia first invaded in 1975, and about 1/3 of the people have been killed.