Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mailrus!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.sys.amiga Subject: Re: Pirates and swapware Message-ID: Date: 9 Jul 90 14:14:49 GMT References: <23720@snow-white.udel.EDU> <90188.203808LEEK@QUCDN.BITNET> Sender: uucp@ncr-mpd.FtCollins Organization: NCR Microelectronics, Ft. Collins, CO Lines: 73 In-reply-to: LEEK@QUCDN.QueensU.CA's message of 8 Jul 90 00:38:08 GMT LEEK> There are quite a few ways to crack pseudo random number. Even with LEEK> active circuit like shift registers or finite state machine, it is LEEK> still possible to crack the design. The cost of reverse engineering LEEK> would only slow down pirates. All you need is one person that crack LEEK> the system and the cracked version would be spreading like wild fire LEEK> (if the protected program was good in the first place.) Looking for a challenge, eh? ;-) >Is trivial to defeat. Better would be to use sucessive values from the >active circuit/PROM to initialize many (perhaps 100s) of constants needed >for useful execution of the program. Now there are lots of calls that must >be circumvented and the cracker must determine in each case what constant >the program expected. (HINT: Not every constant need be 0 or 1.) LEEK> So what constants to put in ? Almost any non-toy, well written application will have many constants already. (e.g. Look through the AmigaDOS header files.) Something having the size and complexity of a "hello, world" program, I consider a "toy" program and not worth the effort of protection. LEEK> Wouldn't the constants be dependent on the applications ? Bingo. LEEK> Not everyone needs speed of light or electron rest mass LEEK> in their program... In fact, constants like "pi", "e" and "the speed of light" are exceptionally _poor_ choices for encryption precisely because they're easily guessed. >The most effective suggestion I've heard so far (sorry I don't recall your >name:-(), is to make a memory image of the running program. However, if LEEK> Kind of hard if the program is running in a shared memory style LEEK> multitasking machines with half a dozen memory configuration unless LEEK> it make stupid assumptions about the hardware configuration of the LEEK> machine. (This is a BIG NO-NO !! ) Hmm, a cracker preoccupied with portability. I admit I hadn't seriously considered the possibility. :-) Actually there has been a product _already advertised_ to create executables from memory images on the Amiga. Check out the current issue of "Amazing Computing". No, I don't own it. LEEK> What about a new floppy drive controller that can handle variable LEEK> data rates ? ... Supposing a program is written with a particular LEEK> data rate than can only be read off but cannot be written (and hence LEEK> duplicated) easily with a standard Amiga drive.... This can be circumvented by using specialized hardware, as I had pointed out. Ultimately _something_ has to be able to create the disks. I'm told you can read at a higher data density than you can write on an Amiga floppy drive, but even this can be circumvented by slowing down the drive via software. Perhaps one of the disk drive gurus out there would care to elaborate. No matter what form of disk based protection you use, disks themselves have a shelf life based partly on how often they are used. Eventually they wear out. Worse, some disk based forms of copy protection actually accelerate the process. _This_ more than any other reason, is why I object to disk based copy protection _on productivity software_. If I lose a game program, I've only lost the game. If I lose a productivity software package, I may lose man _years_ of effort. #include Another $0.02 from, -- Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp