1. RE: Copy Protection
Euman,
Here's a thought that may take a bit of effort, but may work reasonably
well:
Locate one (or more) sector(s) physically on the disk. I.e., be able to
point with a needle to the magnetic tape or reflective coating of the
disk, and be able to say "Sector X is here."
Punch a hole through the disk at the appropriate sector(s).
Have the data on the disk be scattered about, and encrypted. The only
clue to where the bad sectors are is contained, in a program that is
also stored on the disk. Also, the only record of how the data is
scattered, and of what the encryption key is, is stored in the program.
You could even have these two data records (where the bad sectors are
and how to render the data readable) be 'scrambled', to prevent a simple
look at the program code from reading it. The program knows how to
unscramble the records.
The only way to access the information now (without considerable effort)
is via the on-disk program. When run, this program 'unscrambles' the
bad-sector info if necessary, and checks to see that the punched-out
sectors can be neither read from or written to. If the program finds
that the sectors are indeed bad, 'unscramble' the data info if
necessary, then reconstruct and decrypt the data. Finally, the data is
presented to the user/desktop program.
Should the program find that the physical sectors ARE indeed there, it
demands that the original disk be used and aborts. The program won't run
unless from the original disk, and the "visible" data is useless without
the program restructuring/decrypting it. Voila, an uncopyable disk (at
least to the casual--and possibly experienced--user.)
Note that this is all theoretical though; I'm not a hardware guy. 
Rod Jackson
euman at bellsouth.net wrote:
> Hello all,
>
> I am in need of some advice. I would like to make a diskette that
> contains
> private data
> non-transferable to another diskette. What I mean is writting bits to
> the
> boot sector or
> a set of bits at a certain sector that would if copied, be transfered to
> another location on
> the copy to diskette making it inoperable. Is there a way to protect
> serial
> numbers on
> diskettes that anyone knows about? What sectors or hidden sectors would
> not
> transfer
> if a copy was made? There must be a way!
>
> I agree that some of the virus code out there might help in this
> situation.
> I would rather stay away from this type of copy protection...
>
> I thought about using a scatter scheme "broken files" that could only be
> put
> back together,
> if I could find out how to protect the disk first..
>
> Any GREAT ideas.... very much appreciated!
>
> Euman
> euman at bellsouth.net
>
>
2. RE: Copy Protection
Hello Euman,
One copy protection method I've seen in the past is where the software is also
distributed with a printed manual. When the software is run it asks for a
word from the manual to be entered. For example:
"To activate type the 3rd word in the second paragraph on page 32 of the
manual".
If you don't get it right then the software doesn't run - you have to try
again and when you do your asked for a word from a different part of the
manual.
The idea is that while it is easy and very cheap to copy the content of a
floppy it's a bit more hassle to copy a manual. I guess you could photo copy
the manual but if the manual is 100 pages or so this might be a bit pricey.
Also I guess the manual could be scanned in and converted to a word document
(or PDF or whatever) and also copied to a second diskette but even scanning a
100 plus pages is a bit of a pain.
However, the general idea is to make the process more cumbersome.
Regards,
FP.
>===== Original Message From euman at bellsouth.net =====
>
>Hello all,
>
>I am in need of some advice. I would like to make a diskette that contains
>private data
>non-transferable to another diskette. What I mean is writting bits to the
>boot sector or
>a set of bits at a certain sector that would if copied, be transfered to
>another location on
>the copy to diskette making it inoperable. Is there a way to protect serial
>numbers on
>diskettes that anyone knows about? What sectors or hidden sectors would not
>transfer
>if a copy was made? There must be a way!
>
>I agree that some of the virus code out there might help in this situation.
>I would rather stay away from this type of copy protection...
>
>I thought about using a scatter scheme "broken files" that could only be put
>back together,
>if I could find out how to protect the disk first..
>
>Any GREAT ideas.... very much appreciated!
>
>Euman
>euman at bellsouth.net
>
>
>
3. RE: Copy Protection
euman at bellsouth.net wrote:
Euman:
Why don't you shroud the diskette with Euphoria.
Then because you are familiar with contollers, make a
rom that connects to a port. The Rom would have a key code number
,number of uses and date burned into it.
To use the diskette it would be necessary to have the rom.
The data would not be excessable after a certain date, the
number of usage expires or a invalaid key code.
The advantage is the customer could make backups of the
diskette but it would be difficult to copy the rom and if they
did the date or number of uses would expire.
Bernie
4. RE: Copy Protection
Euman,
Well, that's just it. From everything I've read, this CAN'T be done just
with software.
>From what I know, programs are available on the internet that allow you
to copy any disk. It doesn't matter if there are are checksum errors,
hidden data, etc.--every bit written to the original disk is copied to
the new, without any regard for what it means.
As I said, I'm no hardware guru. I get the impression that devising a
new disk format would only the disk from being read by conventional
movements of the disk drive's read/write head. If so, this might work...
although you're now saddled with the need for special software to read
the disk.
Plus, I think committed hackers would be able to unravel the new format
(not that they couldn't also crack the punched-hole disk problem; no
solution is TOTALLY foolproof short of a one-time-pad-encrypted disk
with the key given in person to the appropriate user. And even that only
stops the data from being read, not from being copied.)
Rod Jackson
