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
richard@dataspan.dataspan.UUCP (Richard "Tiger" Melville) (12/06/90)
In article <rcosj.660348537@chudich> rcosj@chudich.co.rmit.oz (John Simmons) writes: >Is there a reliable way to test if the date on a machine has been rolled >back ? 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. I considered this, but all that is required to get around it is to re-install the software, and our record of the date is gone. I am wondering if I just shouldn't touch the guy's .login or some other frequently found but seldom modified file, and use that for my record of the date. Then, if the date of that file is ever found to be in the future, the date has been rolled back. Not foolproof, of course, but perhaps something along these lines could work most of the time... -- _Q Q_ Richard Melville DataSpan Technology Inc. __ /_\) /| 237-9313 400-540 5th ave SW _\___/O____O|/O____/ \_ Calgary Alberta Canada, T2P 0M2 _/ \_
flint@gistdev.gist.com (Flint Pellett) (12/07/90)
rcosj@chudich.co.rmit.oz (John Simmons) writes: >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 That's the problem: where are you going to write it? A reasonably clever user, after rolling the clock back does not get things started again, is first going to re-install from the original installation media. If that doesn't get it going again because you've written a date in some file other than one of the ones originally installed, said user will go back to the backup they made the end of the day they installed your stuff, and see what files changed that day. After they figure out which one you wrote into, they restore it from the backup and they're going again. You can do stuff to make it hard for them to figure out what you've done, but if it is worth enough to them they can always figure out what you did. I've heard of schemes where the installation program on the installation media alters the install media so that it can only be used to install with once: and I've heard of people creating X copies of it before they first install it to avoid that problem. >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. The software could even delete itself from the machine-- that won't help because they can always restore it from a backup. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
friedl@mtndew.Tustin.CA.US (Stephen J. Friedl) (12/07/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. It is, however, possible > to roll back the date on a machine and fool the licence manager software. Many sites will not want to set their date back a year (messes up too many other things), but you can often do it on a per-process basis by setting a timezone with a *huge* hour offset. For instance, I can set my clock back one year by changing TZ=PST8PDT into TZ=PST8768PDT # (24 * 365) + 8 = 8768 Smart software will detect this and refuse to believe a crazy TZ like this. Steve -- Stephen J. Friedl, KA8CMY / 3B2-kind-of-guy / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "If it doesn't core dump, ship it" - Gary W. Keefe, on product development
buck@sct60a.sunyct.edu (Jesse R. Buckley Jr.) (12/08/90)
I suppose you *COULD* make it connect with your machine first, but (I know) that would not be the best. -- -Buck ! User n.: A programmer who will believe (buck@sct60a.sunyct.edu) ! anything you tell him.
boyd@necisa.ho.necisa.oz (Boyd Roberts) (12/10/90)
In article <rcosj.660348537@chudich> rcosj@chudich.co.rmit.oz (John Simmons) writes: > >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. No. How are you going to stop the place where it's written from being re-witten? Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
bzs@world.std.com (Barry Shein) (12/11/90)
Geez, if you want a way to ensure maximization of your profits the
least you can do is offer a consulting fee.
I'll think about this problem for my usual $150/hour, 8 hour minimum.
Send a PO number.
But I'll be g*damned if I'd answer it for free on a newsgroup.
What a sleazy thing to ask for free advice on.
I have at least the same attitude about the value of my expertise as
you do towards the value of your software.
I suggest any suggestions in this thread be copyrighted and licensed
for a royalty to the original requestor's company.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDjfh@rpp386.cactus.org (John F Haugh II) (12/11/90)
In article <1959@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >How are you going to stop the place where it's written from being re-witten? Among other things, by using data encryption or something similiarly nasty like cryptographic checksums. [ All of which can also be defeated, but at a slightly higher cost. ] -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
src@scuzzy.in-berlin.de (Heiko Blume) (12/11/90)
boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >In article <rcosj.660348537@chudich> rcosj@chudich.co.rmit.oz (John Simmons) writes: >> >>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. >No. >How are you going to stop the place where it's written from being re-witten? seems like you never looked into what copy-protection has come up with to hide something (data) from you. i recommend to get an apple ][* and one of the later games from electronic arts. then try to find out what's where on the floppy. remember, there are only 143KB on these disks ! i'll call you for results in a year or so :-) seriously, in the time of 600KB executables it should be absolutely no problem to hide a little date in there somewhere. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
scott@convergent.com (Scott Lurndal) (12/14/90)
In article <1990Dec11.125711.1468@scuzzy.in-berlin.de>, src@scuzzy.in-berlin.de (Heiko Blume) writes: |> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: |> |> >In article <rcosj.660348537@chudich> rcosj@chudich.co.rmit.oz (John Simmons) writes: |> >> |> >>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. |> |> >No. |> |> >How are you going to stop the place where it's written from being re-witten? |> |> seems like you never looked into what copy-protection has come up |> with to hide something (data) from you. i recommend to get an |> apple ][* and one of the later games from electronic arts. |> then try to find out what's where on the floppy. remember, |> there are only 143KB on these disks ! |> Hey, unix systems are not apple II's - generally applications do not have the wherewithal to access tracks on the disk directly to muck about with parity/ecc et. al. as traditional copy protection schemes do. |> i'll call you for results in a year or so :-) |> |> seriously, in the time of 600KB executables it should be |> absolutely no problem to hide a little date in there |> somewhere. If I load an executable, it would be loaded under uid/gid bin with read only access. Therefore the program cannot be altering itself. If it tries, too bad, I don't need any software package that badly. If it is going around mucking about in any file not supplied as part of the software package, no self-respecting system administrator will want it installed on his system. |> -- |> Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 |> public source archive [HST V.42bis]: |> scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp |> uucp scuzzy!/src/README /your/home Scott Lurndal UNISYS
wolfgang@wsrcc.com (Wolfgang S. Rupprecht) (12/17/90)
scott@convergent.com (Scott Lurndal) writes: >If I load an executable, it would be loaded under uid/gid bin with >read only access. Therefore the program cannot be altering itself. >If it tries, too bad, I don't need any software package that badly. > >If it is going around mucking about in any file not supplied as part >of the software package, no self-respecting system administrator will >want it installed on his system. Oh it gets worse than that... I have seen packages for CAD design that want one to recompile vmunix to include some "special" license enforcing *object* code from that company. Yea, right. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) uunet!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
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!"