outer@utcsrgv.UUCP (Richard Outerbridge) (10/25/83)
See SCIENCE, Volume 221, No. 4617, p1279, 21 September 1983 "Scheme to Foil Software Pirates" The article describes a new method of protecting floppy-disk software developed by Adi Shamir and called "...a very clever idea" by Ronald Rivest. The manufacturer uses specially-modified disk drives to put "soft" bits on his disks (bits that a normal drive cannot reliably read) and the program when executing reads the special tracks to make sure that the bits ARE unreliably recorded. The trick is that if the disks are copied the "soft" bits will become random "hard" bits (because normal disk drives only write unambiguous bits). The copied program will detect that the "coupon" tracks have become certain, and can take evasive action. What's more, the original program can selectively write over the "coupon" tracks (again, resulting in unambiguous bits) and so keep count of the number of times the program has been used; like a postage meter, when all or most of the "soft" bits have become "hard", the program can "expire". Neat, huh? csrgv!outer @ U of Toronto CSRG
jpm@bnl.UUCP (John McNamee) (10/26/83)
While that is different from previous protection methods, if I was still in the disk cracking business I would get around it the same way I always did: Transfer the program to a "normal" disk and run it from there. No amount of screwing around with the disk format will stop good disk hackers from moving the program to a non-protected disk. John McNamee uucp: ..!dexvax!philabs!sbcs!bnl!jpm Arpa: jpm@BNL
wolit@rabbit.UUCP (10/27/83)
> While that is different from previous protection methods, if I was still > in the disk cracking business I would get around it the same way I > always did: Transfer the program to a "normal" disk and run it from > there. No amount of screwing around with the disk format will stop good > disk hackers from moving the program to a non-protected disk. > John McNamee Wrong. The basis for the protection is in the program itself, which quits running if it detects that it is being run from a "normal" disk (or an "expired" one). There IS a way around the problem, i.e., attack a copy of the object code with a disassembler, remove those sections that implement the protection scheme, and put it back together, but that is beyond the means of most "Space Invaders" players. Jan Wolitzky, AT&T Bell Laboratories, Murray Hill, NJ
outer@utcsrgv.UUCP (Richard Outerbridge) (10/27/83)
The disks ARE normal! You can make as many normal copies as you wish, but none of the "soft" bits will survive the transfer. To beat the system you need to have special disk drives, which can "write" indetirminate bits, OR hack around in the object code and eliminate the randomness-checker. Both are possible for a dedicated disk-cracker, but the scheme is mainly aimed at the casual pirate. Richard Outerbridge U of Toronto utcsrgv!outer
thomas@utah-gr.UUCP (Spencer W. Thomas) (10/27/83)
But the point is that the program will refuse to run if 1. the disk you ran it from is not in the floppy drive. 2. the disk has the "funny" bits on it in the proper location. Thus, copying it to a normal disk will NOT work. You would need a specially modified floppy drive which can write the funny bits. =Spencer
karn@eagle.UUCP (Phil Karn) (10/28/83)
Ah, but it only takes one hacker to remove the "security" code and make copies that end up in the hands of the "space invaders" crowd. Ignoring the obvious impracticality of "modified disk controllers", it wouldn't be too hard to put a "trap-on-write" into the I/O section of an operating system such as CPM to discover where the disk rewrite was being done. Phil
jjb@pyuxnn.UUCP (10/31/83)
>From my experience, it's not "random bits" that are used to protect
software, by badly formatted sectors. The program is unable to read these
sectors and thus if it does not detect an error condition when trying to
read them, it abends. The computer on which this scheme is used extensively
is the Atari on which the typical user with an 810 drive cannot write bad
sectors. Until recently, the only way around this scheme was to
disassemble the code and find out where the IO calls were made and to
NOP them out.
Jeff Bernardis, AT&T Western Electric @ Piscataway NJ
{eagle, allegra, cbosgd, ihnp4}!pyuxnn!jjbjpm@bnl.UUCP (John McNamee) (11/01/83)
From: jpm@bnl.UUCP While that is different from previous protection methods, if I was still in the disk cracking business I would get around it the same way I always did: Transfer the program to a "normal" disk and run it from there. No amount of screwing around with the disk format will stop good disk hackers from moving the program to a non-protected disk. From: mark@umcp-cs.UUCP The normal disk will not have random bits, the program can detect this (by reading the disk) and so refuse to run. Of course the program would have to be modified to not look for the random bits, but that is quite easy for a good hacker. The disk controler has a certain set of ports assigned to it and a monitor program could easily be used to search for references to that area.
dmmartindale@watcgl.UUCP (Dave Martindale) (11/02/83)
This sounds like a good way of preventing the use of copied disks. However, it is possible to write tracks which will read just unreliably enough that they are demonstrably unreliable on all possible drives? A purchaser of a legitimate copy of the software would be pretty annoyed if his drive was sufficiently better or worse than average that the program refused to run.
john@hp-pcd.UUCP (John Eaton) (11/04/83)
#R:utcsrgv:-255700:hp-pcd:42000001:000:1270 hp-pcd!john Nov 3 08:49:00 1983 Such a scheme might be implemented by lowering the write current to the disk head to a low enough level to "guarantee" unreliable reads. The tricky part may be doing it in a production enviorment. If the current is to low then some customers marginal drives may not pick up anything. If it is to high then some customers high performance drives may actually be able to read the data. It would be interesting to see how big the window is where that scheme would actually work. Another method that may work would involve changing the timing of the data pulses. A disc controller expects to see bit transitions at certain discrete times and creates a clock signal that places these times in the center of a square wave.Instead of writing a bit that would occur in the center of the clock you write one that occurs exactly on the edge of the clock. Depending on disc speed and various other factors that bit could be picked up as either a one or a zero. While such schemes may be a good way to keep your space invaders game out of the public domain,I would never buy a critical piece of software that I needed if it were copy protected. There are times when you just cant wait a couple of days for someone to replace a worn out disc. John Eaton hplabs!hp-pcd!john
henryb@microsoft.UUCP (Henry Burgess) (11/04/83)
Perhaps an additional hardware device would help. I am thinking of little holes in the midia that could inexpensivly be read but would be difficult to copy. Each disk would have a serial number assigned by the disk maker and punched as holes in the midia. The software vendor would use the this number as some kind of key when producing the disk.
jac@allegra.UUCP (11/05/83)
subject:software piracy-coupons and other methods.
Jonathan A. Chandross (BTL MH)
As a software pirate I was bemused to read of the new
methods which you people seem to think will stop software piracy.
SOUNDS LIKE THE METHODS CURRENTLY IN EXISTANCE (ALMOST).
The methods currently in existance are:
1) Non-standard DOS (disk operating system)
This means that the disk is written in such a way that only
the companies load routines can access it.
2) Nibble-count
The number of bytes on a given track (or tracks) is known.
When a copy is made, the number is different, and the progran
senses this and refuses to boot, erases itself,.....
3) Serial numbers
Removing serial numbers is so trivial that it doesn't even
bear mentioning.
I have little or no trouble removing the protection on these
disks. There are other methods, but they get complicated to explain,
and I don't think that this is the time or the place to explain them.
What my friends and I do is allow the program to load, and put it on
a normal disk after removing nibble count checks, DOS checks .....
In other cases (ie non-total load) we merely transfer all of the files,
or copy the disk preserving the nibble count.
Any time that someone comes out with a new method of protection,
it is usually out on the streets stripped of its protection inside of a
few months. I happen to think that these guys (meaning the proponents
of the system ) don't know what the Heck they are talking about.
Putting on "bad" sections on the disk is no problem to remove.
I know of one game which uses them. It took about 20 minutes to strip
the protection off of it.
Jonathan A. Chandross
Bell Laboratories, Murray Hill
Allegra!jac
NOTE: THE OPINIONS EXPRESSED ABOVE ARE NOT NECCESSARILY THE OPINIONS
OF MY EMPLOYER. NOR ARE THEY NECESSARILY CONDONED OR ENCOURAGED.john@hp-pcd.UUCP (John Eaton) (11/08/83)
#R:allegra:-194700:hp-pcd:42000002:000:1590 hp-pcd!john Nov 7 12:54:00 1983 Any program can be pirated if the pirate has the resources and determination to do it. The trick is to make the pirate spend more time breaking the scheme than it would take him to rewrite the program. Protection schemes that can be NOPed over are at best a minimal attempt at security. The prudent programmer will back up his protection schemes with code that verifies that the program is intact and unmodified. Several independent schemes are usually better than one. Progams that detect a copy violation and immediately go out and trash the disc or memory are inviting someone to backtrace and figure out how the violation was detected. A program is better off waiting 20 or 30 seconds after detecting an error to do something about it. That gives the pirate a few million more lines of code to sift through. Ideally the error condition should be "laundered" by passing it through several intermediate stages to make it difficult to figure out where it originated from. A really sneaky programmer will not wipe out the program if it is copied but will modify it enough to make it unusable. During program development you should save the worst bug that you find (you know the one that took 3 days of debugging to find) and reinstall it if the program has been copied. Perhaps you can even leave the bug in and have your copy detection routines remove it if its a legal copy. The pirate will always have the ability to break a program. The only thing that a programmer can do make the "Work Function" great enough to discourage the lightweights. John Eaton hplabs!hp-pcd!john
ajs@hpfcla.UUCP (11/09/83)
#R:allegra:-194700:hpfcla:14400001:000:937 hpfcla!ajs Nov 7 17:25:00 1983 There is a fairly reliable way to secure software, but (naturally) it takes more work. What you need is a machine serial number buried in [[E]P]ROM somewhere, readable by any application program. Now the software can check this number and refuse to run except on certain system(s). Finding and changing a serial number can be close to impossible. Of course, each copy of the software package must be configured to the system(s) it can run on. If you can do the right magic to the software, you can convince it to skip the serial number check, but then, if you can twiddle the object bits, all bets are off anyway. (On the HP9000 Series 500 we provide programmed-in serial numbers for customer use. They are readable via additional uname(2) fields.) Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado ucbvax!hplabs!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"
jlw@ariel.UUCP (J.WOOD) (11/10/83)
Sorry, but I disagree that even serial numbers buried in ROM are adequate for the serious pirate. I have access to a prom programmer here in the lab, and I can just take two machines' ROMs compare them and then make up dups for all my friends. If I'm a good enough circuit designer I could build a device which fits under the the ROM and provides a dial selector to be any machine I want to be. There is a truism here: "Anything I can physically get my hands on for long enough, I can crack." And you can quote me on that. Joseph L. Wood, III AT&T Information Systems Laboratories, Holmdel (201) 834-3759 ariel!jlw
john@hp-pcd.UUCP (John Eaton) (11/13/83)
#R:ariel:-51500:hp-pcd:42000003:000:1385 hp-pcd!john Nov 12 22:36:00 1983 The easiest way to install serial numbers is with proms or eproms that most pirates can find and duplicate. While not perfect it does limit your losses to those who are willing to modify their hardware. The user who would bootleg a program that could run on a unmodified machine might not do so if he had to change his hardware. To be truely effective, serial numbers should not reside in comercially available components and especially not in proms. The best method would be to take a DES encryption IC and add a second key register to it. The first key register would be the normal write only that allows you to encrypt different keys. The second would be a one time programmable (fused link) that would be programmed with the units serial number. When a copy protected program is installed in a machine, it encrypts a number of bytes using the units serial number as the key and saves the results. When running it can then repeat this and self destruct if the results change. One problem with this (and any other serial number scheme) is how do you handle a failure of the serial number IC. Any scheme must make it hard for a pirate to duplicate this IC but easy for a field repair center to do it. By the way, I am now expecting some pirate to write in and tell me how easy it is to pop the top off an IC and read the fused links using a SEM. John Eaton hplabs!hp-pcd!john