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.
kermit%brl-vgr@sri-unix.UUCP (11/04/83)
From: Chuck Kennedy <kermit@brl-vgr> Yeah, it's a neat idea alright. But some customers may say, the heck with those "specially modified drives" and not buy them. -chuck
RALPHW%mit-xx@sri-unix.UUCP (11/04/83)
From: Ralph W. Hyre Jr. <RALPHW@mit-xx> Special drives aren't needed, just special software, which isn't too difficult to write. The only special equipment needed is the encoding equipment used by the manufacturer to write the soft bits on the disk. All this would do would inspire the pirates (who by now are used to having things their way) to hack their disk drives to also be able to write soft bits. Of course, this is a hardware modification, so I can see where it will reduce the problem somewhat. It's the same flavor as putting a program on a cartridge, so that you have to copy ROM chips to get a copy. (Because those crufty game programmers fix their games so they modify themselves as they run, which works with RAM but not with ROM.) Next we'll be seeing expert systems to crack protection schemes. - Ralph Hyre -------
towson%amsaa@sri-unix.UUCP (11/04/83)
From: David Towson (CSD) <towson@amsaa>
Chuck - I think you misunderstood the concept: As I read it, it's the drive
used for RECORDING the disks that is special, not the one used for playback.
I have not seen anything specific about how the "mushy bits" are made mushy.
If it is being done by reducing the write current, then it seems possible for
gradual degradation of the playback level due to disk wear, misalignment, or
whatever to cause some of the mushy bits to become hard zeros. If this
happens, legitimate buyers will find their programs bombing, and this will
lead to much antagonism. On the other hand, if the mushy bits are being
made by playing with the timing, then individual drive speed variations will
probably cause troubles for legitimate owners. Does anyone know the details
of the "mushy bit" recording process?
Dave Towson
towson@amsaaPGW%mit-xx@sri-unix.UUCP (11/04/83)
From: Paul G. Weiss <PGW@mit-xx> It seems to me that the following method would break the Shamir scheme: 1) First the pirate must get his hands on a "pirate diskette", which would be a diskette that is filled entirely with "weak" bits. All it would take is one shady character to obtain access to one of these "modified disk drives", for these to be churned out in scores. 2) Then the pirate's program goes through the disk to be copied, sector by sector. By reading the sector several times, he can determine whether weak bits or strong bits are written on that sector. If the sector is strong, he copies it to the corresponding sector on his pirate disk, overwriting the weak bits there. If the sector is weak, he does not copy it, since he already has weak bits in the corresponding sector. This depends on the assumption that the weak vs. strong areas of the diskette respect sector boundaries. If the protection scheme checks to see that there are both strong and weak bits in a given sector, then the above method would fail, as I don't know how to write less than a sector of data onto a diskette. However, it would seem to me that the task of making sure that specific bits in a sector were weak or strong would be a more complex task than merely recording a sector with many weak bits in it. Comments from hardware types, please? On another note, I have heard of a protection scheme that works by drilling a small laser hole in a sector of the diskette. The protection works by checking that the data in that sector is bad and that attempts to fix it by overwriting the sector will fail. Unfortunately, the protection works at the BIOS level on the IBMPC, which means that it can be broken by just replacing the relevant BIOS routines with pirate written routines. However, I believe that there is promise in such an approach. Any comments? -------
bcw@duke.UUCP (11/10/83)
From: Bruce C. Wright @ Duke University Re: Software piracy and coupons There is so much misinformation flying around the net about this that I feel I ought to get my two cents worth in. First of all, as several people have pointed out, it is not sufficient to write random bits for the "soft" bits - the scheme relies on re-reading the sectors and seeing *different* bits on each read. It might be possible (as one person suggested) to start with a disk with *all* "soft" bits and then write the good ones over it; I'm not sure exactly how the scheme is implemented and this might work. It would still require getting hold of such a pirate disk, though; it would still be impossible for the unadjusted disk drive to write such a disk. It might be possible for someone quite familiar with disk hardware to modify the diskette drive to be able to write such bits, though. All of this has little bearing on whether the proposed scheme is secure. I doubt very seriously that this scheme will slow down a really dedicated and knowledgeable pirate, disk drive modifications or no disk drive modifications. Personally, I haven't tried to crack any microcomputer protection schemes, though I've dealt with larger computers for > 10 years and have never seen a foolproof protection scheme. This goes double for systems where the user has full access to everything by definition (as in a personal computer). The method of attack would be to disassemble the program and find the place(s) where the checks were made, and remove them (of course, there may be some other things needed ... such as removing checksum calculaters and so forth). This could also be done using tools such as DEBUG. The scheme would probably keep out the less knowledgeable pirates pretty effectively (it would not be subject to things like the nibble copiers which are now out and which don't require programming knowledge to use), but for the really sophisticated pirate it would be quite vulnerable, and once a modified pirate copy appeared it could be copied widely (because the protection code would be removed, there would be no restrictions on copying it any more). Keeping out sophisticated pirates is tough. Really. Bruce C. Wright @ Duke University
aaw@pyuxss.UUCP (11/11/83)
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
stekas@houxy.UUCP (11/11/83)
Has it really been established that the new copy protection
techniques rely on "soft-bit"? Couldn't the "bad sectors"
be generated simply by writing a CRC value which is inconsistent
with the data? I don't know of any vanilla flavored floppy
controllers which could write such "bad sectors" intentionally.
It seems that there are better and easier techniques for writing
bad sectors in ways which stock controllers couldn't duplicate than
by writing data so "soft" that they vary from read to read.
Does anyone know for sure? Are "soft bits" a rumor or a fact.
Jim