Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!sol.ctr.columbia.edu!cica!iuvax!maytag!watmath!arpepper From: arpepper@watmath.waterloo.edu (Adrian Pepper) Newsgroups: comp.sys.cbm Subject: Re: Super Snap Shot Cart Detection?? Message-ID: <1990Sep25.221627.8844@watmath.waterloo.edu> Date: 25 Sep 90 22:16:27 GMT References: <418@news.nd.edu> <1990Sep15.171530.12692@xenitec.on.ca> < <436@news.nd.edu> > <438@news.nd.edu> <+VJ%*-+@rpi.edu> <1990Sep24.162347.24968@jarvis.csri.toronto.edu> <449@news.nd.edu> Organization: University of Waterloo Lines: 30 In article <449@news.nd.edu> treesh@darwin.helios.nd.edu writes: > >I have heard rumors of really killer copy protection routines thaat use >the video chip as a sync rigistar. If a program is Snapshotted and then >loaded, the video chip's timming will be off from the programs internal >time keeping routines, and thus the copy is detected. I have never seen >code that could really pull this off, but I have heard about it being done. I must say that simple minds such as mine do wonder about how snapshot cartridges manage to restore the values of write-only registers. I suppose some of the signals must be readable indirectly somewhere, somehow. I have heard that some programs when snapshooten take a while to regain their proper sound. Of course, if true write-only registers are used for timing, or such, it won't be necessary to detect the copying; the program could merely be allowed to continue to function badly as the write-only values are assumed and not refreshed. The problem with this could be that part of the potential consumer market may end up evaluating the product based on the "snapshotted" version, rather than a legitimate version. In short, it's probably better to arrange to detect a certain means of copying if you aim to detect it, so that you can make sure the copy fails in a convincing fashion. I'm not sure if this is a commonly practised principle of copy-detection, or not. >Any comments welcome! So I did. Adrian.