richard@dataspan.dataspan.UUCP (Richard "Tiger" Melville) (12/04/90)
Many of the software products our company sells rely on a licence file which
specifies the duration of time the software is licensed for. The software
then refuses to run when the period has expired. It is, however, possible
to roll back the date on a machine and fool the licence manager software.
This problem must be solved in order for us to distribute free demo versions
which work for a specified period only.
Is there a reliable way to test if the date on a machine has been rolled
back ? (System files which have modified dates in the future might do the
trick.) As portable a solution as possible is desirable, although we mainly
run SunOs 4.0.
--
_Q Q_ Richard Melville DataSpan Technology Inc.
__ /_\) /| 237-9313 400-540 5th ave SW
_\___/O____O|/O____/ \_ Calgary Alberta Canada, T2P 0M2
_/ \_rcosj@chudich.co.rmit.oz (John Simmons) (12/05/90)
richard@dataspan.dataspan.UUCP (Richard "Tiger" Melville) writes: >Many of the software products our company sells rely on a licence file which >specifies the duration of time the software is licensed for. The software >then refuses to run when the period has expired. It is, however, possible >to roll back the date on a machine and fool the licence manager software. >This problem must be solved in order for us to distribute free demo versions >which work for a specified period only. >Is there a reliable way to test if the date on a machine has been rolled >back ? (System files which have modified dates in the future might do the >trick.) As portable a solution as possible is desirable, although we mainly >run SunOs 4.0. Couldn't you get your program to check the date fairly regularly when it is run and write it away somewhere, keeping track of the latest date reached so far, then refuse to run at any time/date earlier than the latest one stored. The software may run after the desired date (if unscupulous people fiddle the machines date ) but it will slowly run out of usable time as the stored date gets up to the final die-by date. You could even have a penalty setup such that it deducts time from the final die-by date if it detects an attempt to run it at a time before the latest stored time/date. John Simmons (VK3KJG) Ph. 660 2619 Royal Melbourne Institute of Tech. System Administrator Fax 662 1060 (Victoria University of Technology) PO Box 2476V ACSnet: rcosj@chudich.co.rmit.oz Melbourne 3001 Australia CSNET: rcosj@chudich.co.rmit.oz.aus ARPA: rcosj%chudich.co.rmit.oz.au@uunet.uu.net BITNET: rcosj%chudich.co.rmit.oz.au@CSNET-RELAY UUCP: ...!uunet!munnari!chudich.co.rmit.oz.au!rcosj
barmar@think.com (Barry Margolin) (12/05/90)
In article <RICHARD.90Dec3143525@dataspan.dataspan.UUCP> richard@dataspan.dataspan.UUCP (Richard "Tiger" Melville) writes: >Is there a reliable way to test if the date on a machine has been rolled >back ? (System files which have modified dates in the future might do the >trick.) No, there isn't. Anyone who has access to change the date would also have access to change anything that the program might look at to verify the date. The Unix superuser is all-powerful within that system. If he's clever enough, he could patch the executable file so that it would skip over the date checks. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/05/90)
In article <RICHARD.90Dec3143525@dataspan.dataspan.UUCP> richard@dataspan.dataspan.UUCP (Richard "Tiger" Melville) writes: > Is there a reliable way to test if the date on a machine has been rolled > back ? No, there is not. ---Dan
mike@bria.AIX (Mike Stefanik/78125) (12/31/90)
In article <RICHARD.90Dec3143525@dataspan.dataspan.UUCP>, richard@dataspan.dataspan.UUCP (Richard "Tiger" Melville) writes: > Many of the software products our company sells rely on a licence file which > specifies the duration of time the software is licensed for. The software > then refuses to run when the period has expired. [deleted] > Is there a reliable way to test if the date on a machine has been rolled > back ? (System files which have modified dates in the future might do the > trick.) As portable a solution as possible is desirable, although we mainly > run SunOs 4.0. One method that I have used in the past was to declare a static string with some unique contents in the code (ie: static char *fubar = "UGGA000000000000") and then write the code so that it is self-modifying. I simply had the program determine from whence it came, opened itself, and searched for that string. Obviously the "0000000000" part is the date ala time(). Look at the current time, and if the current time is less than what was in your magic cookie, you know they rolled the clock back. If all is ok, then simply update that string with the current time. Just make sure that that you lock the image when you are doing this. The above is preferable over using inode information such as access time, because that can easily be fudged. Hope that helps. ----------------------------------------------------------------------------- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike "If it was hard to code, it should be harder to use!"
boyd@necisa.ho.necisa.oz.au (Boyd Roberts) (01/03/91)
In article <292@bria.AIX> mike@bria.AIX (Mike Stefanik/78125) writes: > > [ stuff about re-writting a string in an executable ] > >The above is preferable over using inode information such as access time, >because that can easily be fudged. > And what stops me from re-writing the string in the executable? Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
mike@bria.AIX (Mike Stefanik/78125) (01/04/91)
In article <1976@necisa.ho.necisa.oz.au>, boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: > In article <292@bria.AIX> mike@bria.AIX (Mike Stefanik/78125) writes: > > > > [ stuff about re-writting a string in an executable ] > > > >The above is preferable over using inode information such as access time, > >because that can easily be fudged. > > > > And what stops me from re-writing the string in the executable? Nothing, for the truly dedicated individual. The whole point of security (IMHO) is not to make it impossible, but to make it as *painful* as possible. Anyone with enough intellect, interest, dedication, etc. can break any security scheme. However, encoding the date in the executable would make it more painful for the would-be pirate than would using the touch command. If your looking for a perfect security scheme, then don't let anyone use your software but you. ----------------------------------------------------------------------------- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike "If it was hard to code, it should be harder to use!"
ping@cubmol.bio.columbia.edu (Shiping Zhang) (01/07/91)
In article <306@bria.AIX> you write: >In article <1976@necisa.ho.necisa.oz.au>, boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes: >> In article <292@bria.AIX> mike@bria.AIX (Mike Stefanik/78125) writes: >> > >> > [ stuff about re-writting a string in an executable ] >> > Somehow I missed the article about re-writting a string in an executable. Could someone mail me the original article on this subject? Thanks. -ping
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (01/07/91)
You can't, period -- at least not without hardware support. No matter what you stat or how you may encrypt whatever information you may wish to encode about the file system, it can be circumvented. All the user has to do is make a full backup of the system after the software is installed and working. Then, at any time in the future, the user can reset the system clock and restore the entire file system to the state is was at the time of the backup. However, in commercial environments, doing this is often more expensive in lost productivity than the software costs. If someone is really determined to crack your software, they can always disassemble your application and modify your protection scheme -- even if you use a &%$# kernal patch to obscure your protection scheme. (There are other, more subtle ways of hiding your protection scheme. ;^) Like locking your house or your car, all you can do is make the job more trouble than it's worth. That said, if the computer manufacturer were to add a non-resettable piece of mechanical hardware measuring the elapsed uptime of the computer and provide a system call for accessing the elapsed time, then at least your software could check for consistancy. (i.e. If the elapsed uptime is more than the elapsed clock time encrypted at the time of installation, then something funny is going on.) As a side benefit, the elapsed uptime information could be useful for admin folks and hardware maintainers. #include <std/discalimer.h> Cheers, -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp
vancleef@nas.nasa.gov (Robert E. Van Cleef) (01/08/91)
** enter soap box mode** The sad thing about all of these copy protection schemes is that they serve the needs of the vendor, not the needs of the client. We recently invoked the "roll back the clock" function to allow the continued execution of one protected program because the update the vendor gave us to restore functionality required us to install an OS software upgrade that we aren't ready to install... Software protection schemes that are tied to system hardware numbers, such as ethernet addresses or CPU ID numbers are just as bad - all it takes is a visit from your friendly hardware field engineer to break everything. Software protection schemes may appear to be necessary from a business perspective, but you need to take the needs of the customer into consideration. Recently we almost returned four software licences (at $5k each) to the vendor because it was so difficult to install. The difficulties were caused by their copy protection scheme. Remember what the PC world found out the hard way. Without customers you don't have a business! Installing the worlds smartest and most sophisticated copy protection system will not sell one package. You are a lot better off spending you time and energy building a loyal customer base that wouldn't even consider cheating on you because they believe that they get top value for their investment. **exit soap box mode** -- Bob Van Cleef vancleef@nas.nasa.gov NASA Ames Research Center (415) 604-4366 --- Perception is reality...
mjr@hussar.dco.dec.com (Marcus J. Ranum) (01/09/91)
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) writes: >[...] if the computer manufacturer were to add a non-resettable piece >of mechanical hardware measuring the elapsed uptime of the computer and >provide a system call for accessing the elapsed time, then at least your >software could check for consistancy. Of course, if someone were to try to sell a computer with built-in support for copy protection, nobody in their right mind would buy it because a) the cost of the copy protect hardware would get passed on the the buyer b) the pain in the a** factor of the copy protect would get passed on to the buyer. the cost of hardware failure in the copy protect hardware would be considerably higher. I know a large hospital that had a total computer lapse on several critical systems because some vendor's dbms protection scheme didn't handle leap years right and "expired" at the wrong time. Unfortunately, they didn't lose the entire account as a result, but they bloody well deserved to. Copy protection's plain silly for anything other than PCs, since any organization that has enough money to buy a, say, $50,000 machine isn't going to be stupid (I hope) enough to risk the lawsuit that a software vendor can bring against them. Deep pockets have a lot more to worry about that the average PC user - if they're being dishonest. If they're being honest (which a gentleman must assume until convinced otherwise) they shouldn't have to suffer the insult of distrust - especially from a service provider - what ever became of "the customer is always right?" On the wacky side, I'd love to see a hyper-dongle for a CRAY. ;) mjr. -- How can something that is almost 2 Megabytes in size be called a "kernel"? The truth in advertising laws should apply to software. Let's call it a "gourd" or perhaps a "watermelon". [From the programming notebooks of a heretic, 1990]
mike@bria.UUCP (Michael Stefanik) (01/09/91)
In article <1991Jan7.201353.17937@nas.nasa.gov> vancleef@nas.nasa.gov (Robert E. Van Cleef) writes: >The sad thing about all of these copy protection schemes is that they serve >the needs of the vendor, not the needs of the client. That is because the user is most likely NOT interested in protecting the interests of the vendor. Can you realistically expect the industry to roll over when the users are busy sticking a knife in our back? >We recently invoked the "roll back the clock" function to allow the continued >execution of one protected program because the update the vendor gave us to >restore functionality required us to install an OS software upgrade that we >aren't ready to install... While unfortunate that your vendor wouldn't be able to help you without an OS upgrade, that is sometimes the cost of improvement. You have an agenda, but *so does the software company*. If you don't like the fact that they are requiring to move forward faster than you feel comfortable with, then you simply are using the wrong product. The point is, *life goes on*, and with that comes change. >Software protection schemes that are tied to system hardware numbers, such >as ethernet addresses or CPU ID numbers are just as bad - all it takes is a >visit from your friendly hardware field engineer to break everything. If you are doing something like swapping motherboards, then simply let the software company know in advance what you are doing, and I'm sure they'll accomodate you. If you want to take the attitude of "why should I have to call someone else when I'm changing something on my machine", then you're living in a vacuum, and your expectations will never be met. >Software protection schemes may appear to be necessary from a business >perspective, but you need to take the needs of the customer into >consideration. If the copy protection causes daily interference in one's life, then I would say that the protection was a hassle, and dump the product. On the other hand, the customer needs to consider the needs of the author(s). Assuming that no one pointed a gun at your head and said "buy this software", you made a choice, and with that choice comes rules. Live with it or get out. >Recently we almost returned four software licences (at $5k each) to the >vendor because it was so difficult to install. The difficulties were caused >by their copy protection scheme. Then that software is poorly designed, and I would have gotten out. >Remember what the PC world found out the hard way. Without customers you >don't have a business! Installing the worlds smartest and most sophisticated >copy protection system will not sell one package. You are a lot better off >spending you time and energy building a loyal customer base that wouldn't >even consider cheating on you because they believe that they get top value >for their investment. ** Climbing up on my own soapbox ** May I ask what planet you are living on? A "loyal customer base that wouldn't even consider cheating on you"? ARE YOU SERIOUS? One of the worst things that can befall a software company is the users liking it too much ... they feel "obligated" to "share" it with their friends. The fundamental problem here is that people do not consider the output from my brain in the form of a working program to be real property. People would not even think of holding up a 7-11 will freely copy my stuff and duplicate it for any Tom, Dick and Harry who asks, and I don't get a dime. And yes, dammit, it does have to do with money! I'll put it to you as my grandfather has told me: Locks aren't made to keep criminals out, but to keep honest people honest. People rip us (software engineers) off because it is easy to do it. Make it more difficult, and it will be done less. Period. ** Getting off my soapbox now ... * Your ideas are nice, but simplistic. The world does not consist of wonderful hardworking people all out to help everyone else. People will cheat each other for all eternity. Why? Because they can. Gee, my view of the world is rather bleak, isn't it? :-) -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
pack@acd.acd.ucar.edu (Dan Packman) (01/10/91)
In article <333@bria> mike@bria.UUCP (Michael Stefanik) writes: >In article <1991Jan7.201353.17937@nas.nasa.gov> vancleef@nas.nasa.gov (Robert E. Van Cleef) writes: >... >>Software protection schemes that are tied to system hardware numbers, such >>as ethernet addresses or CPU ID numbers are just as bad - all it takes is a >>visit from your friendly hardware field engineer to break everything. > >If you are doing something like swapping motherboards, then simply let the >software company know in advance what you are doing, and I'm sure they'll >accomodate you. If you want to take the attitude of "why should I have to >call someone else when I'm changing something on my machine", then you're >living in a vacuum, and your expectations will never be met. >... Good points on both sides. One common scenario is the system fails from a hardware problem. The field engineer comes in and swaps out the faulty board (eg, ethernet). The system is rebooted. The copy-protected software fails because it is keyed to a number that changed when the board was swapped out. If one were *planning* a hardware change, then it behooves one to contact the software company in advance. This is not always possible. In this latter case it is clear that protection schemes should be tied to numbers that don't change often and the company should be available in real time to get software up again after such an unanticipated hardware change. >technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly >found to be saying things like "Well, it works on my DOS machine ..." ^^^ We have a problem with individuals like this too... Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU (303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET Boulder, CO 80307 DECNET SPAN: 9.367::PACK
jc@minya.UUCP (John Chambers) (01/14/91)
> If the copy protection causes daily interference in one's life, then I > would say that the protection was a hassle, and dump the product. On the > other hand, the customer needs to consider the needs of the author(s). > Assuming that no one pointed a gun at your head and said "buy this software", > you made a choice, and with that choice comes rules. Live with it or > get out. Sorry, but despite how macho and righteous this may sound in print, it wouldn't last very long in most courts. Consider a scenario: You are lying on the operating table, surrounded by physicians, nurses, and a lot of electronic monitoring equipment. It's a long operation, during which time the clock rolls past midnight. A software package on one of the monitors determines that the hospital's license for this package on this machine has run out, and it shuts itself down. The staff can't figure out how to get it running again, and you die. Your estate naturally sues the hospital and the software vendor. The vendor's lawyer makes the mistake of letting a company representative make the above statement in court. The prosecution points out that it is an admission of not just guilt, but of malicous intent. The company is now legally liable for your death. If the programmer and/or manager that decided to implement this copy protection scheme can be determined, he/she is likely to be charged with (negligent) manslaughter or homicide. [The people who write warranties tend to be aware that there's a fine legal line between disclaimers and admissions of guilt. That's why they are phrased in vague language that nowhere states just what the limitations of the product are.] Anyway, watch the papers; it's just a matter of time ... Myself, I think I'll forgo the copy protection. (Maybe I should also remove the BUGS section of the manual pages, too. ;-) -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc
pavlov@canisius.UUCP (Greg Pavlov) (01/14/91)
[ I assume, given the newgroup that this was posted to, that we are
not talking about MS DOS-based software packages ]
In article <333@bria>, writes:
>
> That is because the user is most likely NOT interested in protecting the
> interests of the vendor.
>
Most sys admins and/or the people responsible for choosing a particular
package ARE very concerned with the vendor's interests: you don't want
a package you bet your company's long-term health on to be "orphaned".
>>We recently invoked the "roll back the clock" function to allow the continued
^^^^^^^^^
> >execution of one protected program because the update the vendor gave us to
^^^^^^^^^
> >restore functionality required us to install an OS software upgrade that we
> >aren't ready to install...
>
> While unfortunate that your vendor wouldn't be able to help you without an OS
> upgrade, that is sometimes the cost of improvement.
^^^^^^^^^^^
>
Hunh ???? I think that you are trying too hard to prove that the "customer
is always wrong".
We, unfortunately, have had to play the clock game also - for software we pur-
chased and pay support fees for - due to messed up "validation strings".
Didn't do much for our transaction logging, inter-site communications, etc.
> >Software protection schemes that are tied to system hardware numbers.....
>
> If you are doing something like swapping motherboards, then simply let the
> software company know in advance what you are doing, and I'm sure they'll
> accomodate you. If you want to take the attitude of "why should I have to
> call someone else when I'm changing something on my machine", then you're
> living in a vacuum, and your expectations will never be met.
>
I think that a vendor who truly believes this is guilty of living in a vacuum
(or doesn't think too much of his software). A lot of us jump through hoops
to try to keep our applications up as close to 100% of the time as possible:
it's in our customer contracts/agreements/whatever. We DON'T KNOW "in advance
that a cpu board will fail and if/when it does, what the replacement's number
will be.
> If the copy protection causes daily interference in one's life, then I
> would say that the protection was a hassle, and dump the product.
I've never seen/lived one that wasn't and a significant minority of them
were destructive to our operation in one way or another.
>
> Gee, my view of the world is rather bleak, isn't it? :-)
> --
> Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
Is the lack of a spokesman disclaimer here significant ?
pavlov@stewart.fstrf.orgmike@bria.UUCP (Michael Stefanik) (01/14/91)
In article <448@minya.UUCP> minya.UUCP!jc (John Chambers) writes: >> Assuming that no one pointed a gun at your head and said "buy this software", >> you made a choice, and with that choice comes rules. Live with it or >> get out. > >Sorry, but despite how macho and righteous this may sound in print, >it wouldn't last very long in most courts. [...] You would have a point *if* the company that you bought the software from did not disclose to you that it had a copy protection mechanism. If you bought the product, knowing that it had copy protection and the nature of that protection, then you made a choice. Live with it or get out. Doing your homework on a package ahead of time is also food for thought ... -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
mike@bria.UUCP (Michael Stefanik) (01/14/91)
In article <3133@canisius.UUCP> canisius.UUCP!pavlov (Greg Pavlov) writes: :In article <333@bria>, writes: :> That is because the user is most likely NOT interested in protecting the :> interests of the vendor. :> :Most sys admins and/or the people responsible for choosing a particular :package ARE very concerned with the vendor's interests: you don't want :a package you bet your company's long-term health on to be "orphaned". No doubt that many of theses companies express their desire to "help" the vendor by duplicating the software illegally ... :-| :> If you are doing something like swapping motherboards, then simply let the :> software company know in advance what you are doing, and I'm sure they'll :> accomodate you. If you want to take the attitude of "why should I have to :> call someone else when I'm changing something on my machine", then you're :> living in a vacuum, and your expectations will never be met. :> :I think that a vendor who truly believes this is guilty of living in a vacuum :(or doesn't think too much of his software). A lot of us jump through hoops :to try to keep our applications up as close to 100% of the time as possible: :it's in our customer contracts/agreements/whatever. We DON'T KNOW "in advance :that a cpu board will fail and if/when it does, what the replacement's number :will be. This is why grace periods are implemented in the software protection schema. :> If the copy protection causes daily interference in one's life, then I :> would say that the protection was a hassle, and dump the product. :> :I've never seen/lived one that wasn't and a significant minority of them :were destructive to our operation in one way or another. Generally speaking, I just find it hard to feel for the end user who complains loudly because we made it a little tougher for him to rip us off ... Well written copy protection is non-intrusive (unless you're busy trying to violate the protection) and has grace recovery for emergency situations. Now perhaps companies out there aren't do it "right", but that doesn't invalidate the concept of protection itself. And, as an aside, of course I only speak for myself, not my company or anybody else out there. This is a given ... -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
weyrich (Dr. Orville R. Weyrich) (01/17/91)
In article <333@bria> mike@bria.UUCP (Michael Stefanik) writes: >In article <1991Jan7.201353.17937@nas.nasa.gov> vancleef@nas.nasa.gov (Robert E. Van Cleef) writes: >>The sad thing about all of these copy protection schemes is that they serve >>the needs of the vendor, not the needs of the client. > >That is because the user is most likely NOT interested in protecting the >interests of the vendor. Can you realistically expect the industry to roll >over when the users are busy sticking a knife in our back? > >>We recently invoked the "roll back the clock" function to allow the continued >>execution of one protected program because the update the vendor gave us to >>restore functionality required us to install an OS software upgrade that we >>aren't ready to install... > >While unfortunate that your vendor wouldn't be able to help you without an OS >upgrade, that is sometimes the cost of improvement. You have an agenda, but >*so does the software company*. If you don't like the fact that they are >requiring to move forward faster than you feel comfortable with, then you >simply are using the wrong product. The point is, *life goes on*, and with >that comes change. > >If you are doing something like swapping motherboards, then simply let the >software company know in advance what you are doing, and I'm sure they'll >accomodate you. If you want to take the attitude of "why should I have to >call someone else when I'm changing something on my machine", then you're >living in a vacuum, and your expectations will never be met. It's a hassle that I could do without. Given a choice, I will avoid exposing myself to this kind of hassle. > >If the copy protection causes daily interference in one's life, then I >would say that the protection was a hassle, and dump the product. On the >other hand, the customer needs to consider the needs of the author(s). >Assuming that no one pointed a gun at your head and said "buy this software", >you made a choice, and with that choice comes rules. Live with it or >get out. If I know in advance that any company holds a philosophy like this I will never "GET IN" in the first place. It costs me money to dump a product. It costs me money to install upgrades. If I have a product which works and serves my needs, I am not at all sympathetic to a company deciding that their "agenda" is that I upgrade my system in order to continue to use a product that I have committed my business to. > >-- >Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation It is no use debating whether or not users will violate your intellectual rights or not by illegal copying (certainly some, but not all, do). The lesson of history is that SOMEBODY has to pay for the software in order for the company to survive. In the MS-DOS world MANY companies have REMOVED their protection schemes beause they found that people would go to great lengths to buy (even inferior) software from a competitor in order to avoid copy protection hassles. The copy protections schemes WERE COUNTER- PRODUCTIVE to the goal of selling software. Some companies even find shareware to be a viable marketing scheme. Are there people using the product without paying for it? Sure. Is the company making more money than if they copy protected the software and sold it outright? Most likely. As I recall, the TI-99 personal computer had build-in hardware support for copy protection (or was it the IBM PC JR?) and part of the marketing strategy was to sell the hardware cheap but make sure the users paid through the nose for copy protected software. This was implemented by putting the software in hard-to-duplicate firmware cartridges. In any case, neither of these computers was a big marketing success. I would be interested in hearing you cite examples of profitable software packages that are copy protected when there is an alternative available that is not copy protected. I am both a software developer and a consultant concerned with keeping my customers happy. I avoid copy protections schemes like the plague in both what I SELL and what I BUY. ------------------------------------------------------------------------------- Orville R. Weyrich, Jr. Weyrich Computer Consulting uunet!weyrich!orville
sarima@tdatirv.UUCP (Stanley Friesen) (01/23/91)
In article <357@bria> mike@bria.UUCP (Michael Stefanik) writes: >Generally speaking, I just find it hard to feel for the end user who complains >loudly because we made it a little tougher for him to rip us off ... >Well written copy protection is non-intrusive (unless you're busy trying >to violate the protection) and has grace recovery for emergency situations. Hmm, I have yet to see a truly non-intrusive scheme. I would require the following before I considered a scheme non-intrusive: 1. Allows backups to be made of the software, which can be used to restore the protected software in case of media failure. 2. Does not require any special hardware to run (the least intrusive system I have yet seen appears to require a network conection to the vendor! Not all of my systems have any netowrk capability) 3. Does not require any user validation beyond normal login procedures. (e.g. no extra passwords to run the package) 4. Can be reinstalled on a new machine immediately in case of major hardware failure. This is just a minimum list, I may think of several more later. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
adeboer@gjetor.geac.COM (Anthony DeBoer) (01/24/91)
In article <91@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: >Hmm, I have yet to see a truly non-intrusive scheme. I would require the >following before I considered a scheme non-intrusive: > >1. Allows backups to be made of the software, which can be used to restore > the protected software in case of media failure. > >2. Does not require any special hardware to run (the least intrusive system I > have yet seen appears to require a network conection to the vendor! Not > all of my systems have any netowrk capability) > >3. Does not require any user validation beyond normal login procedures. > (e.g. no extra passwords to run the package) > >4. Can be reinstalled on a new machine immediately in case of major > hardware failure. Point four would be completely at odds with having any software protection at all. What's to stop an unscrupulous user from taking his routine backup tape from the authorized system and restoring on several new machines as if they were each the replacement machine after a major failure? A hardware dongle (a protection gizmo that goes on a serial port or whatever) could prevent more that one copy from running, but that violates points two and four, the latter because if something horrible happens to the computer the dongle might be history too. Our company uses a package from another vendor that works entirely in software, which as near as I can tell from external evidence works something like this: Every time it wakes up it checks some external evidence of where it's installed (which might be the i-node numbers of a few key files) and uses this and the copy's serial number to generate an large pseudo-random "installation number". If this is the same as last time, then it's okay. Otherwise, it limits use of the package to three users and tells you you need to get it authorized, here are the serial and installation numbers, and please call 1-800-etc. You tell the person on the far end the numbers and he/she gives you an "authorization number" to key in that makes the package happy. This would normally happen only on initial installation and after restoring from a major crash. During normal running, it's completely unobtrusive and you can make all the backup copies you want. The two main holes that might exist in that scheme are firstly that you might possibly be able to do "mirror" backups to exactly duplicate the hard drive on one computer onto a physically identical box, creating a second authorized copy of the software, since it has no idea that it's not on the original machine anymore (honestly, though, I haven't tried this!), and secondly that it's up to the people at their office to try to figure out if the call is legit the second and subsequent times a call arrives asking for a given serial number to be authorized. Here, the unscrupulous user would need to be good at telling hardware horror stories that never happened. I suppose you're not going to get much closer to an optimal scheme. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, Geac J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
cornutt@freedom.msfc.nasa.gov (David Cornutt) (01/26/91)
I once encountered a protection scheme that seemed to be pretty good for both the vendor and the user. The software was Verilog-XL running on a Sun-3 that I sysadm'ed some years ago. It used a pseudorandom key generated from the date, the serial number (extracted from the Sun's ID ROM), and a passcode that was stored in a shell script that had to be sourced before running the software. The key was somehow generated so that it authorized the software for a particular time interval. It somehow stored the date of last invocation in a touch file. It would catch date rollbacks, but allowed some limited rollback to make up for clock resets, time zone changes, and the like. To prevent accidents, as I recall, it compared the current time at each invocation to the stored time of last invocation, and if the difference was too great, it prompted to user to double-check the system clock before proceeding. One time we lost the ID ROM on the Sun. (A decoupling cap next to it on the CPU board caught fire and melted it. After this we started referring to it as the "arc welder in disguise." :-) When the board was replaced, and a new ROM was installed, we just called up Verilog and they gave us a temporary 30-day password over the phone, so that we could continue operating while the license amendment was being amended to reflect the change. The protection scheme in no way hindered backing up or restoring the software. It did very much hinder using it on an unlicensed machine. (The Verilog folks invited us to try to break it.) It was a nice scheme, and I wouldn't hesitate to recommend it. (On top of that, the package itself was a very good package. If this be a blatant plug for Verilog, so be it.) BTW, ordinary CPU upgrades/replacements did not post any license problem with this machine. You just removed the ID ROM from the old board (it was socketed), and put it in the new one. Actually losing the ROM itself was very rare. Of course, this scheme depended on this hardware feature of the Sun, and would have been harder to implement on a machine that didn't have any hardware identification. -- David Cornutt, New Technology Inc., Huntsville, AL (205) 461-6457 (cornutt@freedom.msfc.nasa.gov; some insane route applies) "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."