Preventing date rollback

[Scott Lurndal]

In article <1990Dec11.125711.1468 at scuzzy.in-berlin.de>, src at scuzzy.in-berlin.de (Heiko Blume)
writes:
|> boyd at necisa.ho.necisa.oz (Boyd Roberts) writes:
|> 
|> >In article <rcosj.660348537 at chudich> rcosj at 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 at 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